借物的阿莉艾蒂

写于2011年7月24日,深圳坂田。

很长时间都没有像现在这样静下来看部片子了,昨天把《借物的阿莉艾蒂》看完了。故事情节很简单,结局也没有太出乎意料,情理之中吧,但总觉得还缺少点什么,又找了几篇影评,总的说是部好片。

影片一开始就出现不和谐的一面,乌鸦和猫应该都发现了小阿莉艾蒂,应该是为了争夺“猎物”打起来,让人有种不安的感觉,外面的世界对于小人族来说危险重重。直到出现小阿莉艾蒂回家的路上与愤怒的肥猫道别、从窗户翻进卧室的温馨画面出现,悬着的一颗心才落了地。

阿莉艾蒂妈妈出场的时候,表情有点夸张,差点被雷到了。

后面的故事围绕着方糖展开,翔送方糖并附上几个字,影片中没有看到翻译,想应该是“你掉的方糖”的意思。后面送上花儿的时候也附上了几个字,应该是“我想见你”吧。

阿莉艾蒂还方糖的时候,隔着纱窗,两人第一次语言交流,似乎不只是阿莉艾蒂来还方糖并告诉翔不要干预他们一家的生活这么简单。乌鸦又一次出场,缓解了尴尬局面,阿莉艾蒂被翔救了下来,本想后面应该是两个人倾心而谈,最后致谢离去呢。没想到是女主人公惆怅地看着男主人公惆怅地看着手里的树叶却没有看到自己,然后女主人公悄然离去。看到这一幕,心底似乎有什么被触到了。

后面不幸的“拆迁”还是发生了,阿莉艾蒂妈妈被春姨抓走,阿莉艾蒂与翔默契配合解救妈妈的过程将故事推向了高潮。

土著小人的出现,让人觉得有点意外,似乎也带来了更多的喜感,呵呵。
最后,小阿莉艾蒂与翔道别,互换礼物,挥泪离去的一幕着实让人感动了一下。

终于在富于野外生存经验的土著小人的帮助下,阿莉艾蒂一家开始了漫漫搬家旅程。浆果,鱼儿,这些画面的出现,让人相像他们以后的生活应该也会非常快乐的。而翔也迎来了早上的第一缕阳光,似乎预示着他在手术后也会好起来。总算是一个不算完美的完美结局。

试想一下期待的完美结局,阿莉艾蒂一家住进了翔的祖父辈从英国定制的小人居里,和翔一家一起过着和谐相处的生活,处处能够得到他们的保护与帮助,但是这样他们又属于什么关系呢,寄居更或者是饲养关系?我想都不好吧。而且,现实中应该更多的是像春姨这样对小人族怀着好奇与仇恨的人,是容不下小人族的。也许别人安排好的路看上去很顺畅,但是并不一定是最适合自己的,幸福还是需要自己去创造。

| 1 分2 分3 分4 分5 分 (5.00- 7票) Loading ... Loading ... | 归档目录:生活札记, 观影随想 | 标签: , , |

SkyDrive、DropBox和Google Drive三大公有云存储服务对比

严格意义上说,iCloud相对较为封闭,不算是通用的云存储。上面三种云存储应用,笔者都有使用,就各自的优缺点说一下使用的感受。

SkyDrive还是同Windows绑定太紧密,客户端只支持在Windows Vista SP2以上版本上面安装,XP用户就只能通过网页手动同步,无法体验本地文件夹与网络文件夹的自动同步。自动同步功能还是非常有用的,如:在iPad上面的照片可以很快上传到网络上面,然后在PC上面查看。反之亦然。在自动同步上面做得最好的应该是DropBox,但是DropBox只有2G的免费空间,这个显得有点寒碜。同时DropBox几乎支持目前的所有操作系统。

GDrive在国外应该是很不错的应用,与GoogleDocs天然绑定,15G的共享空间,但是非常无赖,国内还要修改本地的hosts文件来访问,并且修改之后也不稳定。这里提供一个可用的hosts文件配置:

文件路径:C:\Windows\System32\Drivers\etc\hosts

在文件末尾加入如下内容:

173.194.38.128 drive.google.com
203.208.46.180 docs.google.com
203.208.46.180 0.docs.google.com
203.208.46.180 1.docs.google.com
203.208.46.180 2.docs.google.com
203.208.46.180 3.docs.google.com
203.208.46.180 4.docs.google.com
203.208.46.180 5.docs.google.com

再就是移动设备上面,不能支持多媒体文件的播放。而其他两种都可以支持本地播放器播放临时文件。

在快速分享存储内容上面,三者都大同小异。基于账户,基于隐秘链接,公开给所有人三种都有实现。

