解ける問題 解けない問題

　野崎先生の本
　話のもって行き方が野崎先生らしく前提を詳しく説明．
　等分問題はさすがとです．
　アルゴリズムへの展開もおもしろい．ヒルベルトの第１０問題
　圧巻はマチャセヴィッチのフィボナッチ数列を使った証明．

　知性の深い考察がみえる．

　久しぶりに聞いた野崎先生の教訓でした

Chrome OS 詳細

　Chrome OSは、GoogleがNetbook向けに開発しているWeb OSだ、
　ブラウザベースですべてのインターフェイスを実装し、アプリケーションはすべてWebベース。HTML5とCSS3.0によってリッチインターネットアプリケーション(RIA)を作成できるなら、シンプルにWebブラウザ中心のソフトウェア基盤だけで十分じゃないか、というGoogleらしい提案．
　Googleが行ったChrome OSのデモでは、同OSはASUSのEee PCで7秒で起動し、さらに3秒でアプリケーションにログインした。
　Contacts　and panel 確かに軽い
　Google Chrome OS 開発版 ダウンロード提供開始、普通のPCで動く．
　Google Chrome OS は認証済みハードウェア構成とカスタムファームウェアを備えたデバイスにのみプリインストールで製品化される計画です．
　開発版はもちろん普通のPCで試せます。公開されたのは、仮想環境で動くイメージ版。動かすためにはVMwareが必要です。イメージとVMware Player (無償)のダウンロードはリンク先から。BitTorrentやなにかでも落とせます。
　ダウンロード - Chrome OS 0.4.22.8 VMware (300MBくらい)
　ダウンロード - VMware Player

２０１０年まで　待てないかな？

Google Chrome OS

Googleが「Google Chrome OS」のプレビューが発表。Chrome OSはLinuxカーネルを採用し、Google Chromeブラウザを高速に動作させることだけに特化したオペレーティングシステム(スピード、簡単、セキュリティに焦点)。Linuxカーネル上にウィンドウシステム(といってもコアはX.orgで一から作ったわけではなし)を新たに作り、ブラウザ画面が中心となる。アプリケーションは全てWebアプリケーションで、チャットや音楽プレーヤはブラウザとは独立して表示できる。安全性を高めるため、全てにサンドボックスが適用されている。そして、必要のないものは全て削除し、スピードを上げることに努力している。
コールドブートの時間は7秒を約束(デモは12秒)
x86とARMアーキテクチャをサポート: ハードウェアはGoogleの定義するリファレンスの認証を受ける必要あり
最初はネットブックで登場: 内部ストレージはあくまでキャッシュのためであり、ハードディスクではなくSSDのみを利用
リリースは2010年末を予定
エイサー、アドビ、ASUS、Frescale、HP、レノボ、クアルコム、Texas Instruments、東芝はChrome OSのサポートを表明
ドライバは証明が必要: ストレージ、プリンタをサポート
ビデオコーデックはハードウェアアクセラレーションを使ったものを開発中
システムは勝手に自動更新される
オフラインではメディアの再生は可能だが、基本はオンラインである必要がある
開発版はブラウザ同様Chromium OSと呼ばれ、ソースコードがダウンロードできる

SPDY

Googleが「SPDY」（SPeeDY）という、新たなデータ送受信技術を発表.
SPDYはWebのコンテンツを高速に送受信するためのアプリケーションレイヤのプロトコルで、複数のストリームを同時に利用したり、リクエストの優先度付けやHTTPヘッダ圧縮といった機能を備えている。
現在Webで利用されているHTTPはシンプルでエレガントであり、現在でも非常に有用であるが、ウェブサイトやブラウザの進化に対応していくためにSPDY技術や、それをサポートするWebサーバーおよびクライアントを開発したそうだ。
　SPDYはまだ開発中の段階であるが、実験ではWebページの読み込みを55％高速化できたとしている。

　高速化は日本のお家芸だったが．．．　．

Ｇｏ 継続

　Goはご多分にもれずC風の構文を持つ．ガベージコレクタや、「チャネル」および軽量プロセス「ゴールーチン」といった並列プログラミング対応、イテレータ、クロージャ、リフレクションなどの特徴を持つ。
　設計と実装にはかつてベル研UNIXチームに在籍した Ken Thompson、Rob Pike、Russ Coxの3人や、Google Chromeの高速JavaScriptエンジン開発で知られるRobert Griesemerなど、Googleならではの超豪華キャスト．
　ベル研が開発した分散OS、Plan 9 をJava風にアレンジしたInfernoに搭載されていたLimbo言語にそっくりとう話もある
　ベル研チームがGoogle移籍やオブジェクト指向の隆盛に嫌悪感を示していたRob Pikeが「JavaやC++よりもオブジェクト指向的」と積極的にぶち上げてる。
　
　プログラムサンプル内に日本語がある。
Go公式サイトのプログラム例
　
　package main

　import "fmt"

　func main() {
fmt.Printf("Hello, 世界\n")
　}


05 package main
07 import fmt "fmt" // Package implementing formatted I/O.
09 func main() { 10 fmt.Printf("Hello, world; or Καλημέρα κόσμε; or こんにちは 世界\n"); 11 }
　漢字ではなく日本語（とギリシャ文字）である。
youtubeにアップされた一時間のデモで「This is a 日本語 string」なるconst strが扱われている。

Go

