_ The Goog Life：グーグルが従業員を子供扱いすることでつなぎとめている件

ふーん、やっぱりGoogle File Systemは不安定なのか。 あれだけのシステムを安定化させるのは至難の技だろうと推測していたけど、 Googleの技術陣でも難しいことはやはり難しいらしい。 ユーザに見えるような障害をほとんど起こしていないのは大したものではあるが。

ところで、yomoyomoさんの翻訳はうまいなあ。 shiroさんもすごいけれど、 一体どうやったら、このレベルになれるんだろう。

_ Windows screwup forces Ubuntu shift

PromiseのRAIDカード挿したらWindowsが認識できなくって、 付属CDだとレスキューもできなくって、 XPのCD新品を買い直すしか選択肢がなかったので、 結局Ubuntuに移行してしまいました、というお話。 アクティベーションとか、 違法コピーの取締りには効果あるのかもしれないけれど、 これじゃ逆効果だよなあ。 Microsoftは自分で自分の首を絞めている感が。

そもそも、Windowsの圧倒的優位性は「とりあえず買ったら付いているから」という、 異常に単純な理由が最大だ。 んなこたーない、ソフトウェアの機能が... 互換性が... などと思う人は間違っている。 なぜなら、ほとんどの人はロクにコンピュータを使ってないからだ。 メール読んで、ウェブを徘徊して、たまにちっぽけな文書を印刷する程度の、 そういう大多数の人間にとって、いまどきのOSに大差はない。 そういう人々が敢えてWindowsでないものを試してみようかと考え始めるのは、 唯一Windowsが動いてくれない時だけである。 だから、Microsoftがやらなければならないのは、 Windowsがそれなりに動くことを保証することだ。 そして、それをやっている限り、ちょっとやそっとで現在の優位性が揺らぐことはない。

もちろん、最初に付属していなかったカードを付けてやろうなんて人なんだから、 そういう「普通の人」でないことは明らかだ、 この話では。 でも、少し慣れた人が何となく、ちょっぴり弄ってみようかと、 変な好奇心を示し始める機会はしばしばあるだろう。 そして、それで動かなかったら、 Windowsから遠ざかるユーザは一定の割合で現れるだろう。 しかも、一旦他のものへの移行を味わったユーザは、 もはや「Windowsでないと」とか「デフォルトのやつで」とはあまり考えなくなってしまうことに注意。 僅かずつとはいえ、確実にユーザを逃していくことになるだろう。 だから、あんまり厳しくし過ぎるのは自殺行為だと思うわけ。

つまるところ、ライセンス・ビジネスなんてのは、 こういう矛盾を抱えながら、適当にやって行くしかないわけで、 いずれは終焉するんだろうな。 もはやライセンス料で食っていけるような企業なんて一握りしかないし、 新興企業は無料配布ソフトやオープンソース製品と真向から勝負させられるわけで、 下火になっていく傾向しか見えない。

_ The D Programming Language, Version 1.0

へー。 とりあえず開発環境の整備待ち、 とりわけ処理系が安定してくれないと。 今んところ、DMDもGDCもregression testsの結果は芳しくないから、 真面目に使うには恐すぎる。

んで、どれぐらい性能出るのかなー。 native codeが吐けます、だけじゃ意味ない。 nativeだろうがvirtualだろうが、 遅いものは遅い。 Pythonの2.3だか2.4だかの時点で、 インタープリータのオーバーヘッドは高々全体の25%程度だと聞いたことがある。 だから、インタープリットするかコンパイルするかなんてのは、 そんなに重要ではなくって、 どこまで強く最適化を施せるかが鍵なのは自明だ。 それで、現状でどれぐらい最適化をかけられて、 似たようなコードをCやC++で書いた場合と比較して、 一体どうなのよ？というのが気になるのだが、 FAQにも書いていないし、 自分で試してみる気はちょっと起きない。

それはともかくとして、 garbage collectionに関して、前々から思うところがある。 GCが便利で、プログラマがかなり楽できて、 しかも明示的にやるより速かったり、安全だったりする、 というのは分かるし、実感している。 しかし、現在のGCって、 どれもメモリに関するファクタしか考えていない気がするんだけど、 私が無知なだけなのだろうか。

プログラムで使用するリソースにはいろんなものがある。 メモリは代表例だが、例えば、file descriptorsはどうなるのか。 システム中、あるいは、単一のプロセスが一度に開いておけるファイル数は限定されている。 この値はメモリとは直接関係がない。 しかし、openしてコケた時、ファイル数が多すぎて失敗した場合、 GCして、閉じられるファイルは閉じる、なんてことはなされるのだろうか。 私の知っている範囲ではこういうことをやっている処理系はない。

要するに、こういう例を考えてほしい。

class Foo(object):
  def __init__(self, path):
    self.f = open(path)

  def __del__(self):
    self.f.close()

Pythonで書いたが、同じような例は他の言語でもあり得るだろう。 つまり、初期化されると、ファイルを開く。 ファイルのオブジェクトはインスタンスに保持される。 明示的に閉じず、このインスタンスが回収されるタイミングで、 そのファイル・オブジェクトを閉じる。 実際にはcloseなんか明示的に呼ばなくてもPythonだと勝手にやってくれるんだけれど、 ここでは分かり易くするために書いておいた。

この場合、GCがこのインスタンスを回収しに来るまで、 ファイルが不要に開きっ放しになる。 しかしGCがメモリ残量の圧迫をキューにして起動される限り、 file descriptorsが足りないという問題は解決されない。 なぜなら、file descriptorsが足らなくても、 メモリも足りないとは言えないからだ。

現時点でみんなどうしているかと言うと、 こういうリソースは明示的に解放しているのである。 つまり、

  def close(self):
    f = getattr(self, 'f', None)
    if f is not None:
      f.close()
      del self.f

みたいなメソッドを追加して、陽にリソース解放手続きを取るわけ。

でも、これって、ダサダサだと思う。 だって、GCはリソースの明示的管理を極力減らすためにあるわけで、 メモリじゃないというだけの理由で、 結局原始的手動管理に先祖返りしなきゃいけないなんて、 中途半端ではないか。

私はこれが理由で、リソースを馬鹿喰いしそうなプログラムで、 GCを使うことに相当抵抗がある。 明示的なのと暗黙的なのが変に混じっているぐらいなら、 全部明示的な方が却ってやりやすかったりするからだ。 もっとも、Cだとconservative GCしかないから、 余計に心配になるというのもあるかもしれないが...