forcode：虽然很早就听说过firefox将成为网络操作系统入口这样的说法，但是第一次看到有人直接将firefox比作虚拟机，感觉还是很新鲜。陆陆续续也读了不少IT新闻，也有不少想法，稍作一下总结吧。

forcode奇想:手机版的DOS网络操作系统
http://www.qixianglu.cn/374455.html

网络操作系统概念诞生十周年
http://www.qixianglu.cn/380540.html

网络操作系统有四条可能的道路：

1、firefox模式。正如下面的转帖所说，firefox作为虚拟机，所有程序以firefox插件形式运行在firefox之上，无论是什么本地操作系统，只要安装了firefox，你就可以运行相同的程序。

优点：可以实现web程序与本地程序的无缝对接，比如google reader，在google gear的支持下，既可以在线阅读，也可以离线使用；由于软件功能所需要的大部分计算已经由服务器端处理，所以本地客户端可以做的非常小；而且，由于用户操作数据联网，所以可以实现用户操作数据的社会化分享和挖掘。

缺点：网络化程度还不够，所有插件程序依然需要安装在本地，随着安装的插件数量的增加，对firefox虚拟机的要求也越来越高，firefox崩溃的风险比windows崩溃的风险更大，firefox要成一个稳定可靠的虚拟机，还需要加入更多的安全机制，比如类似 windows休眠功能这样的系统状态和操作数据备份工具。

2、facebook模式。facebook模式更加彻底，完全摆脱了本地限制，根本不需要本地有一个虚拟机，不管是firefox还是 IE或者opera，只需要有一个标准的浏览器就可以，所有的计算和功能增减完全在服务器端完成。在这种模式下，本地的计算能力完全不是问题，甚至本地也不需要有一个复杂的操作系统，如果BIOS成功支持大容量记忆体，我们只需要在BIOS硬件记忆体中预安装全功能浏览器，就可以像开电视机一样，按一下按钮，不需要漫长的设备自检和操作系统加载，1秒钟内立刻打开浏览器，马上可以登录到facebook使用各种功能。

优点：本地客户端可以做到最瘦，这非常适合手机这样的便携式平台，可以随时在线，瘦客户端可以加速网络覆盖人数，减少第三世界的数字鸿沟。用户数据和操作可以实现最大程度的社会化，这些数据的SNS交互，可以创造出全新的商业模式，广告的效率可以成倍提高。

缺点：对网络速度和稳定性要求很高，尤其是稳定性，一旦网络出现故障或不稳定，操作无法获得即时反馈，用户体验骤降，所有本地设备都成为废品，不能作其他用途。从目前的技术来看，网络稳定性（尤其是无线网络的稳定性）还有待改进，本地缓存机制依然是必要的。

3、远程协助模式。这种想法是从QQ远程协助功能受到启发产生的，在这种模式下，不需要创造一个全新的生态系统，只需要一款足够强大的远程控制程序和足够快的带宽，只要在你的手机中安装了这款强大的远程控制程序，使用3G网络，你可以观看到在服务器端运行的任何操作系统和程序的桌面，实际上，计算能力依然是在服务器端，但是，你的手机屏幕成为了这个服务器的显示器，你的手机键盘成了这个服务器的输入设备，你的所有操作和反馈全部以图像的方式在手机终端与服务器之间传送，这对客户端而言，下行带宽要求很高。但是3G时代，这可能不是问题了。

优点：在3G普及的前提下，只需要一个程序即可解决网络操作系统的所有问题，依然使用的是传统的硬件、操作系统和程序，所需要的只是一个程序，对于整个社会而言，这是代价最小的网络操作系统方案。你可以使用手机来操作你家里那台服务器上的photoshop来处理你手机刚拍摄的照片，你完全可以使用photoshop的所有功能，处理完的照片，你可以重新传送回手机，然后立刻分享给好友。

缺点：由于必须有一个真实的服务器在同步运行你手机正在操作的程序，所以，在一定程度上造成了硬件的浪费。但是，由于VMWARE这样的操作系统虚拟软件的发展，在一台硬件上虚拟数十台电脑将不是问题。另外，这种网络操作系统的模式依然是非社会化的，用户数据依然是分散存储在各个独立的服务器内，无法实现分享。

4、IM机器人操作系统。我们知道，在windows之前，DOS曾经是非常流行的操作系统，拥有很多优点，不需要在复杂的菜单中来回倒腾，输入一行简单的命令，立刻可以得到需要的结果，现在UNIX等系统，SAS和stata等统计软件依然使用类似DOS的命令行操作方式，对于高手而言，命令行比菜单操作效率更高。IM机器人作为网络版DOS的命令行输入工具，这种想法是来自gtalk机器人，我们只需要给IM的机器人发一个 HELP，就可以返回一大堆的命令选项，然后输入选项序号，可以进入相应的子选项，也可以用来实现不少功能。如果我们的IM内加入数百个机器人呢？每一个机器人可以实现一定的功能，也相当于一个程序，使用率越高的机器人越靠前，也可以使用机器人搜索功能来添加新的”插件”（或程序），这可能在某些领域非常实用，比如金山词霸可以弄一个IM机器人版的程序，天气预报查询，google reader也可以弄一个gtalk机器人。

