「Operating Systems Design and Implementation」（MINIX本）を大体よんだ

Operating Systems Design and Implementation (Prentice Hall Software Series)

Operating Systems Design and Implementation (Prentice Hall Software Series)

途中からコードを丁寧に追うのは諦めたので「大体」．

敷居が高いというイメージがあったが実は文章自体は結構軽いノリの本である．

まともなOSの本というとLions本とか，和書なら，はじめて本とかが挙げられると思うが，MINIX本はある程度x86に則した話もあり，全般的な話もありという感じで，現代のコンピュータでOSを説明するという意味ではかなり良い本だと思う（xv6本（本？）とかはどうなんだろう）．他の本と比べあまり流行ってなさそうなのはなんでなんだろう．あとほんとうの意味でのマイクロカーネル．

「理科系の作文技術」を読んだ

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

有名な本。最近、ビットコインの仕組みなどを書いている関係で、文章の書き方について考える事が多いので、この手の本を何冊か読んでいる。読みかけではあるが、他に読んでいる本としてはOn Writing Well, 30th Anniversary Edition: The Classic Guide to Writing Nonfictionがある。こちらも有名な本であるようだ。

On Writing Wellはエッセイなどに焦点を当てた本なので、推奨する書き方が異なるのも仕方のない面はあるが、対比させて読むとそれなりに面白い。洋書の側では「英語は曖昧な言語である」と言っていて、他方、和書の側では「英語は日本語と比べ論理的で簡潔な言語である」と言っている点が象徴的だ。

また、On Writing Wellで使わないほうがよい記号とされている「；」「：」を、理科系の作文技術では日本語に導入しようとしている点も興味深い。On Writing Wellでは「；」は「―（ダッシュ）」で代用することを勧め、「：」は列挙以外には使うなと書いてある。「受動態を日本語において多様しがちなのは英語の影響」（理科系の作文技術）というのは理科系作文においてはそうなのかもしれないが、他を基準とすると違和感を感じる記述である。

英語的な理科系の文章は、不慣れな読者にとっては読みづらく感じられる事がある。そういったこともあって、当初、ビットコインの仕組みではあまりパラグラフ・ライティングを全面に押し出していなかった。しかし実際にはある程度理科系の書物に慣れ親しんでいる人しか読まないような気もするので、スタイルについては見直したいと思っている。

ハノイの塔をHaskellで書いた

さっきまで理解してなかったので書いてみた。Wikipediaの書き方もわかりづらいし検索上位にわりと酷いのばっかりひっかかるんですがそれは…

import Debug.Trace

moveAtoC :: ([Int], [Int], [Int]) -> ([Int], [Int], [Int])
moveAtoC ((a:as), bs, cs) = (as, bs, a:cs)

solveHanoi n = solveHanoi' n ([1..n], [], [])

solveHanoi' :: Int -> ([Int], [Int], [Int]) -> ([Int], [Int], [Int])

