Willow Garage 的机器人已经送出

Willow Garage 是家开发机器人硬件和配套 open source 软件的机器人公司,主要专注于个人而非工业或军事机器人应用 personal robotics applications。它们成立于 2006 年,两年后 2008 年,PR2 的第一个 alpha 问世。对比:开发了也很酷的 big dog 和 little dog 的 Boston Dynamics 波士顿动力。他们的软件 robot operating system,ROS 用 BSD license 发布,开发方面,目前对 Ubuntu 支持最好。Mac 和其他 Linux 发行版的支持正在开发中,Windows 只有部分支持。

前一段时间,问了提振声势,Willow Garage 弄了个策划 PR2 Beta Program:机器人方面的研究机构可以提出申请,WG 将捐助 10 台他们的 PR2 机器人。这个计划推出后,他们收到了 78 个申请,后来选中了(并小修正了项目目标)11 家机构,78 个和 11 个里美国之外的也不少呀,这些申请机构在申请时也都表明了自己打算利用 PR2 进行的研究。WG 说此计划捐助的 PR2 机器人价值超过 440万 美元 —- 当然,硬件不是唯一出去的东西,免费且 open source 的 ROS robotics framework 也在其中,方便这 11 家机构进行研究开发。所有参与计划的 11 家机构将发布它们的开发成果,从软件代码到理论研究成果。WG 估计在今年的的 ICRA 上,会有展示基于 PR2 的研究成果发布,比如这样一些实际应用(憋住气,不要笑):开关门,插电源插头,叠毛巾,^_^

这 11 家机构已经选定:

* Albert-Ludwigs-Universität Freiburg
* Bosch
* Georgia Institute of Technology
* Katholieke Universiteit Leuven
* MIT CSAIL
* Stanford University
* Technische Universität München
* University of California, Berkeley
* University of Pennsylvania, GRASP Lab
* University of Southern California
* University of Tokyo, JSK Robotics Laboratory

为什么好像没有 卡耐基梅隆 Carnegie Mellon?还是卡瞧不起 WG 的东西?呵呵……

这个月 20 号,11 台中的第一台已经发货到了 Standford 斯坦福,接收方是负责 PR (Personal Robot) project 的 Ken Salisbury 教授。这个项目早先开发了 PR1,ROS 实际上也是 STAIR (Stanford AI Robot) Project 开发的。现在新的 PR2 将是 STAIR Project 的新平台。

PR2 是 WG 全新开发的软硬件平台,专门面向软件开发者和研究人员:WG 的定位也就在这里,可以免去自己首先搭建硬件平台,然后开始 coding 这个过程中不经济不高效的部分,PR2 可以让软件专家马上开始为机器人开发新功能,自然,与 PR2 紧密集成的是 ROS。硬件配置方面,PR2 的脸部,胳膊和底座上都有传感器,头部配备立体摄像机,投影仪,500万 像素摄像头,激光探测器,联网的广角摄像头,手上还有加速度传感器和压力传感器。计算方面,PR2 赶上了好时代,最新的 8 核心 Intel Core i7 至强处理器配备了两颗,每颗下面 24G 内存,一块 500G 硬盘,外加个 1.5T 的专做日志记录。电脑和上面那些五花八门的传感器什么的通过一个 16 口千兆以太网通信。这一大堆东西都在机器人身上,当然还没完,机器人通过连个 dual radio 的无线路由器接入实验室网络。

有此一玩意儿,此生足矣~~

Iron Baby

Patrick Boivin 的短片 Iron Baby 火了,这是个自创精简版 Iron Man,主演是 Patrick 的女儿(没错,女儿),导演是 Patrick,服装是孩子的叔叔。

土豆

YouTube

Patrick 是法裔加拿大人,生活在 蒙特利尔 Montreal。他的 YouTube channel 已经有8万 多人订阅,所有作品有六千多万次播放,这个数字我觉得很了不得。这是位自学成才的“电影人”,片子的导演,剧本,灯光,摄像,编辑,动画,特效等等通常都是他一人搞定,有时候甚至自己创作声效和音乐。这是他的主页

如果没有 YouTube,Patrick 这样的人我们永远也发现不了,生活里的有些乐趣永远也出现不了。

美国:3G 发展后发制人

最新数据形势喜人呀。

