主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹

如果说这个系列的前面那些，都是我在忽悠着大家乱跑的话，那么这一贴，请允许我停下来，面对前方的迷雾，说说我不成熟的想法，说说我的惶惑。如果我语无伦次，请多包含。

我在这个系列里面，一直提到计算机和人的共同发展，是以一个系统+语言的模型作为界面的。系统是我们描述现有计算机的抽象模型，语言是我们描述我们希望系统进行的操作的媒介，同时也是我们扩充系统的方式。

在电子管、晶体管和几十年以前的单片机时代，系统是计算和IO模型，语言是汇编；在小型机和PC时代，系统是OS，语言是Algo家族的直系旁系子孙，如C,Pascal等；那么在现在呢？如果你同意我说的，计算机的发展，已经转移到以数据为中心，那么什么是新的系统？什么是新的语言？

我们过去处理数据，是把它们放到数据库里面，切成整齐的表格，然后用SQL来查询它们。但是数据并不老实，它们说，我们不是表格，我们应该可以扩展，鸟可以扩展为鸡，鸡可以扩展为芦花鸡和白斩鸡。于是出现了面向对象数据库。但是internet的出现，让数据变成了网状结构，而且每个页面都只有有限的共同点，剩下的就是不限长度的文字，还有各种资源链接。

在表格结构被各种奇形怪状的数据撑的支离破碎的时候，SQL的命运似乎也应该很惨才对。但是我前面做的一个项目，让我对SQL的描述能力，有了更新的了解。

那个项目是一个web service。限于工作要求，我不能说明具体的实现。但是我可以说的是，我们的数据源绝对不是数据库里面的表格。这个web service的一大任务，是要定义一个查询界面，用来查询数据源里面的数据。

对于这样一个结构复杂的数据源，我们开始定义新的查询语法，设计接近尾声的时候，我们需要确认这个查询语法是完备的，也就是说，它必须能够描述所有数据源里面的数据。

为了这个完备性我们开了四个小时的会，最后我百无聊赖的趴在桌子上面，在笔记本上乱画，随手写出了：

select * from data_source where source.property is like

说实话我把自己吓了一小跳，因为SQL的语法用在这里很合适，尽管我们操作的不是表格。我于是提出，我们应该把SQL作为一个标准来比较，如果标准SQL的查询里面有的东西我们没有，那我们就要认真看看了。

我们的Architect虽然不太情愿说我们重新发明了SQL，但是毕竟这种说法留出了我们的语法是SQL超集的可能性，于是他也接受了。事实证明，我们的数据虽然不是表格，但是SQL语法可以描述我们的查询的绝大多数。

另外一个让我兴奋的事情，就是抛弃了表格这个东西，大多数SQL语法依然成立。比如鸡有腿，兔子也有腿，但是这根本就是两种不同的腿。如果我们局限于表格，那么鸡和兔子应该是两个不同的schema，鸡兔同笼的题目描述起来就困难了（假如我们的数据组织，不仅仅为了做鸡兔同笼的话）。可是，在SQL里面，我们是用名字的，只要被操作的数据有“腿”这个属性，我们就可以描述。这比面向对象还要好，我们不必为了这道题目，专门给鸡和兔子建立一个公共的陆生动物父类。

更进一步，我们可以在笼子里面扔进去蜈蚣，蛇和CPU，只要他们都有N条叫做腿的东西，我们的描述，依然有效。

不过，internet这种网状结构，就是数据的系统模型吗？SQL更是离数据的语言很远。我们怎样用数据描述这个世界？难道为了任何一种抽象，就要建立一个类。或者做一张表吗？我不认为这样是对的，但是我也不知道什么才是最好的建模方法。或许，这种方法，深深的埋藏在我们的意识里，是我们认识世界的基本方法。或许，这种方法，本身非常的简单。

面对新的机会，遥远的路程，云深不知处。

【全文完】

【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闲言碎语就讲到这里。与其说这几篇文章澄清了一些疑惑的问题，不如说引出了更多悬而未决的问题。悬念，不仅是希区柯克吸引观众的伎俩，也是技术讨论的驱动力。

【全文完】