-- Aにある円盤n個を、Bを使いながらCに移動する
solveHanoi' 1 t = moveAtoC t
solveHanoi' n (as, bs, cs) = (as''', bs''', cs''')
  where (as'  , cs'  , bs'  ) = solveHanoi' (n - 1) (as, cs, bs)
        (as'' , bs'' , cs'' ) = moveAtoC (as', bs', cs')
        (bs''', as''', cs''') = solveHanoi' (n - 1) (bs'', as'', cs'')

A → Bに一番下を除いて移動させて、一番下をA→Cに移動させた上で、B→Cの移動をする。これを再帰的に定義する。
コードに落とす時は、棒を入れ替えたとして考えるのがポイントらしい。

VagrantをParallelsで使う

ここ最近ずっとParallels上のUbuntuで物を作っていたが、冷静に考えるとVagrantを使うべきだったという事に気がついたのでVagrantを使うことにした。

1. Vagrant公式から落としてきて入れる

OSX版をVagrant公式のDownloadからインストーラーを落としてきて入れる。Homebrewやgemsのようなもので入れるとよくないようだ。

1. Parallels用プラグインを入れる

Vagrantでは仮想環境の各ソフトウエアをProviderと言う。デフォルトはVirtualBoxだがParallelsを持っているのでこちらを使いたい。そこで、Parallels用のプラグインを入れる。
Parallels用プラグインはParallels自身が開発しており安心である。

vagrant plugin install vagrant-parallels

2. boxを入れる

Vagrantでは仮想環境のベースイメージをboxと言う。

これまた、parallelsが公式にそれ用のboxを公開してくれている。

入れ方は簡単である。

vagrant box add parallels/ubuntu-14.04

3. Vagrantfileを作る

vagrant init parallels/ubuntu-14.04
vim Vagrantfile

4. vagrant up!!!!

vagrant up --provider=parallels

以降の操作では--provider=parallelsはいらない。

Parallelsのウインドウが開いたりして多少うざいが、ParallelsのウインドウはFn+F6で全て隠すことができるので覚えておくとよいだろう。

あとは、vagrant sshでsshでつなげて、/vagrantにVagrantfileのあるディレクトリのファイルが見え、vagrant haltで終了、vagrant destroyで仮想マシンを処分とかそんな感じである。

最初vagrant sshが効かなかったがvagrant haltしてもっかいvagrant upしたらなおった。

今後の参考資料

最近覚えたことだが、日本語のしょうもないブログ記事などを読むより公式のドキュメントを読んだほうがよい。

このようなブログ記事を読まずに公式のドキュメントを読みましょう。（オチ）

Docker、CoreOS、Google Compute Engine：やめたほうがいい事 ６連発

最近、Docker・Google Compute Engineで分散3Dレイトレーシングといった物のネットワークまわりをいじらせてもらっている。

lighttransport/francine

ところで、DockerもCoreOSもGoogle Compute Engineも全然枯れていないだけに、やってはいけないとは書いてないにも関わらず、うっかりやろうとすると本当に面倒くさい事態に陥る事柄が非常に多い。そういった訳で、この記事では、自分でうっかりやってひどい目にあったパターンをいくつかご紹介したいと思う。何かの参考にしていただければ幸いである。

Dockerでexport / importしてはいけない

Dockerの公式ドキュメントには、当然できる事のような顔をして、Docker containerをexportしてtar.gzにし、それを再びimportするといった手順が示されている。
しかし、例えば手元であるDocker Containerをexportして他のマシンでimportするとこんなひどい怒られ方をする。

$ sudo docker import - peryaudo/hogehoge < peryaudo_hogehoge.tar.gz
2014/05/05 23:42:15 write unix /var/run/docker.sock: broken pipe

このエラーが出る基準はよく分からない。最初はサイズかと思ったが、tarを展開する時に怒られているようだ？

ともかく、やめたほうがいい。素直に、private repositoryを立てよう。

CoreOSをGoogle Compute Engineのデフォルトのディスクサイズのまま使ってはいけない

さて、private repositoryを立ててコンテナをやりとりしよう。
だが、ここで問題がある。Google Compute Engineのデフォルトのディスクサイズは6GB（gcutilコマンド）、10GB（REST API経由）と比較的小さい。
Dockerはtar.gzに落とし込んだコンテナより差分を全部含むコンテナのほうが圧倒的にでかいので、private repositoryでコンテナをやり取りするなどしているとあっという間にこの程度の容量は使い切ってしまう。

gcutilであれば--boot_disk_size_gbなどでサイズをでかくして使おう。CoreOSであれば、ここでディスクサイズを大きくするだけで、自動でパーティションをリサイズしてくれる。

Buildroot製コンテナ内などで、複数のディストリビューションでビルドしたバイナリを実行してはいけない

Buildrootを使うと、極めて小さいサイズのDocker Containerを作成する事ができる。大規模環境でデプロイするに当たってはこれは嬉しい事だ。
しかし、リンクされているlibcによって細かい詳細が違うため、他でコンパイルしたバイナリをそのまま実行すると怒られるので、LD_LIBRARY_PATHなどで、コンパイルした環境と一致するlibcなどのsoファイルを入れておく必要がある。
しかし、ここで、複数のディストリビューションでビルドしたバイナリなどを同居させると、もうにっちもさっちもいかなくなる。

こんな時の対処法として、どうしても他の人がビルドしたバイナリと自分のビルドするバイナリを同居させる必要があり、かつ自分が今のディストリビューションを使い続けたい時、どうすればいいだろうか。もちろん、答えはDockerである。

francineではworkerコンテナのビルドに、「workerコンテナをビルドするためのコンテナ」を作ることで対処している。

CoreOSが勝手に再起動しないと思ってはいけない

CoreOSは独特のセキュリティへのこだわりを持ったOSだが、その特徴の１つとして、完全に自動でOSを最新版にアップデートしてくれるという点がある。

しかしこれはすなわち知らない間に勝手にOSがリブートするという事である。

セットアップスクリプトなどを書く時は、あらかじめこの事を頭に入れた上で書く必要がある。

また、この時、デフォルトではCoreOSは、前回終了時に起動していたコンテナは起動してくれない。これはsystemdでサービス管理をしろという意味なので、下手な事をしないで素直にcloud-config.yamlにsystemdの設定を書こう。Google Compute Engineはインスタンス作成時に、metadataとしてcloud-config.yamlを渡すことができる。

gcutil addinstanceでcloud-config.yamlを使ってインスタンスを立て、直後にgcutil sshで繋いではいけない

cloud-config.yamlは、CloudInit由来のYAML形式による設定ファイルをCoreOSが模倣したもので、完全ではないがCloudInitと同様の設定を使うことができる。
これにより各インスタンスの設定を楽に行うことができるが、これを渡してインスタンスを立ち上げた直後にgcutil sshで繋ごうとすると存在しないパスワードを聞いてくるような謎挙動があるのでやめよう。
といってもcloud-configを使わない訳にもいかないのでうまくワークアラウンドしましょう。
追記(5/12)：ゾーンによって再現度に差があるようだ。

Dockerで同じコンテナ内のプロセスのポートをホストにマップして繋いではいけない

同じコンテナ内にあるプログラムは、仮にホストにポートをマップしていてかつホストを経由しても、繋ぐことはできない。
観念してコンテナを分けよう。

（おまけ 5/12）fleetについて

ドキュメントの「アーキテクチャ」の項目に書いてある事で、現状できない事が存在していて、まだ未熟な印象を受けるし、今回の用途（死んだインスタンスには勝手に生き返ってほしくないしインスタンスとジョブを固定したい）の場合にfleetを使ってもあまり便利にならないと踏んだので現状francineではfleetは使っていない。

Google Compute EngineでCoreOSでDockerみたいなの

  • 疑問
    • fleetでDocker containerを立ち上げるとして、どうやってdocker imageをcluster間でshareするのが普通か?
    • fleetでDocker containerを立ち上げるとして、docker imageのアップデートはどうするのか
      • そういった方法はまだ確立されていないっぽい
    • 全体的にどの程度fleetが柔軟かがよく分からない
      • 今後柔軟になる可能性はあるが、現状はまだまだ

『クルーグマン ミクロ経済学』を読んだ

クルーグマン ミクロ経済学

クルーグマン ミクロ経済学

いろいろ思うところがあって経済学について基礎的な事を知っておくべきだと思ったので、まず手始めにクルーグマンのミクロ経済学を読んだ。Bitcoinについて延々と調べていたら興味がこっちまで伸びてきたというのもある。

元々経済学にはかなり興味があって、理工学部情報工学科以外のどこかを進学先に選べと言われたら理工学部の他学科よりは経済学部を選びたかったくらいだが、長らく、個人的な興味関心と実際の知識が見合ってない感じだったので、これをきっかけに少しずつ解消していきたい。

基礎の部分に限って、経済学の教科書で扱われるような知識は正直どこからが一般常識なのか分からない面が（少なくとも情報分野の知識とかと比較すると）あると思う。しかし、基本をおさえないまま一般常識のみで物事を考えている時、自分がいかに実社会での問題を表面的に捉えていたかを実感した。

また、去年も経済学の一般教養科目を2科目ぐらい取ったりしていたが、基礎的な事が分かってない状態で話を聞くと、何が逆説的な話で何が一般論に沿った話なのかがさっぱり分からないまま（例：先進国における農業は成長産業だ）ずっと話を聞き続けるハメになるという事がよく分かった。

分量の割には1年生の物理ABCDの教科書と比べると全然読みやすいし経済系に興味のある理工学部生はどうぞ。