GigaOm 的 America’s Amazing Rise to 3G Dominance说,美国 70% 移动用户都在 3G 网络上了,相比之下,去年年底,全球的移动电话只有 20% 在 3G 网络上。貌似印度和中国如果能成功普及 3G, 全球的数据会变得很好看。虽然我们经常听到美国用户在抱怨某A公司在覆盖和速度上的欠缺,不过,第一,老美就是爱抱怨不管生活多美好,第二数字表明,美国运营商们在力推 3G 服务方面做得还是不错的,另外愿意乃至主动期望高速数据服务的消费群体也足够庞大有力。

今年第一季度,全球运营商里,数据服务利润的前 10 名里,美国 4 大全都上榜。Verizon 冲到了第一。

北美的 3G 启动和普及比欧洲晚,不过目前结果很是厉害。直观上看,运营商和设备制造商取得了双赢,而且他们仅仅是赢家或者说受益者中的一部分,抛开消费者不直接接触和了解的网侧设备供应商,我们能第一时间反应出的好例子是 AT&T 和 Apple,可实际上另外 3 家 T-Mobile,Verizon 和 Sprint 与 HTC,Samsung 和 Google 等也有互相促进,都是得益者,再往下,iPhone 与 Android 平台上的应用或服务开发者不也异常繁荣兴旺吗。这种利益某种程度上可以说都传递到了国内的代工厂。

现在美国已经是第一批大规模商用 WiMax 的国家(欧洲包括俄罗斯有规模不详的商用),还会是第一批部署 LTE 的国家。相形之下,我们的移动运营市场闭塞,充满光怪陆离的监管,被承载着莫名其妙的责任,当年甚至不光不要早起,还要故意等着速度最慢的齐步走,这其中一朵奇葩乃是 TD 的上马,自由竞争和 risk taking 的创新绝对没问题,可傍上权力大款,踩着国民的脑袋往上主动给人当枪使就是另一个问题了,我从来不信运营 TD 可以用发展自主标准保障国家利益的理由来解释,是不是个跛足的技术只是问题之一,TD 的利益是利益,生态圈本能蓬勃发展带来的利益就不是利益?那些被淹没了的更多更灵活的创新与发展谁为他们说话?我不相信谁有资格和能力能对 TD 带来的回报做保证,更别提要我相信 TD 的利益要高于那些被牺牲掉的产业链里缤纷创新的利益。

高速数据服务我们走晚了,运营商显然不光是运营商还差不多要成国家机关事业单位,利益集团和意识形态都能对他指手画脚,没人保证它们能按照自己的判断做出有逻辑的商业抉择。运营商实力,终端发展情况和产业链上的服务目前不光初级,而且处于扭曲状态。初级倒不要紧,一直在发展就好,可是扭曲状态会…扭曲…我们发展的路。

每次要琢磨是带跑在 Edge 上的Touch HD 还是 WCDMA 上的 Desire 时我都忿忿不平,TD 是个套在中移动裤裆上的贞操带,王建宙们再有雄心壮志,也明白,得屈从于顶着国家利益之名的政治任务,这幅贞操带,自是让中移动无从满足自我,更是那个神秘男权一贯爱使的手段。中移动,恐怕没法随便动吧。这份纠结的悲叹永远指向一个无法或者也无需跟你我明说的问题核心。

加密 Google Web Search 已经发布

这个 logo 稍有不同,一是右上角有个 SSL 标志,另外就是右下方的 beta。Google search 的 SSL 加密版上线了。地址: https://www.google.com。

搜法X功,Y萝卜没有再 connection reset了,我确信,我不光确信还专门恶意试验过了,真是理解了杨利伟太空中那句“感觉良好”啊 —- 只要没有被 block,这个感觉就一直可以良好下去。从弹出搜索提示框到给出结果都没问题 —- 当然,搜索结果里的目标网站能不能访问不关 Google 的事。另一个小遗憾是,Cached 还是 http,但 Similar 相关搜索还是方便地一并提供了 https 。访问速度很快,没有什么迟滞感。

据说工程师式的精确性就是既不提前也不迟到,既不欠奉也不超供。上周六说,“Google 下周可能提供加密搜索”,这帮哥们就真的等到太平洋时间 21 号周五 12:30 PM 正式发布,真的是很“下周”,当然,Google Blog 也做了正式宣布

