2014-01-30

1/9998 = 0.0001 0002 0004 0008 0016 0032 0064 0128 0256...

\(\frac{1}{9998}\)は、4桁で2^13まで2の累乗のパターンが出現する。

\[\frac{1}{9998} = 0.0001\;0002\;0004\;0008\;0016\;0032\;0064\;0128\;0256\;0512\;1024\;2048\;4096\;8193\;6387\;\cdots\]

Hacker Newsによれば、これは以下のような理由による。

The pattern will break down once you get past 8192, which is 2^13. That means th\cdots | Hacker News

このパターンは8192を超えると破れる。つまり、このパターンはすごいことに52桁も継続するのだ(いや、正確には、52桁目で破れる。2の代わりに3となる)

これが動く理由は、\(9998 = 10^4 - 2\) だからだ。これを展開すると、

\[\frac{1}{10^n - 2} = \frac{1}{10^n} \times \frac{1}{1 - \frac{2}{10^n}} = \frac{1}{10^n} \times \left(1 + \frac{2}{10^n} + \frac{2^2}{10^{2n}} + \frac{2^3}{10^{3n}} + \cdots\right)\]

これにより、件のパターンが現れる。このパターンが破れるのは\(2^k\)がn桁を超える時だ。それが起こるのは、近似的に、

\[2^k > 10^n => k > \frac {n \log 10}{\log 2} \]

これにより、\(n = 4\) のとき、\(4 \times \frac{\log 10}{\log2} = 13.28\) となる。

---

他のパターンも階乗の展開で生成できる。

\[\frac{x}{(1 - x)^2} = x + 2x^2 + 3x^3 + 4x^4 + \cdots\]

\(x = \frac{1}{10^n}\) とすると、延々と続くのが、

\[\frac{1}{10^n} + \frac{2}{10^{2n}} + \frac{3}{10^{3n}} + \cdots\]

これはつまり、こうなる。

\[\frac{1}{998001} = 0.000\;001\;002\;003\;004\;005\;006\;007\cdots\]

---

他の分数の例では、

\[\frac{1000}{997002999} = 0.000\;001\;003\;006\;010\;015\;021\;\cdots\]

これは、展開結果が三角数[0]になる。あるいは、

\[\frac{1}{998999} = 0.000\;001\;001\;002\;003\;005\;008\;013\;021\;\cdots\]

これはFibonacci数[1]になる。

---

二乗列を得るのは難しいが、こうやれば、

\[\frac{1001000}{997002999} = 0.001\;004\;009\;016\;025\;036\;049\;\cdots\]

[0] : http://en.wikipedia.org/wiki/Triangle_number
[1] : http://en.wikipedia.org/wiki/Fibonacci_number

> The pattern will break down It doesn't actually: 4096 8193 6387 = \cdots | Hacker News

> パターンが破れるのは

実際には破綻しない。

      4096 8193 6387
    = 4096+8192
    +         1 6384
    +           …

返信: 俺もwolframの結果を見ていて気がついた。基本的に無限に続く数列が、オーバーフローしているというのは、変態的に美しい。

If you'd like to continue the pattern beyond 52 digits, just keep adding 9s to t\cdots | Hacker News

52桁以上のパターンを続けたいならば、元の分数に9を追加すれば良い。

\[\frac{1}{9999999999998} = 1.0000000000002\;0000000000004\;0000000000008\;0000000000016\;0000000000032\;0000000000064\;0000000000128\;0000000000256\;0000000000512\;0000000001024\;0000000002048\;0000000004096\;0000000008192\;0000000016384\;0000000032768\;0000000065536\;0000000131072\;00000002621440\cdots\;×\;10^-13\]

fibonacciの場合、分母の両側に9を付け加えればよい。

\[\frac{1}{998999} \frac{1}{99989999} \frac{1}{9999899999}\]

これによって、0が増え、オーバーフローを防げる。

これはかっこいい。

追記:

平田朋義さんが3乗列を作ってくれた。

\[\frac{333466670000}{3332000199986667} = 0.0001\;0008\;0027\;0064\;0125\;0216\;0343\;0512\;0729\;1000\;\cdots\]

平田さんによる証明は、こんな感じのものがホワイトボードに書かれていた。

\[\frac{1}{10000 - 2} = \frac{0.0001}{1 - 0.0002} = 0.0001 \times (1 + 0.002 + 0.002^2 + 0.002^3) + \cdots \]

なるほど、それで9998だったのか。それで9を足すと精度が増えるのか。

2014-01-27

ギークハウス新宿

ディベロップメントエンジニアという、企画段階で没になった資格の教本がある。この本は、全体的によく書けているのだが、デザインレビューという章がとても香ばしい。

この教本によると、デザインレビューをするには、ソースコードを印刷した紙を相手に渡し、ソースコードの原作者が、ソースコードを音読して伝えるものらしい。これをすることにより、技術者はコードに自信を持つことができる。また、デザインレビューは人事査定のために重要である。たとえ、上司や先輩が技術を知らなかったとしても、知らないなりにレビューできるという。

また、デザインレビューのために必要な部屋割りや椅子の配置方法など、わけのわからない記述が満載なのだ。

この教本の所有者によると、おそらく当時、教本を制定するときに、超有名大企業から超エライ、社内で持て余しているアホが左遷されてやってきたのではないかということだ。おそらく、その企業には出世の道は管理職になるしかなく、COBOLプログラマーとしてはそれなりに成果を上げたアホが、管理職になって悲惨なことになったのではないか。あまりに超エライために、日本語としてすら破綻しているデザインレビューの章が、査読を通ってしまい、印刷までされて、各地の教育機関にレビューするよう配られたらしい。この教本の所有者によると、おそらく当時、裏で手を回して、レビューを落とすように頼んだのではないかという話だ。

この本を紹介したところ、ギークハウス新宿に住んでいる人が、非破壊スキャナを持っているので、ぜひスキャンしようではないかという話になった。そこで、ギークハウス新宿に出かけていった。

ギークハウス新宿は、男が10人ほど一軒家で住んでいる。たまたま、全員技術者であるという。なかなかいい環境だ。

また本をスキャンした翌日、ギークハウス新宿の人間に案内してもらい、秋葉原にも行った。目的は、カタンのドイツ語版と、不自由なゲーム専用機であるファミコンとスーパーファミコンの実機だ。

残念ながら、カタンのドイツ語版は、いま日本では入手困難らしい。中古市場を回るしかないのだという。

さて、ファミコンとスーパーファミコンの実機は、無事に入手することができた。これで、いつでもレトロゲームが楽しめる。

その日は、ギークハウス新宿でピザをごちそうになった。なるほど、手作りのピザは面白い。生地から作るのは面倒だから、生地は買ってくるとして、その上に具材を載せればピザになる。妖怪ハウスでも、今度作ろうと思う。

さて、暇を見つけて、まだ行っていないギークハウスや、あるいは似たような性格のシェアハウスを、おいおいめぐってみるとしよう。

Clang VS 自由ソフトウェア

オープンソースで有名なEric S. Raymondが、自由ソフトウェアで有名なRichard Stallmanに、GCCのアンチプラグインポリシーについて突っ込んでいる。

GCCは、長年、コンパイラーのモジュール化を政治的な理由で行っていなかった。もし、例えばパーサーや意味解析だけを分離して使えるようにしたり、内部表現を規格化したりしてしまうと、GCCの一部が、不自由なソフトウェアに取り込まれたり、あるいは不自由なソフトウェアがGCCのプラグインという形で入り込むことになってしまう。これは、利用者の自由を第一とする自由ソフトウェアにとって、悪夢のような未来である。そのような未来を未然に防ぐために、政治的な理由で、GCCのはプラグインに反対するポリシーを採用している。もし、GCCを改良したければ、自由なソフトウェアとなるべきなのだ。そして、GCCのプロジェクトに参加するべきなのだ。

とはいえ、コンパイラーが機能毎に分割されていないのは不便だ。たとえば、高度なコード補完やリファクタリングのために、コンパイラーのうちのフロントエンド部分だけをテキストエディターから使いたいこともあるだろう。コンパイラーの内部表現が規格化されていれば、内部表現を生成して、そこから先のターゲット別のコード生成はコンパイラーに任せるなどといった使い方ができる。LLVMのコードは、そのような利用も、ライセンス的にも、コード的にも、簡単にできるようになっている。

GCCが市場を独占していた頃はよかったが、今やLLVMが登場し、驚異的な開発速度でGCCを追い上げている。もはやC++の規格準拠度では、完全にGCCを追い抜いている。これはGCCにとって脅威である。以前ならば、GCCでなければ事実上できなかったことが、LLVMでできるようになってきているのだ。しかも、LLVMはオープンソースという間違った目的を持っている。オープンソースと称する浅はかな思想は、利用者の自由を守ることに価値を見出さない。ああ、自由なソフトウェアの未来は暗い。

Eric S. Raymond - clang and FSF's strategy

Clangと自由ソフトウェア財団の戦略

From: esr at thyrsus dot com (Eric S. Raymond)
To: rms at gnu dot org, gcc at gcc dot gnu dot org, emacs-devel at gnu dot org
Date: Tue, 21 Jan 2014 15:19:49 -0500 (EST)
Subject: clang and FSF's strategy
Authentication-results: sourceware.org; auth=none

David Kastrupの最近のemacs-develへの質問により、私は前々から考えていた、もっとより本質的な質問を開こうと思う。一体、自由ソフトウェア財団の目的は、GCCを技術的に制限することにより達せられるものだろうか。

この問題には個人的にも興味がある。私は自由ソフトウェア財団のプロパガンダには、目的を阻害するという点で、反対している。オープンソースかつユーザーがコントロールするというソフトウェアエコシステムに、私は賛同するし、また個人的にも達成をしようと務めてきたところである。一方、自由ソフトウェア財団の遺物は良質の武器であり、GCCは確かに武器庫の中のもっと巨大な大砲だ。

私はGCCに自由ソフトウェア財団がやりたいことをやってもらいたい。自由とオープン性を啓蒙し、プロプライエタリな支配を打破し、開発ツールチェインのベンダーロックインを防ぐのだ。この目的にあたって、アンチプラグインポリシーが、いまだに妥当な方法かについて考えるべき時に来ている。

この問題には、Clangの存在が大きい。Clang開発者は、公の場で、自由ソフトウェア財団のアンチプラグインポリシーが障害であると堂々と発言していて、実際それが彼らの作業の意欲にもなっているのだ。しかも、彼らの進捗たるやすごい。今日、Clangは製品品質のツールに達し、GCCほど高機能ではないにせよ、GCCより優れた機能も提供している。例えば、Clangのエラーメッセージは、はるかに優れている。

Clang開発者は、彼らの目的はGCCを時代遅れにしてゴミ箱行きの遺物にするものである、とは言っていない。しかし、彼らの目標は、疑いようなくそこにある。3年から5年の時間で考えると、GCCの独占に対する現実の脅威となってくるだろう。

あるいは、ClangがGCCを王座から蹴り落としたら、私の目標は達成に近づくとも言える。つまり、自由ソフトウェア財団のクソな営業上の理由により、進歩を妨げて、その結果として地位を脅かされるわけなのだ。

今のところ、私はこの可能性を無視する。思うに、私としてはむしろ、GCCとClangの間で競争を促し、両方共強化させて、オープンソースツールチェイン全体を力を強めたほうがいいのだろう。

故に、自由ソフトウェア財団は、もはや自由なコンパイラーに対するプロプライエタリなベンダーのプラグインを防ぐことはできないのだ。いまや対抗馬が出てきてしまったのだ。アンチプラグインポリシーは、もはや戦略として機能しない。

また思うに、Microsoftを除いては、もはやプロプライエタリなコンパイラーを書きたいとおもうところなんて存在しないということだ。GCCはこの戦争には勝った。オープンソースのツールチェインをサポートすることによる市場の利点は、もう十分に理解されたので、新しいプロセッサーは当然のごとくサポートしているではないか。

そうであれば、GCCの制限を取っ払って、Clangと同じように、開発者の興味をひくようにするのが自然ではないのか?

Clang以前、まだGCCが市場を独占していた頃、このような制限は機能したのかもしれない。異論はある。もはや過ぎ去りし日のことを議論してもしょうがない。今や、そのような制限は無意味なものとなり、GCCの開発を妨げ、Clangの増長を許すばかりだ。

GCCには強みがたくさんある。特に、マルチプラットフォームとクロスプラットフォームサポートにおいてだ。自由ソフトウェア財団は完全にコードを自由にし、政治信条による制限を廃止し、プラグインによる豊富なエコシステムを推奨しなければならない。GCC, Clang, その他のコンパイラーを、単純に技術的な利点でのみ競争させようではないか。

過去15年の歴史が十分に実証しただろう。プロプライエタリなベンダーがオープンソースツールと、同じ土台で戦おうとすると、砂をかむことになると。しかも、彼らはその事実を、飛散な失敗から学んでいて、もはや再び試みようともしないだろう。研究費はもっと有益に費やせるのだ。

まあ、私は誰が勝とうがどうでもいい。GCCだろうとClangだろうと、私の目的は果たせるわけだ。私はどちらのツールも可能な限り最高になってほしい。そして、自由ソフトウェア財団が変化を認識して、時代の流れに追いついて欲しい。

Eric S. Raymond

There's a tendency today to absolve individuals of moral responsibility and treat them as victims of social circumstance. You buy that, you pay with your soul.

-Tom Robbins, Still Life with Woodpecker

Richard Stallman - Re: clang vs free software

Re: clang vs free software

From: Richard Stallman <rms at gnu dot org>
To: gcc at gcc dot gnu dot org
Date: Fri, 24 Jan 2014 09:54:13 -0500
Subject: Re: clang vs free software
Authentication-results: sourceware.org; auth=none
References: <CAJnXXoi2MLpZWxOxknR=mNR91JdZcHrKRsqYZSWY373fvwxObg at mail dot gmail dot com> <87eh439w1n dot fsf at uwakimon dot sk dot tsukuba dot ac dot jp> <CAJnXXojjSAWL8cqZp0X16xa81R73huywtTS90p6O3CpRaPOiDQ at mail dot gmail dot com> <jwvwqhu8zcg dot fsf-monnier+emacs at gnu dot org> <87ha8yqvup dot fsf at engster dot org> <E1W5cXI-0000j4-8x at fencepost dot gnu dot org> <CAJnXXoiuzZhjDGpvXY7psee=+bXn1rB+GdELYP0FS0CuWPqYeQ at mail dot gmail dot com> <E1W6HwP-0001WU-Tg at fencepost dot gnu dot org> <87r47zezcc dot fsf at fencepost dot gnu dot org> <m2eh3ykc3y dot fsf at gmail dot com> <20140123174934 dot GA10933 at thyrsus dot com>
Reply-to: rms at gnu dot org

[[[ 私のメールを読むNSAとFBIの職員に告ぐ ]]]
[[[ 米国憲法を内外の敵より守るために     ]]]
[[[ 諸君はSnowdenの道を辿らざるべからず  ]]]

