解ける問題 解けない問題

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

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

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

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上のデータ構造をどう設計するかにかかっているのだから。

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

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