Pidgin 的回归?

从前啥IM都用 Pidgin 挂着,包括MSN啦,GTalk啦,人人啦,QQ啦,…… 后来发现用 Pidgin挂的话总有些问题,比如人人的XMPP接口会自动发状态啦,QQ时常不能用啦,GTalk 变成 Hangouts 之后干脆要干掉XMPP啦,就渐渐不用 Pidgin了…… 最近天天看着那个工作得不是很靠谱的Telegram客户端 (Linux版在BSD跑当然不靠谱),再看看那个卡得不行的 Hangout 网页版,突然想到是不是 Pidgin 现在可以搞这些了,于是去看了眼…… 虽然 Pidgin 那个难产的3到现在还没出来,界面和从前一模一样 (这几年到底在干嘛……),支持各种协议的插件倒是都有了。 Telegram: telegram-purple https://github.com/majn/telegram-purple Hangouts: purple-hangouts https://bitbucket.org/EionRobb/purple-hangouts Facebook: purple-facebook https://github.com/dequis/purple-facebook 试了试看上去都还工作得不错,终于可以摆脱 Hangouts 那个卡卡的网页版了…… 这三个里面嘛,Telegram和Facebook Messenger的协议都是公开的,所以应该是可以很好支持的。Hangouts 应该是人们自己分析出来的,所以可能时不时需要更新一下。不管怎么说,至少现在都能用,图片啥的也能看见 (虽然Telegram的动画表情还不行……)。 至于 QQ 嘛,还是去 Windows 上挂着比较靠谱……

FreeBSD 的中文console

其实 FreeBSD 的 console 早就支持中文了,问题是默认没装中文字体,所以显示出来都是方块…… 系统提供了 vtfontcvt 工具,用来转换字体到系统需要的fnt格式。它吃俩格式,bdf和hex,我只认识bdf…… 于是尝试转换 wenquanyi 的位图字体。源文件是pcf的,先要找个东西转换成bdf,姑且在github找了个: https://github.com/ganaware/pcf2bdf (刚看了眼原来有port,当初搜pcftobdf没搜到……) 转完之后用vtfontcvt,冒出来了各种错误。先是说字符宽度不支持。 打开文件一看,这货好像对字体有很多假设,比如所有字符宽度不是目标宽度的2倍就是和目标一样(等宽字体?)。 wenquanyi 里面虽然中文都是一样的,但是其他英文什么的有各种宽度,比如10pt的字体,pixel宽度有2-13不等…… 于是先修vtfontcvt才行。这个vtfontcvt问题还真不少…… 除了前面那个假设之外,他还假设每个字符都和目标一样高,是不是写的时候连bdf格式描述都没读过,拿个样例文件就开搞了…… 他还忽略了字符的偏移位置…… 修完的vtfontcvt干了这么几个事情: × 读取FONTBOUNDINGBOX信息,了解全局的基线位置 × 读取字符的BBX信息,这个包括了这个字符多大和应该放哪儿 × 干掉了那个宽度假设。当然,太宽还是不行的…… 打算提交这个修改的时候,发现有个PR已经管了一部分问题: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205707 但是这个PR修的东西略少,也没管位置偏移之类的问题,于是还是把我修的版本交了上去(一开始还弄错一个版本……)。 之后在这个PR和我的patch的基础上又搞了搞,于是支持多字体叠起来了(wenquanyi的英文太丑了,还不等宽……)。 完整版patch:http://www.henryhu.net/vtfontcvt_full.patch 最后转了个Terminus+wenquanyi的字体出来,用vidcontrol -f弄进去,现在控制台终于可以原生显示中文啦! 转完的字体(Terminus 14pt + wenquanyi 10pt): http://www.henryhu.net/ter-wqy-8×14.fnt

Nexus 7 鼓起来了……

