博文

目前显示的是 2014的博文

archlinux on 树莓派注意事项

图片
树莓派 很早就有,两年前 HZLUG 还有线下活动的时候不少人都玩这个。而我一直是用多余的笔记本来当下载机的,所以直到不久前把老本送给老妈用(结果我从老家离开第二天,win7 系统就陷入无限自我修复循环,非常郁闷),才终于有口实入了一个。 真是小巧可爱,相见恨晚。稍稍折腾一下,可以很好的承担下载机甚至各种电视盒子的功能。于是这里记录一下 archlinux on Raspberry Pi B+ 的一些注意事项: 系统 archlinux 有 for 树莓派的版本,不二之选。对着 Installation 照做即可。不上桌面的话(可以直接用 xbmc)tf 卡其实不需要很大,我这里连 xbmc 都装完了才 1.8G。 供电 树莓派多数莫名其妙的不稳定问题都是出在供电上。我是最后翻出了以前带独立供电的 usb hub,硬盘和树莓派都从 hub 取电,现在 15 天了还算稳定。很多卖家推荐 5V2A 的充电器,但是 线材的质量的影响也不小 。可惜国内卖的线材极少有 标注规格 的,唉,我有点想念日本了,通常不用为这些边边角角的事情操心。 花屏/显存 B+ 直接上 archlinux 另一个常见问题是随机出现花屏。原因是 显存没给够 。在 /boot/config.ini 修改这一行即可 gpu_mem_512=128。 下载 transmission,有 web ui。目前除了某些文件名字特别长的种子(呀,貌似暴露了)会下载失败,没发现什么缺点。建议开启 blocklist,我用的是这个  http://list.iblocklist.com/?list=bt_level1&fileformat=p2p&archiveformat=gz 。 samba 外接的 usb 硬盘本来用的是 ntfs,结果树莓派机能本身就没那么强,基于 fuse 的 ntfs-3g 再多耗点 cpu,会导致实际传输速度的进一步降低。树莓派的网口只有 100M,本来就有约 10M 的上限,我用 ntfs 实测的速度大概是 4~5M。后来把 usb 硬盘格式化成 ext4,速度可以达到 5~6M,大概也就这样了。这个是目前最大的 regression,原来用笔记本千兆网卡飙到 40M 左右(机械硬盘的上限)是没问题的。如果路由器够强的话或许可以考虑把硬盘挂在路

虫鸣

自从夏末以来,几乎每天下班,都能听到路边各色的虫鸣。蛐蛐、蝈蝈的声音在北方也很常见,我可以轻易分辨,但像这样婉约的,我还是第一次听到(为了上传这段音频才知道有 youlisten 这样的网站)。 Share Music - Embed Audio Files - Bug Buzz in Hangzhou China 生活中本不缺少美,缺少的是发现美的心情。

记忆里的家

图片
很久没回老家了。前段时间正好趁年假即将过期,连着国庆狠狠回去住了些日子。 五味杂陈。 家乡已经有了不小的变化——新的马路,新的桥梁,新的楼盘——我只能像个外乡人一样,听司机、听同学、听父母浮光掠影的描述着他们所知的片段,然后附和的嗯嗯啊啊。 从我眼里望去,就在四车道马路对面高楼下巨幅招牌和闪烁的霓虹里,依稀还是当年绿树掩映下的四层红砖小楼,楼群的路口是漆了暖暖的淡黄色的围墙,墙上有镂空了的盆景造型,墙后不远还有个蓝色的垃圾箱,每周两次固定时间,都会有翻斗车缓缓开来,等着一旁的叉车来把垃圾箱高高举起。 老屋倒是没太大变化。只是母亲早就开始啰嗦屋小东西多。破家万贯,这是到了我这一辈仍难以改掉的陋习。父亲尤甚,他当年学徒时的笔记,乃至不知何年的物理化学课本仍是舍不得扔掉。而母亲又不想换大屋。于是我只能捡自己的回忆丢掉。几日之内,先后变卖了这些年来积攒的古旧硬件、软盘、光盘和书籍。再添置些新的电器,于改善生活品质虽不显著,毕竟聊胜于无。 只是,老屋的那种天然避风港的家的感觉,那种我置身其中就能慢慢回血,睡一觉就原地复活的神奇却从指缝间滑走了。我记得起老屋里每一件什物的前世今生,却感觉不到他们的主人和我曾是同一个人。 摘抄两个金句(忆自网络,大意): 当你开始不自觉脱口而出『想当年』的时候,你已经老了。 你热爱一切那些从前给你留下深刻印象的东西并奉为经典,而实际上你只是在怀念逝去的青春。 家一直都在。我回到从前的地方,寻到从前的事物,却再也触不到她。她只在我终将消散的记忆里,在我如水逝去的青春里。 所以也就释然了,该去的就让他去吧。

