Media Lab 25 周年及新玩意儿展示

上周五是 MIT 的 Media Lab 成立 25 周年纪念,除了自己的庆祝,同一天 NPR 的 Science Friday 也为其制作了节目,采访了 Nicholas Negroponte,Ramesh Raskar 和 Alex ‘Sandy’ Pentland。录音可以在 Science Friday 网站上收听或者以 MP3 格式下载

参加学校纪念活动的有 Google CEO Eric Schmidt,这是 Negroponte 邀请来的, 还有…… 有一个够重量级的就够了呵呵。晚上是音乐聚会,host 很有 Media Lab 特色:Rock Band 和 Guitar Hero 两款游戏的创建公司 Harmonix。

在整天的活动里,Media Lab 照常会展示一些会照常被大家惊为天人的异常研究项目,或已有成果,或是原型。这其中就有 Fluid Interfaces 的不少东东,比如 LuminAR

LuminAR 把微型投影仪,摄像头和计算机组装在一块,做到很小的 form factor,可以插入标准的台灯插座(台灯正好作为容器,把手和电源供应,很妙),这样就披上了一个亲和可爱的台灯马甲。LuminAR 为用户提供非常自然且方便的电脑操作方式:投影到桌面作为交互界面,用手势操作表达意思,也可直接操作“虚拟”投影出的物体或对象。啥叫指点江山,This is it。 或许哪一天,LuminAR 就能让我们都拥有 Iron Man 电影里那个留小胡子的花花公子在他的工作间里才有的那种机器人。

LuminAR 视频展示(优酷和 YouTube 的内容完全一样,方便不同地方观看)

优酷

 

YouTube

LuminAR 并非如 ZDNet 台湾报道所言是这次 25 周年庆上初次亮相,比如今年 6 月份 Media Lab 网站上就发布过演示视频了。Fluid Interfaces 小组的所有项目都秉承同样的 vision:键盘和鼠标并非要与数字内容打交道的必需品,40年 前发明出来的人机交互模式,到现在已经在严重制约着我们用自然的方式对数字内容进行访问和交互的能力。计算机因为缺少使用者或者自己所处周遭环境的信息而无法在我们需要的时间和地点提供更相关的内容。基于屏幕的界面会常常会分散我们的注意力。而且,计算机一直以来都是为个体用户使用设计的,不能很好的适应协作环境。所以,针对这些问题,Fluid 的项目涉足这些领域:

- 扩充体验 Augmented Experiences:用相关的数字信息扩充人们对周遭环境的感受度。经数字化信息融入真实环境,让同信息的交互更自然,顺畅。

- 可相应对象 Responsive Objects:把传感器,传动装置和显示器嵌入到生活里的平凡物件里,他们就能化腐朽为神奇啦,人们对其做出的有意味的明显动作就能被这些对象相应。

- 协作式交互 Collaborative Interactions:设计实验,让多用户使用那些完全从头设计的新界面。协作参与者从少数到很多人,有本地的,也有远程的,有移步的,也有同步的。

- 可编程材料 Programmable Materials:纸张,织物,木头,食物?统统可以编程。用于控制和操作这些材料的 interface 和 机器 已经被发明出来了。如此这般,这些平凡之物,原本是数字世界之外的存在,现在可以用新材料来制造,因而也享有数字世界的巨大好处:可修改,可编程,响应性和个性化。

这是 MemTable,也是 Fluid 成果之一。

Pranav Mistry (CNET 图品页把人家的名字写错了,写成 Sistry 了), TED 上亮相过的帅小伙,那次也是演示 Fluid 新奇的交互设计,很及时地,给了个很适合向普通大众展示时用的梦幻名字:SixthSense。

SpaceMarks,想起 少数派报告?以立体形式组织书签和 email 等。

CNET 有更多活动图片

相关文章:MIT Media Lab 新家落成

Android Market: 支持付费应用的地区小更新

