Android and iPhone/iPod touch

配合O’reilly老爷爷的一些想法,我也想想我共鸣的想法:

  • iPhone/iPod touch的界面让你感觉非常自然(人性化),几乎不会给你什么惊讶,学习成本比较小。但是gPhone上面的不少东西都需要你自己的捉摸才能搞定,当然,搞定以后就轻松多了。但是iP系列的确更平滑。
  • gPhone的滚球这个东西,也好也不好。因为很多任务你可以通过拖拽屏幕和触摸实现,你也可以通过滚球和点击滚球实现。所以,由于有两条路,你总会问我应该走哪一条呢?走这两条完成这个任务有什么区别呢?这件事让我很苦恼。估计大部分的gPhone开发者在设计自己的app的时候也会问这个问题吧?
  • gPhone上面联系人与Google联系人,日历与Google Calendar的集成绝对是杀手应用。对于一个喜欢google服务,并且已经将这两个服务在客户端(Address/iCal或者Thunderbird)管理的井井有条的朋友,拿到gPhone以后几乎就是无缝迁移了。非常轻松。配合无线,它简直比通过iTunes同步这些数据要高明多了。这就是云服务的力量。当然那些mac下使用mobileme的朋友使用iP系列也是有同样的感觉。但是mobileme的质量和服务水平都差Google services很远。云服务在无限网络下,才是真正的云服务。
  • 但是在音乐和podcast管理上,gPhone让用户感觉还是差了很多。iTunes对于音乐这种个人收藏来说可能是最佳的管理方式,因为一个好得客户端能够让这些大数据量的同步变得轻松和快乐。而使用了gPhone以后我就在犹豫,我是否应该在手机上听音乐呢?但是如果你有的是iPhone,那么它本来就是一个增强了的iPod,配合iTunes管理好你的音乐,生活就真的自由而快乐了。我希望google能够想办法做一个sunbird的插件,sunbird可以读iTunes的数据,这样我就可以依然使用iTunes,但是通过sunbird享受这种便捷了。
  • gPhone上面访问picasa的功能还没有很好的整合,而Youtube也完全没有利用好,没有提供便捷的上传服务。
  • gPhone上的大部分软件都不不够好,在用户界面设计方面还差iPhone竞争激烈的App store里面的顶级应用很远。这也许因为app sotre启航很早,不过gPhone要走的路可就长了去了。比如Twitter客户端,tweetie/twiterrific/tweetdeck在iPhone上几乎是雄霸,而且都很好用。而Twidroid明显还不够好用……
  • Android的Market不好用,因为管理需要在手机上面完成,很不方便。对比iTunes已经集成了管理、升级、删除applications的功能,相比好用了不知多少倍。
  • Android上的游戏简直就是悲剧。因为没有一个让人眼前一亮的东西。相比之下iPhone平台上让人欲罢不能的游戏简直太多了。可是这里有个转机,就是iPod这个中间产品的出现。似乎拥有gPhone后再买个iPod touch能够更好的解决娱乐的问题,而且电力问题也得到了一定程度上的解决。因为商务部分用电话,娱乐部分用iPod touch,不会因为娱乐耽误了商务问题。

这只是第一部分,时间不够了,待续……

昨天在linode上面提了一个ticket,把我的linode从Newark迁移…

昨天在linode上面提了一个ticket,把我的linode从Newark迁移到了Dallas数据中心。主要原因是最近Newark机房实在太慢,慢到无法忍受,而且经常丢包,ssh也经常被reset。昨晚测速,我是北京的网通,Newark机房scp文件的速度也就是5-6k/s,实在无法忍受。所以下决心迁移。

Re-locating a linode installation这篇文章有详细的介绍

我提交ticket以后大概1个小时以后被通知需要重启以后进行一个migration就OK,我的镜像只有1.7G,所以迁移很快,十几分钟以后就迁移完毕了。然后需要更新一下DNS的指向,因为换掉机房以后IP也变化了。