像 Gmail 和 Google Docs 一早已经提供 SSL 安全连接,端到端加密可以保证数据不被偷窥或者篡改,不过对 search 这一服务来说,提供安全加密的服务这一想法就很有新意。目前只有 core service 也就是 web search 提供 https,通常的 图片,地图等还是只能用提供 http 连接的普通搜索。

文中所说:

we’ll continue to add encryption support for more search offerings.

加油!

HP Envy 17 的3屏支持

Intel 的 Calpella 一代移动平台已经发布有段时间了,大大小小的 OEM 们现在差不多都推出升级产品了,这自然包括 HP。Envy 是 HP 的消费类产品线中的奢侈品牌(当年收购 Voodoo PC 然后演化来的),在设计和性能上都非常突出(相比之下,我看 Pavilion 系列就够难看的,特别是那逐渐变厚有镀铬感觉的侧边)。

最近刚出来的是 Envy 14 和 Envy 17,型号数字也表示屏幕大小。在 SlashGear 看了一段访问和介绍视频,其中提到 Envy 17 的一个特性很有吸引力。Envy 17 提供的显示接口有 HDMI,Mini DisplayPort 和 VGA,有这3中接口能单独使用很正常,不过 Envy 还可以配合 ATI Eyefinity multi-display 技术,同时用上这 3 个接口连接 3 个显示器,当做一个扩展的虚拟屏幕。不需要任何额外的转换,分线等设备,非常方便。

这是演示视频的截图:

这下 3 个显示接口利用率可高了,对 Envy 17 这样定位于桌面替代品的笔记本来说,这个特性很贴合定位。现在 Eyefinity 可以一块显卡支持 3~6 个显示器,将其拼接成一个虚拟显示器,具体是 3 还是 6 要看显卡了。HD 5000 系列支持 3, 不过 Radeon HD 5870 Eyefinity Edition 支持 6 个 Mini DisplayPort。Envy 17 用的是 Mobility Radeon HD 5850。

Envy 系列是我看唯一能和 Mac Book Pro 系列在做工和性能上有一拼的产品,不过这一拼也有点勉强,特别是在耗电,厚薄上,设计也感觉有点怪怪的(那个纹理),PC 世界的多样性多到找不到能和竞争对手的旗舰有一拼的产品的地步,着实反讽。

Envy 17 的 3 个输出端口都插上的样子

Video for Everybody: 周到的网页内插入视频方法

Tim Bray 的 blog 今天提到这个不错的东西:Video for Everybody

HTML5 Video 与 flash; H.264 与 Theora 正争得口沫横飞,而那些要在页面里嵌入视频的哥们夹在中间恐怕不好过:认清并跟随趋势是必须的,不能得罪现有用户也是必须的。挠头了有点……我的 code 到底是用 video 标签还是 flash 呢?这种情况,用 Video for Everybody 是个不错的选择。

Video for Everybody 是一段 HTML 代码,放入自己的页面即可。这段代码可以让访问者的浏览器选择最合适它们的视频播放方法:有 HTML5 就 video 标签为主,老一点的浏览器则自动用 flash 观看,这样一来,一个都落下。既使用了最新技术,也不用担心访问者看不到视频,很省心。

去掉注释部分,这段代码不算长(官方网站有注释版,更清楚):
<video width="640" height="360" poster="__POSTER__.JPG" controls>
<source src="__VIDEO__.MP4" type="video/mp4"></source>
<source src="__VIDEO__.OGV" type="video/ogg"></source>
<object width="640" height="384" type="application/x-shockwave-flash"
data="__FLASH__.SWF?image=__POSTER__.JPG&amp;file=__VIDEO__.MP4">

<param name="movie" value="__FLASH__.SWF?image=__POSTER__.JPG&amp;file=__VIDEO__.MP4" />
<img src="__POSTER__.JPG" width="640" height="360" alt="__TITLE__"
title="No video playback capabilities, please download the video below" />
</object>
</video>
<p>Download Video: <a href="__VIDEO__.MP4">Apple iTunes "MP4"</a> | <a href="__VIDEO__.OGV">Open Format "OGG"</a></p>

把其中的 __VIDEO__.MP4, __VIDEO__.OGV, __POSTER__.JPG 等等部分换成对应的文件即可。