一句话消息:不管是发布还是购买付费应用,都木有 China 的份儿,不过 香港 和 台湾 是都入了列,被 Android Market 支持了 —- 今天 Google 增加了支持付费引用发布和购买的区域 ,后面两周还会有扩展(Market 上“发布”和“购买”的支持是分离的)。
一句话总结:想喝汤吃肉,还是得靠自己。

所以,如果投靠港台无门,可以参考我之前写的 Android Market 的区域限制和绕过方法
对不了解技术问题的使用者,换张美国运营商的 SIM 卡可以解决问题,这种SIM 卡淘宝上很多。
了解技术的,root 过后使用 Market Enabler 或者 Market Fix 解决。

Apple 让步了

9月 9 号,Apple 在网站上发布了条 PR,Statement by Apple on App Store Review Guidelines,字数不多,当量不小:Apple 让步啦,第一,放松了原来引起轩然大波的强制要求只能用限定的工具和语言开发 app 的限制;第二,公布了 App Store Review Guidelines (或者看这个 PDF),些许减弱了关于 Apple 在黑箱操作的责难。

关于开发工具方面,这么说的

…today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year.

In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code.

3.3.1 就是 famous 或者 infamous 的工具和语言条款,那时候 apple 要求只能用 Objective-C, C, C++, 或者 JavaScript (跑在 iPhone OS WebKit engine 上),只有前三者(C, C++, and Objective-C)才能使用 documented API。通过 intermediary translation 或者 compatibility layer or tool 来链接 Documented API 是不允许的。这次,这些限制全都被删除了,没有提及要求使用指定的语言,没有要求不使用中间层或兼容层 —- 只要最终的 app 二进制的行为等符合新的 guidelines 就可以。

关于 “as long as the resulting apps do not download any code” 部分,是对 3.3.2 的改写,原来的 3.3.2 相当长,新的 3.3.2 说:

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple’s built-in WebKit framework.

就是要 self-contain,我想这是个安全方面的考虑。不过看上去和老 3.3.2 没什么差别,语言凝练了而已。

3.3.9,新条款

3.3.9 You and Your Applications may not collect user or device data without prior user consent, and then only to provide a service or function that is directly relevant to the use of the Application, or to serve advertising. You may not use analytics software in Your Application to collect and send device data to a third party.

这是实质上去掉针对 AdMob 等第三方 in app 广告服务商的限制。不过,开发者也很关心的其他 app 数据统计问题,比方可否使用 Flurry 等 analytics 工具似乎仍然没有希望。

4 月份的时候,老的这份 SDK licence 是顶着所谓保证效率,安全和更新频率的帽子出来的,如今,这些“帽子”可以不考虑了吗?那不是自扇耳光?要么就是,或许,Apple 洗心革面,不那么邪恶了?
Wired 说,Apple 最新的改变,有可能是因为 FCC 在对 Apple 老条款展开调查。Dictionary! 的开发者 Hampton Catlin 就表示,FCC 的律师和他就这方面沟通过,当然这不代表 FCC 有正式进行中的行动,按惯例,在调查结束前,FCC 既不确认也不否定是否有调查。

我看 Adobe 有点打碎牙齿的意思,最早 Flash CS 5 提供了 Packager for iPhone,方便 Flash 开发者把东西“转”成 iPhone app,后来 Apple 釜底抽薪,宣布了那个广受争议的条款,Adobe 不得不宣布 Packager for iPhone 这个 feature 停止开发,“我们得往前看” —- 多心酸的一句啊。昨天 Apple 的 PR 一出,Adobe 马上表示这是 Great News for Developers,他们会恢复这个 feature 的开发工作。Adobe 还说,他们已经从自己的用户那听到消息,用 packager 开发的 app 已经被 approve 了 —- 当然,别搞混淆了,iOS 的浏览器里的 Flash 还是照样 block 的。当然,好消息是,Adobe 的股价今天立涨 12%,成交量也相当可观。