无题

一个同事 走了。今天应该是头七。 跟他相识很早,那时他还是实习生。后来相忘于江湖,虽然还是同事,却基本没怎么打过交道。印象里始终是那个真诚的腼腆的大男孩。 这里是他 最后的文字 。其实每个心灵都有柔软的一面。 今天应该是头七,无以为祭。谨聆一曲『 我用所有报答爱 』,故人如歌。

我的又一个 fuse 客户端——upyunfs

我写 fuse 客户端可能有点上瘾,是因为我觉得对于在线存储类的服务,能够映射到本地存储,对用户来说是路径最短,学习成本最低、体验最友好的方式。而要实现类似的效果,据我所知要么用 fuse 把远端的存储挂载到本地(如 sshfs、amazon s3fs),要么写个后台服务实现本地和远端的双向同步(同步远端可以轮询或用某种 push 技术,同步本地可以用 inotify,典型案例是 dropbox)。而我之所以倾向前者,是因为 fuse 的实现成本要小很多,对于个人开发者来说性价比完胜。 有了上述前提,什么专门的 GUI 管理工具啦,专门的 shell 啦,在我看来都比较无聊——当远端的文件系统已经变成本地的一部分时,用户可以使用任意自己熟悉的文件管理工具(无论 GUI 还是 CLI),可以使用任意自己熟悉的 shell 环境(包括相应的各种工具),来完成对远端的文件管理任务。比如将 dropbox 同步到 upyun,在我看来只需要这样就可以了: upyunfs -b lyman_foo ~/cloud/upyun # 挂载 upyunfs rsync -avh ~/cloud/dropbox/ ~/cloud/upyun/ # 用 rsync 同步两个文件夹 所以看到 upyun 搞了 开发者比赛 的时候,我实在是忍不住,便写了这个 upyunfs 。 对实现细节不感兴趣的同学可以忽略下面的文字了,不过还是希望各位能给 upyunfs 投个票:到 项目页面 里找到 upyunfs-for-UPYUN,点击「投票」按钮即可。 接下来大概分析一下 upyunfs(以及类似存储系统)的实现要点。 一、技术选择 fuse 有 各种语言的 binding ,从执行效率角度考虑首选当然是 c/c++。但是如 upyun 这样提供 RESTful 接口的服务,用到字符串操作的地方不少,所以用脚本写起来更方便。python 的 binding 我试过一次,问题不少文档不多,所以我一直用 perl。 二、roadmap 基本功能 这个阶段基本上只要做好 fuse 回调和 RESTful api 的映射就好了。具体一点,在线存储系统基本上必不可少的 upload/download/list 操作,大抵就可以对应到 fuse 的 read/wri

再见,delicious

曾几何时, delicious 就是在线书签的代名词。但是就在刚刚,我把自己的书签都搬到了 diigo 。 delicious 自 2003 年出现,2005 年被 yahoo! 收购,2010 年被 yahoo! 宣布关闭,2011 年被 avos 挽救,到今天,一直不死不活,苟延残喘,而我也一直坚持用它。 今天翻看自己的 delicious 页面,才发现丢了近一周的数据。大概是 5 月 4 日起,虽然 chrome 的插件、firefox 的插件在使用时没有抱怨什么,但新书签却再也没出现在我的 delicious 里。 理想不能当饭吃。 我对在线书签的要求也不高:能打标签,别人能订阅、支持主流浏览器足矣。在感受了 digg、pocket、google bookmark 和 diigo 之后,最终选择了 diigo(温馨提示,google bookmark 看起来很有步 google reader 后尘的感觉)。 彻底自由的做法,或许应该是通过自由的浏览器插件、手机客户端存储到本地,然后通过类似 dropbox、btsync 之类实现中央存储或者多点同步。只不过这么理想化的解决方式,在今天凡事都想被做成在线服务的大环境里,越发缺少生存的土壤。 祝 diigo 长命百岁吧。

Android 实现模糊效果的一些笔记