对支持 HTML5 的浏览器,这段代码使浏览器启用 native HTML5 支持,完全不会引入一星半点的 flash。比如 iPad,其访问测试页面就会如此:

如果访问者浏览器不支持 HTML5,比如是 IE,转而使用 flash,如图:

还有考虑更完备的,如果上述情况 HTML5 和 flash 都不支持,比如有些“洁癖”用户不装 flash 插件,再用不支持 HTML5 的浏览器,那同样这段代码会送出一份 place holder 给浏览器:一张视频截图,截图下有视频的地址,愿意的话,访问者可以下载到本地观看。
注意有一点不同:不像通常的浏览器行为,用户不会被提示去装个 flash 插件,记得 IE, Firefox 和 Chrome 弹出那个黄条条?Video for Everybody 这段代码可不会导致这烦人的提示。

当然,Video for Everybody 提供的是方便的前端方案,前提是有 OGG 和 MP4 文件准备选一个呈现给用户。这段代码和编解码本身无关,并不自动做一段视频的多种编码工作。

Video for Everybody 没有使用 JavaScript,不做浏览器嗅探,无论是什么 RSS reader 或者 iPhone,iPad,支持的浏览器/OS 平台非常广泛。我自己用 Firefox 和 IE8 访问了一下 VfE 的测试页面,工作得很好。

现在 iPhone OS 有个 poster 属性处理的 bug,使用这段代码的时候注意一下就好了。

最后,类似的自动适应代码还有另几个选择,可以参看 speckyboy 的文章 HTML5 video Libraries, Toolkits and Players

坚持与这个世界Sync

很不幸,我得开篇就这么黑暗地假设一个场景:你已经被死神盯上,用过的很多剂药物都失效了,一位称职也尽职的医生告诉你,现在有两个方案可选:一是不再进行治疗,什么都不做,接受现状,等待死亡,1周内生命就会平静地结束;另一个是他还有几种药物可用,这些药物绝无伦理或金钱方面的问题,亦不造成身体或精神上的任何痛苦,除了要按时服药这样的小折腾,没有其他任何不妥,不过它们也只能延长1年生命,1年之后,死亡仍会坚定地到来,绝无例外。两个方案你大概会怎么选?

这个死神就是 GFW:Gongchan Fucking Wall,已经被它盯上并被镰刀成功收割的名单很长,最近一个是 Dropbox。不过,现在还有些可选的替代药物,可惜跟前面假设场景里的情况类似,这些药物没有一个可以保证永恒,最多是延长些许生命,这期间只要那个死神愿意,还是可以立马让药物失效,剥夺你的生命。你会选择接受死亡,不再折腾了,还是明知那些待选药的命运捏在GFW手里,撑死生命只能延长1年,也要和GFW 抗争1年?

我这么想前提一下,是因为后面会介绍一些Dropbox的替代品或替代方法,当然还想提一下一劳永逸的完备的超越文件sync范畴的免疫GFW的方案。如果你现在累了烦了,不想再折腾了可以不用看下去了。没事儿,不用过虑,我(并建议所有人)尊重人的选择,并真诚地理解,因为每个人都有决定自己生活的权利,如果总把自己的想法强加给别人,那我们和建造 GFW 的人就没什么不同了。当然,也请不要忘记我这种人的存在,就像我也不会忘记你一样,如果有重新鼓起兴趣想尝试不同的生活的一天,欢迎!

如果你的选择是明知下面这些服务总有一天也会被封掉,还是愿意在他们被一一干掉之前选一个使用,那请继续看下去。尽管有切换的痛苦,有熟悉新软件的麻烦,但我们不惜这样的代价,对我来说,这不是技术问题,这有关信念,有关按自己选择的方式生活,在这片土地上,坚持信念,坚持按自己的方式生活从来就不简单,从来就不是无需付出代价,记得这句?freedom is not free。

Dropbox 的核心我以为只是 sync(多机同步),外加 cloud 端存储可以通过浏览器访问,还有方便地与他人共享。以这3点为核心,功能很精干。开玩笑说的话,我看这就是面向消费者的版本控制软件,无非隐藏了技术细节(没有commit,check out,update,branch等等),改成了消费者友好的人机界面。这是个典型的注重产品的 soul,而不是堆砌 feature 的例子 —- 如果做不到这一点,那一个反例是,你可注意到如今国内的大学?楼房,餐厅,体育操场,课题,论文,院士数量这些都是,都是光鲜夺目的 feature,只是这些 feature 从未也不会带来实力和人们发自内心的敬畏,这样构建出的大学没有 soul,可悲地没有 soul。

