104ビットWEPは1分あれば破れる | スラド
本家/.の記事より。ドイツ・ダルムシュタット工科大の暗号研究者Erik Tewsらは、従来知られていたよりもはるかに少ないパケットを捕捉するだけで、無線LANの104ビットWEPキーが十分クラック可能であることを示した。事実上1分少々あればWEPキーは解読できるということのようだ。 WEPがセキュリティ的に脆弱なのは以前から知られていたことだが、それでもキーの解読には50万から200万のデータパケットを捕捉することが必要と考えられていた。しかしTewsらのページによると、今回改良された手法を使えば40,000パケットの捕捉で50%、85,000パケットの捕捉なら95%の確率でWEPキーは解読可能だという。40,000パケットというのは従来知られていた必要パケット数の10分の1以下であり、受信状況さえ良ければ1分以内に捕捉可能とのこと。実際の計算にも、Pentium-M 1.7GHz、3MB
信じ込ませる - 学校では教えてくれないバッドノウハウ英語 #11
信じ込ませる - 学校では教えてくれないバッドノウハウ英語 #11 学校では教えてくれないバッドノウハウ英語の11回は、 hoge を取り上げたいと思います。 hoge は日本のプログラマの間で、「何か適当なもの」を指す変数として親しまれています。英語圏では hoge の代わりに foo がよく使われます。このような変数は、メタ構文変数(metasyntactic variable) と呼ばれ、ソフトウェアに関する議論や文書などで広く用いられています。 hoge は日本ではなぜかメタ構文変数として定着していますが、英語では「信じ込ませる」という意味のれっきとした単語 (ホウジと発音) です。日本人以外に対して hoge を用いると誤解を生じる可能性があるため注意が必要です。hoge は通常、動詞として用いられます。 例) Please don't hoge me about the sto
GPLv3ドラフト3公開 | スラド
the third draft of GPLv3が公開されました。補足文書なども同時に公開されています。 この版に関して、Linus Torvalds氏は好意的に受け止めている(CNET記事より)ようで「実際に期待していたものよりもはるかに優れている」「少なくとも『絶対だめ！』から『懐疑的である』になった」「少なくとも、GPLの名を汚すものとはなっていないようだ」としています。 ただし 少なくとも論理的に(GPLv3への移行が)可能になったと思えるが、それが現実的かどうか、価値があることなのかどうかは、まったく別の話だ。 (CNETの原文より独自に訳) と、移行に関しては明言していません。GPLv3が普及するとしたら、多数の開発者が関わっているLinuxカーネルなどよりも、頭数の少ないJavaあたりの方が先になるのかもしれません。移行問題に絡んで、GPLv2との互換性がどのようになるのかも
/.-J 編集者next氏(P2P Today)氏、結婚する | スラド
いま、ヨコタンことP2P Today、nextさんの結婚祝賀会に来てます。フィクションの予感もしますが、ともかく……結婚おめでとうございます！！ 実はオレもタレコミの現場（結婚祝賀会のある一角）にいた。どうしようかなーと思ってたら、mhattaのPodcast 第20回にて、結婚しますという発言があったので、迷わず（？）掲載に踏み切った。本家/.のCmdrTacoの結婚記事やOliver就職おめでとう記事トピックがあったことを考えると、これもありだろう。新たなる一歩を踏み出したnext氏に何か一言ある人は、ぜひこの機会に書いてみると喜ぶんじゃないかとオレなんかは思う。 まずはおめでとう。そして、今後の活躍を期待している。
Dependency Injection の基本的なアイディア - bkブログ
Dependency Injection の基本的なアイディア Inversion of Control コンテナと Dependency Injection パターンを読みました。関連する事柄を広くカバーした、隙のない記事です。 ただ、割とボリュームがあるので、「Dependency Injection って結局何なの?」ということを手っ取り早く知りたい向きにはあまり向かないかもしれません。そこで、基本的なアイディアを手短にまとめてみました。 Dependency Injection (依存性注入、DIと略) とはその名の通り、依存性を注入するパターン (テクニック) です。もう少し言葉を加えると、依存性を内部に抱え込まずに外部から注入する、パターンです。 Dependency Injection の基本的なアイディアは「依存性を外部から注入する」です。 DIコンテナと呼ばれるフレームワ
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転
さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最速インターフェース研究会 :: livedoor Readerで今読んでいるフィードをTwitterに送るGreasemonkeyスクリプト