去年 7 月,iOS 版的 Google Voice 和第三方开发的 GV Mobile 都被不明不白地 block 了,此“不明不白”自然是没有公开说法,而不是指 Apple 的当权者不明白。据 TechCrunch 说,昨天 guidelines 一出,GV Mobile 的作者 Sean Kovacs 就含恨从头到尾通读了那份文件(请想象一下已经在五七干校累弯了腰的老一辈党和国家领导人读到自己罪行宣判的感觉),那可是 100 多条规则呢,最后,Kovacs 说,他觉得自己的 GV Mobile 没有违反其中任何一条。

Kovacs 一分钟也没有耽误,马上开机奋笔疾书,给 Apple 的 approval board 发了 email 询问可否在 AppStore 恢复 GV Mobile,很快,他收到了回复,Apple 的一位专员表示欢迎 Kovacs 重新提交 GV Mobile。虽然严格说这不代表任何许可,不过终究是隧道尽头亮起的一点烛光(看来这是一次团结的沟通,胜利的沟通,催人奋进的沟通……)。

Google 表示目前有 BB 和 Android 的 Google Voice 应用,iPhone 则有 HTML5,除此以外没有进一步消息宣布。

或许 Google 目前觉得真正重要的似乎是…… app 内广告。其官方的 Mobile Ads blog 也在昨天发布一篇 An Update on Apple’s Terms of Service,Apple 的新条款其实也意味这,iAd 不是 app 开发者强制的唯一选择了(虽然老天保佑,老条款在这方面差不多从未实质运用过),从书面澄清和承诺上说,开发者现在可以安全地选用他们喜欢的广告提供商了,Google 和 AdMob 都行,

在 guidelines 里有挺好玩或者意义重大的:
# “Apps that enable illegal file sharing will be rejected.”
BT 和一些合法的文件共享软件,即便只是控制程序都要被拒

# “Apps that browse the web must use the iOS WebKit framework and WebKit Javascript”
用户不会碰到 Android 上那样,打开一个地点,被询问要用 Internet 还是 Dolphin 了。

# “Apps that alter the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, will be rejected”
这是我家,谁都不准乱碰任何东西,那情景模式切换的 app 就也要被毙吗?

# “Apps that misspell Apple product names in their app name (i.e., GPS for Iphone, iTunz) will be rejected.”
锱铢必较,睚眦必报

# “In general, the more expensive your app, the more thoroughly we will review it.”
全世界都仇富。

# “Apps that include games of Russian roulette will be rejected.”
为什么?掷骰子就可以?

# “Apps containing pornographic material, defined by Webster’s Dictionary as “explicit descriptions or displays of sexual organs or activities intended to stimulate erotic rather than aesthetic or emotional feelings”, will be rejected.”
这话听起来像取得了大法官斯图波特的“只要我看到它,我就知道它是色情”之精髓

Google Voice 电话的 Myth 及试用

新闻背景:Google Voice 今天在网页中提供语音电话服务,具体不多提了。

Myth:
嵌入在 gmail/igoogle 中,无需下载安装任何客户端,拨打和接听电话都在浏览器中进行。据说“纯浏览器应用”也是 Page 和 Brin 的长期愿景,他们希望并推动着所有 Google 服务/应用都是这样。

直觉反应:
有点怀疑,又不是基于 flash 的实现,按目前光杆浏览器的能力,如果不能访问外设,就无法入出语音或视频,当然,编解码谁完成的我不确定。

真相:
你“必须”先下载安装插件,而且不同浏览器得下载安装各自对应的插件,想一会在 IE 里用,一会在 Firefox 里用?那俩插件都得装好;想在不同电脑上用?每台电脑都得装好插件。插件自然不算是完整客户端,不过要为每台电脑,每个浏览器都下载安装的过程,本质上一样麻烦。“纯浏览器应用”?算了吧。

