Linuxのアップデートが出てた模様。9.04だと、libwrap.soが/lib32に入っているので、単体でインストール可能にはなっているのだけど、JustSystemは相変わらずDebian系の64ビット環境は考慮してくれない。今回のパッケージもdebは32ビット版しか入ってないので、deb版のパッケージを使わずに、tarballを使って入れる。展開されることになるので、/usr/lib32/にコピー。/usr/lib32/iiim/これで、IIIM側のアップデートは終了。path>/atokxup-20.0-3.0.0.i386.tar.gzこれでアップデートが完了。私自身は書いてはないのだけど、ちょっとだけネタを提供してたりするので紹介。有益な話が多いんだけど、デバッグ技法とかを学ぶにはちょうどいいかとは思う。あとWindowsでのデバッグについてのいい本はないんだよね、現在のところ。カーネルとかにはデバッグ系の機能とかがあるんだけど、それを有益に紹介されてないし。PhenomだとSSE2は高速化しているんだけど。MMXを2回実行した方がまだ速いって。それ以外でも、SSSE3のシャッフル変換使えば、Alpha値を持たないPNGや田の画像形式でもパフォーマンスアップを見込める。SSSE3のインラインアセンブラやビルトイン関数は、VC++2008からだから、_emit使って直に書く必要があるけどね。整理したら、レビュー投げるつもりそれ以外に、SSE2での最適化で有名どころといえば、UTF8->Unicodeの変換。これはMozillaとして考えてるとは思うけどね。9.04の開発版に変えたのだけど、Dropboxが動かないようだ。Dropbox"というメニューしか出ない。8.10まではレポジトリがあったのだけど、9.04用はまだ作られていないようだ。調べてみると、最新版に入れ替えれば動くとのことで入れ替えた。Dropboxのフォーラムhttp://forums.getdropbox.com/に最新版が通知されるので、それを使う。私の環境はAMD64なので、それ用をダウンロード。nautilusNautilusを立ち上げるなり、再ログインすればDropboxが使えるようになった。有効にした状態で正式版はリリースされている。PGOというのは、最初のコンパイル時にプロファイルを作成できるようにコンパイルして、その後、実際の動作状態のデータをとって、その後再度コード生成をすることで、コードにおけるさらなる最適化を進めるものだ。複数のオブジェクトファイルやライブラリに渡っていたものでも、インライン化などを通じてコードの高速化に寄与する。これは、x86だと、FASTCALL以外は、引数の受け渡しにスタックを利用するので、x86だと高速化に寄与できるし、Itaniumの場合は、汎用レジスタの数が膨大なので高速化できるだろう。場合は、どうだろうか?。汎用レジスタの数は増えているから、当然最適化しやすいが。実際、ここにMicrosoftの資料がある。http://msdn.microsoft.com/ja-jp/library/aa289170%28VS.71%29.aspxこのデータをみると興味深いのだけど、Itaniumは非常に高速化に寄与するみたいだ。コンパイラで最適化を図ってくれ!というアーキテクチャなので、当然といえば当然か。Professionalを手に入れたので、SunSpiderでFirefoxのテスト。(x64なので、JITは有効ではない)。fasterちょっとは早くなるけど、ベンチマーク上はそれほどでもないんだよね。導入されているんだけど、BTSに登録したから、誰かが見てくれると思っているのは間違い。ゴミくずのようなバグが増えていく昔勤めていた会社は大規模なソフトウェア会社だったためBTSはあったんだけど普通にバグを登録しても放置される状態になる。それは、そのバグ登録等については誰でもできたため、ゴミくずのようなバグだらけになるからという原因がある。(実際問題、原因がソフトウェアに関するものではなかったり、違うバグ修正で直っているものだったり、過去のバージョンで直したものだったり!)。その時の一番の問題は、バグを登録した際にアサインがデフォルトでなしという状態だったのが、一番の問題だった。だれもアサインされてないんだから、当然誰もやりやしない。重要なバグであってもね!。その会社ではBTSを変える時に、デフォルトアサインのままだとバグを登録できなくするように変更したため、誰にアサインすればいいのかが分からない人にはバグ登録ができなくなるということになった。敷居をあげた状態に変更したおかげで、常に誰かにアサインされるため、誰かが一旦はバグを見ることになるオペレーションへ変更した。ゴミのようなバグが増えるきっかけは、開発フェーズの時に報告されたバグが多数残ること。開発をやっている人だったら分かるとは思うが、一つのバグの修正が複数のバグを修正することは多くある。そのため、既に直っているバグがアクティブのままずっと放置されることなんてよくあることになる。その後誰かがもう直っているかどうかの検証をしないと、バグが直っているのにもかかわらず、数字上はバグが残っている状態になる。me)、そこでクローズとなんだけど、ただ開発のマネージャからしてみれば、そんなにテスターにコストを払わないといけないの?。そんなゴミのようなバグ報告に対して??ってことになるよね。fix)でクローズをしてしまって、報告者に「新しいメジャーバージョンで試して、直ってなければ再オープンしろ」という指令が下る。そのため、ある程度のバグの掃除が可能だ。報告者がいなくなったりして、まだバグが残っているのに再オープンされないものもあるから、バグ報告が見逃されるのでは?って思うかもしれないけど、でも、それが重要なバグだったら、誰かまた報告するでしょ?。マイナーバージョンは?って言われれば、それ専用のBTSを別途もっておいて、「そこに報告しろ!」っということにすればいい話。マイナーバージョンのリリースチームがレビューして直すかどうか判断すればいい話だからね。(バグ報告者を制限する)上記のようなゴミバグを増やさないためには、優秀なテスターにのみバグ報告を許すというやり方もある。あるソフトウェア部隊ではそういう手順を取っていた。(実務で使えば、そんなことくらい分かるだろ!ってバグ多数)。その開発マネージャが昇進するという、笑えるオチがつくんだが。(そのソフトウェアにモチベーションを持てなくなる)。前者は、そもそもテスターの問題なのかもしれないけど、テスターに報告したとしても、そのテスターの環境でたまたま再現しないだけで、「再現しないから、バグ登録しない」という話になりやすい。それは、コードを直接書いている人だったら、自分の環境で再現できる話なのかもしれないし、別の関係ない人が再現方法を明確にするかもしれない。そのようなところで止めるべきではないと思う。(ただ、バグの書き方が分からない人をヘルプする人やものは必要だとは思うけどね!)後者は、自分がいろいろできる人だと、変な仲介者を制限されるのは嫌う傾向にある。コードが書けるんだったら、こう書けばもっといいのに!って思うのは当然だし、直接チェックインもしたくはなるよね。BTSに登録して仲介なしに議論したいと考えるのは当然。いう人に対して変な仲介者を通さないといけない状況を作った場合、バグを登録するのにも、無駄な労力を使っていく状態を作ることが、そのコードに対するモチベーションを下げる要因になりやすい。その仲介者のスキルが報告者よりも下だったら、なおさら、無駄な労力を使うことになるので、よりやる気を失っていく。自分の考えそもそもBTSは、開発する上で必要なトラッキングツールなんだけど、外部の人にバグエントリの追加や更新を許可する場合の一番の理由はQAや開発のコストを下げるためなんだ。そもそも無尽蔵にリソースがあるのであれば、別に外部に開かれる必要もないしね。OSSについては、それを外部に依存しているんだから、BTSの運用方法をより考える必要がある。個人的には、バグ報告者を制限するやり方は非常にまずい。バグを報告してくれる人ってのは、悪意ではなく善意の場合がほとんどなんだ。ゴミが増えるということやクオリティ維持のためにそんな方法で善意のある人も制限するのは、バグがあるのにバグ報告がなくなるという悪循環になりうる。善意で報告しているのに、(開発者でもない人とかに)とやかく面倒なこと言われたら、モチベーションが下がるでしょ?次はMozilla.orgについてのBTSの話を書いてみようかと思っている。