書籍「ソフトを他人に作らせる日本、自分で作る米国」を読んでいたところ、元日本IBMの方によるタイトルの発言が飛び出した。この業界に長くいると、仮想記憶に仮想計算機と「仮想」という訳語にはまったく違和感を感じなくなってしまったが。。。曰く、IBMがVirtual memoryを発表したとき（MVSのことかな*1）、日本IBMが仮想記憶と訳したのだそうな。『virtualは「事実上の」「実質的」という意味であり、virtual memoryは「本来のメモリーではないが事実上メモリーとして使える技術」を意味する。』 大学時代の恩師も次のように言っていた。 「仮想」という概念が、コンピュータの世界に入ったのは、１９７５１９６５年のことである。MITがMULTICSという汎用大型TSSの構想を発表した。これが現在の、パソコンネットワーク時代の幕開けの狼煙であった。この中の技術に「仮想記憶」の概念が含
そろそろ「OpenFlow実践入門」についてステマしないといけないのではと思ったので書いてみる。OpenFlowに関して日本語で書かれた書籍はまだ2冊しか出ていないと思うけど、OpenFlowに興味あるならまずはこれを買っておけと。 OpenFlow本と言いつつ、実質はTrema本である。TremaはRubyで書かれたOpenFlowコントローラフレームワークなので、Rubyに愛のない人は厳しいだけど、Rubyを知らなくてもその都度Rubyの文法に関する補足がなされているので、最後まで読み通すことができる。Trema Dayでも、「Python版Tremaはどうなった？」という話が出てきたが、Pythonで再実装するぐらいなら、Rubyを覚えた方が早い。Python使いならRyuという選択肢もある。 高宮さんの巻頭言に感動しながら読み進めていくと、最初に出てくるhello-trema.rb
前回、割込みの起源について触れたけど、もう少し深掘りしてみたいと思ったら、たまたま読んでいた高橋秀俊氏の伝記にPC-2の割込みの話が出てきたので、紹介しようと思う。 同氏は計算機屋からは計算機のパイオニアの一人だが、「物理の散歩道」シリーズで知られるロゲルギストの一人として記憶している人も多いだろう。計算機関係の業績としては、やはりパラメトロン計算機である。後藤英一氏の発明したパラメトロン素子を利用し、計算機PC-1、PC-2を開発した。当時の計算機屋ならば全員が読み、感銘を受けたというウィルクスの「The Preparation of Programs for an Electronic Digital Computer」を参考に、これらの計算機の命令セットはEDSACをベースに設計された。PC-1上で高橋氏が一番最初に書いたプログラムというのが「世界一周」で、先日、和田英一氏がブログに
年末年始にかけてNTT DoCoMoによる3Gネットワークの障害話をよく耳にしたけど、これに関連したblog「レイヤー越えが出来ない人たち」、「レイヤバイオレーション」が面白かった。システムは階層化されており、各人（組織）が得意とする階層もあるが、システムの全体最適を考えると、階層の壁を越えて考えなきゃいけないという話と、実装のことを考えると、階層を守ることはシステムの複雑さを押さえる上で重要という話。これらは完全に直交する話ではないと思うが、この手の「木を見て森を見ず」という話を聞くと、「エンド・ツー・エンドの原則とIPv6」を思い出し、また読み返してみた。言うまでもなく「End-to-end原則」はインターネットを支える設計思想である。インターネットというかARPANETの初期の頃は、TCPとIPは分離されていなかった*1。再送のようなトランスポート機能が必要かどうかはアプリに依存する
ずいぶん間が空いてしまったけど、Make:Japanの記事に取り上げられていたスペースシャトルの制御に用いられたリアルタイムプログラミング言語HAL/Sに関する電子書籍が面白かったので、これを取り上げよう。HAL/Sは当初、宇宙機汎用言語として設計されたのだが、最終的にはスペースシャトルでしか使われることはなかった。その実態はとんでもない奴だったという話。 スペースシャトルが最初に打ち上げられたのは1981年で、昨年7月の最後のフライトでHAL/Sの役割も終わった。HAL/Sはスペースシャトルに搭載された主制御計算機AP-101用に開発されたプログラミング言語である。70年代頭という時代を考えるとアセンブリって選択肢もあったのかなと思ったけど、当時から高級言語を使いたいというニーズは明確にあったようだ。また、米国の軍事・宇宙関係のプログラミング言語だとAdaがぱっと頭に浮かぶ。Adaの国際
TwitterのTLでもMulticsの話がぽちぽち出るようになったので、今日は関連する小ネタを。 UNIXで無意識で使っているls(1)コマンド。manページには"list directory contents"とか書かれているので、listの短縮形だとばかり思っていたら、Wikipediaによるとlist segmentsの略なんだそうな*1。どうもその名前の由来はMulticsにありそうだ。 セグメントとはMultics用語でファイルのこと。ただしファイルとセグメントは等価ではなく、ファイルが二次記憶を抽象化した概念であるのに対して、セグメントは二次記憶であることを隠蔽する概念である。UNIXのメモリマップドファイルに近いけど、歴史的にワンレベルストアとか呼ばれる。Multicsの世界では、UNIXのopen/closeに対する操作がなくて、セグメント名が動的リンカによって解決される
カーネルなど大規模なソースコードを検索したい場合、findとgrepを使ったり、タグジャンプを使うだろう。Eclipse使う場合とか異論はあると思うけど、今日はfindとgrepの合わせ技について調べてみた。 普段はxargsを噛ませて、 $ find . -name \*.c | xargs grep hogehogeとかやるんだけど、findの-execオプションを使った場合とどれくらい性能差があるのだろうか？ 評価環境はVMWare Fusion上のUbuntu 11.04。Linux kernel 2.6.28.10のfs以下で、まずは次の3パターンを比較してみた。3回測定してtimeの最良値を示す。おそらく対象ファイルはファイルキャッシュに載っている思う。 $ time find . -name \*.c -exec grep wait_event_interruptible {
今日はシグナルの歴史を調べてみたいと思う。シグナルというのはUNIXにおけるプロセス間通信の一手段であるが、CPUにおける例外のように、プロセスにとって非同期に発生するものなので、その実装はいろいろ面倒くさい。したがっていろいろ問題もあり、長年の改良の歴史を経て、今のシグナルの仕様に落ち着いた*1。BSDやSVR、そしてPOSIX標準になるまでのシグナルの拡張については文献が多いが、V6/V7以前は知られていないのでは。ということで、私の出番w まぁ、わかったところで喜ぶのは相当な好事家だろうが*2。 いきなりV7以前の話を始めるのも何なので、前提知識として、FreeBSD版悪魔本「4.7.1 シグナルの歴史」からちょっと長いけど引用する。 シグナルは、ユーザが暴走したプログラムを強制終了する場合など、例外的なイベントをモデルとして当初設計された。それは、汎用のプロセス間通信として使われる
libtaskが提供するコルーチン。その歴史は古く、マルチプロセス／スレッドが登場する以前の並行システムの実装によく用いられていた。例えば、Simulaとかが有名だが、スラッシュドットに次のような書き込みを見つけた。 Simula開発者Kristen Nygaard氏死去 Anonymous Coward : 2002年08月14日 12時35分 (#145858) 手元の教科書によると，当初はクラスがデータ抽象化にたいへん有効だ，ということは Nygaard と Dahl も気づいてなくて，1972年になってから Hoare が初めて指摘した (Acta informatica, 1(4), 1972)，とあります．SIMULA67 にクラスを導入した理由は，むしろコルーチンをサポートするためだったそうで． へぇ、これは知らなかった。 このコルーチンの生みの親はMelvin Conway
Lions' Commentary on UNIX読書会に参加した。いまだにLions本が大学の教科書として現役だという事実に驚いたが、読書会に集まる我々も五十歩百歩か。何はともあれ、一緒に読んだり教えたりしてくれるメンタがいれば、現代でも楽しめる一冊であることは確か。すでに読書会のメモがいくつか書かれているようだけど、@kotritさんがきっとまとめページを作ってくれるはずなので、期待！ ここでは実際にUNIX v6が動いているところを見て理解の助けにしたいということで、PDP-11シミュレータsimhでUNIX v6を動かす方法について書いてみる。 PDP-11は古いマシンではあるんだけど、愛好者が多いのでウェブ上には非常に多くの情報が公開されている。シミュレータの開発や当時のディスクやテープのアーカイブもあるし、ソースコードも公開されている。最初はsimhのSoftware Kits
いろいろ動かないなぁと探っていたんだけど、何のことはないパーティションIDをMINIXからPlan 9に変えるのを忘れていて、9loadがパーティションを見つけられなかったというオチで、結局MINIX3と同じアプローチでPlan 9をさくらVPSで動かすことができた。GrubからちゃんとチェインロードでPlan 9をブートできることを確認できたのは収穫だった。回り道したけど、今まで気にすることがなかったブート周りの仕組みがわかったので、合わせてメモを残しておく。 方法は「さくらVPSでMINIX3」とまったく同じで、スワップパーティションにddでPlan 9のディスクイメージを書き込む。fdiskでスワップパーティションのパーティションIDを0x39 (Plan 9)に変更することを忘れないように。 次のスクリーンショットがさくらVPSでPlan 9を起動したところの図。 ただしネットワー
残念ながら参加できなかったけど、3/20〜22にかけてPlan9/Sheevaplugはっかそんが開催された。（きっと個々の成果は公開されるのだと思うが）SheevaplugのSDIO、SATAドライバ周りや、YUREXドライバの移植、rioのカーソルハッキングなどが行われたようだ。直前まで本当に開催されるのかよくわからなかったけど、みんな十分な成果を出せたんじゃないのだろうか。Plan 9漬けの3日間なんて、相当貴重だよ。 私自身は玄柴にアクセスできる環境にいなかったので、リモート参加でちょっとの手間でできそうなものということで、YUREXのmBBU/secをstats(8)に表示できるようにしてみた。 まずはまったのがYUREXがVMWare FusionのゲストOSに見えないことだが、これはvmxファイルに以下の行を追加すればOKだった。詳細はA Power User's Guide
gnotはPlan 9端末のデフォルトホスト名であり、この名前は何に由来しているかと疑問に思っていたのだが、意外なところからわかった。 事の発端は、@__ciruzzo__さんからAT&Tのターミナル630を使ったことがあると聞いたことだ。630というのはRob Pikeがベル研で作ったグラフィカルターミナルBlitの後継機である。次の写真は630のカタログから拝借したものだが、赤いマウスがなんともかわいい。と思ったらボタンが日本人にはとても重すぎて使えたものではなかったそうな。 Blitの名前はグラフィックオペレーションbitblit*1に由来する。BlitはMC68000、256KB RAM、24KB ROM、800x1024のポートレート型のディスプレイとマウス、キーボードを持ち、UNIXとはRS-232Cで接続されていた*2。Blitにはmpxtermと呼ばれる小さいOSが動作し、
一般的にはLinuxを使っているいる人が多いのだろうが、9fansでRuss、Rob、Ken、Daveといった面々が今もPlan 9を使っているのかという話題が出た。答えはNo、彼らはデスクトップ環境としてMac OSを使っているようだ。例えば、Russは2台のディスプレイを用意し*1、片方はacmeをフルスクリーンで使い、もう片方はnon Plan 9アプリと9term用に使っているそうだ。ベル研出身者の間ではsamやacmeは根強い人気があるね。で、残念なことに、もう数年間「リアルな」Plan 9は使ってなくて、もっぱらPlan9portを使っているとのこと。VentiもPlan9portのものを使って運用されている。その他にたまに9vxを動かすことはあるらしい。 そもそもRussがMITに来て最初の数年間はPlan 9を使っていたけど、共同開発が困難とかで周りに合わせてFreeBSD
UNIXでは複数のプロセスが同時にファイルにアクセスできるが、自動的にはロックされないので、おそらく最後のプロセスが書き込んだ結果が結果的に残こることになる。これでは都合が悪いので（特に分散ファイルシステムや分散OSでは）、ファイルロックという仕組みが提供されている。UNIXではflockやlockf、fcntlが使われる。UNIXのファイルロックは基本的にアドバイザリロック（advisory lock）と言って、プログラムがお行儀よく書かれていることが前提になっている。一方、カーネルによって強制的にファイルアクセスを排他制御する仕組みを強制ロック（mandatory lock）と呼ぶ。 Plan 9には強制ロックを実現する仕組みとしてファイルパーミッションを拡張している。exclusive (l)ビットがそれである。 % touch a % chmod +l a % ls -l a -l
SSDで遊んだりとストレージ周りの技術にいまさら注目し始めているところだが、この分野で最近ホットな話題というとdeduplication（重複排除）、thin provisioning、SSDの導入といったあたりなんだろうか。この辺りは@w_katsuraさんの「次世代ストレージシステムを語る」とかが参考になる*1。で、来週はファイル・ストレージシステムに関する国際会議USENIX FASTが開催される。プログラムを見る限りかなり楽しげだ。Twitterでも参加されるという方がちらほら。 @w_katsuraさんが関わっているシステムはHYDRAstorというCAS（Content Addressable Storage）ベースのストレージシステムらしいのだが、FASTにはその上に高性能なファイルシステムを構築する論文が採録されていたりする。CASは90年代前半頃から研究開発が進められてき
ふと見つけた「あなたが一番好きなアルゴリズムを教えてください。また、その理由やどんな点が好きなのかも教えてください」を読んで、diffのアルゴリズムを調べてみた。2つのファイルの違いを見つけるには、共通する部分が最長になるペアを見つければよい。これはLCS (Longest Common Subsequence)問題と呼ばれる。LCS問題の最適解は動的計画法を用いて求めることができるが、計算時間、メモリ使用量ともにO(MN)になる*1。これより早く、また小メモリで実行できるようにいろいろなアルゴリズムが提案されている。 テキストを比較するdiffというUnix系のコマンドがありますが、これは実は高度に数学的なエディットグラフというアルゴリズムが使われています。 [1] E.W.Myers, "An O(ND) difference algorithm and its variations"
LP49をMacOS X（Snow Leopard）のQemuおよびVirtualbox上で動かしてみた。 Qemu まずは、Qemuのインストールから。0.10系と0.11系の違いはよくわからないが、とりあえず0.10.6を使うことにする。今回はソースからビルドした。ちなみにMacOS X用にはフロントエンドを追加したQってのがあるようだが、0.9.1ベースと古いので試さなかった。また、iQemu.appってのも見つけた。余談になるが、Plan 9はVirtualboxでは動かない（というかものすごい遅いだけかもしれないのだが。。。）がQemuは問題なかった。 $ ./configure --disable-aio --disable-kvm --disable-kqemu --disable-sdl --target-list=i386-softmmu $ make $ sudo ma
気になる話題だったので「NoSQL vs. NoKVS ライトニングディスカッション」を聞きに行ってきた。とりあえずPlan 9に近そうな話題をピックアップ。 平林さんのTokyo Cabinet|Tyrantの話から。Tokyo CabinetはBerkeley DB (bdb)の祖先でもあるdbmのモダンな実装である。dbmには先に述べたbdbを含めていろんな派生があるけど*1、オリジナルは1979年にさかのぼって、Ken Thompson氏によるものなんだね。InfernoにはLimboで書かれたdbmモジュールが標準で含まれてそうで、Plan9にはGeoff Collyer氏がUNIX V7のlibdbmを移植したものがある。 bdbはdynamic hashingなどを複雑なことをやっているけど、Tokyo Cabinetはbucket sizeを大きめに決めうちすることでその辺
Plan 9開発者がぞくぞくとGoogleに吸い込まれていき、何が出てきたかというとGoというプログラミング言語だった。TwitterでもGoに関連してPlan 9への言及が増えている。これを機にPlan 9にも興味を持ってもらえれば、これ幸い。 Goに対する私の第一印象は「Limboだなこれ」だった。誰かはLimbo++とかつぶやいてた。CSPスタイルの通信モデルはNewsqueak、Alef、Limboとずっと一貫している。2007年にもなってなぜGoogle Techtalksで20年も前の話をするんだろうと疑問に思ったけど、Goへの伏線はもう生まれていたのかもね。で、Goの構文はC/C++に近いので、Limboより取っつきがよさそう。LimboはDisというプロセスVM（バイトコードインタプリタ）上で動作する言語だったけど、Goはネイティブコードにコンパイルされる。性能はよさそう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