Googleの有名開発者たちがGoというシステムプログラミング言語を発表。複雑だったことがシンプルに書けそう。スクラッチからプログラムを書く時代ではなく、既存プログラムやサンプルプログラムを拡張しながらプログラムを作る時代。既存のGoプログラムに手を入れやすいプログラミング言語か否かが普及するか否かを決めるのではないでしょうか。
マルチコアへの対応を重視しているようです。
Goを開発した理由として、「コンピューティングの状況が一変したのに、10年間以上システムプログラミング言語が登場していない」とのこと。ここ10年間、新しいシステムらしい新しいシステムは登場していない。
　世の中が新規に開発された新OSを望んでいるかというと、技術者を含めて多くの方は、新しいOSよりも枯れたOSを機能強化した方が安定かつ安全でいいと言い出す状況。
システム記述言語としての　幕開けだが、特徴はみえない．

Entity Group

Entity Groupとトランザクション処理
　Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。
　同じEntity Groupに属するEntityのいずれかを操作する際には、db.run_in_transaction() という仕組みを使って一連の操作をAtomicに行う。一つのスレッドがトランザクションから抜ける時に、常にデータの整合性が取れた形になっていることを保証することにより、スレッドやマシンが何台に増えようと破綻することなくサービスを運営することが可能になるのだ。
　Google App Engineの特徴は、このEntity Groupを自由な形でいくつでも作ることができる点。そして、データベースそのものが巨大になって複数のマシンにまたがってしまっても問題なくスケールする点。それぞれのEntity Groupに対してトランザクション処理ができるため、全体のスループットを落とさずに同時期に大量のトランザクション処理を行うことが可能になるのだ。
　　Google App Engine上でEntity Groupを作るには、一つGroupのルートとなるEntityを定め、他のEntityをその子孫（子供、孫、ひ孫、...）として関連づければ良い。
　そんな親子関係を作っておくと、それらの（同じEntity Groupに属する）Entityを実際にディスク上で近いところに格納することにより高速なトランザクション処理を可能にする、というのもApp Engineのすぐれた所だ。
　このあたりの「概念」からしっかりと把握した上でGoogle App Engine上のアプリを作ることをおすすめする。結局のところ、スケーラブルなウェブサービスが作れるかどうかは、Datastore上のデータ構造をどう設計するかにかかっているのだから。

　トランザクション指向設計？な感じだ．確かに理論モデルは背景に見えないが、実用的な気がする．ＤＢの世界は論理設計になると、関係代数の世界になってしまう．いきなりＣＬＡＳＳの登場だ．

　この違和感は　私だけなのだろうか？

辞退の理由 - 完全なる証明

なぜグリゴリー・ペレルマンが、フィールズ賞をはじめとする数多の賞を辞退しつづけたのか。
グリーシャにとってフィールズ賞も一〇〇万ドルの懸賞金も、むしろ不遇度を上げるための道具立てに過ぎないのだ。どちらも自らの証明の証明には少しも貢献しないのだから。
「説明させ、それに耳を傾けること」だ。これこそが、グリーシャが求め、そして得るべき報酬だったのだ。
耳を傾ける人は、誰でもよいというわけではない。説明を理解できる人でなければならない。不運なことに、問題が高度になればなるほど、耳を傾けられる人は少なくなっていく。そんな数少ない人の一人が、マイケル・フリードマンである。ペレルマンの業績を最も評価し寿ぐべき立場にいる人だが、フリードマンはペレルマンの仕事を、トポロジーにとって「ちょっと残念なこと」だと述べ、ペレルマンがその分野で最大の難問を解いてしまったせいで、いまやトポロジーは魅力を失い、結果として「今いるような才能あふれる若者たちは、もうこの分野からいなくなってしまうだろう」と。

　これで打ちのめされぬだとしたら、研究者ではない。

意味が理解できないが、数学者の孤独感を見た気がする．理解してほしい人の評価のあり方．確かに難しい．「わかる人」にわかることを拒絶されることは、そうでない人にそうされるより遥かにダメージが大きいのだ．

ロードバランサ

　負荷の上昇に伴って要求を複数のサーバに分散し、ユーザーに提供されるパフォーマンスのレベルを均等に保つ必要がある。ロードバランスは、受け取った要求を複数のサーバに分散するためのプロセスであり、受け取った要求を複数のサーバに分散するためのプロセスである．
　高可用性がキーワード．
　Apacheのmod_proxy_balancerエクステンションが代表例である．
　その他の主技術は以下のものがある．
　サーバの応答をバッファ化；負荷が高くなってきたらロードバランサが応答をバッファまたはキャッシュから取り出して返すようにすれば、サーバの処理能力を節約して、他の優先度の高いタスクに振り向けることが可能。
　サーバの「健康診断」を実施して、ダウンしたサーバまたは過負荷状態のサーバを認識できる。サーバの稼働状況の診断は、ほぼリアルタイムに行うことも、定期的に行うこともできます。異常なサーバが見つかった場合は、それぞれのソリューションの要件や機能に応じて手動または自動で正常なサーバに置き換える。
　大規模なポータルは、ハッカーからさまざまな手口で攻撃され、深刻な脅威にさらされる．例えば、同じURLを連続して要求してDoS（Denial of Service：サービス停止）攻撃や分散DoS（Distributed Denial of Service）攻撃を実行するプログラムは、サーバに極度の負荷を与える。ロードバランサは、このような攻撃を緩和または阻止する能力を備えている．

支援しているＰｊ　で　ふと思った　ことでした