优点：操作效率很高，可以迅速得到需要的结果。在某些领域可能非常有用处，比如可以用来做统计，所有统计数据和统计软件全部存放在服务器端，你可以在手机内使用IM（比如gtalk）的SAS机器人，可以与它交互来获得需要的统计分析结果。也可以用来输入搜索关键词、获取SNS的好友消息等，将来3G网络肯定是随时在线，这种SNS好友动态也是很多人关心的，移动版的IM机器人应该大有用武之地。非常不消耗系统资源，而且可以保存所有操作过程的记录，可以作为一种补充模式存在下去。

缺点：缺乏用户数据的交互，缺乏图形界面（但是未来IM支持图形反馈界面应该也是必然的了），非图形化界面，输入可能比较繁琐，而且需要记忆大量的操作命令，学习成本较高。

做好准备迎接新的平台大战。Google Gears 直指微软领地
from 译言-电脑/网络/数码科技 by 净空无道

原文作者：Nik Cubrilovic
原文链接：Get Ready For A New Platform War. Google Gears Drives Straight A
译者：净空无道

Google 在去年五月发布了 Gears，之后的一年里 Gears 被
认为是一个小众产品，只会有很少开发者和用户用它来开发能够离线访问的 web 程序。兴许你还能回想起当年的争论：在到处都有网络连接的情况下，究竟谁需要离线访问功能，而且还没有足够的程序支持，等等。不到一年的时间，就在几周前，Google 亮出了他的王牌：Gears 助力 MySpace 加速邮件系统。其实 Google 早就加入了这场提供新 web API 的比赛，但是居然一年了都没有人注意到。

将 来的浏览器很可能会变成运行所有程序的虚拟机。在这种情况下，操作系统会变的透明，就像 Adobe 所作的，它的 Flash 技术是现在使用的最普遍、最统一的 web 虚拟机，而微软则要自保（它的利润的来源）了。Google 不隐瞒他们想瞄准并且攻击微软的野心，他们知道，要做到这点的最好方法就是上移一层把操作系统架空，让浏览器成为标准且强劲的应用程序虚拟机。

很难在一片评论里表达清楚 Gears 如何改变并且增加 web 程序的功能。以前使用基于浏览器的 Javascript 脚本，MySpace 中的一些类似邮件列表和排序、根据好友列表过滤这样的功能会让人感觉很慢，而当浏览器向服务器发送多个请求时，进度条还可能会定住，沙漏图标在不停的旋转。而现在，安装 Gears 只要在确认框点击一下并且等待几秒钟，安装之后，以前让用户抓狂的那些功能现在感觉起来就好象是浏览器自带功能一样。Google 给我们秀了一把 Gears 与 MySpace 集成后的能力，这唤醒了大部分人关注他真正的意图：不再仅是离线浏览，而是直接针对 Adobe 和微软所采取的行动。

截至目前为止，Google 拥有一系列共计 28 个基于 web 的程序, 这些程序在全世界有数百万的用户。Google 开发 web 程序的技术都是基于标准的 HTML、CSS 和 Javascript。选择 Ajax 仅仅是因为这是最好的解决方案，但是 Google 还要做更多以面对现实，那就是每个类似的 web 开发技术体系都是被一个直接的竞争者所开发、控制。Google 对开源浏览器 Firefox 的开发给予了强大的支持，并且支持开放 web 标准作为他们的技术体系之选。Google 这么做是因为他们的 web 程序都依赖于开放标准，Firefox 的失败会导致 Internet Explorer 复生并且把 web 的控制权拱手让给微软。

以前，只用基于浏览器的 Javascript 来支持 web 程序对 Google 来说不是个问题。直到竞争者领先一步发布了他们自己的第二代 web 平台，分别是 Flex/AIR 和 Silverlight，情况才发生了变化。基于 web 的程序在有了类桌面的界面和功能后能够做什么，从这一方面开说，微软和 Adobe 已经超前了一大步。用不了多久，大大小小的竞争者就会使用竞争性技术平台创建竞争性程序，那会使 Google 的产品看起来像是还停留在上个世纪九十年代的样子。

留给 Google 的选择现在很明了了：要么放弃使用基于浏览器的 Javascript 和开放标准进行开发，转而接受新技术中的一种，要么继续坚持使用核心 web 技术并且发展这些技术直到成为可行的替代技术。Google 的问题是，新标准和预期的浏览器功能很快就会带来富 web 技术，但是开发那些标准的进度却如此缓慢，以至于很可能需要几年时间才能看到那些标准被广泛的应用。新的 HTML 标准，HTML5，特别关注扩展本地浏览器对 web 程序的支持能力，在不用附加私有运行时的情况下。Google web API 的基础就是这些同样的功能以及其他的附加功能。