实验:
用 Chrome 做实验,登录 gmail,展开 gmail 左边栏的 chat,会要求安装,跳到 Google Chat 页面,比如这是对 Windows 的:

静默安装,无选项,无用户介入

如果是 IE, 需要下载 Google Talk Plugin Video Accelerator。这个我就没试了。

Chrome 安装过后,Firefox 就不用装了,想来是因为两者都支持 NPAPI 插件的缘故,用任何一个浏览器装过后,可以两者通用。

然后拨了个 Google 总机,650-253-0000。从1)接通速度 2)语音清晰度 3)通话有无断续或延迟上看,效果不错,听音辨识没问题。当然,挑刺肯定是挑得出的,而且后面我试用也连续打了同一个电话好几次,表现细节还是有区分的。当时是接入着 VPN 的,也就是没用利用到最大带宽给语音,不过总体我觉得不错。

上市公司在 google finance 都能查到总机,所以,然后,我又播了 Yahoo,Apple,北上播了 Microsoft, Amazon ,东进打通 Goldman Sachs 和 Morgan Stanley……我觉得我也够贱的,反正不要钱……

Amazon 和 Apple 的自动应答是男声,好玩,其中 Amazon 打通后按提示再按键进入 customer service 或者 marketing 等,会马上听到女声提示说分机号不对,弹回那个男声菜单,很奇怪,不知是按键传送问题还是能检查 fake 号码?其他几家公司都是女声录音;这些家公司的语音质量参差不齐,或许有线路问题,有自家录音问题,同一家公司连续接通几次,比方 Microsoft 和 Yahoo,质量也都不同,而且是绝对不可忽视的差别;有时候语音中间有点磕巴(不是延迟,就像流畅谈话中的毛刺),不知是编解码问题,还是本来线路质量就不好,或者 VOIP 不可克服的缺陷。我自认曾调戏接线员无数,应付过不少人工和机器的 greeting,不过还是很难分清这磕巴是 TTS 合成的缘故还是实时编解码地方出的问题;Goldman Sachs 的录音质量不好,有气息和背景噪音,然后1级菜单下去就接通了一位女士真人,不好意思,我不是有意的,不过我得说,对方语音过来很清晰;Morgan Stanley 更不好意思了,总机直接是真人,听起来有点强弱不均,不过这种问题在普通座机上也会出现,不知道谁的责任。

最后,我勇敢地拨打了自己的中移动号码,证明,chat 这边快速的回铃音只是用户体验设计,是骗人的,无论对方手机有无接通响铃,chat 都会马上听到回铃,让人感觉好像响应性不错,一般 chat 这边听到回铃 2 下,手机这边实际就开始响了,可以接受;接通后听得到有些回音,不严重,也没有啸叫 (如果用过 android 上的 fring 就知道啸叫那劲头了……),有可以感知的延迟;最悲剧的,如果手机拒接,chat 这边还起劲地响着回铃音…不知道是不是 bug,如果接通后手机正常挂断,chat 这边能正确地知道通话结束,挂断。

要说不足,无论是 Chrome 还是 Firefox,从按键回音速度看,有延迟不流畅。不过 pop out,pop in 设计得很贴心,可以把拨号盘弹出/弹回到独立浏览器窗口。

回到前面说的安装的 plugin,这是个名为 googletalkplugin.exe 的程序(如果先前已经装过 Google Talk ,会不会还需要装 plugin 呢?我装 plugin 前没装 Google Chat,现在也懒得验证了),32 位,装在 user 的 appdata 下,而非 program files 或 program files x86。用 process explorer 观察内存占用 private 和 working set ,在 Firefox 里,不拨打电话时分别是 11M/14M ,接通电话 22M/18M ;在 Chrome 里,不拨打 12M/15M,接通 23M/19M。如果关闭浏览器,或者关闭 gmail 那个 tab,此程序会自动退出,不占用资源。