对于文件历史版本备份,三者都能保存一定时间的文件的历史版本,GoogleDrive和DropBox还带有回收站,误删文件可以从回收站中找回。

相信随着互联网业务发展的日新月异,用户的增多,空间、平台、收费与否都不是问题。阻碍信息流通的产品设计会越来越少。

| 1 分2 分3 分4 分5 分 (5.00- 5票) Loading ... Loading ... | 归档目录:移动互联 |

华为终端最近挺热闹

酝酿了3个多月的华为Ascend P6终于在伦敦Roundhouse亮相,这一次在宣传和营销上可谓做足了功夫。昨晚失眠,索性就把发布会的视频翻出来过了一下。并没有微博和各个消费电子门户上面造势的那样惊艳,只能说是一部普通的手机罢了。牺牲了电池容量和本可以在去年就发布的时间点,换来了6.18mm的超薄厚度。K3V2始终是一个硬伤,这次发布会中没有强调P6是用的K3V2E。高通的骁龙系列都从4核心1.2GHZ发展到了枭龙800的4核心2GHZ+,覆盖了低中高端的所有需求。而华为的终端机型,无论处于哪个档次,一直使用K3V2,这样的做法让人看不出终端开始走向高端的趋势。

22257642_1371567595555_500

1.5GHZ 4核心CPU,720P HD 4.7英寸屏,2000mHa电池,前置500W像素、后置800W像素摄像头,2GRAM,从配置上面看不到任何“旗舰”的标志。这些配置都是去年的主流配置,在今年Q3相信各大厂商都会推出新的主流配置手机,这个配置会被甩到很远,而正是那时,P6才放量上市。加上细节问题百出的不争气Emotion UI,相比之下,恐怕消费者不会把P6放在首选的位置。余总承东1000万的销售量恐难以达到。

 

再来看一下,一直作为卖点的超薄、外观设计。不得不承认,P6的外观设计颠覆了之前的华为手机外观的印象。同事常笑谈,手机像情人,如果一个手机只是屏幕非常非常大,如美腿(Ascend Mate),只是厚度非常非常薄,如P6,就好象一个男人在夸她家的妹子胸大,只有胸大,相信没有人认为这是每个人都喜欢的美。外观设计的确比较出众,但是要想到这是一个“1000多人跨部门合作”的成果,这样外观必然是有一些标杆参照的,否则必然是一个各方妥协没有一致性的怪物。仔细看一下P6的外观,正面上方可以说是iPhone5的,下方是索尼一直坚持的双C倒角造型。金属外壳,可以看出为了打造旗舰,舍出了血本。2688的价格,如果真像发布会上面与S4和iPhone5对比的那样,那么也算是良心价了。这个价格应该是吸取了Ascend D2初期定价过高的教训,但是仍然过高了,相信不出一个月会有大幅的跳水。

 

总的来说,还是可以看到进步的,希望P6是一个终端的转折点,以P6为基础,将配置与主流机型拉齐打造出真正的旗舰。

| 1 分2 分3 分4 分5 分 (4.83- 6票) Loading ... Loading ... | 归档目录:数码硬件 | 标签: , , |

端午节回家

22点51分,列车准点发出,很快就适应了略带颤动但也平稳的行进节奏,伴随着轰隆隆的声音。

这还是第一次年中的时候回家。不知道从什么时候开始已经没有了那种久违的回家的喜悦感。以前不会为生活,为自己将要成立一个什么样的家庭而烦恼,只是专注于自己的学业,工作,当这些都慢慢达到自己尽最大努力能达到的程度时,好像除了拥有一个真正属于自己的小家庭外,已经没有什么可以令家人放心了。

像这样的长途旅程也许会越来越少。还是特别怀念这种方式,身边都是陌生人,不同的目的地,不同的年龄,不同的行业,但是他们似乎都有一个共同的目的,赶往一个温暖的港湾。在这样的漫长旅途中,感受尤为强烈。父母在一天天的老去,而我却还不能给他们提供应有的幸福。我的地又在哪呢?

是不是又想太多了,一觉醒来,也许就到终点站了。

| 1 分2 分3 分4 分5 分 (5.00- 4票) Loading ... Loading ... | 归档目录:生活札记 |

发布一个改良后的轻量级下载工具

一直都觉得迅雷等工具太重了,即占用网络带宽又消耗系统资源。而且在下载源的出口速度普遍超过家庭宽带的速度时,p2p已经起不到下载提速的作用,甚至还会在下载完成后占用上传带宽。因此一直想找到一个最精简的下载工具,axel是目前发现的比较合适的。以后试着用脚本写一个类似的工具。

