タグ

2005年11月16日のブックマーク (5件)

  • 2005-11-14

    深夜の街角で。吐く息が思った以上に白いさまを見て、ちょっと驚いてしまうの。 寒さは気が付かないうちに浸透してくるわ。体にも、心にも。そうして、時には魂までにも… http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ 会員用のサイトなので、引用控えめモードよ。よろしくってかしら? WebシステムとDBサーバの拡張に関するお話よ。 http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より Webシステムのボトルネック回避(1) DBサーバーの負荷分散が有効 そうねぇ。ネタとしてはとても面白いと思うんですの。 http://itpro.nikkeibp.co.jp/article/COLUMN/20051111/224435/ より 「WebサーバーやAPサーバー

    2005-11-14
  • DDR2が今年不振だった理由とは

    今年は新しい高速DRAM技術が主流に躍り出ると考えられていた。その技術はデータ転送速度の向上と省電力という特徴を併せ持っている。だがその技術、つまりDDR2は成功を収めなかった。デスクトップPCユーザーに受け入れられなかったことが主因だ。 DDR2は、主流になったと言えるほどの、つまり、最も広く使われるDRAMチップになったと言えるほどの数字を残さなかったが、だからといって、今後も主流にならないとは限らない。DDR2は来年こそ主流のチップになると見込まれている。だが、今年の市場でその受け入れが進まなかったことは、DRAM技術の向上のペースを鈍化させることになりそうだ。 次世代のDDR3は、1品種がハイエンドグラフィックスチップとセットで既にゲーム機に搭載されているものの、PCへの搭載はおそらく2007年以降になるだろうと、メモリチップの電子商取引市場を運営するDRAMeXchange Te

    DDR2が今年不振だった理由とは
    dnsystem
    dnsystem 2005/11/16
    あんまり聞かないなと思ったら不振だったのか。
  • BREWアプリは公開まで、なぜ時間がかかるのか

    au端末を使っているユーザーで、“携帯対応”と書いてあるサービスを実際に試そうと思ったらiアプリのみの対応だったり、新しい端末を買い、遊びたいゲームをダウンロードしてみたら「その機種は対応していない」というエラーメッセージが出た……といった経験をしたことはないだろうか。 現在auの端末は、基的に全機種がBREW対応になっている。携帯上で動かすアプリを利用しようとする場合、ドコモユーザーにとってのiアプリに対し、auユーザーはBREWアプリを使うことになるが、しかしアプリの配布・運営の点において、iアプリとBREWアプリには大きな違いがある。 それは、iアプリが自由に開発・配布ができるのに対し、BREWアプリはKDDIの承認を得なくてはエンドユーザーへ配布できないというところだ。さらに言えば、BREWアプリを配布するには原則としてKDDIのサーバ※にアップロードし、そこからユーザーがダウン

    BREWアプリは公開まで、なぜ時間がかかるのか
    dnsystem
    dnsystem 2005/11/16
    IIDX WAVE2は作ってすらいねぇな
  • TUXのベンチマーク記事 - naoyaのはてなダイアリー

    カーネル・モードで高速に動作するオープンソースのWebサーバー「TUX」の性能を,現在主流の「Apache」と比較した。静的コンテンツに大量のアクセスが集まる用途で,TUX 3.2はApache 2.0の1.57倍の性能を出した。OSが扱えるTCPコネクション数を増やす調整を施せば,標準設定時より性能が33%改善する。 TUX のベンチマーク記事。参考になります、グッジョブ。 カーネルモードで動作するウェブサーバー TUX、ということで久しぶりにこの名前を聞きました。3, 4 年前に Linux Magazine のムックか何かで特集されていたのを思い出します。その後あまり話を聞かなかったので TUX プロジェクトは頓挫したのかなと思いきや、それは僕の勘違いで、ちゃんとプロジェクトは動いていて成果が出ているということなのかも。 この記事ではベンチマークの比較対象として Apache が選ば

    TUXのベンチマーク記事 - naoyaのはてなダイアリー
  • Sender ID:送信者側の設定作業 ― @IT

    送信ドメイン認証は、Yahoo!やGmailで「DomainKeys」が、Hotmailで「Sender ID」が利用されているほか、多くのISPが対応を表明したことにより一段と普及が進んでいる。すでに米国などでは、送信ドメイン認証に対応しているドメインからのメールを優遇して通すなど、利用することのメリット、また利用しない場合のデメリットなどが現れてきている。 稿では2回にわたって、IPアドレスベースの認証方式に分類される「SPF(Classic SPF)」およびSender IDについて解説する。前編では、SPFおよびSender IDを導入するに当たって、実際にどのように手を動かせばいいのかについて説明したい。 IPアドレスベースの送信ドメイン認証 まず、IPアドレスベースの送信ドメイン認証について説明する(図1)。送信側は、「Sender Policy Framework(SPF)

    Sender ID:送信者側の設定作業 ― @IT
    dnsystem
    dnsystem 2005/11/16
    次の DNS サーバには SPF レコード入れなきゃな...