个人感觉 Chat 语音电话的最大好处:
电脑到电话的花费省下来了。当然,集成到 android 中就模拟出无需电脑这个中间物的情况了。
以前 Skype 什么的要买点才可以电脑到电话,这些 VOIP 服务商都把通过 PSTN 接入传统电话网路作为收费项目,而 Google Chat 此举一下解放了一大批人,想象一下这些应用场景,全都不要钱了:中国学生问询美国学校招生情况;淘宝国内买家电询美国代购卖家;老娘问万里之外的儿子有没有搞定洋妞;沪市挤出的散户call美国券商;东方毛孩儿逮住北美同龄人练习口语……

God bless Google,哦…等会儿,应该是 God bless the no-evil Google.

Facebook 传闻,时差与处理器

这周有传言说 Facebook 要考虑使用装备 ARM 处理器的服务器,替代 Intel 或 AMD 的 x86 服务器。此传言出现在 Facebook is the first to jump into ARM servers

我读到这个消息是周二晚上从 TechMeme,考虑到 TechMeme 的时效和衡量 credit 的算法,我相信这是最早出现的,也是谣言的源头。

昨天晚上还是 TechMeme,福布斯 Forbes 有新文章 Is Facebook About To Use ARM Chips In Its Data Centers? No! ,这不是 Forbes 在说不,是 Facebook 的 vice president of technical operations,Jonathan Heiliger,说, “This story is completely false”,用词很直白,不用翻了。
Heiliger 本人也在 SemiAccurate 那篇谣言源头留了言说明。考虑到在这件事上,使用什么 technology infrastructure 不属于需要掩盖,迷惑乃至撒谎的丑闻或竞争型商业秘密,false 应该是明确的表态。当然,你还可以纠着 Heiliger的原话 we have no plans to deploy ARM servers in our Prineville, Oregon data center,说他这只是说 Oregon 的 data center,重新表述重音的话,是不是可以解释成不否认在其他地方部署呢?你要愿意这么想我也不能怎么样了。。。。。。

今天有国内媒介报道谈论这事儿,比方我今天早上从 Google Reader 看到 ifanr 的 ARM正式进军服务器处理器 —- 可惜,兴奋过头了,这是根据最早的那篇不实的谣言报道的。

看来技术新闻真是容易螳螂捕蝉,黄雀在后,最后还有个小屁孩等着黄雀呀,一下没有注意 follow up 就容易错过一个环节乃至看到完全不一样的东西,说不定我后面还等着一哥们打算说我的消息也 out 了呢,不排除,不排除我此文一出,Mark Zuckerberg 都在我 blog 留言,我K,咱 Facebook 就是打算用 ARM 了!

按我的理解,如今 server farm 里的故事在媒体口中就剩下 电力 了,偶尔靠谱的还提到 performance per watt,仿佛功耗就是 chip design 的唯一命门和衡量产品的独门标准了。可是,请考虑一下,这是建立在 AMD 和 Intel 的产品已经提供了可以接受的性能的前提下的,媒体看到了工程师们正在热切地谈论“功耗”,却没看到他们已经不那热切谈论的话题“性能”,他们不谈论不是因为不重要,是因为已经做得不错,不需要再极其强烈地关注了,需要极其强烈关注的东西已经让位于“功耗”。这就像高手过招,不会再战术性地比拼蹲马步这样的基本功了,不是基本功不重要,而是大家都高手,基本功是不成问题的,所以他们要比的就是其他功夫招式了。在这里,Intel 和 AMD 产品的基本功就是“性能”,其他招式,目前,就是功耗或功耗效率。

现在,场景来到了 ARM,这时候,再把上面的规则适用就乱来了,因为大家的基本功不一样了。有哪个媒体在文章里提到总线,带宽,HyperTransport,QPI(CSI),多 socket 架构,cache 一致性….等等等等,然后把这些被认为丑陋臃肿的东西和 ARM 能提供的比较一下?没有,因为媒体不懂,因为媒体以为这方面 x86 产品和 ARM 没啥区别,那就……只比 功耗 好了,哇…… 不得了呀,ARM 这么省电,x86 完了 …… 故事出来了。