我其实还是挺喜欢平板的,买过若干个。其中Nexus 7 2013在淘汰下来之后,就一直扔在桌子上当动态相框使。(不过Nexus 7 2013依旧是最好的7寸平板之一……) 上两天想调整一下角度,一摸发现形状好像不太对…… 拿过来一看,居然鼓起来了…… 一般来说嘛,鼓起来还是因为电池时间长了内部有气体。我扔到冰箱去冻了一个晚上,倒是缩回去了,但是过一会又鼓起来了…… 于是只能拆了。网上说拆起来还挺容易,实际上我拿信用卡划了半天才划开来,还弄坏了背壳上十几个扣子中的四个…… 基本上就是拿信用卡插到前后壳的缝然后一路划,但是更好的办法是用靠谱的工具来开,我懒得搞…… 里面基本上是这个样子: 很明显电池鼓起来了,亏他没把上面那两条线给弄断…… 电池倒是好拆,把两条线从插座拔出来之后,拧掉几个螺丝就好了: 拆下来的电池,最后的地方大概有2.5倍原来的厚度。摸了摸就是一些气体,还没绷得很紧,可以按下去…… 虽然我想过戳个洞把气放掉是吧…… 但是听说好像挺危险的,于是直接买了个新(?)电池,ebay上很多,只要$15…… 不过多半也是山寨的或者老的。 于是今天电池寄过来了,还挺快的…… 这个新电池一看就很山寨,型号都不一样…… 不过形状倒是很正常。螺丝孔都有用过的痕迹,多半是哪儿拆下来的…… 换上去倒是很顺利,开了之后看了下,居然基本还是充满电的。容量比原来的貌似小了不少,不过倒是不影响我的用途,我反正就放着当相框,从来不拔电源…… 新的设备好像都越来越难拆了,估计以后再胖听就直接扔掉了吧……

Streaming Music的方法

最近之前买的虾米会员过期了,忘了续了…… 于是看了眼目前可用的几种方案…… 虾米 买了会员国外才能用,不过会员很便宜,有不靠谱的自己写的客户端,速度有时候不太行。 也有些歌下架了。会员一个月可以下100首。好像没有无损来着。 网易 一样买了会员才能用。只有Linux客户端,BSD下面只能跑网页版,Wine出来的有点问题。速度也是有时候不行。 有些歌下架了,其中某些可以靠黑科技下下来,某些就不行。买了会员一个月可以下300首。号称很多歌有无损。 Spotify 不付钱有广告,有不少想听的东西找不到。好像有Linux客户端来着,据说Wine出来的客户端也还行,当然也有网页版。速度没有问题。 Google Music 不付钱没法搜,只有电台。很多歌没有。没有PC客户端只有网页版,网页版还有傻逼DRM…… Apple Music 反正也要付钱来着?一样也是缺东西,PC客户端就不要想了……   所以总的来说都很糟糕。其他还有QQ音乐啦酷狗啦酷我啦之类的,酷我这种好像就没有版权下架的情况…… 目前暂时用的是曲线救国的路径,先从网易那边下下来,然后利用Google提供的云存储传上去,再用手机streaming…… 但是Google没有客户端,网页依赖DRM,所以BSD上还是没法用…… 考虑把Google提供的云存储换成自己的云存储,自己架一个服务器然后用符合标准的客户端听…… 不过VPS肯定不行,存储太小,只能用NAS或者在自己家里弄个服务器再搞个动态域名之类的了……

关于监控系统

事情的起因是实验室的一台服务器重启之后起不来了,看了一下发现有快硬盘坏了。 顺便看了一下,另一块也差不多了。 按理说这种事情都有监控脚本盯着,本不该发生的。 结果跑去监控的机子上一看,原来那个机子的邮件系统坏了6个月了…… 邮件系统坏掉的原因是Arch某次升级的时候貌似postfix要手动干点事情,否则就起不来。 所以光有监控系统是不够的,还需要 a. 监控监控系统的系统,这样下去貌似没完…… b. 在正常工作的时候也报告一把,这样挂了就能知道。 但是天天收到正常报告也会烦,如果都从收件箱过滤掉,那就没意义了…… 所以好像也没啥好办法…… PS. 邮件队列里堆了94万封邮件…… 上次跑实验跑出来的,幸好没发出去……