不知从 ios 的那个版本起有了毛玻璃效果,于是这东西就成了 Android UI 设计师们爱用的效果之一。实现这个效果,技术的核心是对图像的模糊处理。 当然,技术上需要做到什么程度,取决于要实现的效果如何。如果需要模糊的对象是固定的,而且是整个图像一起模糊掉,那么最简单的办法还是在开发阶段就计算好模糊的图片——photoshop 的滤镜能达到的效果永远比工程师重复发明轮子在用户手机上算要来的好。然后把这模糊图放在清晰图的上面,通过控制模糊图 ImageView 的透明度来实现渐变毛玻璃效果。在布局不是特别复杂的情况下,这样做的效率还可以接受(实在想优化的话就自己在 Canvas 上画吧)。 如果需要在手机端计算模糊图,那么 这篇文章 和 这篇文章 是很好的补习资料,常见的 Box blur 和 Gaussian blur 的原理讲的很清楚。实际上,Gaussian blur 因为涉及的基本都是浮点计算,执行时间是 Box blur 的数倍。以 note2 为例,自行计算一张 radius=16 的 720x1280 的 Gaussian blur 图片,Java 版本需要约 1 分钟,c++ 版本最快也要约 20 秒(纯 cpu 单线程,多线程的边界情况处理器来很麻烦所以没折腾成),而 Box blur 同样的图片虽然可以在几秒内完成,但对于某类图片(比如带明显横竖条纹的)的模糊效果非常差,即使两次 Box blur 出来的效果也还是差强人意。自行实现模糊的另一个要命的问题是内存。例如  StackOverflow 的这个 FastBlur 答案 (很多讲模糊文章都引用了这个答案),虽然速度上还不错,但是内存消耗的实在是有点粗放,只适合做小图片处理。 据说 API 17 以上 Android 提供了 RenderScript 来可以利用 GPU 做模糊计算。去年底的时候我参考 这篇 折腾过,不过没成功。一是 API 17 这个门槛实在是高(貌似通过 android-support-v8 也可以,但也非常折腾),二是 RenderScript 调试起来实在困难。总之 RenderScript 这条路我没走通。前阵子 又有一篇文章 带了示例代码,有兴趣的同学可以继续尝试。需要注意的是像这种高大上的解决方案,兼容性有待验证(Android 设备的又一个命门)

Android 应用卸载监控的实现方法

不再主业折腾 Android 了,这段时间会陆续把之前折腾过的东西记录一下,免得日后忘记。 对于产品经理和运营来说,知道哪个用户,什么时候,为什么会卸载你的 app 可能是很重要的事。虽然我觉得挺扯蛋——看看国内那些应用在卸载时弹出的页面,可选原因 12345,列的比用户想的都全面周到——这分明就是在说,我也知道自己干了很多坏事让你们不爽,可我干的坏事是如此之多以至于我实在弄不清你们的底线在哪里。 好吧,在我朝可以有理想,但是不能太理想主义。所以本文只从技术角度讨论一些实现细节。 首先来看 这篇文章 ,基本勾勒出了实现卸载监控所需的技术框架。这篇文章有以下几个关键字: JNI Android 应用被卸载之前,其运行实例就会被停止掉。因此必须要有代码能够脱离应用的生命周期管理。这个入口就是 JNI。进入 c 的世界,想象空间完全不是 Android API 可以比拟。 fork 对于卸载监控这个需求来说,JNI 是入口,为的就是进入 fork 这一环。fork 本身是比 Java 更为历史悠久的系统调用,在这里负责生成监控进程,是整个逻辑中非常关键的一环。至少要把 fork 示例的执行逻辑 搞懂(系统补习的话当然是建议读 APUE 相关章节,后面 exec 也会用到)。 inotify Linux 特有的文件监控 api, IBM 这篇 介绍的很好。 UserSerial 这个是 Android 4.2+ 引入的安全机制,原文说的很清楚,这里不再赘述。 但是这篇文章的实现方案两个明显不足: fork 出来的进程仍旧是一个带着 dalvik 的庞大进程(内存 20MiB+) 通过进程父子关系较容易找到卸载监控进程 所以,针对上述不足,可以继续改良实现方案: exec 将 inotify 部分的逻辑抽离到独立的可执行文件中,fork 出来的监控进程,可以通过 exec 这个独立的可执行文件来将自己变成一个非常轻量级的监控进程(内存占用只有 KiB 级别),同时也可以通过参数将伪装自己的进程名字。其实 fork + exec 的组合在传统的 unix 多进程编程中非常常见。 两次 fork 为了断绝父子进程关系,可以通过两次 fork 的技巧。主进程 A 通过 JNI 调用,进行第一次 fork,其父进程 A 继续运行

风光月霁

就在刚刚,部门赶在财年结束前达成了关键业务指标。来往群里大家喜悦之情溢于言表。我也很欣慰。 毕竟这是动荡了几乎整整一年以来,难得令人愉悦的瞬间。这段时间以来,战略调整,项目更迭,拥抱各种变化。带领一个并无甚 android 开发经验的团队在湍流中站稳脚跟并形成战斗力,颇为不易。 此刻,前路空前明朗,团队欣欣向荣。对上对下,再无牵挂和遗憾,该是我可以抽身的时候了。 感谢团队的伙伴们。你们很优秀。送别的礼物我很喜欢。