唉…… All men are created equal, all processors are not。

前半句是 杰佛逊 等厮说的,后半句是鄙人续貂,当然,不保证原创性。

从数据上说,Intel 自 Core2 一代开始,per core 大概 30W,这个数据在 Nehalem 一代得到很大优化,Xeon 系列最少 4 core 最多 8 core (是 core 不是 thread),per core 最低到 11 W,最高 23 W (根据频率,cache 大小等自然不同);而 AMD 要拿出来的 Bobcat 设计,据称可以到 1W (未经证实,拍砖我也认了)。而,用户并不是谁最省电就用谁,而是在不伤害或者不严重伤害效能的情况下……你知道的……

从 ARM 的角度,如果用于服务器产品,只计算处理器的功耗是不够的,比如需要 enable 64 位支持吗(这方面我真不清楚,不知道从版本几的核心有这个,可能根本没有)?再比如要支持服务器常用的 ECC DIMM,势必增加专门的 memory controller,这不需要增加耗电,或者占用 die 或者板子面积,继而增加成本吗?这方面 ATOM 也好不了多少(虽然 Seamicro 已经有基于 ATOM 的服务器产品了),同样没有加入 64 支持,另外我记得必须要搭配 965 还是 945 系列 chipset,那就限制了支持的 memory 类型。

我觉得 ifanr 文章里有些说法不妥(我还是很喜欢他们的文章的,特别是评测和爆料,此处仅为交流无恶意),比方:
“别说ARM核心,就是现在最顶级intel i7 extreme980 6核12线程也入不了Facebook的法眼。”,这只是桌面处理器,说顶级值得商榷,不是 Xeon,ODM 不会拿来做服务器产品,Facebook 自然没法买没法用,要是 Facebook 自己搭机器,我看不会用不是因为效能不够,而是因为这个产品的定位。
top500 里,“看看最近的超级计算机50,排名末尾的机器也使用以万为单位CPU核心。这说明如果依靠数量,ARM核心同样有潜力匹敌专业服务器CPU阵列。”,不好意思,我觉得只能说明多 socket/多 core 的超级计算机架构以及软件优化有多么重要,而不是简单依靠数量(看看国产银河就知道了);特别是,用多 ARM 来拼性能,那 die 的面积,成本,每 core 效能等就不好说了。目前代工厂生产 ARM SoC 的工艺普遍落后 Intel 一乃至两代,依靠工艺省电省成本就别想了。扩展说来,top500 的趋势比较有风向标意义,不过和商业应用实践上是不一样的,因为超级计算机可以采用偏门的私有的无需考虑大规模市场应用场景的技术,成本顾虑不大,而一般的商业实践要考虑标准化和成本,如果有人用 ARM 拼出了打败 road runner 的机器绝对是好事,因为先行者可能已经搞定了基本的理论难题,不过这不意味着 Assbook 和 Google 有可以插上电源开始用的基于 ARM 的服务器。

说 ARM 会取代服务器市场里 x86 的地位,本身就是一个不够精确的提法。因为 server 里跑的应用特性和角色差别很大,需求也就不一样,有的 IO 密集,有的处理能力密集,有的要求低延迟,有的要求高并发,有的适合 SIMD 类型的指令来做,有的则是 MIMD,如此等等,不一而足。这些类型里,有些完全可以用 ARM 完成,而有些,目前仍然是 x86 胜任。简单地下个结论,ARM 取代 x86,是不合适的。