以上面3个核心功能为指标,我找了这么些替代服务。后面先逐一简介,然后是功能比较(自从把 blog 迁到新地址 ResetTarget.com 以来,还真没这么认真地试用写写有价值的软件/服务了):

. SugarSync
SugarSync虽然貌似媒体曝光率不比 Dropbox,不过我看一点不比Dropbox差,也是个十分优秀的服务。单论feature,SugarSync不比Dropbox缺了什么,所以替代Dropbox绝对没问题的,实际上它提供得比Dropbox更多,有些设计用起来就能体会到“哇,这个更方便”。

SugarSync 的客户端界面直观,漂亮,拖放即可操作。有右键菜单启动SugarSync Manager,然后所有操作在SugarSync Manager 中完成,而不是右键菜单中提供直接命令。

跟Dropbox比,SugarSync最大的优点是可以指定任意文件夹加入多机sync关系,而不像Dropbox那样只有拖入Dropbox文件夹的才行。SugarSync的magic文件夹其实是和Dropbox文件夹的功能类似,全自动,无询问式地互相sync。而SugarSync Manager中可以指定任意文件夹加入同步,在其中观察多机器之间文件夹的同步关系和状态等功能非常直观也很实用。

目前有免费plan和多种收费plan,容量和特性上有差别。现在还能看见有10G 免费计划,哈哈,别错过(需要给TrialPlay一次机会哈)。如果你以前是试用用户,已经过期,还是可以转成free plan的。
这个 SugarSync 链接是我的referral链接,通过这个注册并安装客户端,你我都能获得250M的额外空间。完成入门向导还会有 250M 的奖励空间。

. syncplicity
这是在精简程度上最类似DropBox的,其功能和客户端的实现上都如此。直接命令和操作都在右键菜单命令中完成,没有类似SugarSync Manager 的控制台部分。

. ZumoDrive
ZomoDrive 的做法和上面两个比较不一样,安装后会映射一个虚拟驱动器,缺省其盘符是Z,不过用户是可以自定义这个盘符的。ZumoDrive 实际上不是文件sync,其核心只是创建能访问其他机器的文件夹的快捷方式,没有做适当的隐藏和抽象。我认为这个和Dropbox以及前面两个不太可比,介绍一下,看有哪位觉得适合自己吧。

在任意一台安装了ZumoDrive的机器(比如A,B,C 中的B机器)上,指定一个文件夹“连接到ZumoDrive”,就能在其他安装了ZumoDrive的机器A和C上访问B上的那个文件夹。这种模式有些人可能喜欢,有些人可能不习惯。

. iGliss
客户端做得有点简陋,从UI和响应性看的出来,而且不能从客户端直接注册新用户,得在网站注册,然后客户端登陆。另外,不支持代理。从工程师的角度看,做得很差,都没有兴致评价了。

. EverNote
严格说来,EverNote 的精髓不在我们前面提的3点,不大符合我们说的文件sync的主旨,不过理论上沾边,提一下,供参考,看喜好了。

比较
. 免费计划和容量
SugarSync:免费2G,现在这个免费plan的链接放在页面下方,不那么显眼,其实还是有的。另有4个收费计划,30G,60G,100G,250G,价格从50 到 250 刀一年不等。
Syncplicity:免费2G,收费的也只有两个选择,15刀每月,容量50G;还有个就是定制的。我觉得这么下来Syncplicity的钱可以买SugarSync 100G还绰绰有余,而SugarSync提供的功能又多,Syncplicity实在没吸引力呀。
ZumoDrive:免费2G,外加多种plan,从10G到500G,

. 文件操作:同步,加入,删除等
SugarSync和Syncplicity都以目录为添加和同步单位,而不是单个文件。目录可以位于机器的任何路径—这点比Dropbox好。加入文件夹后两个软件都能正确迅速地开始同步,该有的提示都有,需要用户给出order的都会询问。同步速度也不错。ZumoDrive 亦然,从任何一端访问都没问题。