自由ソフトウェア運動で、我々はコンピューターのユーザーの自由を啓蒙してきた。オープンソースの価値である単なる「より良いコード」という究極の目的と、自由ソフトウェアの価値は、根本的に異なるものである。もし、GCCが自由なコンパイラーから不自由なコンパイラーのプラットフォームに成り下がった場合、もはや自由という目的を果たすことはできない。故に、我々はそのような自体を阻止せずんばあらず。

自由ソフトウェアとオープンソースの詳細な違いについては、 http://www.gnu.org/philosophy/open-source-misses-the-point.htmlを参照。また http://thebaffler.com/past/the_meme_hustlerのEvgeny Morozovの全記事も参照。

ClangとLLVM開発者は、我々と共通の価値と目的を共有していないため、別の結論に達したのだ。自由を守るという我らの目的に彼らが反対する理由は、単に不便であるというだけであり、彼らにとっても必要である事柄を認識していないか、あるいはそもそも気にしていないのだ。おそらく、奴らは自分達の仕事を、「オープンソース」などと呼称し、自由についてはあまり論じていないのだろう。奴らはAppleという、自社のapp storeは不自由なソフトウェアであることを要求するほど自由を忌み嫌う企業から支援を受けている。(*)

不自由なコンパイラーがLLVMを土台にしているのは、私の正しさである、危険が現実のものであるということを如実に証明している。もし、私がGCCを不自由な組み合わせで使えるように「オープン」にしたならば、それは敗北を防ぐ助けにはならない。むしろ、敗北を早めるだけだ。

GCCが、他の技術的に優れていて、しかも同じぐらい自由を守るコンパイラーによって置き換えられたのならば、個人的には悲しいことであるが、私はコミュニティの進歩に歓喜するであろう。LLVMの存在は、我々コミュニティにとっては、退化である。なぜならば、LLVMはコピーレフトではなく、不自由コンパイラーの土台として使われ得るからである。つあmり、LLVMへの貢献は、我々の助けになるのと同様に、プロプライエタリなソフトウェアの助けにもなってしまうのだ。

退化の理由は、非コピーレフトコンパイラーが存在することにより、不自由コンパイラーの土台となりうるからである。LLVMにしろGCCにしろその他のものにしろ、コンパイラー自体は問題ではないのだ。GCCをそのような目的に提供することは、タオルを投げ入れるようなもんドア。もし、そのことによってGCCが「勝利」するのであれば、勝利など虚しい。なぜならば、本当に重要である、利用者の自由という点では、勝利していないからだ。

もし、読者は、我々がこの点で「妥協」しなければならないと考えるのであれば、http://www.gnu.org/philosophy/compromise.htmlを参照。

我々を助けるが、敵の助けにはならない唯一のコードは、コピーレフトなコードである。許諾的なライセンスで提供される自由ソフトウェアは、我々のためにはなるが、敵のためにもなってしまうのだ。もし、自分の作業に自由の利点を得たいならば、利用可能な武器を使うべきだ。すなわち、コードをコピーレフトにするのだ。私は、LLVMの主要アドオンの開発をしている者達に、コードをGNU GPL version 3 or laterで公開することを推奨する。

もし、GNUプロジェクトの目的を変更することを議論したいのであれば、適切な議論場所はgnu-misc-discuss@gnu.orgである。そちらに移動してもらいたい。

