Raspberry Piをいくつか運用していてよくSDCardが壊れるなと思ってより耐性の高いカードを買わないとと思っていたら、SDカードに書き込まずに運用するということが広く行われているということを発見してトライ。Docker対応する方法は簡単には見つからなかったので試行錯誤した。
以下作業メモ
普通にセットアップ(事前に/boot/ssh, /boot/wpa_supplicant.conf を作成)
raspi-configでpassword, hostname, timezoneの設定
tmux, emacsをインストール
watchdogの設定 (1)
readonly modeにする基本設定 (2)
外部ディスクの追加
# /etc/fstab PARTUUID=abc-def /media/foobar ext4 defaults,auto,users,rw,nofail,x-systemd.device-timeout=5 0 0 PARTUUIDはblkidで確認。
この辺りまでは既にやり方がネットに書かれていたのでそれに従っただけ。
containerdのファイルを外部ディスクに移動
mv /var/lib/containerd /media/foobar ln -s /media/foobar/containerd /var/lib dockerの作業フォルダも外部ディスクに
# /lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd --data-root /media/foorbar/docker --containerd=/run/containerd/containerd.sock 時刻の設定 NTPは時間が違いすぎるとうまく動かないので、起動スクリプトの中でntpdateを呼ぶようにした。 ただし、まだhostname serviceが動いていないのでipで指定する必要がある(変わったらまずい)
# /usr/lib/ntp/ntp-systemd-wrapper ntpdate 133.243.238.244 もちろんexternal driveが壊れる可能性もあるけど、docker-composeのファイルとかがSDCardにあればすぐに再構築できるのであまり問題はなさそう。
Twitterで分けて書くとちょっと見づらい長さを書きたい時にどこに書いたものかと考えて、日記の存在を思い出しました。
今回は数年ぶりの参加で、@riesz先生と一緒にMox Camlというチーム名で出ました。@riesz先生による記述はこちら。
前日の夜遅くにPNGを解析して”Lambda The Gathering”であることを知るも、”Lambda”よりも”The Gathering”に引っ張られてギャザリングのルールを教えてもらったりしていました。カードを何枚手元に置けるとか。。。ここで”Lambda”の方を学んでおけばもうちょっとマシな結果だったかもしれないです。
当日朝起きて、問題を読みながら移動。合流して問題の内容を確認。ギャザリングについて調べつつチーム名を決めました。（Mox RubyとかMox Pearlとかいう強いカードがあるらしいです）
シミュレータはどうみても関数型言語で書くべきだろうということで、OCamlで書くことにしました。OCamlは私が全然書けないという問題はありましたが、昔exampleプログラムとかは書いたことあるはずなので採用。シミュレータに全ステートを出力させて、C++のルーチンで手を考えるという可能性も検討しましたが、自由度が下がりそうなので避けました。
夕方ころ、match構文や再起の使い方を学んでいる時点で、@riesz先生がシミュレータを完成させました。このシミュレータの完成度は高く、後に2箇所小さな修正が入るものの、他は完全に動作していました。初日の夕方にこのレベルのものがあったのは大きなアドバンテージだったと思います。
その後どういう抽象度で思考ルーチンを書くかという議論をしました。各ステートに置いて、複数の取り得る手から最善の手を取るという観点から、後に評価関数を作れるような仕組みにすることや、ある程度大きなまとまり(attack(i, j))のブロックでプログラムを構成し、一度決めた動作は必ず実行するという仕組みにすることなどを検討しました。議論の末、相手の攻撃などで状態が常に変わり続けることを考え、ステートレスに毎回状況を判断して最善のことをするという構成にしました。
Exampleをきちんと見ていなかったため、attackやhelpなどの使い方が分からず、いろいろいじってみたりGoogle先生をフル活用したりして、なんとか使い方を「発見」していました。それをステートレスを前提としたコードにある程度見やすく書く方法を模索したりして、この日は終了。
2日目は「いろいろな機能を追加する日」であると信じて始まり、必要に応じてHelpを実行したりする機能の追加などをしていました。Invalidでの負けが多かったので、HelpやAttackの構築途中や発行時点で引数の値を確認する仕組みを作ったりなど。この時点ではまだ繰り返しが実現することを知らず、「くり返しとかはできないようにルールを作ってあるんじゃないかな」とか今考えればとんでもないことを言っていました。ルールを読み直していた@riesz先生がApplication Limitについて書かれていることを発見し、もしかしてループが可能なのではないかという説が再び浮上し、SKIをひたすら捏ねくり回した末に（まだ親切なExampleの存在を知らず）ループが構成可能なことを発見して驚いていました。
2日目未明〜3日目は、@riesz先生はループによるHelp爆弾を作り、その後も新たな兵器の開発に注力していました。その間にぼくは新たに得られた「殺されて爆弾を埋め込まれたらおしまい」という知見を元に「殺されない」ようにする努力をしていました。敵が構成中のAttackを読みだしてスロットが死ぬ危険があれば早急にHelpの用意をはじめるといった仕組みや、ステートレスの利点を生かしてHelpやAttackの対象を柔軟に変更しつつも、行動の変化によって構築途中の式が無駄になりにくい仕組みを作っていました。
最終的に出来上がったものは、8割方勝つくらいのものでした。調子がよければExcellentですが、そうでなければ普通に戦って勝ちます。負ける時も、Excellentで負けたり、戦って競り負けたり。
もうちょっと早い段階からSKIで何が出来るのか真剣に考えていれば、もうちょっといい結果が出せたかもしれないです。問題文は隅々までよく読みましょうということですね。あとは、2人チームというのは中途半端だったかもしれないです。2人しかいなくてもコード共有や他人のコードを理解する作業などの手間はかかるので。プログラムが小さいうちは「パッチができあがった頃にはプログラムの構造が変わっていて全部書き直し」みたいなことが結構ありました。普通ならシミュレータ係とAI係みたいに分けるところが、@riesz先生が一瞬でシミュレータを作ってしまった一方ぼくはOCamlの文法を調べていために分担などなくなったというのも原因だと思いますが。
学んだこと：
・問題文はよく読みましょう。
・モジュール分けとか、コードの管理をどうするかとか大切。
・学校の授業はちゃんと聞いておきましょう。SKIコンビネータとか聞いたことはあったのに。
・関数型言語１つくらいちゃんと使えるようにしておいても悪くない。
とても教育的な問題でした（少なくともぼくにとっては）。計算理論についてもですし、関数型プログラミング言語についても勉強になりました。何日も1つの事に集中する経験ができて、久しぶりに関数の世界に触れられて、楽しかったです。すばらしい問題を作っていただいた運営者様と、足手まとい感満載のぼくに付き合ってくれた@riesz先生に感謝感謝です。
では、おやすみなさい。
なんかここ2,3日で立て続けに指摘されたので。
はい。mixi日記はボットでスキャンしてます。
別に毎日毎日なんどもみなさまの日記を見に行っているわけじゃないです。ごめんなさい。
具体的には、Plaggerでmixiの日記をとってきて、RSSにしてGoogle Readerで読んでます。快適。もっといい方法あったらぜひ教えてください！
Google App Engineとか使ってみようと思って試しているうちに、ふとevalが使えるか試したところ使えたので、MapReduceをGAEでやってみました。完全におもちゃですが、何かできそうってことは伝わるかと。
デモサイトはこちら：http://gae-mr.appspot.com/ (無尽蔵に使われるとまずいので、GMailアカウントでログインするようにしてあります。ログインに本質的な意味はありません。)
コードはこちら：http://github.com/ohkura/gae-mapreduce/
※ gitとかgithubとか使ってみたいと思っていたので使えてよかった。
Subversionが安定して動くようになって以来、バージョン管理システムの動向は気にしていなかったのだけど、最近分散型バージョン管理システムが熱いらしいのでちょっと調べてみた。
なんか比較説明を見ていたら、Mercurialがいちばんよさげ。Haskellで動いているdarcsとか格好いいんだけど常用するツールとしてどうかと問われるとちょっと引かざるを得ない。ちゃんとした理由があるわけじゃないけど；
というわけで、Mercurial使ってみました。使い方は簡単で、インストールの後バージョン管理下に置きたいディレクトリで
$ hg init $ hg add $ hg commit
と打つだけ。subversionみたいにサーバでリポジトリを作ったり云々は必要ない。
分散して動作する云々より前に、別の場所へのバックアップをあえて作る必要がないようなちょっとした時に簡単にバージョン管理ができるのがとってもありがたい。リポジトリがローカルにあるからネットワークにつながっているか否かも気にする必要ないし。
しばらく使ってみようと思う。
はてなスターとかいうのがちょっと面白いかもしれないと思ってつけてみた。「へぇ」ボタンみたいなものだと思います。日記のタイトルのちょっと右をクリックすると☆がつく。
自分の領域であるはずの、自分の日記に勝手についたひとたちの中には怒っている人もいるようです。そりゃそうでしょう。でもその逆の側面、はてなダイアリー以外のサービスでも使える形で提供されているというのは、いいことだと思います。mixiのように一部の機能だけでも使いたければ全機能使え、というのではなく一部の機能だけでも使わせるっていうのはサービスの方針として好きかな。
WordPressで構築されているブログに追加するには、ヘッダに下のコードを追加するだけ。
<script type="text/javascript" src="http://s.hatena.ne.jp/js/HatenaStar.js"></script> <script type="text/javascript"> Hatena.Star.Token = 'http://s.hatena.ne.jp/で発行されるトークン'; </script> <script type="text/javascript" src="http://s.
入れてみました。（unnoがプレッシャーをかけてきたからw）
インストーラとか、アイコンのデザインとかは新しい雰囲気の部分の中にまだ古い雰囲気の部分が残っていて、まだまだベータという印象。いままでなかったアイコンはきれいな新しい感じのアイコンだけど、OutlookExpressやネットワークといった以前からあるアイコンは古臭いまま。この辺は製品版では置き換わるだろうからまぁ別にいいだろう。
OSXを知っている人ならば、「一般的に見てWindowsのアイコンよりもMacのアイコンのほうがきれい」ということに同意してもらえると思うが、Microsoftはこの点をVistaで改善しようとしているように見える。きれいにしたい意図は感じられる。けど、やっぱり使いやすい色使いときれいな色使いというのは同じではないわけでそのあたりで苦慮しているような気がする。（個人的にはOSXは利便性よりもデザインを優先していると思っている）
インストールして、ログインしてみてまず思ったのは、「いろいろ変わってる」という点。コントロールパネルの各要素へのアクセス方法とか。なんとかセンターというのがたくさんあって、整理の仕方が変わっている。
もしかしたら、新しいユーザーにはこちらのインターフェースがいいのかもしれないが、多くの人が一度はWindowsPCを使ったことがあるであろう現状で、アクセス方法をいろいろ変えるのが適切かどうかは疑問に思う。ウィンドウの一番上にタイトルバーがあって、メニューが次に・・・という配置も柔軟に変える気でいるようで、「一般的なWindowsアプリならば使い方は一目瞭然」という形から離れていっているように思える。
オブジェクトが階層構造に配置されているという「整頓されているから探しやすい」というアプローチは完全に捨て去られたように見える。それよりも、「やりたいことをめざして適当にたどっていくといくつものパスから目的にたどり着ける」アプローチのようだ。このアプローチの転換は、MacOSの漢字Talk7だか8だかあたりに、同じフォルダを複数のウィンドウで開けるようになった時点から始まったと個人的には認識しているのだが、最近のWeb検索の普及に伴ってこのアプローチの転換が加速しているようだ。
※Web検索は完全に後者のアプローチ
さて、評価したいところ。フォントがとても見やすくなった。これは、ディスプレイドライバを入れてちゃんと表示された瞬間に改善に気づく。なんとなく文字のバランスが変だと思うことがあるのと、「み」の形に違和感があるような気もするが、全体としてはかなり見やすい気がする。英字と全角文字のバランスが取れている状態になったが、これは長年英字は横幅が小さい状態で使ってきたせいか、かなり違和感がある。これは慣れの問題だと思われるので、使い続けていれば気にならなくなるのかもしれない。
もう一点評価したいところは、ドライバがWindows Updateで導入できそうだという点。この機能はWindows Updateがはじまった時点から「ドライバも自動でアップデート」の試みはあったが、現実的にはほとんどのドライバはWindows Updateでは提供されてこなかった。今回、標準添付されていなかったx無線LANやパワーマネージメントのドライバをWindows Update経由で導入できた。このままうまく進んでくれれば、ドライバを簡単にアップデートできるようになるかもしれない。
OSXでは管理者権限が必要な部分で管理者パスワードを入力するダイアログが表示される。Vistaではより頻繁に（印象だけど・・・）これに類似のダイアログが表示される（ただし、確認ボタンを押すだけ）。
全体としてみて、確かに変わった。ただ、WindowsXPが出て5年経っていて、「これが５年分の進歩」といわれると、かなり寂しい気がする。まだ細かくは見ていないが、どの機能も2001年時点では想像できなかったというようなものではなく、今までサードパーティ製のソフトウェアで実現されていたものをOSに標準搭載したに過ぎないように見える。フラッシュメモリをディスクキャッシュで使う機能などは興味深いが、５年間というのはムーアの法則に従えば１０倍以上の進歩が各方面であるはずだし、この５年のネットでの動きを考えれば、Vistaでの進歩がこれだけというのは残念に思う。
しばらくこの日記が見えませんでした。
でも誰も見ていないだろうから、誰も困りませんね。人気サイトじゃなくてよかった(笑
しばらく前から、自宅サーバーの電源が入らなくなった。
で、今日開けて、怪しそうな部品を１つ１つ見ていったら、どうも電源が悪いらしい。
で、電源の構造なんてどうせ単純だろうと思って、分解して、ホコリとかをとって、見てみたら
ヒューズが飛んでた。ヒューズがハンダで直づけされていたから、ヒューズの交換は諦め。
で、電源を友人から借りてくるというのも手だけど、しばらく前に買ったもののDebianを入れて遊んでみたくらいにしか役に立っていないVMWareを活用することに。
HDDをメインマシンの空きスロットに挿して、起動・・・できない。
差し込んだHDDはIDEのもの。でも、メインマシンはSATA。で、IDEがSATAよりも優先されるのは決まっていることらしく（BIOSで設定変更できない）、どうしようもない。
が、ふと思い出した。NT系のWindowsは、BIOSのデバイス情報を利用しないのでは？
ということで、BIOSでIDEを全てNoneと認識させて、SATAからブート。Windowsはデバイスを再スキャンするからIDEのHDDも認識。
で、それをVMWare上で起動。と・・・こっちはいとも簡単に動作。
というわけで、サーバー復旧しました。
よかったよかった。
VMWareはCPUはほとんどホストマシンそのままの速度が出るから、Pen3 500MHz -> Athlon64 3000+になって、だいぶ反応が良くなった。メモリも問題なし。サーバーのディスクアクセスが増えても、メインマシンのメインHDDとは別だから問題なし。
と・・・いいことづくめ。
だけど、月刊Windowsパッチの際に、Linuxサーバーなのに再起動させられるという問題が・・・