从SugarSync同步的机器中任意一方删除文件夹并不会自动删除另一端的文件夹(这是正确的期望行为),也不会删后自动把另一端自作聪明地重新sync过来(也是正确的期望行为),在SugarSync Manager里会显示哪端的文件夹还在,哪端删除了,关系和状态很明了,如果愿意用户可以重新选择同步起来,这个功能考虑得很周到。

相比之下,这方面Syncplicity做的不够好,Syncplicity在收到新文件夹改动时,会询问用户本端新文件夹路径,不过缺省路径总是在my documents下,不论对端是在哪里,不够智能。在一端删除一个文件夹,另一端不会自动删除,不过也没有任何提示,想在删除端重新和对端同步比较麻烦,因为没有类似SugarSync Manager那样的控制台,查看当前多机的同步状态以及各自加入了哪些文件夹很不方便。在试用过程中,在两台机器上,Syncplicity都发生过失去响应。

. 多机器同步
能多机同步本是天经地义的,不过3个软件的免费版本都是有些限制的,都只能在2台电脑间完成。有哥们会想,那我用SugarSync连一对电脑,这一对中的一台再和第三台用Syncplicity连,如此一来不是达到3台可以超越限制吗?理论上可以,不过拿他们的Windows 版来说,这些软件都要hook Windows explorer来进行文件变化侦测,多个软件对同一个目录/文件来的话,存在发生冲突并造成混乱的可能性,XX有风险,用户需谨慎哈。

. 客户端OS
SugarSync:Windows,Mac OS X
Syncplicity:仅支持Windows
ZumoDrive:Windows,Mac OS X,Linux —- 列出了Ubuntu和Fedora,32和64的包都有

. 两端都编辑加入同步关系的一个文件
用“合适”的文本编辑器在两台机器上都打开该文件(“合适”的意思是专业的文本编辑器知道用适当的不一定是独占模式使用类似 fopen() 的调用打开文件),一端编辑存盘,另一边很快编辑器能弹出侦测到文件改变,经用户确认reload 后载入文件。期望的正确行为是同步软件(SugarSync和Syncplicity)不应该报错无法打开或无法更新文件,而编辑器应能像处理一般本地文件一样侦测改变,完成reload,而且文件应该确实是最新版本,无内容丢失,无混乱。SugarSync,Syncplicity和ZumoDrive全都完成了全部过程,都没出现问题。当然,我拿txt测试的。要实现精细的“实时”多方同时编辑,应该使用其他服务而不是这三种“粗粒度”的宏观同步软件。

. 从网站访问cloud端存储的文件
三个软件都会在服务器端存放软件,所以都可以从浏览器访问。都是https。Syncplicity的web访问页面完全基于flash,SugarSync和ZumoDrive是HTML+script。

. 专门的移动设备应用软件
SugarSync:iPhone,Android,BlackBerry,Windows Mobile。在 HTC Desire,WCDMA 情况下测试移动设备支持: Android应用启动后自动提示是否备份相机摆设的照片,很人性化,不错。为了鼓励用户使用,在移动设备上完成“发送文档”,“发送照片”和“上传照片”的用户能再获得250M空间。在Android上只能查看不能编辑文档(和文件格式无关,即便txt亦不能)。 iPad 版客户端支持编辑,很酷。
Syncplicity:无移动设备应用
ZumoDrive:iPone,Android,WebOS,这个的Android应用我就没试了。

. 代理支持
三个软件都支持,

. 方便的共享
一个url链接发给别人,就能方便地共享文件。
SugarSync:可以share 文件夹和文件,可以从客户端发起要share 的操作,不过会启动浏览器到SugarSync网站,后面操作设置等都在网站完成。可设置权限:只读或者可以添加编辑,还能设置密码。
Syncplicity:实现得有点别扭,只能share文件夹,要share单个文件这样的粒度不行,workaround 是把这个文件放到一个目录然后share目录,折腾。
ZumoDrive:可以share文件夹和文件,ZomoDrive客户端会直接生成URL,不过没有权限密码等设置。