(*): もしバイナリが公開されたソースコードから生成されたものであっても、ソースコードの改変版から生成さればバイナリをインストールすることはできない。たとえソースコードが自由であっても、バイナリはプロプライエタリなのだ( http://www.gnu.org/philosophy/free-sw.htmlを参照)。Appleのapp storeのバイナリは、自由なソースコードとして公開することはできるかも知れないが、AppleのルールとAppleのDRMにより、バイナリは自由と離れないのだ。

--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: ありえん! そいつは不自由な(自由を否定している)ソフトウェアだ。
Ekigaとか、普通の電話を使え。

2014-01-22

C++03とC++11の違い:数値ライブラリー編

C++03とC++11の違いシリーズもそろそろ終わりが近づいていきた。今回は数値ライブラリー編だ。といっても、中身はひとつ、std::complexについてだ。

変更:std::complex<T>の特殊化の表現方法が規定された

C++03では、std::complexのメモリレイアウト、すわなち、オブジェクトがストレージ上でどのように表現されているかは、規定されていなかった。C++11では、C99の複素数ライブラリーと整合性をとるために、C++における複素数ライブラリーであるstd::complexの表現方法を厳格に規定した。

これにより、実装依存のメモリレイアウトに依存しているC++03のコードは、C++11では動かなくなるおそれがある。もっとも、そのようなコードは、もともと規格が動作を保証しないコードなので、自業自得だとも言える。

さて、std::complex<:T>:の表現方法はどのように規定されたのか。それは§26.4に書いてある。簡単にまとめると以下のようになる。

今、zがlvalue式で、その型がcv std::complex<T>であり、Tがfloat, double, long doubleのいずれかであるとすると、

  • 式、reinterpret_cast<cv T(&)[2]>(z)は、正しく動く
  • 式、reinterpret_cast<cv T(&)[2]>(z)[0]は、zの実数部を意味する
  • 式、reinterpret_cast<cv T(&)[2]>(z)[1]は、zの虚数部を意味する

さらに今、cv std::complex<T> *型の式aがあったとして、a[i]は、妥当であるとすると、

  • reinterpret_cast<cv T*>(a)[2*i]は、a[i]の実数部を意味する
  • reinterpret_cast<cv T*>(a)[2*i + 1]は、a[i]の虚数部を意味する

まあ、かなりCの構造体(構造体のアドレスは実数部のアドレスと等しく、実数部と虚数部の間にパディングなし)に近いようなレイアウトになるわけだ。もちろん、C言語でもこの手の詳細は未規定なのだが。

あるいは、コードで書いたほうがわかりやすいかもしれない。もちろん、このような規定を正確に記述できる機能は標準C++にはないが、例えば以下のようなコードが、よくある環境では上のような意味になるかもしれない。

// 実装依存の例示用コード
template < typename T >
struct complex ;

template < >
struct complex<float>
{
    float real ;
    float imarginary ;
} ;

このような表現の詳細に頼ったコードは書きたくないものだが・・・、必要になるのかも知れぬ。

2014-01-21

OpenBSDに相当額の寄付が集まる

'OpenBSD Foundation Fundraising for 2014' - MARC

前回の怪しいBitcoin長者の支援表明はともかく、OpenBSDが危機的状況にあるとの声明を出してから、わずか一週間で、10万カナダドルが集まったそうだ。

List: openbsd-misc
Subject: OpenBSD Foundation Fundraising for 2014
From: Bob Beck <beck () openbsdfoundation ! org>
Date: 2014-01-20 18:49:25
Message-ID: 20140120184925.GC30292 () hogfat ! obtuse ! com

やあみんな。

一週間ほど前、OpenBSDプロジェクトが去年の経費を払う資金がない(とくに、電気代が払えない)ことと、資金提供元を維持できないことを警告した。

我々の危難のニュースは先週、広く伝わり、コミュニティからの反応と、企業の寄付には多大なものがあり、その反応の一部は、インターネットメディアにも取り上げられた。

寄付をしてくれたすべての者に告ぐ、「ありがとう」。簡単にまとめると、一週間で危険な状況から、財団への寄付が約10万カナダドルに達するほどになった。開発者として、これほどやる気を奮い立たせることはない。

我々はこの勢いに乗り、今年の資金調達目標を15万カナダドルに設定した。参照、

http://www.openbsdfoundation.org/campaign2104.html

もし、読者がすでに貢献したのならば、ありがとう
もし、読者が貢献できるのならば、してくれ
もし、この目標に到達できる人、あるいは職場を知っているのならば、連絡してくれ

-Bob

OpenBSDは、OpenSSHをも開発しているわけで、大多数の読者は恩恵を受けているだろう。

2014-01-20

あるルーマニア人のBitcoin長者、OpenBSDの危難を救うと表明、付記OpenBSDへの寄付方法

Romanian Billionaire Saves OpenBSD | Bingo Blog

ルーマニア人でBitcoin長者のMircea Popescuが、Freenodeの#openbsdに現れて、OpenBSDプロジェクトが電気代を払えないという危難に対し、2万カナダドルの支援を表明した。

引用されているログは以下の通り。

Jan 19 22:14:04 <mircea_popescu> soo, who has the authority to make a deal so I can cover the 20k shortfall 
Jan 19 22:16:24 <woopstar> mircea_popescu: you need to contact Theo
Jan 19 22:16:32 <mircea_popescu> how would i go about that ?
Jan 19 22:18:27 <woopstar> mircea_popescu: i believe his email is [redacted because email addresses don't belong in plaintext]
Jan 19 22:20:32 <mircea_popescu> woopstar ty.
Jan 19 22:20:49 <woopstar> mircea_popescu: anytime. Would be fantastic, if you can set up a deal with Theo
Jan 19 22:14:04 <mircea_popescu> で、俺が2万の穴埋めをしてやるが誰に話つけりゃいいんだ? 
Jan 19 22:16:24 <woopstar> mircea_popescu: Theoに連絡する必要があるな。
Jan 19 22:16:32 <mircea_popescu> どうやって?
Jan 19 22:18:27 <woopstar> mircea_popescu: 奴のメールアドレスは(訳注:原文にはメールアドレスがあったか?)
Jan 19 22:20:32 <mircea_popescu> woopstar thx
Jan 19 22:20:49 <woopstar> mircea_popescu: いえいえ、Theoと話がついたら、最高だな。

これを確認できる一次ソースが見つからないのだが、少なくとも、19日にfreenodeの#openbsdで、上に引用された会話が行われたことは、筆者が直接#openbsdで聞いて確かめた。

<ezoe> Is it true that a bitcoin millionaire named Mircea Popescu stated he will pay 20k shortfall in this channel yesterday? news is spreading, but I can't find the trustworthy source to confirm it.
<weezelding> ezoe: here's some speculation https://news.ycombinator.com/item?id=7087800
<Stubbe> ezoe: There is only a IRC chat that states it, nothing is sure until the money is in the bank ;)
<ezoe> weezelding, yes, I read that, and other similar online bookmarking sites.
<ezoe> Stubbe, I see. I want to know if the conversation (quoted at http://www.thedrinkingrecord.com/2014/01/19/romanian-billionaire-saves-openbsd/) happened yesterday.
<Stubbe> it did
<ezoe> Thanks.
<woopstar> it did
<woopstar> :)
<Stubbe> I know woopstar
<ezoe> oh.
<Stubbe> lol
<Stubbe> :D
<woopstar> he knows me
<woopstar> <3
<ezoe> woopstar, thanks.
<Stubbe> <3

もちろん、現時点では払うと表明しただけで、実際に金の送金は行われていないわけだが、とにかく会話の事実はあったようだ。

また、日本でPaypal経由で寄付をすることが困難、というよりも違法である現状を説明したところ、なんとOpenBSD財団は、銀行口座による寄付受付もしているということを伝えられた。国際的な銀行振込は少々面倒だし、またそもそも、カナダの非営利団体への送金が、日本で法的な寄付にあたるかどうかもわからないが、OpenBSDを金銭的に支援したい人は、以下のWebサイトにOpenBSD財団の銀行口座の情報が載っている。

Donate to the OpenBSD Foundation

風邪

今年に入って早々に風邪をひいてしまった。原因は分かっている。吉田寮の入り口の廊下にあるコタツで寝たことだ。昔から無理のきかない脆弱な肉体であるとは十分承知なのだが、やはり健康なときには、そのことを忘れてしまいがちだ。それに、吉田寮にいる間に、一度ぐらい試してみたかったのだ。

吉田寮の廊下は、ほとんど外である。特に入り口はひどい。外気が直接吹き込んでくる。コタツの外はほとんど外である。

翌朝めざめて、その日はそれほどなんともなかったのだが、やけに水っぽい鼻水が多く出るようになった。二日目から、明らかに熱があり、体がだるくなった。

困ったことに、東京に引っ越す予定の日時は、17日の夜か18日だったのだ。東京に行ってやることが多いので、出発をあまり長く遅らせたくはない。風邪を治す薬などというものが存在しない以上、病院に行ったところでどうしようもない。あるいは、インフルエンザであるという可能性もあるにはあるが、多分違うだろうと思う。

18日まで粘ってみたところ、まあ、歩けるぐらいには回復したので、東京に移動した。ただし、体がだるかった時には出ていなかった咳が出るようになった。やれやれ、人に感染させてはまずい。マスクをしよう。

もとより、吉田寮で寝るときは常にマスクを着用していた。それでこれなのだから、やはり1月に京都で外同然の場所で寝るというのは、かなり強靭な肉体が必要なのだろう。

さて、そろそろ体のだるさもだいぶ消えてきた。ただし、咳がさらに多く出る。困ったものだ。

2014-01-19

東京に引っ越した

18日に東京に引っ越した。

当分の間は、野方にある妖怪ハウスというシェアハウスに住む予定だ。もし、C++の規格について疑問があるものや、カタンを遊びたいものは、妖怪ハウスまで来るといい。

さて、私が東京に引っ越した理由であるが、もう公開してもいいのだが、まだ完全に決まっていないことがあるので、今しばらく公開を差し控えておく。

今後がどうなるにせよ、これ以上C++の規格をやるには、東京に出てこなければならないのだ。結局、日本のプログラマーのほとんどが東京にいるという事実がある。一部の一流プログラマーが、田舎で活躍することはあるにせよ、大半のプログラマーは東京にいる。現実がそうである以上、C++の規格に基づいてC++を教育するのならば、やはり東京に出てこなければならないのだ。

本も多少売れたことだし、しばらくは東京での生活が続けられる。

2014-01-17

OpenBSDが資金難で開発停止の危機

'Re: Request for Funding our Electricity' - MARC

OpenBSDが、資金枯渇で電気代が払えず、開発停止の危機が目前に迫っているようだ。

List: openbsd-misc
Subject: Re: Request for Funding our Electricity
From: Bob Beck <beck () openbsdfoundation ! org>
Date: 2014-01-14 20:03:37
Message-ID: CAComcpM_hcqQuLnb=otudLjYjwaA5wMU14EyxLCdJWEXOJoLNQ () mail ! gmail ! com

この問題に注目を集めるために取り上げる。

資金減少により、プロジェクトの経費を払うことができる資金元が必要だ。OpenBSD財団がプロジェクトの電気代を支払うために、寄付を受け付けることができるようにする必要がある。

問題は目前に迫っているのだ。電気をつけるための資金がなければ、OpenBSDは開発停止する。

もし、読者か、読者の知っている企業が、我々を支援してくれるのならば、とても喜ばしいことだが、今年に入って急激な資本枯渇に見舞われている。つまり、このプロジェクトは、金を他のことに使う前の、2万ドルの電気代を払うことができないでいる。この状況は維持できない。

On Fri, Dec 20, 2013 at 5:08 PM, Theo de Raadt <deraadt@cvs.openbsd.org> wrote:

> 電気代のための資金問題か解決されていないので
> 要請する。

> だがそれ以上にも資金が必要だ。資金が得られなければ、
> もう維持できないからだ。この要請はちっぽけなものだ。

> -------

> やあみんな

> OpenBSDプロジェクトは、開発とビルドマシンを動かすため、多大な電力を使用している。
> 輸送の問題で、マシンを空間や電力を無料で提供してくれるような場所にうごかすことはできないので、
> その方向に議論を進めないようにしよう。

> 我々が求めているのは、我々の会計ではなく、自分の会計で電気代を支払ってくれるカナダ企業だ。
> 長期に渡る支援者を求めている。

> これにより、様々なOpenBSD活動を支援することができるのみならず、
> 我々を事務作業から開放してくれる。このコストを削減できれば、
> 資金をプロジェクトの他の部分に回すことができる。

> カナダ企業が会計上の理由で最適だろう。もし、他国の企業でも
> できると思うのであれば、意見を聞きたい。

> 実際の金額をここで公表することはしない。
> 真剣に考えているなら連絡を乞う。

> Thanks

なお、OpenBSDへの寄付は、以下のWebサイトから行うことができる。

Donate to the OpenBSD Foundation

C++03とC++11の違い:アルゴリズム編

今回は、C++03からC++11にかけて変わった互換性の問題を引き起こすおそれのある、今やおなじみになったシリーズの、アルゴリズム編だ。

変更:一部のアルゴリズムの、入力の結果の挙動が、ある未規定な状態から、別の未規定の状態に変わる。

これは、C++11にムーブが導入されたためだ。std::removeやstd::remove_ifなどが該当する。

// C++03とC++11で挙動が変わる例
#include <vector>
#include <algorithm>

template < typename T >
void f( T const & t1, T const & t2, T const & t3 )
{
    // t1, t2, t3はそれぞれ等しくないオブジェクトであるとする

    std::vector<> v ;
    v.push_back( t1 ) ;
    v.push_back( t2 ) ;
    v.push_back( t3 ) ;

    // vectorの要素 { t1, t2, t3 } 

    std::remove( v.begin(), v.end(), t2 ) ;

    // vectorの要素 { t1, t3, 未規定の状態 }
}

C++03でも、C++11でも、このコードを実行した後のv[2]の状態は、未規定である。ただし、C++03では、コピーされるのに対し、C++11では、ムーブされる。そのために、未規定は未規定でも、異なる状態の未規定になる。

これは、元々が未規定の状態になるという点においては変わらないので、それほど問題になることはないだろう。C++11規格では、標準ライブラリに渡すユーザー定義型のムーブ後の状態は、未規定だが、規格の型に対する要求(たとえば、DefaultConstructibleを満たすとか)は、依然として満たしていなければならないと規定している。これはユーザーの責任でもある。

次回は数値ライブラリについて。

2014-01-14

C++03とC++11の違い: コンテナーライブラリー編

Bazaarの記事の翻訳にだいぶ時間を取られたが、C++03とC++11の違いシリーズを再開する。今回は、コンテナーライブラリーの違いについて。

変更: メンバー関数sizeの複雑度(complexity)が定数(constant)になった。

C++03では、コンテナーのメンバー関数sizeの複雑度は規定されていなかった。これにより、例えばコンテナーの要素数に比例して線形にコストが上がるような実装も可能であった。たとえば、コンテナーの内部実装がリンクリストである場合、要素数を記録するためのデータメンバーを持たずに、メンバー関数sizeが呼び出された際に、イテレーターを全てたどって要素数をその場で計算するような実装も可能であった。

そのような実装を可能にしてしまうということは、移植性を考慮したコードでパフォーマンスの予測がたたないという問題がある。そこで、C++11では、sizeの複雑性は定数とならねばらなぬと規定された。したがって、規格準拠のコンテナーは、そのように実装しなければならない。

変更: コンテナーの要件の緩和

C++11では、新たな特性を持ったコンテナーを追加した。新たな特性を持ったコンテナーをサポートするにあたり、既存の全コンテナーが満たすべき要件は、あまりにも厳しすぎるため、その要件を緩和した。これにより、全コンテナーで保証された挙動を想定しているC++03のコードが、C++11で追加された新たなコンテナーには想定外となる場合がある。

C++11で緩和された要件は以下の通り:

  • メンバー関数sizeを持たないコンテナーが存在する。size() == 0を確かめたいならば、empty()が代わりに使える。
  • 構築後に空ではないコンテナーが存在する。(std::array)
  • swap()の複雑度が定数ではないコンテナーが存在する。(std::array)

変更: ユーザー定義型にdefault constructibleの要件

sequence containerとassociative containerで、一部の操作をする際に、テンプレート実引数で与えるユーザー定義型の要件として、default constructibleが加わった。

たとえば、以下のように書いた場合

// T型の要素でサイズが10のvector
std::vector<T> v(10) ; 

T型はデフォルト構築可能でなければならない。

C++03では、これがはっきりと規定されていなかったが、C++11では、規格で明記されるようになった。

変更:一部のメンバー関数のシグネチャ変更、戻り値の型がvoidからイテレーター型になった

コンテナーの一部のメンバー関数の戻り値の型は、C++03までは、void型であると規定されていた。ただし、イテレーターを返したほうが都合が良かったり、その時点で実装上判明しているイテレーターを、後から見つけるのにコストがかかったりするため、返して欲しい場合があった。そのため、一部のメンバー関数の戻り値の型が、voidからイテレーターを返すように変更された。

変更されたのは以下のメンバー関数である。

  • erase(iter) for set, multiset, map, multimap
  • erase(begin, end) for set, multiset, map, multimap
  • insert(pos, num, val) for vector, deque, list, forward_list
  • insert(pos, beg, end) for vector, deque, list, forward_list

これらのメンバー関数の戻り値の型が、voidからイテレーター型に変わった。

これにより、C++03コードのうち、メンバー関数へのポインターをとる合法なコードが、C++11では違法になる可能性がある。逆に、C++11で合法なコードがC++03では違法になるということでもある。

// 例
#include <vector>

int main()
{
    // well-formed in C++03
    // ill-formed in C++11
    void // return type
    ( std::vector<int>::* cpp03_ptr ) // name
    // parameter-list
    ( std::vector<int>::const_iterator,
      std::vector<int>::size_type n,
      std::vector<int>::value_type const & x)
    = &std::vector<int>::insert ;


    // ill-formed in C++03
    // well-formed in C++11
    std::vector<int>::iterator // return type
    ( std::vector<int>::* cpp11_ptr ) // name
    // parameter-list
    ( std::vector<int>::const_iterator,
      std::vector<int>::size_type n,
      std::vector<int>::value_type const & x)
    = &std::vector<int>::insert ;
} 

まあ、こんなコードはあまり書かれないのではないだろうか。

変更:シグネチャ変更、一部のメンバー関数の仮引数のiteratorがconst_iteratorになった

シグネチャが変更されたメンバー関数は以下の通り。

  • insert(iter, val) for vector, deque, list, set, multiset, map, multimap
  • insert(pos, beg, end) for vector, deque, list, forward_list
  • erase(iter) for set, multiset, map, multimap
  • erase(begin, end) for set, multiset, map, multimap
  • すべての list::splice
  • すべての list::merge

これも、メンバー関数へのポインターなど、具体的なシグネチャに依存しているC++03のコードが、C++11では修正が必要になる可能性がある。稀ではあると思うが。

変更:シグネチャ変更、resizeの仮引数の値の型がリファレンスになった。

C++03では、resizeは以下のように定義されていた。

void resize(size_type sz, T c = T());

C++11では、ムーブセマンティクスを追加したため、このシグネチャも変更することになった。また、関数を分割して、オーバーロードすることにした。

void resize(size_type sz);
oid resize(size_type sz, const T& c);

リサイズで増えた要素をデフォルト構築するのが1つ目。指定された値で初期化するのが2つ目。

resizeにムーブはない。なぜならば、複数の値を、ひとつのオブジェクトを使って初期化しなければならないからだ。

次回はアルゴリズム編。

2014-01-13

プログラマーのジョーク

language agnostic - What is your best programmer joke? - Stack Overflow

私はコンピューターサイエンス科で教育しているが、何かユーモアによって場を盛り上げたい。ユーモアは場を退屈させず、物事を印象深くするし、物事を学ぶモチベージョンにもつながる。さらに、ジョークが技術的な理解を必要とするのであれば、さらにモチベーションが上がるのだ。

このstackoverflowの質問を受けて、様々なプログラマーのジョークが投稿されている。その評価順に紹介すると・・・

A man flying in a hot air balloon suddenly realizes he’s lost. He reduces height and spots a man down below. He lowers the balloon further and shouts to get directions, "Excuse me, can you tell me where I am?"

ある人が熱気球で飛んでいて、道に迷ってしまった。高度を下げて、地上にいる人を見つけた。更に高度を下げて、地上に向かって叫んだ「すみません、私はどこにいるんでしょうか?」

The man below says: "Yes. You're in a hot air balloon, hovering 30 feet above this field."

地上の人は言った「うん、君は熱気球に乗っていて、地上から30フィート上を漂っているね。」

"You must work in Information Technology," says the balloonist.

「君はITで働いているんだね」と気球乗りは言った。

"I do" replies the man. "How did you know?"

「そうだ」と地上の人は言った。「なぜ分かったんだ?」

"Well," says the balloonist, "everything you have told me is technically correct, but It's of no use to anyone."

「そうだね」と気球乗り、「君の教えてくれたことは技術的に正しい、ただ、何の役にも立たない」

The man below replies, "You must work in management."

地上の人が答えた「君は管理職だね」

"I do," replies the balloonist, "But how'd you know?"*

「そうだ」と気球乗り、「なぜわかった」

"Well", says the man, "you don’t know where you are or where you’re going, but you expect me to be able to help. You’re in the same position you were before we met, but now it’s my fault."

「そうだな」と地上の人、「お前は今どこにいるかわかっておらず、どこに向かうかもわかっていない。にもかかわらず助けを求めている。お前は会う前と変わらない状況にいるが、さて、責任は俺が負うわけだ」

これはそうとう昔からあるジョークの改変版

ノックノック

「誰だい?」

とてもながい沈黙

「java」

(;・∀・)

ご存知有名なノックノックジョーク。Javaは遅い。

A SQL query goes into a bar, walks up to two tables and asks, "Can I join you?"

SQLクエリーがバーに入って、2つのテーブルに向かって、言った。"Can I join you?"

必ずしも人とは限らない何かがバーに入るというジョーク

Saying that Java is nice because it works on every OS is like saying that anal sex is nice because it works on every gender.

JavaがあらゆるOSで動くから良いというのは、アナルセックスはあらゆる性別で行えるから良いと言うようなものだ。

コメント:これは卑猥だ! Jから始まる卑猥な単語を使わないでくれたまえ。

Jから始まるある言葉は卑猥。

Q: how many programmers does it take to change a light bulb?

A: none, that's a hardware problem.

Q: 電球を変えるのにプログラマーが何人必要か?

A: ゼロ、ハードウェアの問題である。

電球を変えるのにポーランド人が何人必要かというジョーク

A young Programmer and his Project Manager board a train headed through the mountains on its way to Wichita. They can find no place to sit except for two seats right across the aisle from a young woman and her grandmother. After a while, it is obvious that the young woman and the young programmer are interested in each other, because they are giving each other looks. Soon the train passes into a tunnel and it is pitch black. There is a sound of a kiss followed by the sound of a slap.

若いプログラマーとプロジェクトマネージャーが列車に乗り、山を超えてウィチタに向かった。空いている席は、若い女とその祖母の座っている席のみだった。しばらくして、若い女と若いプログラマーは互いに目配せをするようになった。お互いに好意を抱いていることは明らかである。やがて、列車はトンネルに入り、真っ暗闇になった。キスの音がした後に、ビンタの音がした。

When the train emerges from the tunnel, the four sit there without saying a word. The grandmother is thinking to herself, “It was very brash for that young man to kiss my granddaughter, but I’m glad she slapped him.”

列車がトンネルからでたとき、四人は無言で座っていた。祖母は思った。「あの若い男が私の孫娘にキスするだなんて。はたかれて当然だわ」

The Project manager is sitting there thinking, “I didn’t know the young tech was brave enough to kiss the girl, but I sure wish she hadn’t missed him when she slapped me!”

プロジェクトマネージャーは座ったまま思った。「あの若造が小娘にキスをするほど大胆だとは思わなかったな。だが・・・娘さん、狙いを外して私を叩きおった」

The young woman was sitting and thinking, “I’m glad the guy kissed me, but I wish my grandmother had not slapped him!”

若い女は座ったまま思った。「あの人がキスをしてくれたのは嬉しいけれど、祖母がびんたなんてしなければよかったのに」

The young programmer sat there with a satisfied smile on his face. He thought to himself, “Life is good. How often does a guy have the chance to kiss a beautiful girl and slap his Project manager all at the same time!”

若いプログラマーは座ったまま、満足気な笑みを顔に浮かべていた。彼は思った。「人生とはいいものだ。いい女にキスできて、しかもプロジェクトマネージャーにビンタできるなんて、めったにないぞ」

コメント:

プログラマーに関連したジョークではないな。登場人物を変えても通用するだろう。

これは大いにプログラマー関連だ。「いい女にキスできるなんて、めったにないぞ」とは、いかにもプログラマーだ。

やれやれ、このジョークを最初に読んだのは1980年代で、当時はアメリカ兵とロシア兵だったぞ。光陰矢のごとし。

A physicist, an engineer and a programmer were in a car driving over a steep alpine pass when the brakes failed. The car was getting faster and faster, they were struggling to get round the corners and once or twice only the feeble crash barrier saved them from crashing down the side of the mountain. They were sure they were all going to die, when suddenly they spotted an escape lane. They pulled into the escape lane, and came safely to a halt.

物理屋、エンジニア、プログラマーが車に乗り、険しい山道を運転している最中、ブレーキが壊れた。車はどんどん加速していき、危うくカーブを曲がり、一度か二度は、ガードレールがなければ転落するほどであった。彼らが皆、死を覚悟した時、脱出レーンを見つけた。脱出レーンに車を向け、ようやく安全に停止した。

The physicist said "We need to model the friction in the brake pads and the resultant temperature rise, see if we can work out why they failed".

物理屋は言った。「まずブレーキパッドの摩擦と、摩擦による温度上昇をモデル化すれば、なぜ壊れたのかわかるだろう。」

The engineer said "I think I've got a few spanners in the back. I'll take a look and see if I can work out what's wrong".

エンジニアは言った。「トランクにスパナの数本も入ってるだろうから、何が壊れたのかみてみよう」

The programmer said "Why don't we get going again and see if it's reproducible?"

プログラマーは言った。「もういちど再現するかどうか試してみるというのは?」

いかにもプログラマーらしい。

When your hammer is C++, everything begins to look like a thumb.

もしハンマーがC++だったら、すべてのものが親指に見えてくる。

指を打ってしまう。

A computer science student is studying under a tree and another pulls up on a flashy new bike. The first student asks, “Where’d you get that?”

コンピューターサイエンス科の学生が、木の下で勉強していると、別の学生が、ピカピカ新品のバイクで乗り付けた。先の学生がたずねた。「そいつをどこでてにいれたんだ?」

The student on the bike replies, “While I was studying outside, a beautiful girl pulled up on her bike. She took off all her clothes and said, ‘You can have anything you want’.”

バイクに乗った学生が答えた。「外で勉強していたら、超美人の女がバイクで乗り付けてきたんだ。その女は服を全部脱いで、「なんでもあげるわ」って言ってきたんだ」

The first student responds, “Good choice! Her clothes probably wouldn’t have fit you.”

先の学生が答えた。「そいつはいい選択だね。女物の服は君には合わないだろうしね」

その選択は正しい。

If you put a million monkeys at a million keyboards, one of them will eventually write a Java program.

もし、百万匹のサルを百万個のキーボードの前に立たせたら、彼らのうちの一匹は、いずれJavaプログラムをひとつ書くだろう。

The rest of them will write Perl programs.

残りのサルは皆Perlプログラムを書く。

さもありなん。

Q: "Whats the object-oriented way to become wealthy?"

Q: オブジェクト指向的に金持ちになる方法は?

A: Inheritance

A: 継承

["hip","hip"]

(hip hip array!)

ん?

追記:元ネタ判明、Hip hip hooray - Wikipedia, the free encyclopedia

A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.

COBOLプログラマーはY2K問題への対処で相当に設けたので、死んだ時に自分自身を冷却保存した。未来のある日、彼は蘇生させられた。

When he asked why he was unfrozen, he was told:

彼が解凍された理由を尋ねると、曰く、

"It's the year 9999 - and you know Cobol"

今は9999年だ。お前はCOBOLを知っている。

さもありなん。

xkcd: Random Number

Programming is like sex:

プログラミングとはセックスのようなものだ:

One mistake and you have to support it for the rest of your life.

一度失敗しただけで、生涯ずっとサポートを余儀なくされる。

Software is like sex: It's better when it's free. (Linus Torvalds)

ソフトウェアとはセックスのようなものだ:フリーのほうがいい(Linus Torvalds)

Q: How many prolog programmers does it take to change a lightbulb?

Q: 電球を変えるのにPrologプログラマーが何人必要か?

A: Yes.

コメント:

Prologの長年の苦い経験からいうと、より適切な答えは、Noだ。

In Prolog programming (in contrast perhaps to life in general) our goal is to fail as quickly as possible. - The Art of Prolog/MIT Press

Prologプログラミングにおけるゴールは(人生も含めた一般論とは反対に)、できるだけ早く失敗することである。

To understand what recursion is, you must first understand recursion.

再帰とはなんであるかを理解するためには、まず再帰について理解する必要がある。

so this programmer goes out on a date with a hot chick

さて、、このプログラマーは美人とデートして、

コメント:

自慢だが、俺の嫁はラリるぐらい美人だし、デートをねだられたこともあるんだぜ

俺はプログラマーだが、大勢の美人と遊んでるぜ

こんなにユーモアのセンスのないプログラマーにひっかかる美人を見つけてきたということに驚きだ。

The fantastic element that explains the appeal of games to many developers is neither the fire-breathing monsters nor the milky-skinned, semi-clad sirens; it is the experience of carrying out a task from start to finish without any change in the user requirements.

開発者が楽しいと思うゲームとは、火を吹くモンスターや、色白ビキニのセイレーンが出てくることではない。ユーザーからの仕様変更要求なしに最初から最後までやり通せることである。

In the 1960's the KGB was very interested in learning everything possible about the American space program, sending all sorts of spies to find every possible piece of information.

1960年代のKGBは、アメリカの宇宙開発のあらゆることを知りたがっており、様々なスパイを送り込んで、どんな僅かな情報でも探らせた。

One afternoon, a breathless spy returned to headquarters with a page of paper in his hand, excitedly shouting to his superior, "Comrade! Comrade! The Americans are using Lisp to write their rocket launching software!"

ある日の午後、一人のスパイが息を切らせて本部に駆け込んできた。手には紙切れを持ってる。興奮して上官に叫んだ。「同志! 同志! アメリカ人はロケット発射ソフトウェアにLispを使っているぞ!」

The commander was skeptical. "How do you know?"

司令官は用心深かった。「なぜ分かったんだ」

"I broke into their research lab and stole a page from the teletype machine! It's not the whole program, but it's the final page and contains the concluding logic of the program! See for yourself!!!!"

「奴らの研究所にしのび混んで、テレタイプから一枚盗んできました。プログラム全部じゃないんですが、最後のページでして、プログラムの最後が載ってるんです。見てください」

The commander looked at the page and smiled:

司令官はページを見て、ニヤついた。


))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))))
))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))
)))))))))))))))))))))))))
))))))))))))))))))))))
))))))))))))))))))))
))))))))))))))))
)))))))))))))))
)))))))))))
))))
)))
))
))
)