反过来,我也不能狂妄到觉得 ARM 涉及服务器市场这一天绝无可能到来。曾经 DEC/IBM 当道,只卖 mainframe,SUN 不信邪横空杀出的时候,无非被看成草根货色,不足为惧,可谁知就成就了 SUN 的事业,DEC 消失,IBM 明智地转向;当年 x86 从 Pentium 开始才蹒跚进入哄哄作响的机房,彼时 Power/PowerPC 和 SPARC 等也觉得 x86 不过就是便宜货而已,天下地下,哪能相提并论,可后来,拜业界明智合力促成软硬生态链发展所赐,x86 已经是如今服务器市场 珠穆朗玛 或 K2 级的角色。

我也喜欢竞争,希望有新技术进入服务器市场,是竞争让 Nvidia 提出 GPGPU,让 AMD 收购 ATI 推出 fusion,让 Intel 拿出 ATOM,收购 WindRiver 和 McAfee,因竞争而动本是好事,否则大公司的高管们就可以总睡在自己的春秋大梦和前A片演员的温柔乡里了,太舒服了吧。它至少保证了我们有摆脱坏产品的可能(虽然不敢说 100% 导致摆脱坏产品的后果)。

x86 有太多的 legacy,每次 IO,每次 memory transaction,每条 instruction 执行将来或许会被条分缕析,发现在特定应用场景下成本或效率比不上 ARM 或 LEG 这样的 RISC 处理器,是的,它输给 ARM 或许会因为这个,而不是简单地被一块电表砸落马下;ARM 的这一天会到来,不过那是因为从 英伦 的实验室到 台湾 的代工厂里大家挥洒的智慧和汗水,而不是因为媒体抽象地殷切希望和“判断” ARM 已经冉冉升起。

Android 上音乐服务比较

Androinica 有篇文章汇总比较了目前 Android 上可用的 music streaming 服务。

图片链接到 flickr 上的大图

这篇文章的文字内容不太好,没看出各自服务的特色和区别,也没有数据和作者的关键发现做支撑,不过总结出的表格可以参考,而且列了这么多家公司,可以为感兴趣又没接触过的朋友做起点用。

总得来说,还是那么几家,Pandora,Slacker,Rhapsody,Last.fm 等等,成名的都还在持续努力,新兴的也一个没落。就我个人来说,凡是 9.99 的一个没考虑,都赶上联通 WCDMA 包月套餐的费用了…… 剩下的呢,其中 slacker 感觉很差,时常连不上,报错也很莫名其妙,建议大家回避。

我现在用的是 Grooveshark,在联通的 WCDMA 上表现不错(即便不在手机上,做电脑上的在线音乐服务 Grooveshark 也不错),我选上高质量音乐时常也跟得上(一般都是晚上在家听,路上没试过)。另外 Grooveshark 的 on-demand 和 随意 skip 太重要了,音乐本来就是放松和享受的,谁想被绑架去听不喜欢的声音呢?连挑歌的机会都剥夺了,没意思了。
话说回来,联通这张 W 的网目前看来不错,最坏的时候有 40KB,200多,300多到 400 KB 也不稀罕,上传倒是稳定得很,都是 200KB 左右(SpeedTest.net 的 android app 测试),以后争取多拍拍照片上传一下什么的,别浪费了哈哈。

解密 Cyber Command Logo

美军刚成立的网络战司令部 Cyber Command,总部在 Maryland 马里兰州的 Ft. Meade, Meade 堡。虽然大多数人应该已经看到了相关报道,还有些官方声明什么的,不过恐怕还是晕乎乎的不知道他们打算干什么。所以,还是从已公布的信息里发掘点好玩的东西吧。

上面是 Cyber Command 的 logo (美军各军种,部队都对设计自己的 logo 乐此不疲,还颇有忠诚感),在那句大大的 UNITED STATES CYBER COMMAND 的内环,刻着一串数字:9ec4c12949a4f31474f299058ce2b22a。