. 资源占用
一般来说,“资源占用”应该写写内存,处理器,IO (包括硬盘和网络)等使用的均值,峰值,分布,典型情况,极限数据等。不过,其实,我长久的意见都是,最终消费者不具备也不需要具备知晓并衡量这些指标的技能。似是而非的数据和理解其实更会误导用户,比蠢货更可怕的是喜欢说话的蠢货。
作为结论,可以说,SugarSync,Syncplicity 和 ZumoDrive 的资源占用中等,它们本非小巧类型的工具软件,不过使用的资源也绝不夸张。如果你的 Windows (不论什么版本)本来就能顺畅地在电脑上跑起来,电脑的主要部件属于 3 年以内的那几代产品,这 3 个软件问题就不大。

最后,因为我是工程师,喜欢全面的控制感和精细的选项,所以我的选择是SugarSync。各位可以根据自己的需要选用一个。

SugarSync网站上还有个和很多网站的feature对比列表,也有参考价值。里面包括了MobileMe,Box.net,Mozy等。不过开头我说了,sync是我看中的核心功能,也就是文件更新后能自动同步到多台机器上,而 Box.net 等都是太粗粒度的存储 storage 服务,sync不是其核心或者做得不好,因为今天根本没有考虑,也就没试用。

这篇已经够长了,剩下的一些另写一篇。

Google 下周将提供加密搜索 encrypted search

关于 Nexus One 的改变和 street view 的隐私问题现在好像是吵吵嚷嚷最厉害的时候,不过与此同时还有条对我们来说有重大意义的消息:Google 下周将对搜索也提供加密通道方式。

最早 Marissa Mayer 在 13 号的年度股东会议上 Q&A 的时候 “提到”了这么个 feature。现在,在 14 号刚刚出来的关于解释 WiFi 信息搜集的官方 blog 文章 WiFi data collection: An update 里,算是正式确认了:

Earlier this year, we encrypted Gmail for all our users, and next week we will start offering an encrypted version of Google Search. For other services users can check that pages are encrypted by looking to see whether the URL begins with “https”, rather than just “http”; browsers will generally show a lock icon when the connection is secure.

这么个重大利好消息,居然隐藏在对另一件事的说明中,而且还是快到文尾才提到……

https 需要不少 server 端处理能力,对搜索这么个使用数量庞大到难以想象的使用来说,使用 https 是个很超现实的决定,或许,会以不太一样的方式提供吧。如果是真的话,我们不用再碰到操蛋的 connection reset 了 —- 即便有些目标网站仍然不能访问,不过至少不会被 TMD 的愚蠢地误伤。

有些哥们不方便读到原文,放上上述 Google 官方 blog 原文,我加粗了那句关键的话:

Nine days ago the data protection authority (DPA) in Hamburg, Germany asked to audit the WiFi data that our Street View cars collect for use in location-based products like Google Maps for mobile, which enables people to find local restaurants or get directions. His request prompted us to re-examine everything we have been collecting, and during our review we discovered that a statement made in a blog post on April 27 was incorrect.

In that blog post, and in a technical note sent to data protection authorities the same day, we said that while Google did collect publicly broadcast SSID information (the WiFi network name) and MAC addresses (the unique number given to a device like a WiFi router) using Street View cars, we did not collect payload data (information sent over the network). But it’s now clear that we have been mistakenly collecting samples of payload data from open (i.e. non-password-protected) WiFi networks, even though we never used that data in any Google products.

However, we will typically have collected only fragments of payload data because: our cars are on the move; someone would need to be using the network as a car passed by; and our in-car WiFi equipment automatically changes channels roughly five times a second. In addition, we did not collect information traveling over secure, password-protected WiFi networks.

So how did this happen? Quite simply, it was a mistake. In 2006 an engineer working on an experimental WiFi project wrote a piece of code that sampled all categories of publicly broadcast WiFi data. A year later, when our mobile team started a project to collect basic WiFi network data like SSID information and MAC addresses using Google’s Street View cars, they included that code in their software—although the project leaders did not want, and had no intention of using, payload data.

As soon as we became aware of this problem, we grounded our Street View cars and segregated the data on our network, which we then disconnected to make it inaccessible. We want to delete this data as soon as possible, and are currently reaching out to regulators in the relevant countries about how to quickly dispose of it.