Obfuscated C Contest for 1990: westley.c

There are 10 types of people in the world. Those who understand binary and those who have regular sex.

世の中には10種類の人間がいる。2進数を理解できる者と、普通のセックスをするもの。

なぜプログラマーはUNIXを好むのか:

unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep

コメント:俺が見たバージョンは、

who && gawk && uname && talk && date && wine && touch && unzip && strip && touch && finger && mount && fsck && more && yes; yes; more; yes; umount && make clean && sleep

These two strings walk into a bar and sit down. The bartender says, "So what'll it be?"

二人の文字列がバーに入って座った。バーテンダーが言った。「何にします?」

The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy owmc63^Dz x.xvcu"

一人目の文字列が言った。「まずはビー=るをjdk^CjfdLk jk3s d#f67howe%^U r89nvy owmc63^Dz x.xvcu」

"Please excuse my friend," the second string says, "He isn't null-terminated."

「気にしないでくれ」と二人目の文字列が言った。「こいつはnull終端されてないんだ」

コマンドラインロシアンルーレット


[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*

Told by Gerald Weinberg in various incarnations:

Gerald Weinbergから聞いた話で、何度も改変された後だが。

A group of ten top software engineers is sent to a class for aspiring managers. The teacher walks in and asks this question:

10人のトップソフトウェアエンジニアが管理職養成セミナーに送られた。講師がやってきて、次の質問をした。

"You work for a software company which develops avionics (software that controls the instruments of an airplane). One day you are taking a business trip. As you get on the plane you see a plaque that says this plane is using a beta of the software your team developed. Who would get off?"

「あなたはavionics(飛行機の機器の制御ソフトウェア)を開発するソフトウェア会社で働いています。ある日、あなたは仕事で飛行機に乗りました。飛行機に搭乗した時に目にしたプレートには、この飛行機はあなたの開発部署が開発したソフトウェアのベータ版が使われているとあります。降りる人?」

Nine developers raised their hands. The teacher looked at the tenth and asked, "Why would you stay on?"

開発者9人が手を挙げた。講師は10人目を見て、たずねた。「なぜあなたは降りないのですか?」

The tenth said, "if my team wrote the software, the plane would not get off the ground, much less crash."

10人目が言った。「もし、うちの開発部署がソフトウェアを書いていたならば、飛行機は飛び立つことすらできませんよ。墜落なんて起こりようがない」

Once upon a time there was a shepherd looking after his sheep on the side of a deserted road. Suddenly a brand new Porsche screeches to a halt. The driver, a man dressed in an Armani suit, Cerutti shoes, Ray-Ban sunglasses, TAG-Heuer wrist-watch, and a Versace tie, gets out and asks the Shepherd:

昔々、砂漠の道の横で、羊を番する羊飼いがいた。急に、新品のポルシェがけたたましくやってきて、その場に停車した。運転手は、アルマーニのスーツを着て、セルッティの靴を履き、レイバンのサングラス、タグ・ホイヤーの腕時計、ヴェルサーチのネクタイという出で立ちで、車から降りて、羊飼いに聞いた。

Man: “If I can tell you how many sheep you have, will you give me one of them?”

男「もし、私がここに何匹の羊がいるか当てられたら、羊を一匹もらってもいいかな」

The shepherd looks at the young man, and then looks at the large flock of grazing sheep and replies:

羊飼いは若い男を見て、羊の大群を見て、答えた。

Shepherd: “Okay.”

羊飼い「いいぜ」

The young man parks the car, connects his laptop to the mobile-fax, enters a NASA Webster, scans the ground using his GPS, opens a database and 60 Excel tables filled with logarithms and pivot tables, then prints out a 150 page report on his high-tech mini-printer. He turns to the shepherd and says,

若い男は車を停め、ラップトップをモバイルFAXに接続し、NASAの衛星画像サイトに入り、GPSを使ってその場をスキャンし、対数表やピボットテーブルが満載の60枚ものExcelテーブルを開き、ハイテクなミニプリンターで150ページものレポートを印刷した。男は羊飼いの方に向き直り、言った。

Man: “You have exactly 1,586 sheep here.”

男「きっかり1586匹の羊がいるね」

The shepherd cheers,

羊飼いは微笑んだ。

Shepherd: “That’s correct, you can have your sheep.”

羊飼い「そのとおりだ。羊をやろう」

The young man makes his pick and puts it in the back of his Porsche. The shepherd looks at him and asks,

若い男は羊を選び、ポルシェのトランクに積んだ。羊飼いは男を見て聞いた。

Shepherd: “If I guess your profession, will you return my animal to me?”

羊飼い「もし、ワシがお前さんの仕事を当てられたら、羊を返してもらえるかね」

The young man answers;

若い男が答えた

Man: “Yes, why not?”

男「いいよ。やってみたまえ」

Shepherd: "You are an IT consultant."

羊飼い「あんたはITコンサルタントだな」

Man: “How did you know?”

男「なぜ分かったんだ」

Shepherd: “Very simple. First, you came here without being called. Second, you charged me a fee to tell me something I already knew, and third, you don’t understand anything about my business…Now can I have my DOG back?"

羊飼い「簡単さ。一つ、あんたは呼ばれもしないのにやってきた。二つ、ワシがすでに知ってることを教えるのに対価を要求した。三つ、あんたはワシの仕事について何も理解しておらん。さあ、ワシの「犬」を返してもらおうか」

Unix is user friendly. It's just very particular about who its friends are.

UNIXはユーザーフレンドリーである。ただ、UNIXは友達の選り好みをするだけだ。

Richard Stallman, Linus Torvalds, and Donald Knuth engage in a discussion on whose impact on computer science was the greatest.

リチャード・ストールマン、リーナス・トーバルズ、ドナルド・クヌースが、誰がコンピューターサイエンスに与えた影響が最も大きいかについて議論した。

Stallman: "God told me I have programmed the best editor in the world!"

ストールマン「俺は世界一のエディターを書いたと、神がおっしゃった」

Torvalds: "Well, God told me that I have programmed the best operating system in the world!"

トーバルズ「俺は世界一のオペレーティングシステムを書いたと、神がおっしゃった」

Knuth: "Wait, wait, I never said that."

クヌース「おいおい、ちょっと待ちなはれ。ワシ、そんなこと言うてへんで」

Knuth先生は神か。

ヤクの売人

  • 顧客を「ユーザー」と呼ぶ
  • 「最初は無料だよ」
  • 東南アジアと重要なコネを持っている(ブツを運ぶため)
  • 奇妙な符牒「スティック」、「ロック」、「ダイムバッグ」、「E」
  • 14歳から25歳までの市場に金があると知っている。
  • 仕事は、業界の生産する、より新しい、より効き目のいい調合にささえられている。
  • よく、斡旋屋やポルノ女優と一緒にいるところを目撃される
  • 製品には不健康的な中毒性がある。
  • 仕事をうまくやれば、依存する映画俳優などと寝れる。

ソフトウェア開発者

  • 顧客を「ユーザー」と呼ぶ。
  • 「無料体験版のダウンロード」
  • 東南アジアと重要なコネを持っている(コードのデバッグのため)
  • 奇妙な符牒、「スカジー」、「アイエスディーエヌ」、「ジャバ」、「ggrks」
  • 14歳から25歳の市場に金があることを知っている。
  • 仕事は業界の、より新しい、より高速な機械にささえられている。
  • よく、営業やベンチャーキャピタリストと一緒にいるところを目撃される。
  • 製品には不健康的な中毒性がある。DOOM, Quake, SimCity, Duke Nukem 3D.
  • クソ! クソ!! クソ!!!

ソフトウェア開発者とは不遇なものだ。

If your mom was a collection class, her insert method would be public.

お前のカーチャンがコレクションクラスだったら、insertメソッドはpublicだな。

お前のカーチャンを罵る形式のジョーク

Female software engineers become sexually irresistible at the age of consent, and remain that way until about thirty minutes after clinical death. Longer if it's a warm day.

女プログラマーは皆、性的な魅力を持ち、死ぬ30分前までその魅力を保つ。もし温かければ、魅力はもう少し長く保たれる。

[Scott Adams, Dilbertの作者]

This is from the 70s. It can easily be updated to the present day, but it has a certain charm just the way it is:

これは70年代のジョークだ。現代版にアップデートすることもできるが、このままにしておいたほうが面白いこともあるだろう。

Three women sat discussing their husbands and their sex lives.

3人の女が座って、それぞれの夫と性生活について話し合っていた。

"My husband's a wrestler," said the first. "He's really strong and aggressive in bed."

「夫はレスラーなの」と最初の女は言った。「ベッドではとっても強くて情熱的なの」

"My husband's an artist," said the second. "He's really gentle and sensitive."

「夫は芸術家なの」と二人目は言った。「優しくて雰囲気がいいのよ」

"My husband's an IBM salesman," said the third. "He sits on the edge of the bed and tells me how good it's going to be when I finally get it."

「夫はIBMのセールスマンよ」と三人目。「ベッドの端に座り、これからいかに素晴らしいことが起こるかを延々と話して聞かせるのよ」

The C language combines all the power of assembly language with all the ease-of-use of assembly language.

C言語はアセンブリ言語の力と、アセンブリ言語の使いやすさをあわせ持っている。

コメント:

それと、アセンブリ言語の移植性

それと、アセンブリ言語の美しさ

それと、アセンブリ言語の可読性

Three men are talking: A programmer, a doctor, and a lawyer. The lawyer says, "Man, the only way is to have a mistress. With all these divorce suits, it's terrible. The only way is to have a mistress." The doctor says, "Are you kidding? With all the STDs out there, you want a wife and that's it." The programmer says, "You need both a wife and a mistress. Because when you're not with the mistress, she'll assume you're with your wife, and when you're not with your wife, she'll assume you're with your mistress, and THAT leaves you more time to be in the lab programming!"

三人の男が話し合っていた。プログラマー、医者、弁護士である。弁護士が言った。「君たち、持つべきはセフレだよ。こんなにも離婚訴訟が多いんだ。悲惨だよ。セフレに限るね」と。医者が言った。「気は確かかね。こんなにも性病が流行っているのだぞ。妻を一人もてばそれで十分だ」と。プログラマーが言った。「妻とセフレを両方持てばいい。というのも、セフレのところに行かなければ、セフレは僕が妻のところに行っているのだと思うだろうし、妻のところにいかなければ、セフレのところに行っているのだろうと思ってくれる。これはつまり、僕がプログラミングする時間が増えるってわけだ」

まあ、たしかにプログラマーにはこういう人間が多いかも知れない。こういう人間だからプログラミングに適正があるのだろうか。

Q: how many Microsoft programmers does it take to change a light bulb?

Q: 電球を変えるのにマイクロソフトのプログラマーが何人必要か?

A: none, they just make darkness a standard and tell everyone "this behavior is by design"

0人。彼らは暗闇を標準とし、「この挙動は仕様です」と言う。

さもありなん。

How long does it take to copy a file in Vista? Yeah, I don't know either, I'm still waiting to find out.

Vistaでファイルをコピーするのにどのくらいかかるのか。俺にもわからん。まだ検証中だ。

Two bytes meet. The first byte asks, “Are you ill?”

The second byte replies, “No, just feeling a bit off.”

これは訳せない。

If the box says, "This software requires Windows XP or better," does that mean it'll run on linux?

もし箱に、「このソフトウェアはWindows XPか、上位版を必要とします」と書かれていた場合、それはつまり、linuxで動くってことか?

GNU/LinuxはWindowsよりベターだ。

If Java is the answer, it must have been a really verbose question.

もし、答えがJavaであるならば、その質問はよほど冗長な質問だったのだろう。

さもありなん。

what do Computer Science students use for birth control?

コンピューターサイエンス科の学生が避妊に用いる方法は?

Their personalities.

性格

An infinite number of mathematicians walk into a bar.

無限人の数学者がバーにやってきた。

The first orders a beer, the second orders half a beer, the third orders a quarter of a beer, the fourth an eighth, and so on.

一人目はビールを注文した。二人目はビールを半分注文した。三人目はビールを1/4注文した。4人めは1/8で、以下同様に続いた。

The bartender looks at the line going out the door,turns to the line and says "you guys suck!".

バーテンダーは行列がドアの外に続くのを見て、行列に向かって言った。「お前ら最悪だな」

Then he pours two beers and walks away.

そして、バーテンダーは二杯のビールを注ぐと、歩き去っていった。

プログラマージョークというわけではないが、おもしろい。

Why doesn't C++ have a garbage collector?

なぜC++にはガベージコレクターがないのか。

Because there would be nothing left!

なぜならば、あとに何も残らないから。

コメント:もし、JavaのGCがまともにうごいたら、プログラムの大半は残らない。

C++においては、コレクトされるのはCプリプロセッサーぐらいなものだ。

Java programming is like teenage sex ....

  • Everyone talks about it all of the time (but they don't really know what they're talking about);
  • Everyone claims to be doing it;
  • Everyone thinks everyone else is doing it;
  • Those few who are actually doing it:
    • Are not practicing it safely;
    • Are doing it poorly, and
    • Are sure it will be better next time."

Javaプログラミングは十代のセックスのようなものである。

  • みんな話をしている(だが、何を話しているか理解しているものはいない)
  • みんな、やっていると主張している。
  • みんな、他人はみんなやっていると思っている。
  • 実際にやっている極小数の者は:
    • 安全にやっていない
    • うまくやっていない。
    • 次回はもっとうまくやれると信じている。

ああ、Java、この悲惨な言語。

A programmer is walking down a road when he hears a frog say, "If you kiss me, I will turn into a beautiful woman. We can get married, and I will be your loving wife forever". The geek and the frog stare at each other for a bit, and then he picks up the frog and gently places her in his front pocket. The frog sticks her head out and says "aren't you going to kiss me?"

"No" says the programmer, "I am a programmer, I don't have time for that - but a talking frog is really cool!"

プログラマーが道を歩いていると、カエルがものを言った。「キスをしてくだされば、私はもとのお姫様に戻れます。結髮して枕席を同じくし、黄泉まで共に友為らんとす」。ギークとカエルは一瞬見つめ合った。そしてプログラマーはカエルを拾い上げると、ポケットに収めた。カエルはポケットから顔をつきだして言った。「キスしてくださらないんですの?」

「いや」とプログラマーが言った。「俺はプログラマーだ。だからそんな時間はない。でも、物を言うカエルというのはかっこいいだろ」

Your mommas so fat that not even Dijkstra is able to find a shortest path around her.

お前のカーチャンはデブすぎるんで、ダイクストラすら最短周囲を見つけられないでやんの。

どれだけ複雑な形状なのだろうか。

C++ - where your friends have access to your private members.

C++では、友達はプライベートなメンバーにアクセスできる。

Software developers like to solve problems. If there are no problems handily available, they will create their own problems.

ソフトウェア開発者は問題を解くのが好きだ。もし、お手軽な問題がなければ、彼らは問題を作り出す。

Life Before the Computer

An application was for employment
A program was a TV show
A cursor used profanity
A keyboard was a piano!

Memory was something that you lost with age
A CD was a bank account
And if you had a 3-inch floppy
You hoped nobody found out!

Compress was something you did to garbage
Not something you did to a file
And if you unzipped anything in public
You'd be in jail for awhile!

Log on was adding wood to a fire
Hard drive was a long trip on the road
A mouse pad was where a mouse lived
And a backup happened to your commode!

Cut - you did with a pocket knife
Paste you did with glue
A web was a spider's home
And a virus was the flu!

I guess I'll stick to my pad and paper
And the memory in my head
I hear nobody's been killed in a computer crash
But when it happens they wish they were dead!

面白いが、そのまま訳すことができない。

Your momma's so fat, that when she sat on a binary tree she turned it into a sorted linked-list in O(1).

お前のカーチャンは超絶にデブいので、バイナリツリーの上に座ったら、O(1)でソート済みのリンクリストに変えちまうぜ。

なんて便利なカーチャンなんだ。

The women I went to university with had this to say about their chances of meeting guys in our CS department : "The odds are good, but the goods are odd."

大学の同期の女が、コンピューターサイエンス科で、男に出会う可能性についてこう言っていた。「可能性はいいわ。でも、いいのは可能性の問題ね」

oddに含まれる二つの意味をうまく使ったいい英語のジョークであると思う。

A programmer is walking along a beach and finds a lamp. He rubs the lamp, and a genie appears. “I am the most powerful genie in the world. I can grant you any wish, but only one wish.”

プログラマーが砂浜を歩いていて、ランプを見つけた。ランプをこすると、ランプの精が現れた。「ワシは世界一強いランプの精である。何でも望みの願いを叶えてやろう。ただし、願い事はひとつだけだ」

The programmer pulls out a map, points to it and says, “I’d want peace in the Middle East.”

プログラマーは地図を引っ張りだし、指差して言った。「中東を平和にしてくれ」

The genie responds, “Gee, I don’t know. Those people have been fighting for millenia. I can do just about anything, but this is likely beyond my limits.”

ランプの精は答えた。「ううむ、それは難しいな。そのへんの奴らはもう何千年も争い続けているからして。ワシは何でも叶えられるとは言ったが、その願いはワシの力をもってしても難しい」

The programmer then says, “Well, I am a programmer, and my programs have lots of users. Please make all my users satisfied with my software and let them ask for sensible changes.”

そこでプログラマーは言った。「そうか、僕はプログラマーなんだ。僕のプログラムにはユーザーが大勢いるんだよ。僕のユーザー全員が、僕のソフトウェアに満足して、さらに大胆な変更をも受け入れるようにしてよ」

At which point the genie responds, “Um, let me see that map again.”

するとランプの精は答えた。「さて、その地図を見せてもらおうか」

My grandpa told me a non-CS variant of this several years ago. It went something like this: A young man finds a genie's lamp. He rubs it, and out pops the genie. "For freeing me from the lamp, I shall grant you one wish," the genie says. The man thinks for a moment, then says "I wish for a road to Hawaii." The genie gasps. "What a thing to ask for! Even for me it would take years to complete! Do you have a simpler wish?" The man thinks long and hard this time, then he says "I wish to understand women." The genie looks at the man, sighs, and says "You want two or four lanes on that road?"

俺のじいちゃんが、このジョークのプログラマーに関係ない派生版を昔話してくれたよ。こんな感じ。若い男がランプを見つけた。こすると、ランプの精が出てきた。「ワシをランプから自由にしてくれた礼に、願い事をひとつ叶えてやろう」とランプの精は言った。男は少し考えてから、言った。「ハワイまで行ける道がほしい」。ランプの精はうめいた。「何を考えているんだ。ワシのちからを持ってしても、そんなのは何年もかかるぞ。もっと簡単な願いはないのか」と。男は、こんどは長い間一生懸命考えて、言った。「女というものを理解したい」と。ランプの精は男を見て、ため息をつき、言った。「道は二車線か? 四車線か?」

ユーザーは、ソフトウェアの些細な変更をも嫌うものである。男が女を理解するのはかくも難しい。

Three programmers meet accidentally at the urinal while attending a technical conference. The first programmer finishes up his business, washes his hands with loads of water, walks over to the towels and uses almost the entire roll to dry his hands. He turns to the other two and says "At Microsoft, we are trained to be extremely thorough."

三人のプログラマーが、技術カンファレンスの参加中に、トイレの中で出会った。最初のプログラマーは用を足し終え、手を大量の水で洗い、タオルをほとんど使い尽くして手をふいた。彼は二人に向き直って言った。「マイクロソフトでは、やりつくせと教育されるものだ」

The second programmer finishes up, walks over to the sink and washes his hands with much less water, then uses a single towel to dry his hands. He remarks to the other two "At IBM, we are trained not only to be very thorough, but also very efficient."

二人目のプログラマーが用足しを終え、手洗い場に向かって、さっきよりだいぶ少ない量の水を使って手を洗い、たった一枚のタオルを使って手をふいた。彼は残りの二人に向き直って言った。「IBMでは、やりつくせと教育されるが、効率的にやれとも教育されるものだ」

The third programmer finishes his business, walks right past the sink and towel rack and lauds over his shoulder as he walks out the door: "At Apple we don't piss on our hands!"

三人目のプログラマーが用足しを終え、手洗い場もタオル掛けも無視して、ドアに向かいつつ、肩越しに聞えよがしに言った。「Appleでは、手に小便をひっかけたりしないものだ」

これは相当に古いジョークで、投稿主が聞いたオリジナルの話は、役者はそれぞれ、Motorolla、DEC、Sunだったらしい。

さらに古いオリジナルのジョークでは、役者は有名大学(Harvard/Yale/Dartmouthなど)だったらしい。

Q: How come there is not obfuscated Perl contest?

A: Because everyone would win.

Q: なぜ醜悪なPerlコンテストは開催されないのか?

A: 皆勝ってしまうから。

Documentation is like sex. When it's good, it's very good. When it's bad, it's better than nothing.

ドキュメントとはセックスのようなものだ。もし良かった場合、それはとても良いものだ。もし悪かったとしても、何もないよりはマシなのだ。

はて。

It's been said that if you play a windows CD backwards, you'll hear satanic chanting...worse still if you play it forwards, it installs windows.

WindowsのCDを逆再生すると、悪魔を褒め称える歌が聞こえるという。なお悪いことに、もし通常再生すると、Windowsがインストールされてしまう。

Q: How many programmers does it take to kill a cockroach?

A: Two: one holds, the other installs Windows on it

Q: ゴキブリを一匹殺すのにはプログラマーが何人必要か?

A: 二人。一人が取り押さえ、もう一人がWindowsをインストールする。

コメント: これはゴキブリの虐待だ。

不自由なWindowsのインストールとは恐ろしい。

What is your best programmer joke? | Hacker Newsに乗っていた面白いジョーク

A TCP packet walks into a bar, and says to the barman "Hello, I'd like a beer."
The barman replies "Hello, you'd like a beer?"
"Yes," replies the TCP packet, "I'd like a beer."

I'd tell you my UDP packet joke, but I'm not sure you'd get it.

TCPパケットがバーにやってきて、バーテンダーに言った。「やあ、ビールだ」
バーテンダーは答えた「やあ、ビールか?」
「そうだ」とTCPパケットが答えた「ビールだ」

UDPパケットジョークも話したいんだが、みんなに受けるかどうかわからないな。

2014-01-09

AREAのHDDケース、SD-U3HD2Cは地雷、買うべからず

私は、引っ越す前までミドルタワーのコンピューターを使っていた。さて、引っ越すにあたって、このような持ち運びに不便なコンピューターは、実家の物置に、ひとまず放り込んだ。今はラップトップも十分なパフォーマンスを持っていることだし、もはやデスクトップにこだわる理由もない。ラップトップと、まともなキーボードとマウスさえあれば、とりあえずは作業できる。固定の場所には、まともなディスプレイを設置すればいいだけだ。

さて、もうかれこれ6年ほど使っていたミドルタワーのコンピューターの処分方法を考えなければならないのだが、さしあたっての問題は、データのサルベージだ。昔のデータで、持っておきたいものがある。しかし、色々と面倒だ。

まず考えられるのは、ミドルタワーのコンピューターにインストールされたOSを起動して、何らかの方法でデータを移行する方法だ。しかし、これは色々と面倒だ。

まず、コンピューターを使える状態にしなければならない。使える状態にするというのは、電源ケーブル、ディスプレイケーブル、キーボード、マウスを接続して、安定した場所に設置しなければならない。実家で、その作業をするのはあまりにも面倒だ。

かつまた、コンピューター自体を作動させたとして、どうやってデータを移行するのだ。USB接続の大容量のストレージ経由か? LAN経由か? そのようなUSB接続の大容量のストレージは持っていないし、ルーターも持っていないので、いずれにせよ、なにか買わなければならない。

どうせ買うならば、これからも必要になりそうな機器の方がよい。SATAストレージをつなげて、USBストレージとして機能させる機器だ。一般的な正式名称はよくわからないのだが、HDDケースなどと呼ばれているようだ。

というわけで寺町に行き、SD-U3HD2Cなる製品を買った。ただし、読者はこれを買ってはならない。

SD-U3HD2C 究極なバックアップツール(titleママ)

この製品は、3.5インチのHDD、2.5インチのHDD/SSDを、二台までさすことができる。そして、二台ともUSBストレージとして使えるのだという。他にも、これ単体でストレージをクローンする機能があるそうだが、それは必要ない。ちょうどHDDが二台あるので、二台同時に扱えるのは便利だと思ったのだ。

まず、一台だけさしてみる。なぜかHDDが横に揺れる。ラップトップに接続してみるが、動作しない。なぜだろうか。別のUSBポートにさしてみるが、やはりUSBストレージとして認識されない。どういうことだろう。

不良品かと思い、返品のことを考えながら、少し雑事をして、さてまたラップトップに戻ってみると、なんとUSBストレージとして認識されていた。一応、使えるようだ。

はて、不思議なこともあるものだと、いちどUSBケーブルを抜いてから、またさしなおしてみる。すると、やはり認識されない。数分そのまま待っていると、また認識された。なんという遅さだ。

ふとみると、さっき認識されなかったUSBポートは、USB 3.0だ。はて、この製品はUSB 3.0対応と箱にデカデカと謳ってあるのだが。

ためしに、USBメモリを指してみたが、一瞬で認識された。別に持っていたUSB接続の外付けHDDをさしてみるが、やはり一瞬で認識された。あきらかに、この製品がおかしい。

さて、肝心の、二台同時に使える機能はどうだろうか。二台のHDDをさして、再び試してみる。認識に何分も待たされた挙句、なぜか一台しか認識されなかった。クソすぎる。

というわけで返品した。その日のうちであるし、店頭でも動かなかったので、すんなり認められた。

教訓としては、安物は良くないということだ。

さて、いずれにせよ、SATAストレージをUSBストレージにする変換器は必要だ。今度は、安物ではなく、定評のあるものを買わなければならない。何を買えばいいだろうか。

2014-01-08

bzrは死につつある。Emacsは移行しなければならない

bzr is dying; Emacs needs to move

Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。

私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。

bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている:

http://www.stationary-traveller.eu/pages/bzr-a-retrospective.html

[訳注:翻訳:本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて]

全Emacs開発者はこれを絶対に読め、そして一晩寝て、またもう一度読め。この記事の著者が書いたような罠に、Emacsも陥っていると言いたいからではない。「ソレ」は別の話だ。いま議論すべきなのは、bzrの失敗の重力圏から脱出するということについてだ。

理論的には、bzrのコードベースが十分にまともで、これ以降も継続して使うことができるならば、このbzrの失敗は、我々には何らの影響も及ぼさぬはずである。私が思うに、bzrは十分にまともである。

現実的には、bzrにとどまることは、Emacsの将来性とイメージに悪影響を与える。失敗したバージョン管理システムを使い続けるということは、プロジェクトに新しい開発者を惹きつけられないことを意味するからだ。

苦々しい事実としては、多くの若いハッカーたちは、すでにEmacsは恐竜であると考えている。難しく、ゴテゴテとして、重量級で、まあ一般的に言えば前世紀の遺物だ。このイメージを払拭するためには、我々はヘンテコで異質で前時代的なものにとどまることはできないのだ。

現在、bzrの利用を継続するということは、そういうことになってしまうのだ。bzrは学習コストが高いというわけではなく、小難しく時代遅れだという理由で、我々は新人を得る機会を損失してしまうのだ。現状から脱却するコストは、時間経過と共に上昇するばかりだ。

gitがこの戦争を勝ち抜いた。悲しいことだ。個人的にはMercurialの方が好きなのだが、だが、Mercurialにしたって、最近ははかばかしいことは聞こえてこない。私はgitの勝利に納得し、移行した。私はEmacsプロジェクトにも同様にするよう強く主張する。

私は以降にあたって技術的に主導できる、reposurgeonの作者として、私はそのためのスキルと経験を持っている(私は最近、GNU troffをCVSからgitに移行させた)。しかし、プロジェクトの主導者が、最初に決断をしなければならないのだ。

--
Eric S. Raymond

No one who's seen it in action can say the phrase "government help" without either laughing or crying.

メールで参照している記事は、このブログで日本語訳している。

本の虫: Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて

Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて

Bazaar-NG: 7 years of hacking on a distributed version control system

Bazaarの開発者が、Bazaarが失敗した理由について、当時を振り返って書いている。なかなか面白い。

Bazaar-NG: 分散バージョン管理システムを7年ハックしてきて

この7年間、筆者はBazaarプロジェクトに関わってきた。筆者はプロジェクトから距離を置き始めている今この時、筆者のこのプロジェクへの関わりや、何が良くて何が悪かったのかの意見などを、振り返ってみるべきだと思う。

この回顧録には多くの複雑な詳細が出てくるので、筆者の誤りもあるかも知れない。間違いを見つけたら知らせてくれ。

黎明期

< ddaa> dscmsには2種類ある。古臭いやつと、実験中なやつ。

2004年、筆者は、 SambaのコントリビューターであるMartin Poolのブログをたまに読んでいた。当時、Martinは異なるバージョン管理システムを調べて、ブログに記していた。筆者も当時、 CVS から Subversionに移行したところで、そこで紹介されている、別の新しいソース管理システムには興味があった、たとえばdarcsやtlaといったものだ。tlaは少し試してみたが、そのモデルは気に入ったものの、実際に使うには面倒すぎると考えた。

2004年末か2005年はじめあたりに、MartinはCanonical Ltd.に入社して、新しい実験的なバージョン管理システム、Bazaarを開発していると発表した。コマンドラインではbazであるBazaarは、GNU archのforkである。

その年の春、筆者は Linux.Conf.Au in Canberraに参加した。MartinはBazaar-NGについてのトークを行った。とうじはそういう名前で呼ばれていて、その場で簡単なデモも行われた。当時のストレージフォーマットは、まだバージョン管理されたファイルの完全なテキストを保持していたので、それほど効率的ではなかった。筆者は単純なUIと分散バージョン管理システムの信頼できる機能が気に入った。そこで、筆者はBazaar-NGを注目しておくリストに付け加え、メーリングリストを眺めた。

LCA 2005における、別の有名なイベントとしては、BitKeeperプロトコルに関する tridgeの悪名高いプレゼンがあった。このトークにより、Larry McVoyはBitKeeperの無料版をやめたし、LinusはGitをハックし始め、Matt MackallはMercurialを始めた。もちろん、当時これを予想できたものは誰一人としていない。

Sambaのbzrの利用

その年の暮れ、SambaははじめてGoogle Summer of Codeに参加した。我々はすべての生徒にSubversionのメインレポジトリへのコミット権を与える管理をしたくなかったので、Bazaarを試してみることに決めた。我々はBazaarにインポートしたソースコードを提供し、生徒たちに、変更を含んだクローンを公開するように言った。

筆者はMartinと知り合いだったし、Bazaar-NGはm当時のDVCSの中ではいい選択だったのだ。すべてのソースコードをSubversionからBazaarに変換するのは大変だった。当時はまだfastexport/fastimportはなかったし、そもそもSubversionからBazaarに変換するためのサポートも一切なかった。ただ、Tailorという、あらゆるVCSからあらゆるVCSへのへんかんをさぽーとしようとしていた ツールがあっただけだ。

Tailorをどう使おうとも、バグは避けられなかった。筆者はいくつかのバグ修正に貢献することになったが、結局信頼できるほど動かすことはできなかった。明らかに欠点は、変換方法であるディスク上のすべての変更を再生にあった。とてつもなく遅かったのだ。

Samba Summer of CodeにBazaarを使うのは、どうみても成功とは言えなかった。とても遅かったし、バグにぶち当たりまくった。明らかに、bzrはSambaのようなサイズのプロジェクトに使うほどには成熟していなかったのだ。筆者はまだ熱中していた。モデルはいいし、bzr開発者はバグ報告への対応が早いし、それに単純でとっつきやすいUIがとても気に入っていたのだ。小さなプロジェクトには筆者は使っていて、とてもよく動いた。

Bazaarは他の分散バージョン管理システムとも組み合わせて使うこともできるが、Subversionとの組み合わせはとりわけてひどく、欠けている部分も多かった。筆者は、この当時、GitのUIがとても基本的で、かろうじてまともに使うためにはラッパースクリプト("cogito")が必要だったことを記憶していている。

最初の貢献

夏過ぎに、筆者は最初のbzrパッチで貢献した。Tailorのソースをいじったことを別にすれば、これが筆者の最初の公開したPythonのコードだ。パッチを受け付けてもらうためには、色々と苦労が必要だった。

その年の暮れ、Gustavoがsvn2bzrの最初のバージョンを公開したので、筆者はテストを開始し、貢献し始めた。svn2bzrの発表に対する私のreplyは、この後、数年にわたって我々が遭遇し続けた問題を的確に言い表している。

sambaレポジトリを変換しようとしたのだけれど、最初の10コミット(~11000コミットのうち)を変換するだけで6時間かかった。tailorだと10時間以内に終わる(メインブランチの6000コミットの変換だけど)

比較のためにいうと、2012年に昔のSambaのSubversionレポジトリの最初の6000のメインラインリビジョンをインポートするのは、5分以内に終わる。

当時を振り返るに、Bazaar-NGは、今よりもずっと、コミュニティプロジェクトだったのだろう。そりゃ、Canonicalは主要な開発者を雇っていたし、ほとんどのファイルにCanonicalのコピーライトはあったが、それよりもずっと多くの人々が貢献していたし、ロードマップはCanonicalの都合ではなく、自由ソフトウェアプロジェクトの需要に従って決められていた。Bazaar-NGは、"bazaar-ng.org"という独自のドメインを持っていた。最初の数年は、貢献者ライセンス同意に署名する必要もなかった。

筆者が興味を持った機能に、Foreign Branchesがあった。Aaronがwikiに書いたように、Bazaar-NGの多数のファイルフォーマットを隠匿する既存の機構は、たとえばSubversionのような、他のバージョン管理システムのフォーマットをサポートするのに使うことができるはずだ。これに触発されて、筆者はBazaarにSubversionを取り込むためのプラグインのハックを始めた。名前は無難にbzr-svnとした。その当時、Sambaは近い将来にSubversionから移行する予定はなかったので、筆者はこれにより、Sambaをbzrからハックできるようになるとも期待していた。

初めてのスプリント

2006年の5月あたりに、LarstiQと筆者は、ロンドンで行われたBazaarのスプリントに招待された。筆者にとっては初めてのスプリントとなる。このスプリントは初めてにして唯一の、Bazaar-Mercurial合同スプリントで、Canonicalのオフィスで行われた。

スプリントには6人参加した。Martin Pool, Robert Collins、John Meinel、Aaron Bentley、Wouter van Heijst、それと筆者だ。この当時、MartinとRobだけがCanonicalで働いていた。他のCanonical社員が遊びに来ることもたまにあった。RobはGNU archのユーザーフレンドリーなforkであるbazにとりかかり、JohnとAaronはtlaとそのforkに、それぞれとりかかった。

スプリントはとても強烈で、部屋に皆で集まると、新しいことが次々と起こるものだ。私自身はそれほど大量のコードを書いたわけではないが、人生であの数日以上に、多くの物事を学んだ日はない。私はエクストリームプログラミングやユニットテストやテスト駆動開発や高度なPythonプログラミングに触れた。あらゆる種類の新しいバージョン管理の概念には、不思議な名前がついていて、まるでX-Filesを見過ぎたような人間が名づけたようだった(ghost rivision、patience diff、history horizon、nuclear launch codesなどなど)

その日の印象は今でも残っている。筆者は小さなホテルの会議室に座って、Robと最初のCommitBuilder APIの実装をペアプログラミングしていた。JohnとWouterがbzrをunicode互換にするためにJohnのどでかいブランチをハックし、最後にしぶとく残るテストを通そうとしていた。Aaronは筆者にrevision id aliasとghostを昼飯を食べながら説明してくれた。小さなCanonicalのオフィスに収まりきらなくなったので、誰かのキッチンテーブルの上に座っていたのを思い出す。David Alloucheは、ホテルのバーでビールをやりながらBazaar-NGの前身とtlaについて筆者に語った。筆者はネストされたツリーについて語った。6年後、われあれは未だに議論している。楽しかった。あのやる気と効率といったら。

あのスプリントの印象は強烈だった。あの時、良き指導者に恵まれなかったら。Martinがスプリントを開催してくれて、Canonicalがスポンサーしてくれて、あの4人のハッカーの辛抱強さには、本当に感謝している。

bazとarchの影響

Bazaar-NGのモデルは、Bazaarの前身(baz)が受け継いだ、archモデルの欠点を埋めることを目的としていた。とはいえ、まだtla/baz/archのレポジトリをインポートして、ユーザーに既存のレポジトリをアップグレードさせることができるはずだった。もともと、Bazaar-NGは次世代のbazのためのPythonで書かれたプロトタイプ的な位置づけだった。モデルの正しさが実証できたならば、baz 2.0として、Cで再実装される予定だったのだ。ある時点で、筆者にも正確には断定できないが、Pythonで書かれたbzr自体が、bazの次世代となることが決定され、既存のbazコードベースは、放置された。

私はArchやBazの利用にあたって不満があったわけではない。ただし、長年、そのモデルについて学ぶにつれて、その欠点も見えてきた。Archはユーザーがリビジョンやディレクトリーやタグに付けられる名前に、かなりの制限を設けていた。学習曲線は急峻で、ユーザーは複雑な内部モデルや、多くの操作用のサブコマンドを熟知しなければならなかった。自分が何をしているかわかっていない場合、自分の足を撃ちぬくのはとても容易で、取り消しできない操作も一部にはあった。誰か他人のブランチから派生する場合に、単に既存のデータをコピーするのではなく、派生先ブランチを歴史としての親ブランチとして参照するようになっていた。もし、他人のレポジトリ(とリビジョン)がネット上から消え失せれば、自分のリビジョンより他の歴史をたどることはできなくなってしまうのだ。

bzr(と既存のArchデータフォーマットの互換性がある部分に関しては、その前身にあたるbazも含めて)はもっとユーザーフレンドリーかつロバストになろうと努力した。ユーザーインターフェースは、馴染み深いCVSやSubversionのコマンドラインに少し近いものになった。リビジョンを内部的に区別する長ったらしい擬似乱数文字列にくわえて、リビジョン番号をユーザーに表示するようにもなった。ほとんどすべての操作はやり直し可能だ。レポジトリはすべてのデータを含むため、歴史へのアクセスは高速で、自分以外の誰かのHTTPサーバーが問題なく稼働しているかどうかに依存する必要もなくなった。WindowsとMacも二級市民ではなくなった。bzrは、UNIX風のスラッシュにくわえて、バックスラッシュもパス区切り文字として認識するようになったし、ファイル名のエンコード方式も規定した。

データフォーマットはデータモデルの結果であり、その逆ではない。データモデルに変更がくわえられたならば、その変更に会うようにファイルフォーマットが変えられる。これは従来のデータベースではとても厄介なことだが、DVCSレポジトリのような分散データベースでは、それほどでもない。

bzrはarchからいくつかの基本的な機能を受け継いだ。ブランチはネット上から消えやすいため、リビジョンも失われることがある。バージョン管理システムはそのことを知っている(なぜならばどこか別の場所へのリファレンスであるから)が、その中身にアクセスすることはできない。これは"ghost rivision"とよばれている。bazではブランチを素のhttpを経由して共有することができた。bazにおけるリビジョンとファイルはユニークな識別子が振られていて、名前が変えられたとしても、その正体を追うことができる。bzrはリビジョンIDとファイルIDという概念は保持したが、その制約を変えた。IDを単に擬似乱数文字列としたのだ。目的はgitがやっているような「おバカ」な中身のトラッキングではなく、正体のトラッキングだ。

これらの機能はとてもいいものなのだが、果たして苦労に見合うだけの利点があったかどうか疑問だ。どうも思うに、bzrは人々がarchやそのforkに対して思いつくあらゆる機能をサポートすべきだ、ひとつのDVCSはすべてを統べる、といった感じの風潮があったのではないか。一部の機能がどのくらい役立つかは、当時としても疑問だった。

筆者はghost revisionの熱烈な支持者であった。ghost revisionは別のフォーマットをサポートするのにとても便利だったからだ。しかし、パフォーマンスに悪影響を与え、fetch操作における失われたリビジョンを見つけるアルゴリズムも複雑になった。また、我々は、オホン、幽霊と相いれぬ多くのバグに悩まされてきた。bazからのインポートさえなければ、ゴーストのサポートは、もう少し後まで遅らせるべきだったのだ。

愚直な転送のサポート。ブランチの提供元にbzr専用のコードを必要とせず、HTTPやFTP経由でアクセスできることは、とてもいい機能だ。この利点としては、通常のHTTPやFTPサーバーを開発ブランチのホストに使えるということだ。特に、クラウド以前の時代には、CVSやSubversionのように、独自のコードをサーバー上で動かす必要があることに比べて、とても大きな利点だった。

Bazaarの転送の隠匿により、同じコードがローカルレポジトリにもリモートレポジトリにも利用できた。bzr logをフルクローンせずにリモートレポジトリに対して走らせることができるのは感動だ。このような方法で愚直な転送をサポートするには、ツケも支払わなければならなかった。HTTP越しのパフォーマンスに影響するため、レポジトリへのアクセスは、あまりシークできないし、巨大なデータを読み込むこともできなかった。

だが、その代わりに、リモートレポジトリにもあらゆる操作ができるのだ。ただ、ユーザーがフェッチしてローカルで自前で行うのではなく、レポジトリとブランチに対するすべての操作をサーバー側で行うbzrスマートサーバーを実装するときには、これは問題になったのだが。

bazにあった素晴らしい機能が、パフォーマンス上の理由で捨てられたものもある。cherry-pick merge trackingのサポートだ。

(Some of Martin's early notes on Arch).

当初、Bazaarのリリースは頻繁だった。しばらく、月齢リリースがあった。三週間の開発と一週間の安定化とプラグイン修正だ。開発は小刻みで、すぐに採用された。ファイルフォーマットや設定にほんのわずかでも、以前のバージョンのbzrが読み込めない可能性がある極小の新機能が追加されたツォいても、ファイルフォーマットバージョンがインクリメントされた。変更は積み重ねるのではなく、即座に適用したのだ。これにより、数ヶ月おきに新しいフォーマットが出ることになった。その後、フォーマットの変更は収まり、2009年からは、新しいフォーマットは追加されていない。残念ながら、bzrは二週間おきに新しいファイルフォーマットを追加しやがるぜ、というイメージを払拭させることはできなかった。

オーガ

筆者が参加していたもうひとつのプロジェクトは、「オーガモデル」と呼ばれていた。なぜならば、オーガのように、そしてソフトウェアとしては珍しく、レイヤーを持っていたからだ。

Bazaarが新しいバージョンのファイルフォーマットをこれほど頻繁に追加できた理由は、UIと、APIと、ファイルフォーマットの実装が、綺麗に隠匿されているからだ。これはgitとはえらい違いだ。gitはディスク上の様々なものをUIに露出させている(例えば、ディスク上のリビジョンを識別するためのsha1チェックサムだとか)。既存のgitのツールを、全く別のファイルフォーマットに対応させるのはとてもむずかしい。Bazaarにとっては、とても簡単だ。

思うに、この点こそが、どちらも似たようなモデルを使っているBazaarとGitの重要な違いなのだろう。このために、Bazaarは昔の日効率的なweave formatからpack formatに簡単に移行できたわけだし、別のフォーマットも第一級市民としてサポートできるが、大量のグルーコードや余計な複雑さがついてまわる。様々な点で、Bazaarはトップダウンに作られているのだ。Gitのようなボトムアップとは違う。

ただし、これはBazaarがGitより優れていると主張しているのではない。David Wheelerかだれかが言ったはずだが、

All problems in computer science can be solved by another level of indirection... Except for the problem of too many layers of indirection.

コンピューター科学におけるあらゆる問題は、さらに一段階の間接参照を挟んでやれば解決できる。ただし、あまりに間接参照のレイヤーが重なり過ぎるという問題だけは解決できない。

パッチの採用が困難

Bazaarは変更に対してかなり厳しい要件を設けていた。これは良くもあり悪くもある。すべてのバグフィクスや挙動の変更は、テストスイートにも変更を反映させたり、あるいはテストスイートを拡張したりする必要がある。すべての変更は、二人のコミッターによってレビューされる必要がある(ただし、コミッターはセルフレビューできるので、あと一人だけでもいい)。CanonicalがBazaarのほとんどのソースコードの著作権を保有する(歴史的な理由による例外もある)。それから、2009年からは、Canonicalのcontributor license agreementに署名する必要もでてきた。

筆者の初めてのパッチが採用されるには相当に時間がかかった。修正自体は簡単だったのだが、適合するテストを書くのは難しかった。たまに現れる貢献者も、この問題と格闘していたし、実際、何人かには貢献を避けるだけのものがあった。やがて、CanonicalのBazaarハッカー達は貢献者からのパッチを代行するようになったので、バグ修正や変更が採用されるのが、だいぶ簡単になった。

もちろん、れびゅーとテストにここまで厳格であることで得られる恩恵もあった。採用されるほとんどの変更は高品質だった。テスト、リファクタ、その他の些細な変更が自身を持って行えた。筆者はBazaarに大きなデータロスのようなバグを見たことがない。regressionは起こるには起こったがまれだった(プラグインの互換性を壊すAPIの変更は別だが)。筆者は何年も、bzrのtrunkを快適に使っていた。

ただ、品質要求が貢献者を遠ざけたわけではないと思う。GitやMercurialにしても、そこまで厳格ではないかも知れないが、似たような要件を課していただろう。彼らとて、そのために行われなかった貢献もあったはずだ。

あるいは、Bazaarがよそに比べて複雑なところが、貢献の大小のちがいなのだろうか。ほとんどのGitユーザーはファイルフォーマットの詳細を知っているし、たとえ知らないにせよ一日で学べる。Gitのバグをソースファイル上で見つけるのは、様々なレイヤーが関係するBazaarを理解するよりも、だいぶ簡単だ。新し目のBazaarのファイルフォーマットは、たいていドキュメント化されていない。bzrの世界にいて何年も経た後でも、いまだに筆者は、gitのpack実装のバグを修正するほうが、Bazaarのバグを修正するより簡単だと感じる。

あるいは、違いを如実に語る例として、Gitの詳細のLWN記事が、Gitのリリースから5日後に公開されたことが挙げられるだろうか。

これはファイルフォーマットについて知りたい一部のギークどもが臆病風にふれられて逃げ出すから問題というわけではない。ユーザーが何か低級層のコードの問題に出くわした時、その問題を修正するだけの力がないことが問題なのだ。ユーザーがbzrのバグに出くわして、レポジトリにアクセスできなくなり、悪態をつきながら離れていったのをみるとき、とても残念に思う。そのバグがどんなに些細なものであったにせよ。

プラグイン

Bazaarの良くも悪くもある別の点としては、プラグインだ。bzrlibのほぼすべての箇所は、プラグインで拡張可能だ。Bazaarを変更するプラグインで最も多い利用方法は、新しいサブコマンドの追加だ。プラグインがインストールされれば、常にbzrlibに読み込まれて初期化されるのだ。

Pythonを少しかじっていればプラグインを書ける。いいドキュメントが揃っているし、基礎的なプラグインを書くのには、bzrの詳細についてそれほど知っている必要はない。プラグインではほとんど何でもできる。例えばレポジトリのファイルフォーマットのサポートだとか、bzr logの出力フォーマットのオーバーライドだとか、レポジトリにアクセスできるプロトコルの追加だとか。

ある意味、プラグインはbzr本体に新しいコードが採用されにくい状況への対象方法として使われていたのだ。わざわざレビューワーを説得する必要もない。テストを書く必要もない。要するに、プレグインは新しい機能を試すのに最適だったということだ。Canonicalへの著作権譲渡も必要ない。

プラグインはBazaar本体より遅れていることが多かった。APIに対する変更は、そのAPIを使うプラグインをぶち壊してしまう。古いAPIを非推奨扱いにして、ユーザーに新しいものを使うように促す機構も用意されていた。ただし、bzrlibには大量の公開されたAPIがあったのだ。現実には、プラグインで使うのはその一部で、公式な方法で非推奨扱いにするのは時間がかかったので、しばしば見送られた。

新機能をプラグインに突っ込むのがとても簡単であるがために、変更を上流に採用させるためのインセンティブに欠けていた。実際、これにより、インストールされたBazaarを最新版に保つというのは、Bazaarバージョンとプラグインのバージョンをジャグリングしているようなものだ。お互いに互換性がなければならないのだ。

我々はBazaar自体にもっとプラグインを盛り込むべきだったのだ。Pythonのように、バッテリーまでついてます[訳注: batteries includedとは、Pythonの標準ライブラリがとても充実している様を言い表す慣用句]とね。MercurialもGitもやっていたことだ。

急速な開発

2005年から、CanonicalのBazaar部署はゆっくりと5人にまで増えていった。2006年と2007年は、新しい楽しい変更が常にあった。スプリントももっとあったし、筆者もさらに大勢のbzrの貢献者に対面した。Andrew Bennetts, Vincent Ladeuil, Ian Clatworthy, Martin Albisetti。

Bazaarはファイルフォーマットをとても改良した。そしてさらにpackファイルに入れるためにも変更した。高パフォーマンスのスマートサーバーも入ったが、ただし、「高パフォーマンス」という部分は、当時はやや理論的なところがあった。我々はシリアライズされたリビジョン(バンドル)をメールで送りあった。Bazaarのグラフィカルなフロントエンドを作る人や、Webフロントエンドを作る人も出てきた。

Bazaar開発の議論は、ほとんどIRCかメーリングリストで行われていた。変更を提案するには、パッチか、マージリクエストをメーリングリストに送る。するとコミッターがレビューして、メインのBazaarブランチを管理するBOTに送る。やがて、Aaron BentleyがBundleBuggyというWebサイトを立ち上げたので、メーリングリストに提出された変更とその状態をトラックすることができるようになった。

大移行

2007年の終わり頃、最初の大き目の自由ソフトウェアプロジェクトが分散バージョン管理に目をつけ始めた。2008年から2009年にかけて、大量のプロジェクトが中央バージョン管理から移行してきた。

前回のVCS移行、すなわちCVSからSubversionからの移行は、Sambaではとてもうまくいった。2007年10月に、ある開発者が、Gitへの移行を提案した。筆者はSambaに貢献するために、bzr-svnを長年使っていて、GitのかわりにBazaarを提案したかったが、パフォーマンスという点で、まだGitには遠く及ばないと気がついた。Sambaが移行した後、筆者はbzr-gitをハックし、Bazaarを使い続けられるようにした。

2008年1月、BazaarはGNUプロジェクトになった。現実に、特に何かが変わったというわけではなかった。

2008年、さらに多くのプロジェクトが、三大分散バージョン管理システムに移行し始めた、Mercurial、Git、Bazaarだ。筆者はまだforeign branchプラグインや、bzr-gitや、Robが始めたbzr-hgプラグインに関わっていたし、さらにbzr-svnや、 bzr-gtkにも関わっていた。

さて、Launchpadはマージの提案をまともにサポートしたので、BazaarはLaunchpadに移行して、メーリングリストに送られたbundleに変わって、Launchpadを使ってマージの提案を行うようになった。

一方、DVCSツールもだいぶ発達してきた。多くの人が、Visual StudioやEclipseやNautilusにDVCSを組み込みはじめた。Ian Clatworthyはドキュメントをまともに整備し、bzr-explorerを始めた。CanonicalのBazaarチームは、Bazaarに移行したい様々なプロジェクトからの要望に答えるべく働いた。

筆者は、様々な外部ツールとの連携が十分にとれていないことが、ユーザーからとっつきにくくしているのではないかと危惧していた。当時を振り返るに、おそらく筆者は、原因と結果を取り違えていたのだろう。

改変不可能性と、完全な歴史

Bazaarは、それ以前にあったArchやSubversionのように、歴史を忠実に記録することに力を注いでいた。歴史は参照されるが失われることもある(ghost rivision)。理由は単になくなったか、あるいは誰かが意図的にレポジトリから消したか(たとえば、誤ってパスワードをコミットしてしまったとか)

Bazaar開発者は常に、歴史の改変は邪道であると考えていた。歴史が正確ではなくなるという以外の、改変可能な歴史に対する反論としては、歴史を改変させることを許してしまうと、ユーザーが容易に自分の足を撃ち抜けるようになってしまうからだ。歴史の改変は、同じデータに対する2つの微妙に異なるバージョンを生み出す。このような改変を拡散させるのは、関わりたくないほどに難しくなる。

当初の計画では、Bazaarにアノテーションをつける予定だった。Gitでオブジェクトにノートを付与して、コミットメッセージの誤字脱字を修正できるのと同じだ。

その他のBazaarの設計思想としては、後で必要となる場合に備えて、可能な限りの情報を保持するということだ。Bazaarは明示的に、リネームを記録しているし、たとえば、一連の変更点を提出させるときなどに、歴史を組み込むことを推奨している。

パッチのためにユーザーの歴史を破棄するのではなく、変更をもたらす新しい"mainline"コミットとして参照される。

"mainline"とは、左手側の祖先である、いうなれば、tip(ノードの最初の親)からDAGの左手側に潜っていって、ツリーの根本まで戻っていったときにみるリビジョンだ。

BazaarのUIはmainlineの概念を反映している。たとえば、ドットなしのリビジョン番号はmainlineのリビジョンで、"bzr log"と"bzr qlog"は、デフォルトでmainlineしか表示しない。貢献者がパッチを提出する前の変更点である右手側の歴史は、本当に必要とするときのために記録されているが、通常は隠されている。

この時点で、多くのプロジェクトが、既存の歴史を、次世代DVCSにインポートしてテストしようとしていた。Git、Mercurial、BazaarメーリングリストとIRCチャンネルは、どのシステムが、他のシステムには存在する必要不可欠な機能を欠いているかという議論とフレーム戦争であふれかえっていた。多くのプロジェクトが、それぞれ思い思いにピカピカの次世代ソースコード管理ツールを選んでいくに連れ、bzrの問題点が、次第に明らかになってきた。

パフォーマンス

長年、パフォーマンスは次第次第に向上してはいたものの、Bazaarはまだ、中規模から大規模のプロジェクトで、十分な速度ではなかった。プロジェクトは、Bazaarを使うと、Gitやmercurialを使った時に比べて、より多くのディスク容量を必要とした。

運用

Bazaarが提供しているいくつもの運用は、人々を混乱させた。bzrは、独立したブランチからお互いにpullしたりpushしたりといった真の分散型として使うこともできれば、SubversionやCVSのような、中央環境でやるような、中央ブランチに束縛されたローカルブランチとして使うこともできた。Bazaarの主要な開発者は中央管理的な運用をすることはなかったので、これはやや特殊な用法だが。

一つのブランチにつきひとつのディレクトリという方針は、小規模なプロジェクトにはうまく動くが、レポジトリのサイズが増大するにつれて破綻した。ユーザーはディスク効率のため、複数のブランチから共有されるレポジトリの作成を余儀なくされた。Cプロジェクトではたいてい、同じworking treeを複数のブランチで再利用するのは便利なことだ。これはBazaarでも可能なのだが、それほど便利ではなかった。

ヒストリートラッキング VS コンテンツトラッキング

History is a set of lies agreed upon.

歴史とは、合意された嘘の集合である。

Bazaarの思想の3つ目の問題は、完全に改変不可能な歴史である。ソフトウェア開発者は歴史家でも法律家でもない。多くのユーザーは、歴史を簡単にしておきたいと思うものだ。ユーザーが気にかけるのは、trunkに起こった変更を追って、変更の経緯を明らかにすることであって、trunkに入るに至ったパッチに対する個々のコミットや間違いではない。Gitは"rebase"を提供してる。これは、単に上流ツリーにローカルの変更を再適用するものだ。Gitはしばしば、バージョン管理ツールではなく、コンテンツトラッカーと呼ばれている。そういう名前で呼ばれたほうが理解しやすいのだ。

これに関係するが、Gitは単純なコマンドラインツールによって、レポジトリを低級層からひっかきまわすことができる。例えば、SVNからインポートされたレポジトリから、巨大なISOを除外することができる。Bazaarは長年、rebaseプラグインはなかったし、ようやくrebaseプラグインが出てきた時も、パフォーマンスが遅すぎたし、あまり強力ではなかった。Bazaarには、必要とあらば変な歴史を改変するためのツールは、あまりなかったのだ。

当時、筆者が少し驚いたことには、多くの人は、Gitのリネームの検出が100%の精度をもっていないことを、あまり気にしていないことだった。どうやら、リネームの誤検出に出くわすのは、それほど頻繁ではなかった(それに簡単に対処できる)ようなので、十分にやっていけたようだ。筆者もやっていけたし、問題に出くわしたのは、数えるほどしかなかった。

Bazaarのリネームに対する解決方法にも問題はあった。Bazaarはユニークな識別子を、ファイルが最初にワーキングツリーに追加される際に割り当て、ファイル名が変更されたとしても、ファイルをトラックしていた。これはファイルが独立してバージョン管理され、ユニーク識別子が2つある場合に、とても問題になった。

技術的に、BazaarとGitのデータモデルは、それほど違ってはいないというのは、興味深い点だ。Bazaarは明示的にディレクトリをトラックし、ファイルにIDを付与してリネームもトラックしていた。一方、Gitはヒューリスティックを使った。違いはむしろ思想や、ツールや、ディスクのレイアウトだ。

CanonicalのBazaar人員は、パフォーマンスの問題と、レポジトリのディスク上のサイズを解決するために、新しいフォーマットを設計した。brisbane-cre (2a)は2009年の夏頃に公開された。ただし、バグもかなりあった。特定の利用例でのパフォーマンスregressionもあった。残念なことに、この時点で、Bazaarは遅いものだという評判が定着していたため、光のように速い新フォーマットでも、揺さぶりをかけることはできなかった。

一部の人間は、Bazaarはそれほどコミュニティによる貢献がなく、完全にCanonicalの塀の中で開発されたと主張する。皮肉なものだ。Bazaarの大部分はCanonical社員に寄って書かれたことは確かだが、それはCanonicalがBazaarに貢献していた人間を雇ったからにすぎないのだ。多くの者は、Canonicalのその他のコードの開発に移っていった。

筆者も、2009年にCanonicalに入社して、Lunchpadのパッケージ側(Soyuz)の開発を、AGPLでリリースされた数カ月後から行っていた。筆者は暇な時間にBazaarの開発をしていた。

利用者減少とUbuntuへの注力とUDD

2009年の終わり頃、GitがDVCS戦争の商社となりつつあることは次第に明らかになっていった。Bazaarへのコミュニティの貢献は次第に減っていったのだ。

2009年末、CanonicalはBazaar業界に姿を現し始めた。Canonicalは商用サポートを売りはじめ、同時に、オンラインにパッチを提出した貢献者は、まず contributor agreementに署名するよう求められた。2010年のどこかで、ドメイン名がbazaar-vcs.orgから、bazaar.canonical.comに変わった。

CanonicalのBazaarチームの目的は、BazaarがUbuntuプロジェクトのパッケージ管理をうまく扱える、まともな汎用のバージョン管理システムとすることになった。CanonicalにおけるBazaarの当初の目的は、すべてのソースパッケージに使えることにより、未だにtarballとdiffに固執するUbuntu開発者に、バージョン管理の利点をもたらすことだった。

筆者はBazaarの人気のなさに失望していたものの、まだBazaarには期待していたし、Ubuntuのソースコードの管理ツールとなるという役割をはたすことにも期待していた。foreign branchのサポートは、世の中にいくつもあるVCSツールを、共通のインターフェースで扱えるという点で、重要だと考えていた。筆者はLaunchpadのテクニカルアーキテクトになったRobのかわりに、Bazaarチームに移った

James Westbyは、bzr-builddebプラグインを土台にして、すべてのUbuntuのソースパッケージをBazaarに自動的にインポートするスクリプトを書いた。Bazaarチームは、Jamesの実験的な実装を引き継いで、1万7千ほどあるすべてのUbuntuのソースパッケージを、Bazaarにインポートすることを試みた。すべてのパッケージに適用することができた暁には、Launchpadのtarballアップロードは無効化され、Launchpadにブランチをpushするという新しいアップロード方法になるはずだった。

問題なくすべてのパッケージをインポートするということは、とてもむずかしい問題であった。ヘンテコなファイル名のパッケージあり(UTF-8ではない文字や、バックスラッシュや改行)、奇妙な祖先あり(Debianからの変更をマージ、nativeからregularに変更してさらに戻すなど)、とてもでかいファイルあり、debianの複数のtarballあり、他にもあらゆる奇妙なものであふれかえっていた。

長い間、癌と闘病してきた末に、 Ianが亡くなった。Ianはbzr-explorerのドキュメントに尽力してきたし、それ以上に、陽気で、とてもいい奴だった。

パッケージブランチが古くなったことに伴うfetchが、古き良きtarball(これは広くミラーされている)より遅いとあっては、Ubuntu開発者から、あまりいい目でみられなかった。当時を振り返るに、すべてのパッケージをBazaarに移行する前に、すべてのパッケージをBazaarに正しくインポートするというのは、間違っていたのだろう。パッケージを一つづつBazaarに移行させていくほうが良かったのだろう。そもそも、Ubuntuにとって重要なパッケージは限られているわけだし、パッケージインポーターを正しく動かすという難しい作業も省ける。

負け組Bazaar

CanonicalのBazaarチーム以外の外部の人間による貢献は、2011年の半ば辺りには、まれになってしまった。2012年の初頭には、CanonicalのBazaarチームは他のプロジェクトに配置転換されてしまった。まだ、たまにBazaarのバグフィクスぐらいはするのだが。Martinは2012年4月にCanonicalを退職した

2012年の前半6ヶ月、筆者は暇な時間で、作業中のブランチを完成させた。その後は、なるがままに任せようと考えた。

そろそろ、先に進むべき時だろう。まだ気に入らない部分もあるにせよ、Gitはまともなソースコード管理システムだ。Bazaarは、これ以上発展しない。数年後にも新しいユーザーは出るだろうし、バグ修正の貢献者もいるだろうが、筆者が願っていたほど広く受け入れられてはいないのだ。

bzrはGitファイルフォーマットへの別のUIとして、つまり、Gitと競合するのではなく、Gitの一部として、第二の人生を歩むことができるだろうか? まあ、できるかもしれない。筆者も含む何人かは、そういう提案もしていた。そうするとしても、まだやるべき作業が多すぎる。bzr-gitは未完成なのだ。Bazaarが単にUIだとするならば、bzr風のGit UIをスクラッチから、libgit2とかDulwichとかの上にでも作ったほうがいいだろう。

結論

Bazaarにはもっと可能性があった。Bazaarは人気で書きやすいプログラミング言語で書かれていた。コードは綺麗で、コメントも大量にあり、テストのカバー率も高かった。Bazaarには簡単なコマンドラインUIがあり、ナイスなグラフィカルフロントエンドがあり、まともなクロスプラットフォームのサポートもあり、十分にドキュメント化されていた。何年もの間、フルタイムのエンジニアが働いていて、活発なコミュニティも存在した。

我々には、大切なものがわかっていなかったのだ。いい機能だけれど、思ったほどには必須ではない機能に注力してしまった。あまりにもやりすぎてしまった。無意味に込み入った不必要な機能を削ぎ落とさなかった。理解が難しく、貢献が難しく、巨大なレイヤー化されたコードベースのパフォーマンスの修正も難しかった。コードベースが大きくなるに連れ、バグの範囲も広くなり、リファクターも難しくなっていった。

これは筆者の専門である、foreign branchプラグインにも言えることだ。bzr logやbzr diff -c 1200やBazaarの標準APIが、GitからBazaarへのレポジトリの変換を介さずに、Gitレポジトリを直接扱えるのは、便利であるのは確かだ。しかし、そのために余計に複雑になり、余計にアーキテクチャー上の(パフォーマンスの)バグを出してまで、価値のあるものだっただろうか?

Bazaarを、いい奴、才能のある奴と開発できたのは楽しかった。筆者はとんでもなく多くを学べた。何か、新しいことを始めるべき時だ。

2014-01-05

なぜ私が飲み屋に行かないのか

久しぶりに飲み屋に行って、なぜ私が飲み屋に行かないのか思い出した。

タバコだ。

タバコを吸う人間は許しがたい。

2014-01-04

主要なハード屋がVP9のハードウェア支援のサポートを表明

[Phoronix] Intel, NVIDIA To Support Google's VP9 Codec

どうやら、GoogleはVP9のハードウェア支援の約束を主要なハード屋と取り付けたらしい。

Herb SutterがCairoのMLにC++標準規格にCairoを入れられないか打診中

[cairo] Cairo and ISO C++

[Phoronix] Cairo Proposed To Become Part Of ISO C++

Herb Sutterが、CairoのMLに登場して、CairoをC++標準規格の軽量描画ライブラリとして採用できるかどうかの質問をしている。

軽量グラフィックライブラリーについては、私のブログの去年の10月の簡易レビューでも解説している。本の虫: 2013-10 post-Chicago mailingの簡易レビュー

こんにちは。私はHerb Sutterと申します。ISO C++標準化委員会の議長を勤めております。Behdadさんが質問の場として、このMLを紹介してくださいました。

C++標準化委員会は、ISO C++の標準規格に取り入れることができる、基本的な2D描画ライブラリを策定しておりまして、その土台となる(あるいは、バインディングなどでそのまま取り入れる)ことができる、先例となる既存のライブラリを探しております。現時点での、目的と議論については、以下のふたつの論文で閲覧できます。

2つ目の論文に書いてある通り、C++標準化委員会は機械的にC++化された版のCairoを提案する方向を検討しております。特に、「機械的にC++化」と申しますのは、Cairoをそのまま取り入れて、1ページ程度のリストで定義できるような変換を施すこと、たとえば、_create系の関数をコンストラクターにして、(mystruct*, int length)系の関数仮引数をvector<struct>&仮引数にして、などといったような変換です。設計と隠匿と関数は変わりません。これにより、C++標準化委員会は、同じ変換を更新版のCairoにも適用することで、将来のCairoの進化に追随することができるのです。

Cairommのことは存じておりますが、あまり活発に開発されていないようでありますので、我々といたしましては、C++ではないとはいえ、Cairoを土台としたいのです。Cairoはとてもよく書かれたCであると存じております(すでにオブジェクト指向で、すでに正しくconstされていてなどなど)

C++標準化委員会は、これを正しいやり方で、団体の合意のもとに行いたいと考えておりまして、フィードバックをいただけたらまことにありがたく存じます。また、Cairoのドキュメントの一部を標準規格で使いたいと考えておりまして、これは、MPL 1.1であるように思われますが、権利関係の合意が得られるかどうかを確認したく思います。

今後とも宜しくお願いいたします。

Herb

本気か? 正気か?

2014-01-02

星の王子様

たまたま、サンテグジュペリの星の王子様の新訳が転がっていたので、暇つぶしに読んだ。

基本的に、私は一度読んだ小説などは、あまり読み返したりしない。なぜならば、次に続く文章が分かっているので、それほど面白くないのだ。ただし、星の王子様を読んだのは、確かまだ小学生の時で、もはや話の筋をあらかた忘れている。それに別人の翻訳というのも気になる。

さて、読み終えたので、感想を書きたいのだが、どうもこの本に対しては、うまく感想を書きにくい。この本をグダグダと批評するのは、大人のやることではないか。少なくとも、この本を読み終えた後しばらくは、そんなつまらない大人にはなりたくないものだ。

ただ、どうしても一言だけ書いておくと、名作と呼ばれるだけの不思議で味わい深くでどこか物悲しい話だ。ああ、結局、批評してしまった。つまらない大人になったものだ。

実は、このブログを本の虫と名づけたのは、もともと、読書感想を書くつもりでいたのだ。

C++11の新しい関数の宣言

以下はC++03の関数の宣言である。

// int型の仮引数を一つ取り、int型の戻り値を返す関数
int f( int ) ;

以下は、C++11から追加された、新しい関数の宣言である。

auto f( int ) -> int ;

もちろん、関数へのポインター型の宣言にも使える。

// C++03
int (*fp)(int) ;

// C++11
auto (*fp)(int) -> int ;

新しい関数の宣言は、単に文法が変わっただけで、意味は変わらない。ただし、戻り値の型を後置できる文法なので、そのためにコードがわかりやすくなる。

例えば、ポインターを返す関数へのポインターが書きやすくなる。

// C++03
int * (*fp)() ;

// C++11
auto (*fp)() -> int * ;

他にも、複雑な関数テンプレートを書く際にも使いやすくなる。

C++14では、新しい関数宣言の文法をさらに拡張して、戻り値の型推定の機能が追加された。

// 戻り値の型はint
auto f( )
{
    return 0 ; 
}