主题：【原创】浏览器是怎么变成操作系统的 -- 美人他爹
家园 断点续传的的问题，和数据压缩问题。。。 在HTTP和FTP层中早已解决。关键在WEB与FTP server和Browser与FTP client两端同时支持最新版的HTTP和FTP协议。与TCP/IP层（含下面的协议层）没有任何关系。据俺了解现在的Browser不支持HTTP1.1的几乎没有。
家园 在这篇里根本没有提到浏览器 面向云计算服务平台的系统中，并不需要浏览器横挡在本地OS与云服务器之间
家园 google wave似乎已经在预定这些协同标准了 家园 这是一个caching问题在网络时代的变形 和很多学校的seminar一样，这个问题要是扔到当年读书的系里，会有几个教授和研究生为这个事情讨论一天的。
Caching，就是
1.如何多快好省的把自己在当前时间T，以及近期T+dt要用的数据，放在手边。
2.把自己的工作结果，告知他人。
师兄所说的6点，我看可以总结为一个“view”模型：就是说：本地的文件是对远方云系统的一个视图。所谓视图，就是对远方的美景拍照，拍照的结果，就是把美景变成本地的一组像素。所以：
1.
有没有可能参考P2P文件共享的做法，先把大文件分割成若干小碎片，然后陆续传输这些碎片？同意。像素就是碎片
但是假如在传输碎片的过程中，原文件发生更改，该怎么办？这个是cache update的经典问题，和具体应用有关。好在，云计算不是CPU，可以有多种更新方式。
2.
但是如果这样做，假如有多个人同时写，那么checkin的时候，需要不需要合并他们的更改呢？只lock自己要修改的那个碎片如何？我看，还是可以公开多种选项，让不同应用去选择是否lock & write，还是checkout & merge。
3.
有没有办法回避过多的握手，又不造成安全隐患？除了某好莱坞导演会把还没有公映的大片放在云上，然后回家用iphone看，这个世界上面需要保密的东西，没有那么多数据吧？如果要保密，应该把关键的数据碎片进行加密，或者不要选择云。和具体应用有关。
4.
如果云计算存储的文件发生更改，如何通知本地文件系统？可以公开几种更新机制，按使用频率指数收费
5.
把云计算平台的某个文件夹，整体mount到本地文件系统，有没有必要支持这样的功能？需要一张毫发毕现的美景？没问题，只要：
a.您离的足够近【网络连接足够好】
b.您的钱包足够鼓
6.
有没有办法加快速度，节省内存？只更新修改过的碎片？
关键词(Tags): #caching，家园 5点同意，1点存疑 前面5点都同意，溢美之词就不多说了。
最后一条我没有解释清楚。举个例子，譬如我手机上存着2008年的地图数据，假如云计算平台上的地图数据已经更新到了2009年版本，那么应该如何更新我手机上的地图数据呢？
最简单的办法，先删除手机上2008年版本的数据，然后下载2009年版本的数据。但是这样的做法，隐含着必须下载整套地图数据，从而占用带宽很多。
鉴于2009年版地图数据，比2008年版差不了太多。所以，如果云计算平台先算出2009版与2008版之间的差额，然后手机就只需要下载这个差额，差额+2008版=2009版。
师弟的办法是，先把2008版和2009版分割成若干小碎片，然后逐个比较小碎片之间的差距。这些差距的总汇，就是前面说的差额。
这个办法当然是可行的，但是很难保证差额的尺寸尽可能小。把问题简化一下，或许能够解释得更清楚。假设有两个byte arrays。2008版的数组有100个bytes。2009版的数据与2008版相差不多，只不过在2008版开头插入了新的5个bytes，这样2009版总共有105个bytes。
假如按照师弟的办法，先把2008版的数组分割为10段，每段10个bytes。同时把2009版的数据也按10个bytes一段，进行分割，这样分了11段。接下来，逐对比较这些小碎片，从第一对，到第10对，每对都有5个bytes的差异。总共差额至少有（5x10 + 5 = 55）bytes，但是事实上，差异只是头上5个bytes。
总之，分割再比较的办法，对于如何分割十分敏感。感觉这个办法不够皮实。
家园 应该不是简单的分割 我去年和data domain的人聊过，他们的领域是用硬盘做差分备份，他们也面对同样的问题：如何在一个文件的两个版本里面找到最小的差异，这样可以帮他们节省空间，在我们这个问题里面，可以节省的是带宽。
他们的做法，貌似是用版本v1的某些字段，在版本v2里面找对应，然后这个查找有窗口，可以对付v2里面的添加删除和修改。和diff的办法差不多，但是我想里面应该有很多的heuristics。
嗯，添一段数学描述。
这个问题如师兄所言，是一个比较两个串的距离的问题：串s1和串s2之间的最短距离diff(s1, s2)。这个问题有经典解法，但是如果串很长，比如数百兆，那么计算起来太困难。
那么我们加入一些heuristics：比如我们知道其实s2是s1的更新，那么其实s2和s1只有有限的差别，其他地方都是一样的。我们就可以用分而治之的办法，也就是说，存在一个对s1和s2的分割D，使得：
D将s1和s2分割成相同数目的段p，每个段长度不同，但是这里面sigma(diff(p1i, p2i)) = diff(s1, s2)
那么我们的目标，就是找到一个分割D',使得这个分割计算出来的diff，最接近D的diff值。
如果再加一些heuristics，我们知道一般的文件都是有内部结构的，我们对于这些结构，可以加以利用，比如mpeg4的文件是分帧的，html/xml是树形的等等。这些都可以帮助我们建立这个分割。
家园 恩，你的diff patch的方式更好一些。
家园 谢谢：作者意外获得【通宝】一枚 鲜花已经成功送出。
此次送花为【有效送花赞扬，涨乐善、声望】
家园 应该是操作系统即浏览器 对浏览器就是操作系统这个说法近期还是比较有体会的。主要是写了个在线的中文输入工具，为了和gmail之类的整合，着实费了些心思，也长了些见识。大概十年前写过x-window下的中文输入法。比较之下，相似性真的很多。加上现在越来越多的online application。浏览器即操作系统的时代还真的不远了。其实我觉得更确切的说法应该是操作系统即浏览器。
顺便推广一下我的在线输入法：
http://www.livechars.com
据新兵营里反应，还满好用的。
家园 【原创】【3】 ChromeOS与Android 【3】 ChromeOS与Android，同室操戈，相煎何急
2009年7月10日BusinessWeek周刊上，有篇文章谈Google ChromeOS，重点是质疑ChromeOS的竞争矛头。表面上看，ChromeOS的竞争对手是微软的Windows。鉴于在PC领域全面挑战Windows的时机尚未成熟，所以ChromeOS选择了上网本（Netbook，MID），作为切入点，先占据一块根据地，然后谋求扩大根据地，从农村包围城市。
但是从实际效果看，一方面Google ChromeOS并没有对Windows构成实际威胁，另一方面，反倒是挖了自家兄弟，Android的墙角。文章给出的证据是，1. HTC和BORQ这样的厂商，在选择上网本的操作系统的时候，对于究竟是该用ChromeOS，还是用Android，感到很困惑。2. 预计到2011年，ChromeOS可能会占据上网本13%的市场份额，而Android的市场份额会降低到7%。
为什么Google会同时支持两套OSes，而且两套产品的市场定位有相当大的重叠？
Google的VP，Android的领军人物Andy Rubin的解释是，Android针对手机市场，专注于处理移动网络连接，手机电池管理等等。换句话说，Android与iPhoneOS竞争，而ChromeOS与Windows竞争。坦率讲，我们不认为Andy Rubin的解释非常有说服力。理由如下，
1. ChromeOS和Android的Kernel都是Linux。这两套Linux Kernels，似乎没有什么显著不同。
2. 关于Android在移动网络连接，电池管理方面有独到之处，说白了，这些独到之处其实就是一些libs。我们把这些libs通称为MiddleWare。ChromeOS与Android的MiddleWare或许的确存在差异，但是只要调整MiddleWare中包含的libs，这些差异很容易弥补。譬如，只要把Android的有关libs，移植到ChromeOS中去，ChromeOS也就具备了移动网络连接，电池管理的特异功能。
3. Android的主要卖点是Dalvik VM。有了Dalvik，应用开发商就能够用Java语言编写软件。ChromeOS似乎不包含Dalvik，但是把Dalvik移植到ChromeOS，似乎也不是一件非常困难的事情。
4. ChromeOS的特色在于基于浏览器来做GUI管理，而Android仍然延用传统的办法，靠调用APIs的办法来实现UI。把基于浏览器的GUI管理，与Dalvik相结合，难度不小，但是还是可行的。以后写专文探讨。
总之，我们认为，
1. ChromeOS和Android专注于不同的市场的传言，从技术上讲，这些的说法不太可信。
2. ChromeOS的矛头从长远来讲，或许是Windows，但是近期内，实际上冲击了Android的市场份额。从长期来讲，受威胁的很可能是Linux KDE和Gnome，而不是Windows。
3. ChromeOS和Android各有所长，最好的办法是融合，取长补短。从技术上讲，虽然有些难度，但是值得尝试。
家园 有可能Android+Chrome=ChromeOs