由于标准开发的极其缓慢，导致通向更快更好，而且仍旧免费开放的 web 程序之路被堵死了，所以 Google 决定通过 Gears 自己进入这个市场。想法其实很简单：把明天的 web 技术带到今天的浏览器里。这些特定的功能大部分都来自新的 HTML5 规范，但是标准制定小组已经在上面花费了好几年。不想再等这个小组完成规范，Google 自己通过件对浏览器进行扩展，实现了这些功能并且达到了那个小组能达到的最高水平。他们宁愿在短期内抛弃标准（原话是“以后再考虑实现”）也要把他们的 web 程序带到能够对抗 Flash 和 Silverlight 的下一代标准。

Gears 有一个 30 人左右的小组开发，这个小组是 Google 内部开源小组的一部分。这个小组由 Vic Gundotra 带领，再一次讽刺的转变过程中，他由微软的传教士成为 Google 的高级开发者。这个一小组开发者着手进行开发，并且保持 Google 对 Javascript 和开放浏览器虚拟机的兴趣。理论上，他们看起来很可能被大组织或者微软和 Adobe 正在投入各自平台的预算所超过。为了改变这个状况，他们把 Gears 从 Google 中分离出来（字面上也是–现在这个项目名称就只是”Gears“）并且在开源协议下发布源代码。

第一个发行版将只关注于 HTML5 里面提议的新功能中他们认为最重要的功能：基于客户端的结构化数据和对象存储。由于选择了首先实现客户端存储，所以下一年里 Gears 会被构架成一个离线应用程序解决方案，由于其他的竞争者好像都没有注意到这个这么巨大目标，所以如果他们不是有意而为之，那么肯定会发展的很好。 Google 本来有可能开发他们自己的浏览器，某些博客里的推测和谣言也都指出了这一点，但是浏览器市场竞争激烈，却平淡乏味，而且通常会失败。另外，即使他们开发了自己的新浏览器，他们还要驱使用户接受这个新浏览器，在决定性的市场聚集起来之前只能等待，就是这样，市场上还会有 70% 或者 80% 甚至 90% 的人不使用 Google 的浏览器，却想使用 Google 的程序。

这种情况下，可选的捷径就是跳过浏览器直接在上面增加一层--Google 自己的 web 层。所有常用浏览器都提供了让开发者扩展功能的机制，这样一来，Google 要做的就是对每个浏览器开发对应的插件。这能让新的 web API 能够适应所有的桌面而不需要用户去适应，最重要的，这比起进入浏览器市场来说见效快而且痛苦少。现在可以让浏览器来做所有无聊的事情：渲染 HTML、显示界面、用户选项等等，与此同时 Google 却在改变现状，埋头向前冲。

现在 Gears 支持大量完整的新功能，有一些新功能是和微软、Adobe 他们的下一代 web API 相同的，而其他的则是 Google 自己创造

你可能对这些文章感兴趣：

• 2005-12-28 -- 寄生植物操作系统之实用寄生物种:骆驼牌矿泉水兽 (0)
• 2008-08-05 -- forcode奇想：每一个光子都是宇宙的种子 (1)
• 2008-07-17 -- 如果有100票支持，forcode就动笔写科幻小说《小精子玩转地球》 (0)
• 2008-07-17 -- 奇想家园SNS社区简要使用指南1.0 (0)
• 2008-07-14 -- forcode点评：经济危机是互联网的春天？ (3)
• 2008-07-08 -- 康盛推出类open social平台MYOP的感想 (0)
• 2008-07-07 -- 强烈需要的UCenter home插件功能 (0)
• 2008-07-07 -- 超强人体艺术（组图） (1)
• 2008-07-04 -- 去科幻SNS“奇想家园”注册吧 (1)
• 2008-06-29 -- 终于找到小时候看过的最恐怖电影《再世惊魂》（剧透+在线播放） (0)

Related posts:

1. Google Reader 下周将改版 根据 Google Reader 的官方 Blog，Reader 下周将会有一个较大的改版。主要有2个方面的改动：用户界面及整合 Google+。 估摸着用户界面的改动就是走向小清新化了（终于。。），而整合 Google+ 也顺理成章。...
2. 谷歌地图API即将收费 　　Google地理开发博客宣布，谷歌地图API（Google Maps API）将不再免费提供，当用户调用谷歌地图API超过一定限制，将会按照超出的次数来收取费用，费用是每一千次调用4-10美元左右。 　　对开发商的影响 　　Google建议使用Google Maps API的开发商，需要评估一下调用谷歌地图的用法，确认他们的服务是否受到影响。如果调用次数超过限制，则需要： 　　1、降低调用Google Maps API的次数，将其限制在每天二万五千次以下。...

以上关联文章由 Yet Another Related Posts Plugin 提供支持。