又换了一家VPS提供商……

一开始是PhotonVPS,后来是linode,接着Amazon EC2,现在跑到了DigitalOcean…… 换linode因为PhotonVPS时常网络不好偶尔还重启,换EC2因为linode只有PV的虚拟机而FreeBSD一直不支持64位的PV,换DigitalOcean因为它终于支持FreeBSD了并且便宜性能好还有GitHub的100刀优惠…… 搬家倒是挺方便,把数据库、网页、配置打包拷过去就完了…… 这回能呆久一些就好了…… 毕竟搬家还是要费一些功夫的……

关于一堆可疑的SNMP包

很久以前,我系的CRF(管理计算机资源的)来找过我,说我机子被黑了。我观察之后没啥症状,就问他们为啥那么说。 他们拿出来一个单子,说你机子往外发可疑的包,只有被黑了才发这种包。 我看了一眼,貌似我的机子在广播SNMP包。我觉得这事情也不是那么奇怪,毕竟一堆程序依赖snmp库,但是他们觉得有问题。 于是我在防火墙加了个规则,说如果有这种包就记录一下并且扔掉。其他还干了很多事情,例如换私钥之类,总之很麻烦。之后,他们就不来找我了…… 系统里的确偶尔会记录下这种包的发送记录。那时候尝试看了一眼,没看出为啥,也就没有管。 过了很久之后,一天我看着这些记录,觉得很烦躁,想着干脆研究清楚为啥会发这些破包。 首先,那些个记录里记录了发包者的UID。在我的机子上,记录的UID是colord的UID。 colord是啥呢?可以参见http://www.freedesktop.org/software/colord/intro.html。基本上是个管理色彩配置的东西,如果你不是特别关心你颜色显示得是否准确,其实有没有都无所谓。 colord发SNMP包还是很难让人理解。ldd看一眼,发现colord并没有链接libnetsnmp,net-snmp也不是他的依赖。 观察一下colord的依赖,其他貌似都挺无辜,但是有个可选依赖是sane。我机子上恰好也装了sane。 sane是啥呢?参见http://www.sane-project.org/,Scanner Access Now Easy(这Now是硬插进去的吧!),是个管扫描仪的东西。 sane倒是依赖net-snmp,所以多半是它干的好事。 之后把colord和sane代码扒下来看一眼,大概知道是怎么回事情了。 说colord有个sane插件,嘛大概扫描仪也需要色彩配置。这个插件会启动一个叫colord-sane的程序,这个程序链接到了libsane。sane有个插件叫magicolor,管理Konika Minolta的一个系列的扫描仪。 colord因为某些原因要更新设备列表,于是调进那个插件。插件启动colord-sane,导致sane也让他的插件们更新设备列表。那个magicolor系列扫描仪估计比较高级,能够联网。magicolor插件更新设备列表就去群发SNMP包,在本地网上找这个扫描仪。这个包被CRF看见了…… 其实也怪那个SNMP请求范围太广。他发的SNMP包基本上就是让本地所有的SNMP设备向他报告自己是啥设备,有啥功能之类。这看上去当然挺危险…… 最后说这个过程是怎么触发的。在开始打记录之后,我发现当我插拔手机/平板的时候,那个记录会一起出现。这种事情很容易联想到UDEV,sane和colord其实都装了UDEV规则,而这里引起问题的是colord的规则。那个规则说,只要USB设备插入/拔出,并且有gphoto支持,就给colord发个通知。Android的手机/平板当然在这个范围,于是引发了一系列事件,最后SNMP包就发出去了…… 总体现象是你插拔手机会发SNMP包,谁知道里面有这么一个过程…… 如果有个工具,能够告诉他触发条件和结果,问他中间的因果关系,倒是会方便不少。好像也不是搞不出来,不过貌似没啥学术价值……