任何一个了解点计算机知识的人,再加点一般常识哈,就能意识到这个主要和计算机打交道,或者说以计算机及相关技术作为矛和盾的司令部的 logo 上的一串 16 进制数字可不是装点门面的。Wired 也神秘兮兮地说,一位 Cyber Command 知情人士向他们确认““It is not just random numbers and does ‘decode’ to something specific, I believe it is specifically detailed in the official heraldry for the unit symbol.” 反正那不是我们吃饱撑的刻上去的无意义的随机数,它是能解码出一些特定信息di。。。。

作为提示,这位知情人还说:在徽章的设计阶段,就有好几个提议,最后的决定是显而易见的,Cyber Command 得刻点什么在自己的徽章上,就像其他军中单位一样,那这个刻点什么就应该是“Cyber Command 的任务了”。当然,这样出噱头赚眼球的机会,Wired 绝对不会放过,而看来 Cyber Command 还是知道如何在群众中推广自己的,而且他们找到了合适的推广媒介:包括 geek 们常看的 Wired。所以,Wired 还专门修文一篇,提问广大读者,这串数字怎么解读,什么意思。

果不其然,读者 jemelehill 在 Wired 文章发布 3 个小时内,就搞出了答案。这串 hex 是 Cyber Command 的官方 mission statement 的 MD5哈希。

原文是
USCYBERCOM plans, coordinates, integrates, synchronizes and conducts activities to: direct the operations and defense of specified Department of Defense information networks and; prepare to, and when directed, conduct full spectrum military cyberspace operations in order to enable actions in all domains, ensure US/Allied freedom of action in cyberspace and deny the same to our adversaries.

翻译是
USCYBERCOM 策划,协调,整合,同步并执行这些活动:领导国防部指定的信息网络中的行动并实施防卫;随时待命在接受命令后,执行全面的网络空间中的军事行动,以保证所有方面的行动能力,确保美国和盟国在网络空间的行动自由并阻止敌方的行动自由。

这个 statement 自然每个政府部门都有个正式表述,Cyber Command 的可以在各种新闻稿或者官方资料中找到,比如其官方网站中就明白摆在那儿啦。

有兴趣的哥们可以自己按 MD5 算一遍(不知道算法的,可以到 wikipedia 上看,有伪码参考),看看是不是 9ec4c12949a4f31474f299058ce2b22a。或者,HASHCRACK 也可以帮你算算,输入 MD5 或者 那句完整的话,都可以算出对方,当然,如果输入完整 mission statement,记得复制完全,否则自然算出来的 MD5 不一样,我就是少拷贝了最后一个句号,还纳闷怎么会不对……

so,看看那个 logo:闪电,刺刀,钥匙,白头鹰,每个都很美国,每个其实放到其他军种的 logo 上也都说得通,所以,这串 hex 倒真显得很有意义了,贴合并提示了 Cyber Command 的任务和能力,这是专业化的表示,也很好得体现了 Cyber Command 的与众不同。

当然,这次这个猜猜我是谁的游戏,Cyber Command 看来策划的不错,Yahoo News,美联社,法新社,Slashdot,华盛顿邮报,洛杉矶时报等等媒体都故意报道了一把,刺激读者来解密,就是个最好的推广手法。挺好玩,挺有人情味。

MD5 Message-Digest algorithm 5 是密码学里常用的 hash 算法,RFC 1321 中的内容,MIT 的 Ronald Rivest 教授 1994 年完成,前任是 MD4。不过现在已经被证明不能保证无 collision。几乎全部美国政府部门的应用,都已经要求抛弃 MD5,专用 SHA-2 了。不过一般性的使用,比如验证文件完整性,用 MD5 还是很常见,而且要求不高也没什么大问题。

最后,我再得瑟一个,这个 hex:

d41d8cd98f00b204e9800998ecf8427e

对应的字串是什么?hashcrack 上都没有的哈,不用费心了哈哈 —- 只要你不懒,一定找得到答案。

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 的无线路由器接入实验室网络。

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

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不是其核心或者做得不好,因为今天根本没有考虑,也就没试用。

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