Maintaining people’s trust is crucial to everything we do, and in this case we fell short. So we will be:

  • Asking a third party to review the software at issue, how it worked and what data it gathered, as well as to confirm that we deleted the data appropriately; and
  • Internally reviewing our procedures to ensure that our controls are sufficiently robust to address these kinds of problems in the future.
  • In addition, given the concerns raised, we have decided that it’s best to stop our Street View cars collecting WiFi network data entirely.

    This incident highlights just how publicly accessible open, non-password-protected WiFi networks are today. Earlier this year, we encrypted Gmail for all our users, and next week we will start offering an encrypted version of Google Search. For other services users can check that pages are encrypted by looking to see whether the URL begins with “https”, rather than just “http”; browsers will generally show a lock icon when the connection is secure. For more information about how to password-protect your network, read this.

    The engineering team at Google works hard to earn your trust—and we are acutely aware that we failed badly here. We are profoundly sorry for this error and are determined to learn all the lessons we can from our mistake.

    Posted by Alan Eustace, Senior VP, Engineering & Research

    H.264 编码使用率大幅上升

    尽管 web 上 75% 的视频是由 Flash 承载的(承载和编码无关,Flash 也支持 H.263,H.264,VP6 等编码),不过关于 Flash 必要性和前途的争论是最近几个月很热闹的话题。特别是如 Jobs 所说:纵然如此,这 75% 里几乎所有视频也已经有 H.264 格式,因此可以被支持 H.264 的浏览器直接观看,无需客户端 Flash 插件。Microsoft 最近也插了一杠子,表示他们在 IE9 的 HTML5 video 标签的编码支持上,选择 H.264。

    提一句,Microsoft 根本不是说 IE9 不支持 Flash 插件,原文里说的话

    当前,Web 上的视频基于 Flash 的占据主导地位。虽然视频可以是其他格式,但对典型用户来说,浏览器在某个网站不用 Flash 就方便地观看视频仍然是个挑战。Flash 确实有些问题,特别是在可靠性,安全性和性能上。我们和 Adobe 的工程师紧密合作,在持续进行的技术讨论中共享我们了解的关于这些问题的信息。尽管有这些问题,Flash 仍然是在今日的 Web 上提供良好用户体验的重要部分。

    这更应该理解为,考虑到向后兼容性和 Web 现状,IE9 当然很有可能继续支持 Flash。而且,再浅显不过的道理是,当前 video 很大程度上依赖 Flash ,但 Flash 可绝不是仅仅用于 video。如果 Microsoft 决定掐掉 Flash 的后路,我倒宁愿相信跟视频编解码方案无关,而是 Microsoft 使坏,要给 Silverlight 铺路。

    说来说去,如果有更多的数据来辅助争论就好了。

    TechCrunch 的 H.264 Already Won—Makes Up 66 Percent Of Web Videos 提到了一些,作者 Erick Schonfeld 联络了 encoding.com,问了问他们那边的数据。encoding.com 的客户包括 MTV, WebMD,Brightcove,Nokia 和 MySpace 等,他们去年编码了 5 百万个视频,从统计上来说,采样覆盖率还行,也是有效数据。encoding.com 的 Jeff Malkin 的回应包括了如下的图表,去年一年各种编码格式的占有率:

    图中表示的变化趋势是:
    H.264: 31% –> 66%
    Flash FLV 和 VP6 统统算作 Flash:早前 69%,当前仅剩 26%
    Ogg Theora:目前 4%

    附带说明:FLV 是承载,支持 H.263 编码。FLV,MP4 和 MOV 等等等等也都是承载,可以承载 H.264 编码的视频。

    好玩的正好是,上面的数据表示,去年 Flash native 编码和 H.264 编码的占有率几乎正好交换了位置。当然前面提到了,Flash 也可以播放 H.264 编码的视频,但是,如果有了浏览器 native H.264 支持,Flash 插件在播放此格式视频方面自然就可有可无了。

    当然,这份数据遗憾的地方在于:这是基于 encoding.com 自己的数据(我还不知道哪里有更全面的关于 web 上视频的近似总量统计数据),另外就是这里有编码格式和承载的混合,没有清晰地区分。不过好歹算作一个参考吧。另外考虑到 YouTube 占据了 web 上 40% 的视频数量,而其也支持 H.264,你说未来会是个什么样子呢?Flash 或者 Adobe 如果想不出更有破坏性,更有突破性创新的招儿……