axel是linux下的多线程下载工具,工具支持多线程并发下载,支持断点续传。这里基于axel-2.4的源码,在cygwin下编译了Windows版本。基于gnu的开源license,发布一个Windows的版本。

编译好的软件包见文末的下载地址。

其中,mydownload.bat为启动程序,在使用之前只需要修改其中的目录即可:

@cd /d "C:\Users\t\Desktop"
@set maxcons=8

:renew
@set /p url=请输入下载路径:
@call D:\software\axel-2.4\axel.exe -n %maxcons% -a "%url%"
@echo finished!
@echo;
@echo;
@goto renew
@pause

axel.exe文件的路径和下载后文件存放的路径。即以上粉红色部分。

下载地址:http://shentar.me/wp-content/uploads/2013/06/axel-2.4.zip

| 1 分2 分3 分4 分5 分 (4.50- 6票) Loading ... Loading ... | 归档目录:C/C++ |

和小室友一起,又过了一个儿童节

DSCF0012

| 1 分2 分3 分4 分5 分 (5.00- 4票) Loading ... Loading ... | 归档目录:生活札记 |

通过/proc/stat文件信息,java实现计算cpu使用率

/proc/stat 文件内容:
[root@Shentar ~]# cat /proc/stat
cpu 602 0 2164 11445 2294 0 17 0 0
cpu0 306 0 1232 4553 2125 0 15 0 0
cpu1 295 0 932 6891 169 0 1 0 0
intr 7110 269 7 0 1 1 0 5 0 1 0 0 0 91 0 0 106 0 6521 0 108 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 38984
btime 1368275792
processes 2713
procs_running 1
procs_blocked 0
[root@Shentar ~]#

第一行的数值表示的是CPU总的使用情况,所以我们只要用第一行的数字计算就可以了。下表解析第一行各数值的含义:

参数 解析(单位:jiffies)

(jiffies是内核中的一个全局变量,用来记录自系统启动一来产生的节拍数,在linux中,一个节拍大致可理解为操作系统进程调度的最小时间片,不同linux内核可能值有不同,通常在1ms到10ms之间)

user (38082) 从系统启动开始累计到当前时刻,处于用户态的运行时间,不包含 nice值为负进程。

nice (627) 从系统启动开始累计到当前时刻,nice值为负的进程所占用的CPU时间

system (27594) 从系统启动开始累计到当前时刻,处于核心态的运行时间

idle (893908) 从系统启动开始累计到当前时刻,除IO等待时间以外的其它等待时间iowait (12256) 从系统启动开始累计到当前时刻,IO等待时间(since 2.5.41)

irq (581) 从系统启动开始累计到当前时刻,硬中断时间(since 2.6.0-test4)

softirq (895) 从系统启动开始累计到当前时刻,软中断时间(since 2.6.0-test4)stealstolen(0) which is the time spent in other operating systems when running in a virtualized environment(since 2.6.11)

guest(0) which is the time spent running a virtual CPU for guest operating systems under the control of the Linux kernel(since 2.6.24)

结论:总的cpu时间totalCpuTime = user + nice + system + idle + iowait + irq + softirq + stealstolen + guest

计算时,采样两个时间点的数据,对于时间点1,记录总的cpu时间total1,记录空闲时间idle1,对于时间2,同样记录total2和idle2。

菜谱使用率为:cpuusage = 1 – (idle2 – idle1) / (total2 – total1)

注意,如果时间点1和时间点2间隔足够小(小于10ms),则可能出现total2 – total1为0,这样cpu使用率应该为0,而不是采用除法计算。

java代码如下:

阅读全文 »

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 归档目录:Java |

收藏一些配置

CPU Intel 酷睿i7 3770K(散) 1 ¥ 2000
主板 技嘉GA-B75-D3V(rev.1.1) 1 ¥ 769
内存 金士顿8GB DDR3 1600 1 ¥ 275
硬盘 希捷Barracuda XT 2TB 7200转 64MB SATA3(ST32000641AS) 1 ¥ 600
固态硬盘 三星SSD 840 Series SATA III(120GB) 1 ¥ 629
机箱 百盛C615 1 ¥ 118 ¥118 4家商家
电源 酷冷至尊战斧500(eXtreme Power Plus 500) 1 ¥ 359
散热器 超频三红海至尊版 1 ¥ 145
键鼠装 罗技MK330键鼠套装 1 ¥ 180
光驱 先锋DVR-XD11C 1 ¥ 349

20130308-212444.jpg

| 1 分2 分3 分4 分5 分 (4.67- 3票) Loading ... Loading ... | 归档目录:数码硬件 |