很奇怪,给人家的server部署munin很方便(包括centos或者ubunt…

很奇怪,给人家的server部署munin很方便(包括centos或者ubuntu),但是自己的ubuntu server的munin却一直什么都输出不了。我已开始只看了/var/log/munin下的munin-node.log和munin-update.log,但是没什么迹象,只是发现有个别文件无法写入。后来修正了一下权限就都解决了。可是我的/var/www/munin还是空的。

后来才发现问题都记录在/var/lib/munin下的munin-update.stats和munin-graph.stats里面。其实罪魁祸首还是权限问题。解决方法如下:

  • 首先把/var/www/munin, /var/lib/munin, /var/log/munin/, /var/run/munin的权限都修改为munin:munin(如sudo chown munin:munin /var/www/munin)
  • 然后登录为munin用户,sudo su – munin –shell=bin/bash
  • 执行/usr/bin/munin-cron,看看有什么报错,如果是权限问题就修改权限

此时/var/www/munin就不是空的了。最后分析主要原因就是执行了某教程上说的sudo /usr/share/munin/munin-update –force-root,结果造成munin的数据文件的权限编程了root:root,后面munin的cron脚本用munin的用户执行/usr/bin/munin-cron的时候就出错了,无法写入。

在ubuntu server里面删除并重新安装munin-node的时候出错: …

在ubuntu server里面删除并重新安装munin-node的时候出错:

Initializing new plugins..Restarting munin-node.. *
Munin-Node appears to be unconfigured.

这样解决:

sudo apt-get remove --purge munin

这样再安装就没有问题了

数据导入的过程也应该是一个“事务Transaction”

上上周导入数据,我们约定了数据格式,写好了导入脚本,进行了充分的测试。但是当天给我们的数据结构却发生了巨大的变化,但是给我们的更新window就是当天,所以我们只能再写程序将格式转化为我们先前约定的格式。我和 @nasiless 同学结对做这件事。经过3、4个小时的努力,转换没问题了,将中间数据转化的操作演练了一下,没啥问题。当准备好停机升级,又从数据提供方得知其中一部分数据是错误的,然后又给我我们一份补丁文件(名-值对,需要覆盖现有值)。我们由于担心重新生成数据非常费时间,所以分析一下补丁对我们操作的影响。@nasiless 同学和我确认应该只影响其中一个中间数据文件,然后写脚本修正了一下。最后我们“成功”导入数据恢复服务了,当时很庆幸居然成功了(那个时候已经是晚上11点了)。当然其中有一部分导入失败的数据(9xx条)我们输出了一份文件准备后面手工输入。

一周后来(期间系统又进来很多新数据),我们发现导入的数据中失败的那部分可能是由于补丁文件也需要应用在另一部分的中间文件上造成的。可是当我们想反推这个过程并重现它的时候,我们发现我们的临时转换脚本(就是把那天修改的数据文件向中间文件转换的程序)居然放在了我的/tmp目录下,而其间我的mac重启过,所以这些脚本已经不见了。剩下的只有那个导入失败的log和映射补丁文件,我们经过推演问题已经变得非常复杂了。几个错误因素结合在一起,数据再回复的确是个非常费脑子的工作。还好经过反复排查,这些结果都是可逆的,不过其中人工操作众多,非常费事。我们也只能硬着头皮做了。因为这个系统还涉及到钱的问题,钱又涉及分帐问题,所以反推非常麻烦。

我们的结果还算好的,因为有方法反退效果。可是最大的问题在于这个过程本身应该是“事务”,必须全部完成或者全部恢复,当时我们的做法没有遵循这个基本的原则。而且我们的导入程序中复用了系统逻辑代码,但是忘记修改事务边界,没有将多个事务join起来,所以造成了脏数据的出现。这个也是后来折腾我们的一个主要原因。

所以教训就是:数据导入操作本身就应该使用事务,确定好所有的事务边界。而且数据导入的流程也应该是一个事务,不应该允许可能出现脏数据的请款存在,因为这种问题往往是追悔莫及的,也就是safe steps的极致。

“刷机惊魂险变砖”始末

周六才到手的G1险些在今天变砖,历程是这样的。内容不专业,不是帮您刷机的,只是告诉您怎样刷坏的。

中午吃饭下楼正巧碰到Andriod牛人“小新(quakelee@twitter)”,吃饭间请他一起研究我新买的G1。小新本人用的也是G1,旁边几位同事也不少G1,刷机大都是由小新帮忙。而小新也欣然接受帮我刷机。

吃饭归来就去我们的“不拆不舒服司机”和“不焊不舒服司机”的小魔屋(SA办公室)刷机。小新看了下我的基本情况,是TIM的西班牙版本机(或者是意大利版),当时的主Rom是hiapk的2.2版本,里面有SPL能够启动Fastboot,副rom不明。

  1. 小新首先察看了一下机器的版本,发现root权限已经有了(俗称“采权”完毕)。因为已经刷了非官方的hipak 2.2 rom所以小新启动检查了刷机的SPL认为这个机器应该比较容易刷新rom。小新首先尝试了刷新SPL到工程版本,后来小新发现这个机器的SPL也能进入3个绿机器人滑滑板的界面,所以小新说这个已经是工程SPL了,可以直接刷新的副Rom(Recovery)到自定义版本的Recovery,这样就可以用它刷主Rom了。
  2. 小新启动了ubuntu,然后让G1进入SPL,连上Fastboot,发现连接一切正常。然后小新就格式化了Recovery分区(fastboot erase recovery),然后小新使用fastboot更新那个自定义recovery,但是出错了,报告signed verify failed,签名错误。小新大呼可能要瞎!他和我解释他没有备份我的recovery,现在无法刷recovery就只有主rom了,而这种情况下面的所有刷机都回困难重重。而且刷不进去自定义rom很有可能是SPL有问题,但是没有了recovery分区就很难刷SPL……
  3. 小新向蛋总求救,听说蛋总身在米国,半夜帮忙,实在感谢。小新咨询了一下当时的情况,发现情况可能比想像中要遭。但是蛋总的意思是这个手机没啥特殊,应该肯定能刷好。小新还去“机锋”和“安卓”论坛寻找有用线索,无果。他尝试了几个不同版本的自定义recovery,都是报告签名错误,包括蛋总推荐的RaMon也不可以。此时气氛凝重,小新告诉我下面每件尝试都是高风险,随时可能变砖。我心想管理员做事谨慎,所以应该不会有问题,充分相信小新。
  4. 死马当活马医,小新发现居然Fastboot现在工作还正常,也能用adb练到手机里面。他与蛋总切磋了一下,蛋总推荐降级,说可以通过fastboot boot recovery.img的方式重启并刷入rom。小新尝试了一下,惊喜的发现居然可以通过这种方法引导进入自定义recovery,当时使用的是RaMon 1.5.2的recovery rom。这个露出了一丝曙光。
  5. 然后小新仔细梳理了一下刷机流程,并对比了他自己的G1,发现问题出在我的baseband和SPL。首先我的baseband是老版本,所以一开始刷入工程版SPL的操作失败了。而后进入的SPL虽然有三个绿色机器人滑滑板界面,但是它是一个新版本的非工程版(或者说官方版本,检测签名的版本)的SPL。它虽然看起来和工程版SPL一样,但是完全不能用来刷自定义rom。
  6. 小新说唯一的出路就是重刷SPL。但是要先升级baseband。其实到了这个地步,我的主rom(hiapk 2.2)还是可以启动的,只是如果不做后面操作一个是以后主rom坏了就再也无法recovery了,再有就是SPL也就无法升级了。所以小新推荐我继续刷机,不过他警告我操作风险很大,我说继续。
  7. 用fastboot boot recovery.img进入自定义recovery,然后刷新了baseband,一开始重启不了了,我们以为要砖。小新想起这个需要重启进入recovery另外一次,所以又fastboot boot了一次recovery,重启就又可以进入主rom系统。也就是说此时机器还是可用,而且离成功进了一步。
  8. 下面要刷SPL,风险很大,小新特意去网上找了一个和它G1一样的版本并检查了md5sum。然后继续fastboot bott recovery.img重启,刷工程SPL很快,小新问了下蛋总这样做没啥风险(用fastboot boot img的方式进入临时recovery刷SPL的这个行为)?蛋总说没有问题。小新重启机器。此时舜佳鹏一两位团队成员跑过来围观,听说现在状况很危急纷纷表示我的机器不会这么容易变“砖”的,但是也幸灾乐祸的表示如果”真得变砖“也不要过度悲伤,然后两人协同超哥去给我买了一瓶美年达。这美年达喝在嘴里那叫一个酸呀,真要砖了那可太心酸了。
  9. 此时心都跳到嗓子眼了。重启后小新用adb试着连,能连上,可以看到引导了。因为这个过程需要再进入recovery两次,所以小新fastboot boot recovery了一次。但是……这次重启后,我俩彻底崩溃了,机器无法引导,adb连上后报错,无法建立连接。所以就不能再次fastboot boot recovery了,那么就瞎了,也就是说砖了。这次小新用低沉的声音和我说:“完了,这次是真砖了……”
  10. 此时屋里鸦雀无声,大家都被“砖了”这个词震惊了,大家纷纷围观过来……我心情无比沉重,小新明显也是,一直和我说对不起。可是我知道这个完全是我造成的,托小新那是找人帮忙,哪有人家帮我的不是。我心想不能给小新压力,故作震惊,说没关系,机器先放在你这里,看看还有啥补救措施啥的,然后我就出去了。
  11. 回到作为先是浑身发冷,然后浑身发热,然后浑身无力。赶紧和老婆用gtalk报告噩耗,还要老婆外出看不到。但是晚上老婆要过来找我看电影,电话不能用了她一定很着急。而且这不是最麻烦的,这是老婆好心怕我手机太破才给我批款子买的,到手里两天,用了还没超过3个小时就变成高科技“板砖”,这是何等可怕的“悲剧”呀,心情一下子十分黯淡。我故作镇静的开始看手头的程序,可是哪有心情呀,幸好pair不在,否则魂不守舍的我肯定会让pair很郁闷。
  12. 恍惚了有半小时还是一个小时?我求助了twitter,有热心朋友帮RT,但是显然也没啥帮助信息出现。心灰意冷呀。此时小新从远处摆出“囧”字脸走向我,和我说:“真的是砖了,你明天拿到村里找奸商看看能否加钱换一个吧。我拿到机器就要拆后盖,其实当时有点恍惚,就像宠物走了想要再检查一遍它的身体一样……超哥和小新阻止了我,并说你先看看机器呀。我一看,发现屏幕居然亮着,系统已经启动了!赛,当时真是喜出望外!

尾声。小新告诉我原来是大胖同学解救了我俩。这个机器按着照相快门键启动就可以引导入SPL,然后就可以刷机,刷机后就好了!所以是大胖救了我们。原因是小新刷的机器都是按return和开机进入SPL,但是大胖的机器按快门和开机进入。所以按照大胖的习惯我的机器就开开了。后来测试发现,我的机器只支持快门+开机进入SPL,而小新的机器只支持return+开机进入SPL,而大胖的机器两个快捷键都可以。所以世界还真是无奇不有。

老婆到达的时候我的G1已经又工作正常了,不过心灵真的受到了打击。一个到手3小时的新G1,居然马上就砖了,本来为了省钱买它,如果再入手一个那还真要用上一个iPhone 3G的价格了,吓人呀。不过还好,修好了,这1850没有打水漂。一个教训就是,下次做这样心跳的事情要多做功课,每一步想好撤退方案再行动,所有危险动作前要double check前置条件是否达到,否则,那还真是一步一步走向“变砖”,连头你都没法回了。

感谢帮助刷机3个半小时的小新,感谢帮助G1起死回生的大胖,感谢资深技术支持蛋总。感谢团队的围观群众舜佳、彭一、远超,还感谢老婆没有责怪我。

刚才好消息传来,居然G1又好了,是在没有Recovery系统的情况下用fastb…

刚才好消息传来,居然G1又好了,是在没有Recovery系统的情况下用fastboot boot recovery.img进recovery系统,然后刷SPL的。但是SPL刷后要重新进入recovery,由于没有,需要再次fastboot boot recovery.img。而后由于我这个版本的机器需要按住照相键重新启动,可是大牛 @quakelele 同学的机器是按住return的,所以一直无法启动,我们都已经以为这只年轻的G1变砖了。我都心灰意冷本来准备掏钱去中关村换的,失落的回到座位开始求助twitter,能看到朋友帮助retweet很感动,可是一时半会儿也没有有效的帮助。还好大胖同学帮忙实验了一下我的“砖”,没想到就正常启动了。他们过来的时候还骗我说只能去中关村了。我拿过来就想拆后盖实验一下,谁知实际上是想给我一个惊喜。机器又正常启动了,换了新的系统……谢谢 @quakelele 、大胖、还有我们team的几位兄弟为了安慰我给我买了美年达。可以放心了。

刚到手第2天,G1砖了,好大的悲剧呀。这次惨了。哥们刷机顺序出了些问题,现在ba…

刚到手第2天,G1砖了,好大的悲剧呀。这次惨了。哥们刷机顺序出了些问题,现在baseband是新的,但是recovery坏掉了,而且SPL也失败了,莫大的悲剧呀。只能看到TIM启动LOGO,然后就卡死了。一筹莫展中。

早上突然看到所谓的2009十大开源软件里面有一个Suse Studio,它是一个…

早上突然看到所谓的2009十大开源软件里面有一个Suse Studio,它是一个很有趣的项目。仔细看了看它支持software applicance,也就是把一个定制的Suse studio distro作为一个虚拟机镜像,运行在自己的Hypervisor上面。维基百科果真是好东西,解释了一下这个听起来有点耳熟,看起来才发现很熟悉的东西。其实它就是虚拟机的运行环境管理器,而且它有两种主要形式(Type1, Type2)。Type 1是一个固件层应用,它直接工作在硬件上面,并为Guest系统(guest operating system)提供运行环境,并监控Guest系统的运行状态,像Xensource的xen控制器,VMware ESX都属于这一类。而Type2就是工作在操作系统上的一个Guest系统运行环境,不直接工作在硬件上层,我们常用的VMWare workstation和Fusion,还有Virtual box就是这一类。所以Hypervisor就是运行环境的管理工具,当然也要提供相应的虚拟运行环境。以后企业内部对在虚拟环境下运行的linux distro的需求会大增,像Suse studio这样的提供在网站自定义distro的服务一定会很受欢迎!