2009-09-19
2008-09-06
PCのメンテナンス
Duty | | 
Windows XP Home ed.
- Cドライブディスクデフラグ
- GIMP 2.4.2のアンインストール
- GTK+ 2.8.9のアンインストール
- 秀丸メールのアップデート: 4.x→5.08
- Adobe Reader 9.0のインストール
- OpenOffice.org 2.4.1のインストール
- OpenOffice.org 1.9.121のディレクトリ削除
- OpenOffice.org 2.0のディレクトリ削除
- continued
2008-08-25
coLinux 0.7.3に入れたUbuntu 7.10を8.04にアップグレードする part 1
私はcoLinuxが好きではないし、やや過去のモノだという気持ちも拭い切れないんですが、どういうワケだか実務レベルでの試用を行なっています。
教科書どおりの作法
$ sudoedit /etc/apt/sources.list
$ sudo aptitude clean
$ sudo aptitude update
$ sudo aptitude safe-upgrade
した。
たくさんのパッケージのためにlibdb4.6を入れる
上の結果を見て、
$ sudo aptitude install libdb4.6
をしないといかんな、と気づいて、
$ sudo aptitude install libdb4.6
$ sudo aptitude safe-upgrade
とする。
これでも
69 not upgraded
とか言ってるし。
aptitudeのためにlibcwidget3を入れる
aptitude(hardy)がlibcwidget(hardy)を欲するようになったとかあるので、
$ sudo aptitude install libcwidget3
$ sudo aptitude safe-upgrade
とする。
64 not upgraded
gccが4.1から4.2になった
gcc-4.1(gutsy)だったのに、
gcc-4.2(hardy)となったので、
としたら、
GCC OpenMP (GOMP) support libraryもくっついてきたので、結局、
相当。
ここで、safe-upgradeすれば、
62 not upgraded
hal, hal-infoなどのために。。。
分からんので、保留。
ubuntu-standardの道連れでufw, bash-completion, friendly-recovery, mlocate, uuid-runtime
が必須で、
その他の
- bash-completion
- friendly-recovery
- mlocate (locateの簡易版？)
- uuid-runtime (RFC 4122)
も推奨で勝手に入ってきたけど、そのまま入れちゃう。
61 not upgraded
このへんで休憩
時間切れ。
2008-08-24
百度が速いわけと人力はてなの回答のひどさと。
百度は、なんであんなに速いんでしょうか？
【予想】
・DBが完全にメモリに乗っかっている。
・インデックス数が少ない
いや、まー答えは何でもいいんだけど、さ。
1 回答者：verify 2008-02-15 23:30:24 満足！ 14ポイント
日本で誰も使ってないからでは。
やっぱこっちでしょ。↓
マジつまんなすぎ。質問者が
はい、次の方どうぞ。
とかかわすしかない気分が分かる。のに、14ポイントって＞＜
2 回答者：hagix 2008-02-16 03:56:49 満足！ 14ポイント
http://fnconf.blog98.fc2.com/blog-entry-59.html
他の検索エンジンに比べて精度が低いから。。。。と、勝手に思っていました。
？？？
質問者のリアクションのように、
うーん、精度が低い = 速い というのが単純なイコールではないような。
である。正直言って論理的に飛躍しすぎ。
はい、次。
3 回答者：yo-net 2008-02-16 13:14:35 満足！ 14ポイント
回答とずれていたらごめんなさい。
多分ユーザ数が少ないからだと思います。
さらに、付け加えると、分散サーバで日本のサーバはjpアドレスからのアクセスに限定しているから、
ユーザ数が少ないのと合いマッチして早いのでは。
CEOが開発した検索アルゴリズムも関係しているかもしれませんが、良くわかりません。
[...]
これがもっとも近い気もするけど、それだけじゃ答えになってないだろうなぁ。
4 回答者：jagging 2008-02-16 14:29:52 満足！ 14ポイント
早いんですか？
早い・・・確かに早いですね。
そんな回答中で聞き返しても＞＜
...とかいう私も回答するを押してから調べることはあるけれども。
プログラマが優秀（または優秀な人が身軽に仕事が出来る）
プログラマが優秀だとどうしてレスポンスが早くなるのかを聞いていると思われる。サーバを絞っている、最適化する、の意味が分からない。
個人的には、早いのは当たり前なので、
あなたのエンドユージングのことはおそらく質問者は聞いていないんだよ。
そういえば、
話、飛躍しすぎ。
ニコニコ動画とかは
一月で100倍増になったアクセスを
サーバーを13台くらいで、チューニングのみで乗り切ったとかで、
技術凄いらしいです。
どうすごいのかよく分からないけど、一ヶ月で1アクセスが100アクセスになったのをサーバ13台もかけてチューニングもしなきゃいけないなんて全然技術力ないYo!!!
せめて、百度とニコニコ動画のアクセス数の比較をしてくれ。説得力に欠くなぁー。
サイト運営では、
大手より、ベンチャーの方が、よっぽど効率の良いサイトが多いように思えます。
ん？どっちのことを大手と言って、どっちをベンチャーと言っているの？
百度公司ができたのは1999年*1で、ニコニコ動画の運営元の株式会社ニワンゴができたのが2005年*2だから、前者が大手で後者がベンチャーと言っている？
...そもそも論理的破綻だらけなので、そんな細かいとこいいや。
5 回答者：turkey_hate 2008-02-16 18:11:24 満足！ 14ポイント
・広告が無い
日本版の百度は広告に関する処理（ReadもWriteも）が無いからでは？
→本家の百度(http://www.baidu.com/)は広告が出るのだけど、やっぱりそんなには速く無いような気が。
・インデックスが少ない
検索結果の件数もGoogleの方が一桁くらい多いですね。
あと、百度は国の政策で、内容によってインデックス化出来ない物が
あったりなかったり？
たとえば、天安も
・・・ん？
すいません、玄関に誰か来てるみたいなので、後で続きを書きmas
やっとまともな議論になった！
6 回答者：KUROX 2008-02-16 19:03:58 満足！ 14ポイント
（１）検索結果のキャッシュっぽいものをもって、ごまかしてそうな感じ
同一キーワードで検索した場合に検索時間の差が激しすぎる
Googleは毎回ほぼ同じなんですね。
（２）２バイトコード（漢字）を初めから想定した設計をおこなっていて
その点で、有利な点がどこかにあるとか
1は分かる。2は不明。というのは質問者も述べている:
> 検索結果のキャッシュっぽいものをもって、ごまかしてそうな感じ
そう、画像検索で、個々の画像をぽろぽろ読み込むような感じが全くなく、一発ですぱっと全サムネイルが表示されるんですよね。（こちら側の回線が光の場合）これができるのは、あらかじめページがメモリ上にキャッシュされて、ディスクアクセスなしでレスポンス返せるからじゃないかな、と個人的には思っているのですが。
> ２バイトコード（漢字）を初めから想定した設計をおこなっていて
これがわからない。
baidu の外側の文字コードはUTF-8で、文字コードの変換なしに入出力した方がサーバ側の効率はよいような気がするんですよね。とすれば、検索DBもUTF- 8でまるごと設計してしまった方が変換処理が入らない分速いような気が。ちがうかな。。。そもそもUTF-8のマルチバイトコードは3バイトじゃなかったでしたっけ。
7 回答者：myusky 2008-02-16 21:19:12 満足！ 14ポイント
２バイトに強いという話がこちらに。
http://japan.cnet.com/interview/media/story/0,2000055959,2036716...
マルチバイトの強さと速度には関係なさそうな気もするし、リンク先は機能的な話で速度に関しては述べていないなぁ。
8 回答者：knaka20blue 2008-02-17 00:18:15 満足！ 14ポイント
(狭義な意味での検索エンジンとして)
>・インデックス数が少ない
はとても大きいと思います。
クエリに対してヒットするドキュメント数が少なければ
ドキュメント毎にスコアをつけてスコアの大きい順にソートするという
処理の時間が短くてすみますから。
確かに。
(日本語のページに限れば1億ページもあれば99%以上のクエリに
100ページ以上を返すことは容易でしょう)
ん？？？
あとはヒットしたドキュメントに
Googleのスコアリングアルゴリズムの複雑さはよく語られていることで
この辺を端折っているとレスポンスはかなり良くなると思います。
baiduがgoogleのそれよりも複雑でない明らかな理由がないなぁ＞＜
もちろん可能性としては有力だとは思うんだけど。
9 回答者：knaka20blue 2008-02-17 16:56:17 満足！ 13ポイント
>でも、キャッシング機能をもった検索サーバを日本においてよかったんでしたっけ？
この辺は近く法律改正されるみたいですね。
http://www.mext.go.jp/b_menu/shingi/bunka/gijiroku/013/07100407/...
国内に置いているサービスなんて山ほどあるわけですし...。
なるほど、参考になります。
10 回答者：hirokiea 2008-02-17 18:22:39 満足！ 13ポイント
結果ページのHTMLソースが軽いためじゃないですか。
唯一鋭い指摘。
客観的データを与えているのはこれだけですね。
もっとも内情を知れる人はここには書かないだろうけど。
11 回答者：quocard 2008-02-18 17:56:36 満足！ 13ポイント
広告がないというのが大きいかもしれませんが
・利用者が少ない
・検索をするデータベースがそれほど大きくない
というのがあるのではないでしょうか。
始まったばかりというわけではないですが、クロールして集めているデータの
量がgoogleなどより少ないから早いという見方も出来るかもしれません。
上のほうの意見と同じ。
またSSDやテラビットイーサを使用したとしても途中のネットワークがボトルネックになって
それほどの効果を発揮できるかどうかは疑問が残ります。
そんなことはないけどなー。
12 回答者：KUROX 2008-02-20 23:07:24 満足！ 13ポイント
こんばんは
DBにシングルバイトのカラムとマルチバイトのカラムがあったとして、マルチバイト側の方が
速くなる設計ってどんなんなんでしょうね。不思議。
http://japan.cnet.com/blog/tamon/2006/09/15/googleoraclebig_6721...
データの持ち方とかそういう基本的なものではないでしょうか？
あと、表示はUTF-8だとしても、実際に持っているデータはどういうコードか不明です。
その不明なコードだとUTF-8よりもマルチバイトで速くなるの？？？
13 回答者：RIKKUN 2008-02-21 10:28:02 満足！ 13ポイント
http://www.nextglobaljungle.com/2008/01/fc2.html
アダルトフィルタがデフォルトでＯＦＦだから、不要なフィルタリングコストの分速いとか・・・。
質問者：biz_tanaka 2008-02-21 13:19:38
ああ、なるほど。
それもありますね。
しっかし、すんごい画像がヒットしますよね。なんだこりゃ。
14 回答者：yukimasa_2k 2008-02-22 00:28:52 満足！ 13ポイント
憶測＆上の方々もおっしゃっていますが、アダルトフィルターの有無が一番大きいのではないでしょうか。
文字だけを見て除外するにしても、するとしないでは大違いですし…。
まぁ、そうかもしれないねぇ＾＾
総括
あまりこれと言った図星的回答も革新的なアイデアも得られず。
はてなクオリティですか？
2008-08-02
離散データの高階（高次）微分が分からない
みんな大好きXPathGraphの最近のグラフを見てたら、
おそらく d:id:ka-nacht 氏 (また、そしておそらく、@kana) が
http://xpath.kayac.com/graph/HoUXrRhf3RGCvw
ってのを作ってて、私も最近、高階微分で悩んでいたので、勢いあまって
こんなにも無駄な有用なグラフを作ってしまった。
さて、d:id:ka-nacht 氏の no title は、おおもとの
の一階微分
をさらに微分したものである。
だから、おそらくd^2/dt^2のデータは二日分遅れているはず（離散データの微分はどこの微分かなのか、ってのが私は理解できていない＞＜）。d/dtが一日遅れているとするならば。
二回、微分をすれば、二階微分であることくらいは高校生でも最近じゃ中学生でも、いや、小学生高学年くらいでも、知っているであろうが、時系列なんかの場合、
(X2-X1)-(X1-X0)=X2+X0-2*X1
であることを使って一発で二階微分が求まる、、、
んだけど、これで合っているのか悩んでる＞＜
離散数学も解析もろくにやっていないから、分からんとです。誰か教えてえろいひと。
じゃあ三階微分は
(X3+X1-2*X2)-(X2+X0-2*X1) = X3-X2+3*X1-X0
なの？みたいな。。。＞＜
とか言ってみたものの、私の扱う世界では時系列の三階微分が必要な場面ってないけどさ。。。
二階微分も符号だけで十分みたいな＞＜