タグ

2013年7月23日のブックマーク (6件)

  • VIrtualBoxで仮想ネットワークを構築 | それなりブログ

    1. VirtualBoxを起動 2. メニューバー「VirtualBox」>「環境構築」 3. 「ネットワーク」タブを選択 4. 右側にある、黄緑色の小さい「+」ボタンを押す 5. 作成された行を選択したまま、右側の小さいスパナマークのボタンを押す 6. 「IPv4 アドレス」を「192.168.56.1」にする、多分デフォルトでそうなってる 7. 「DHCPサーバー」のタブを選択し、「サーバーの有効化」のチェックを外す 8. 「OK」を押して保存して終了、念のため一式閉じた後に再度開いて、正しく保存されているかを確認 これでホストOS内に、192.168.56.* のネットワークが作成されました

    saisa6153
    saisa6153 2013/07/23
  • 違法素数 - Wikipedia

    違法素数(いほうそすう/英: illegal prime)とは、素数のうち、違法となるような情報やコンピュータプログラムを含む数字。違法数(英語版)の一種である。 2001年、違法素数の1つが発見された。この数はある規則に従って変換すると、DVDのデジタル著作権管理を回避するコンピュータプログラムとして実行可能であり、そのプログラムはアメリカ合衆国のデジタルミレニアム著作権法で違法とされている[1]。 DVDのコピーガードを破るコンピュータプログラムDeCSSのソースコード 1999年、ヨン・レック・ヨハンセンはDVDのコピーガード (Content Scramble System; CSS)を破るコンピュータプログラム「DeCSS」を発表した。ところが2001年5月30日、アメリカ合衆国の裁判所は、このプログラムの使用を違法としただけではなく、ソースコードの公表も違法であると判断した[2

    saisa6153
    saisa6153 2013/07/23
  • なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes

    Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか? 何が問題で、なぜ Google はそれらを作り変えるのか? SPDY や QUIC は Google の独自プロトコルだけど、それは当にただの独自プロトコルで終わらせていいのか? 20% ルールで作ってみた Play プロジェクトでしかないのか? こうした新しい動きには、かならず「それまで」と「今」を踏

    なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
  • プロセス・パイプ・リダイレクション・ファイルディスクリプタの実体を見に行く - ザリガニが見ていた...。

    プロセス置き換えとか、名前付きパイプとか、とても便利な機能なのだけど、その仕組みはどうなっているのだろう?断片的な知識ばかりでは、その核心にはなかなか辿り着けない。サンプルコードの真似はできるけど、それ以上の発想はできない...。もっと根的なところからちゃんと理解しておかないと、いつまでたってもコマンドの使い方の質が理解できないと感じた。プロセスとは何か?パイプとは何か?リダイレクションとは何か?ファイルディスクリプタとは何か?可能な限りその質を探ってみようと思う。 UNIXのプロセス UNIXでは、複数のユーザーがログインした状態で、同時に複数の処理を依頼される状況が多々ある。 ところが、どんなに高性能なCPUであっても、ある瞬間に処理できるのはたった1つの処理だけである。 そんな時OSは、それぞれの処理に必要なメモリ領域を割り当てて、CPUをタイミングよく切り替えながら同時並行的

    プロセス・パイプ・リダイレクション・ファイルディスクリプタの実体を見に行く - ザリガニが見ていた...。
  • 【進撃の巨大データ】RealTimeLog集計を目的としたRedisの活用 - Y's note

    Log集計の設計を再考 【進撃の巨大データ】Log集計用DBとシステム構成の美しい設計を考える - Yuta.Kikuchiの日記 人生を前向きに楽しむことを心に誓った@yutakikuchi_です。最近はこのブログで【進撃の巨大データ】というタイトルで何回かBigDataに関する記事を書いています。前回はLog集計用DBとシステム構成の美しい設計を考えるという題でInnoDB、InfiniDBを使ったLog集計のmerit/demerit、SystemPerformanceについて記述しました。それから時間をおいて再考し、InnoDBを使う場合のメリット/デメリットと注意事項が不足している事に気づいたのでここで追記します。更に集計の緊急度に合わせて使用するDBを変えます。リアルタイムではRedis、定期処理ではMysqlを使って集計することを試してみたいと思います。 Log集計方法のme

    【進撃の巨大データ】RealTimeLog集計を目的としたRedisの活用 - Y's note
  • 【進撃の巨大データ】Log集計用DBとシステム構成の美しい設計を考える - Y's note

    [:W560] Log集計用DB設計 考える問題 Document無しのAgile開発をガチで推奨したい@yutakikuchi_です。【進撃の巨大データ】の第2回目として巨大アクセスLog集計用DBの設計について勉強した内容についてメモしたいと思います。DB周りはそこまで詳しく無いので詳しい皆様からの突っ込み大歓迎でございます。また図々しいですが知恵をください(笑)。 今日の主目的は下の2要件を叶えるためのDB設計を考える事です。特に問題になるのがRealTimeの話でTableにLogDataを書き込む処理と集計のSQLをどのように組み立てるか、それ以外にもSystemPerformanceとArchitectureにも関わってきます。 リアルタイムで大量データを集計したい 定期処理で大量データを集計したい 使うもの Fluentd : Fluentd: Open Source Log

    【進撃の巨大データ】Log集計用DBとシステム構成の美しい設計を考える - Y's note