主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹
你这篇有很多的观点俺不太赞同。等有足够的时间俺会接着乱弹。
这篇文章不错。Google确实在大方向上掌握的不错。基于html+css的UI确实是发展方向。但弄个新语言代替JS有些不妥。现在的JS的问题其实不在语言本身，而在DOM上。本来JS的优势是跨平台，跨浏览器，但现在有太多的不兼容性要考虑。
至于是否预编译，就又回到了兼容性和效率这对矛盾上来了。假设所有的客户都有java虚拟机就不现实，不知道Simple假设的是什么。
对浏览器就是操作系统这个说法近期还是比较有体会的。主要是写了个在线的中文输入工具，为了和gmail之类的整合，着实费了些心思，也长了些见识。大概十年前写过x-window下的中文输入法。比较之下，相似性真的很多。加上现在越来越多的online application。浏览器即操作系统的时代还真的不远了。其实我觉得更确切的说法应该是操作系统即浏览器。
顺便推广一下我的在线输入法：
http://www.livechars.com
据新兵营里反应，还满好用的。
让我认真想想关于SQL的事情该怎么聊。
围观
兼听则明，欢迎批评。
Andy Rubin是牛人，ChromeOS的头儿是谁？我不太清楚，估计也不是个甘于就范的主儿。
牛牛相遇，总是要相互顶一阵子的。大公司里经常出这样的事情。
过分啊，Python这么好用的东西。呼呼。
【4】 ChromeOS与Android，云在哪里？
Google的核心技术是什么？作为以搜索为主业的公司，Google对于搜索算法的投入当然很着力，但是搜索算法比较容易模仿，所以搜索是Google的强项，但不是其它公司无法望其项背的核心技术。Google的云计算平台是百万台规模的服务器集群，如此超大规模的集群，迄今为止，世界上还没有其它公司能够匹敌。云计算才是Google的核心技术。
所以，Google不惜余力地鼓吹云计算技术，这是合乎逻辑的。至于Google研发ChromeOS和Android的意义，不仅说明Google急于扩大自己的根据地，而且是把战火烧向其它公司的传统领地的战略部署，犹如当年老毛坐稳了延安根据地以后，就指派刘邓大军千里挺进大别山，是同出一辙的战略意图。
奇怪的是，从目前收集到的资料看，ChromeOS和Android，似乎都没有强调如何与云计算平台对接。具体来讲，ChromeOS和Android这两个OSes里面，都没有明确包含可移动式文件系统（Mobile File System）。
或许有人会争辩，不需要可移动式文件系统，因为只要给定一个URL，ChromeOS和Android操作系统就可以读写存放在网络云计算平台上的文件了。
在回答这个问题以前，我们先回顾一下，把云计算与ChromeOS和Android紧密联系在一起，有什么好处。ChromeOS和Android这些OSes存在的意义，首先在于方便应用程序的开发，其次在于支持应用程序高效率地运行。所谓高效率，关键在于节省计算资源的消耗。而节省计算资源，无非是找到CPU，Memory，Disk，以及网络带宽这四方面消耗的最优分配，以最快的速度和最低的总量消耗，响应用户的需求。
把云计算和本地OS紧密联系在一起，从终极意义上讲，是以带宽消耗的增加为代价，换取CPU，Memory，Disk消耗的降低。从具体做法上讲，有两个模式，一是前店后厂模式，云计算负责完成半成品，把半成品交给本地OS，本地应用程序完成后续加工，最后呈现给用户。另一个是资源外延，把云计算当成是本地CPU，Memory和Disk的外延，而应用程序把这些外延资源都当成本地CPU，Memory和Disk使用。
这两种模式的区别在于，如果使用前店后厂模式，应用程序需要明确地指挥，哪些工作转发给云计算平台处理，哪些留在本地处理。如果使用资源外延模式，应用程序不知道云计算的存在，似乎本地有无限的CPU，Memory和Disk。
如何把上网本和手机本地的CPU和Memory，与云计算无缝对接，这个问题比较复杂，以后专文探讨。把本地Disk空间与云计算存储空间对接，难度小得多。可移动式文件系统的目的，就是把本地Disk空间，外延至云计算平台。
或许有人会争辩，把本地Disk空间，外延至云计算平台，无非是把本地Disk空间，看成是云计算存储空间的一个缓存（cache），一个子集。只需要在本地文件系统加一个LRU（Least Recent Use）模块，管理哪些文件值得保留，哪些应该删除就可以了。
粗略想想似乎的确是这么回事儿，但是仔细想想，还有其它问题需要解决。
1. 移动设备的网络连接不稳定，时常发生中断。如果沿用传统的TCP/IP协议，假如一个文件的传输尚未结束，网络连接就中断了，那么等到网络连接恢复时，尤其是超过相当长的时间间隔后，需要从头到尾重新传输整个文件。有没有可能实现断点续传？有没有可能参考P2P文件共享的做法，先把大文件分割成若干小碎片，然后陆续传输这些碎片？但是假如在传输碎片的过程中，原文件发生更改，该怎么办？
2. 在传输过程中，防范原文件发生更改的关键，在于设定正确的读和写的锁机制。传统的写的锁机制，是排他性的，即一人在写，其他人都不能读。假如一个人在写的过程中，网络连接中断，写的过程迟迟不结束，那么就会造成其他人长久不能读的状态。能不能参考CVS的办法，在写以前，先checkout出一个拷贝，在这份拷贝上写，等写完以后，再checkin，这样就不会妨碍其他人读文件了。但是如果这样做，假如有多个人同时写，那么checkin的时候，需要不需要合并他们的更改呢？
3. 如果传输过程需要加密，沿用传统的SSL/TSL办法，绕不开使用公钥和私钥的握手的过程，这个过程很耗时。假如网络连接时常中断，每一次连接恢复时，需要重复握手的过程。有没有办法回避过多的握手，又不造成安全隐患？
4. 本地文件系统是云计算存储系统的一个子集，本地与云计算之间需要同步。如果云计算存储的文件发生更改，如何通知本地文件系统？如果采用本地文件系统主动的方式，定期向云计算申请核对的做法，有可能造成本地文件更新不及时。如果采用云计算平台主动的方式，通知本地文件系统及时更新，那么云计算平台势必要记住每个移动设备的文件系统里存放了哪些文件。如果移动设备很多，就不免给云计算平台造成很大负担。
5. 把云计算平台的某个文件夹，整体mount到本地文件系统，有没有必要支持这样的功能？
6. 当云计算平台存储的文件发生更改时，本地文件需要更新。最简单的更新方式是，删除本地文件，重新下载更改过的新文件。但是假如新文件和旧文件相差不多，最好在云计算平台预先算好新文件和旧文件之间的差额，然后让本地下载这个差额，最后在本地把差额叠加到旧文件，就实现了文件更新。这样做的好处是降低了下载量，问题是如何计算这个差额？使用Edit Distance算法是一个思路（http://en.wikipedia.org/wiki/Levenshtein_distance），但是假如文件尺寸很大，完成这个算法会消耗很长时间和大量内存空间。有没有办法加快速度，节省内存？
------
关于ChromeOS和Android闲言碎语就讲到这里。与其说这几篇文章澄清了一些疑惑的问题，不如说引出了更多悬而未决的问题。悬念，不仅是希区柯克吸引观众的伎俩，也是技术讨论的驱动力。
【全文完】
鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
和很多学校的seminar一样，这个问题要是扔到当年读书的系里，会有几个教授和研究生为这个事情讨论一天的。
Caching，就是
1.如何多快好省的把自己在当前时间T，以及近期T+dt要用的数据，放在手边。
2.把自己的工作结果，告知他人。
师兄所说的6点，我看可以总结为一个“view”模型：就是说：本地的文件是对远方云系统的一个视图。所谓视图，就是对远方的美景拍照，拍照的结果，就是把美景变成本地的一组像素。所以：
1.
同意。像素就是碎片
这个是cache update的经典问题，和具体应用有关。好在，云计算不是CPU，可以有多种更新方式。
2.
只lock自己要修改的那个碎片如何？我看，还是可以公开多种选项，让不同应用去选择是否lock & write，还是checkout & merge。
3.
除了某好莱坞导演会把还没有公映的大片放在云上，然后回家用iphone看，这个世界上面需要保密的东西，没有那么多数据吧？如果要保密，应该把关键的数据碎片进行加密，或者不要选择云。和具体应用有关。
4.
可以公开几种更新机制，按使用频率指数收费
5.
需要一张毫发毕现的美景？没问题，只要：
a.您离的足够近【网络连接足够好】
b.您的钱包足够鼓
6.
只更新修改过的碎片？
面向云计算服务平台的系统中，并不需要浏览器横挡在本地OS与云服务器之间