Chrome 3月5号更新版本闪退

今天打开chrome浏览器后,提示有新版本可用。ios下的chrome不像pc版本更新得那么勤,看到有更新,迫不及待的点击了更新按钮。安装完成,却发现无法启动,确切的说是闪退。幸好还有safari,google了一下,发现遇到这个问题的还真不少。

Chrome闪退

有人提到是“下载插件”导致的,卸载了chrome download manager后,果然问题解决。appstore里大量的闪退不知道是不是也是这个原因导致的。

当初之所以将系统越狱也是因为需要安装这个插件,不能从浏览器下载文件这个没法忍受,而GOOGLE又不能发布一个越狱产品,相信这样个插件的市场很比较大,这是不是意味着chrome被一个小小的插件绑架了。不管闪退的原因是什么,这次chrome的损失应该是非常大的。当一个产品大规模用起来后,程序员真有一种如履薄冰的感觉。相信很快就有解决问题的新版本出来了。

| 1 分2 分3 分4 分5 分 (5.00- 3票) Loading ... Loading ... | 归档目录:移动互联 | 标签: , |

system调用导致子进程socket句柄泄漏问题分析

关于fork和行缓冲的问题 中讨论了fork的一些特性,堆栈复制,确切的说是‘写时复制’。这篇将讨论资源的复制问题。

问题引出:A进程与B进程各自独立,都是服务器进程,常驻系统,互不相干。在某次重启A进程后,发现由于固定监听的端口被占用而无法启动。检查,发现是B进程占用了该端口,检查B进程代码,没有相关的打开该固定端口和打开随机端口的动作。问题百思不得其解。

最终,发现B进程不只是占用了该固定端口,还打开了很多本该只有A进程才会打开的句柄资源。很快联想到A是B的子进程,B是A fork之后在子进程中运行的。进一步分析,发现A进程有着类似于监控B进程的作用,在特定情况下,会调用B进程的监控脚本来重启B,调用时用的是system函数。

再来看system函数的实现,用fork产生一个子进程,在子进程中运行脚本,脚本启动B。B就这样降到了A的子孙辈,无论是第几代子孙,都会继承A的资源。

这样,当B重启之后,B也打开了只有A才会使用的端口,对B来说,它根本不使用这些资源,甚至不知道自己打开了哪些句柄,这非常不好。之后,某个时刻,当A重启时,A原来申请的资源会一一释放,但是已经被B继承的那份拷贝还处于打开状态,导致A启动时报端口冲突。

问题分析清楚,也就好解决了。解决的方案有:
1、重写system函数,再派生子进程后,运行脚本之前,将所有不需要的句柄关掉,一般的多进程服务端程序也都这么做。
2、发现java程序并没有打开父进程的资源,可以用java实现一个‘脚本调用器’,解决办法似乎不是特别优雅。
3、在申请资源的时候用fcntl将句柄设置为不被继承。

在分析方案的过程中也学习了vfork与fork的差别,vfork只是父子进程共享堆栈,但是句柄资源还是复制了。也分析了exec与fork的区别。都找不到完美的解决办法。

3方案解决当前问题最简单,但是容易留下坑。2方案总觉得很别扭。决定采用1。问题又来了,A进程本来就不是多进程的模式,因此它并没有集中管理资源,想要从代码中增加全局变量收集零散资源似乎很困难。想到了常用的lsof工具,这个工具不是可以列举任何进程的句柄吗?查阅其源代码,原来是读取proc虚拟文件系统下的数据来实现的。如法炮制,也用这个方法遍历本进程的fd目录,将得到的句柄一一记录,在关闭了proc目录后,将记录下来的句柄关闭,这时还会将已经关闭的proc目录的句柄又关闭一次,不过不会有什么问题。存在的问题是必须以root运行才能得到句柄列表。

奋笔疾书,写完了新的system函数,却发现脚本不能运行完成,总是在中间某个点就退出了。经过在脚本中反复打点,发现总是在同一行上面退出,这一行是一个shell函数调用,猜测,是不是新的system中指定的脚本解析器不支持函数?另外写测试程序,也不是这样的。继续找原因,原来这一行还使用了标准输入、输出、错误重定向。而标准输入输出已经在父进程中关闭了,重定向当然会有错误。保留0,1,2三个句柄后问题彻底解决。其实这三个句柄也是不能随意关闭的,一但句柄关闭后,系统会将句柄号分配给其他资源,这样如果代码中使用了重定向0,1,2,那后果会不堪设想。

| 1 分2 分3 分4 分5 分 (4.86- 7票) Loading ... Loading ... | 归档目录:C/C++, 软件技术 | 标签: , , |
返回顶部