HeartOutside

not yet

OS X Font Trouble

苦于电影字幕显示异常,进而发现问题时由于字体导致的,在 FontBook 中能看到某些字缺失。

很多关键字体,如 AppleMyungjo,AppleGothic, Hiragino Kaku,Hiragino Mincho 系列基本都有问题。OS X 也未提供方法改变系统字体,工具软件如 TinkerTool 等也没有能改变中文字体的工具。

粗暴一些的做法,直接覆盖

1
sudo cp a-true-type.ttf /System/Library/Fonts/AppleGothic.ttf

就能解决问题。

推荐在号称对字体美感出名的 Apple 系统里安装 Microsoft YaHei Version 6.01 字体。

也推荐 tcfail 的解决方案。

English Version:

How to change OS X Chinese system font?

  • Use FontBook find out which font ruin the Chinese word.

  • Copy a normal True Type Font file to replace it, like:

1
sudo cp a-true-type.ttf /System/Library/Fonts/AppleGothic.ttf

Nexus Update 4.0.4(IMM761)

我没有参考什么攻略,直接看Google Nexus Images的文档, 然后下载 yakju

然后解开压缩包

1
tar zxf yakju-imm76i-factory-8001e72f.tgz

然后执行

1
2
cd yakju-imm76i
sudo ./flash-base.sh

最后

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
yakju-imm76i $ sudo fastboot -w update image-yakju-imm76i.zip
archive does not contain 'boot.sig'
archive does not contain 'recovery.sig'
archive does not contain 'system.sig'
--------------------------------------------
Bootloader Version...: PRIMELA03
Baseband Version.....: I9250XXLA2
Serial Number........: 0--------------2
--------------------------------------------
checking product... OKAY
checking version-bootloader... OKAY
checking version-baseband... OKAY
sending 'boot' (4148 KB)... OKAY
writing 'boot'... OKAY
sending 'recovery' (4478 KB)... OKAY
writing 'recovery'... OKAY
sending 'system' (316111 KB)... OKAY
writing 'system'... OKAY
erasing 'userdata'... OKAY
erasing 'cache'... OKAY

系统重新启动,成功

公司内部代码协作

公司内部,团队间不可避免的有代码互相访问的事情发生。

普通方式

提供者提供头文件和库供调用者实施访问,这是比较常见的方式。当然库有可能是静态库,动态库。

静态库要求双方编译环境,运行环境一致,否则就得提供多种环境的库文件。动态库要求稍微弱一些而已。

很多人会把别人的头文件进行封装,美其名曰为了屏蔽变化,虽说封装开销微乎其微,但是我尤其讨厌这么做。 这种事情甚至会出现在一个团队内的两个人间,一般这两人可能是独立设计。这是缺乏信任、沟通的结果。

如果只提供二进制,看不到代码,又不是经济方面的原因,那么这种公司可以离开了。

如果出现数次使用邮件、聊天软件传文件等方式交流代码,也无力改变,这种公司也可以考虑离开。

远程调用

提供者可以只提供 IDL 文件。 取决于远程调用的使用、部署方式等。工程间的依赖、接口的变更这都是需要解决的问题。

也可以进一步提供封装过服务发现、调用方式、错误处理等后的库。问题就和普通方式一致了。

直接使用

要求大家的代码在一颗代码树下,代码间能互相调用,工程间能引用。

假想公司内有个独立的防止 Spam 的小组,业务部门 Blog 需要使用他们的代码。

spam/check.h
1
2
3
4
5
6
7
#ifndef SPAM_CHECK_H__

namespace spam {

bool Check(const char* text);

}

该工程产生 libcheck.a

blog/publish.cc
1
2
3
4
5
6
7
8
#include "spam/check.h"

void Post(...) {
  if (spam::Check(text))
    return false;

  // ...
}

调用方的工程文件需要声明

blog/blog.gyp
1
  'dependencies' : ['spam.gyp:check'],

gyp 为工程文件,最终生成 Makefile

Blog 编译时自动加入 -lcheck,一般静态链接发布。能如此做是有很多先决条件的:

  • 公司内一颗代码树,至少都拥有可读权限

  • 每个团队间的代码不能互相影响,需要每个团队都得采用分支开发,保证主线是稳定,可发布版本

  • 信息是开放的,每个团队的代码的变更其他团队应该能知道

  • 公司内部有统一的良好的沟通工具,如 IRC, 邮件列表等

还有其他规范,如

  • 统一的代码风格

  • 目录规则、namespace 规则、冲突解决等。

如果是远程调用,大致可以拆解为:服务发现、调用包装、错误处理等子项,每个子项也可以同理解决。

很多公司把代码的权限管理得相当不错,虽然我也能遵守,但是通常呢?

有能力的人不太在乎那些个代码,没有能力的呢?通常可能都玩不转那些个代码
连Google都是内部开放代码,有什么理由制造层层障碍。这种公司也不值得留下。

限制创造力的规则。

High Power Smartphone

收集了最近能找到的电池容量超过1500mAh的智能机的信息,列表如下。

battery(mAh) price(RMB Yuan)
三星GALAXY SII 1650 2750
索尼LT26i 1750 3600
联想乐Phone K2 1760 2999
摩托罗拉XT910 1780 3199
HTC One X 1800 3950
LGOptimus LTE 1830 2750
华为U8860 1930 1899
小米M1 1930 2430
摩托罗拉XT910 MAXX 3300 4290
三星GALAXY Note I9220 2500 4299
酷派D539 2500 925
华为S8600 2000 1798
天语W800 2000 2980
联想乐Phone P70 2000 989

Mawk and Gawk

今天发现 Debian 里的 awk 是 mawk,过程是发现一台机器上的 awk 执行报错

1
 awk: line 2: function strftime never defined

然后发现此 awk 原来是 mawk

Debian 可能有足够的原因:

mawk is a very fast AWK implementation by Mike Brennan based on a byte code interpreter.

引入 mawk 代替gawk,但是由于这两个版本的细微差别,肯定会困扰一些人。

还有一个类似的例子是 dash, 无数次以为脚本写错后,才把习惯改为 !/bin/bash。

竞争固然是好,这些批着同一件皮的东西有着这样、那样的差别,会让每个人都经历一次或多次查错的经验。

WTF!

Trivial Detail in Facebook Messenger

I download facebook messenger from here. After install I found something interest.

First it’s a C++ managed CLR program. I think running on Win8 is their main purpose.

Then I noticed it use a several open source library almost all from Google.

about certification signing:

  • FacebookMessenger.exe not signed.
  • FacebookUpdate.exe signed.
  • FacebookCrashHandler.exe signed.

Sadly, I never saw the interface, because it(verion 2.0.4373.0) keep quit abnormally on my winxp. facebook main window preview

Whatever, it’s absolutely above average in Windows application technology.

密码泄漏事件下的冰山

曝光在大众面前的 CSDN 密码泄漏事件只是冰山一角,很小的一角。 如开始时间,其实攻击从2011年就开始了,下载文件里的日期一般不会做假: - 2011-01-31 22:46 100W.txt - 2011-03-08 20:49 duowan_user.txt - 2011-10-16 01:02 www.csdn.net.sql

至这些密码泄漏开始,利用这些数据获取其他价值的的攻击行为从来就没有停止过,差不多同时就听闻各大网站被攻击。至 CSDN 事件曝光这是很长的一段时间,但是各大公司都选择了沉默应对攻击。

对历次泄漏数据汇总后,共计有 24249858 个合法邮件地址

24249858 total
10874262 qq.com
 5811878 163.com
 2362741 126.com
 1259566 sina.com
  780195 yahoo.com.cn
  644629 hotmail.com
  474650 sohu.com
  301836 yahoo.cn
  284507 tom.com
  195086 21cn.com
  193720 gmail.com
  165742 vip.qq.com
  161241 yahoo.com
   93434 yeah.net
   88933 eyou.com
   79438 sina.com.cn
   64147 139.com
   61092 yahoo.com.tw
   46959 msn.com
   42924 163.net
   40649 live.cn
   26327 263.net
   26000 foxmail.com
   24563 yahoo.com.hk
   18414 vip.sina.com
   17923 sina.cn
   16093 sogou.com
   15333 citiz.net
   13412 mail.china.com
   11049 chinaren.com
    8239 etang.com
    7201 189.cn
    6759 live.com
    5731 vip.163.com
    5324 china.com
    3993 msn.cn
    3480 2008.sina.com
    2251 371.net
    1648 yahoo.co.jp
    1603 netease.com
    1389 elong.com
    1132 mail.ustc.edu.cn
     820 sjtu.edu.cn
     645 x263.net
     564 zte.com.cn
     526 hotmail.com.tw
     522 neusoft.com
     453 bjtu.edu.cn
     406 huawei.com
     202 bofthew.com
     149 owlpic.com
      78 uggsrock.com

邮件服务提供商似乎没有太多作为,Gmail 提示不要使用相同密码,我使用的国内的邮件服务商(qq,163)没有类似举动。

各个邮件服务提供商都没有表现出应有的社会责任,未及时告知用户安全问题,导致整个中国互联网集体容颜扫地。

在表现上,各邮件服务提供商反应也不尽相同。 * QQ 每个登录都有验证码 * 163 貌似没有采取什么措施,截至12月22日还能用其中信息登录他人账户成功

不管如何,这次事件各互联网公司应对策略都有了长足的进步,验证码等技术得到了提升。

真正的冰山是利用这些信息的非法获利,各大互联网公司都有虚拟货币,甚至支付宝,有什么样的故事呢,我不得而知。

Question to a Startup Team

  1. 你得到的投资有多少?按计划能支撑多久?
  2. 技术人员的总股份有多少?
  3. 如果这个项目失败了会怎么样?

关键问题是第3个,鲜有第一个项目就成功的,做好失败的准备,整个团队继续努力,成功的机会更大。

Digest

  • Project Gutenberg DVD 里有404本中文书.
  • gcc 4.6 support -Ofast optimization level.
  • American Reunion 4 will arrive in 2012
  • Puppet Labs earn $8.5 million investment. #
  • 百度云 #
  • Upp 界面技术应该比QQ”蜂鸟”(Hummer)的界面技术更强一些
  • 在公司里揭疮疤,需要非凡的技巧,不然会成为众矢之的抑或埋下祸根;只有圣人能干这事。

Nc and Tar Play Nice Then

Convenience transfer file with nc, just like:
receiver:

1
 nc -l -p 2000 > filename

sender:

1
 cat filename | nc 192.168.1.1 2000

It is working fine for single file.

Tar archiving also convenience too.
pack:

1
 tar c .

extract:

1
 tar x

Combine them together, seem not work fine.
receiver

1
 nc -l -p 2000 | tar x

sender

1
 tar c .  | nc 192.168.1.1 2000

I think the reason is tar result is block by block, and there is nothing mean EOF, so tar x never know when to close the pipe.

I also found #1 use cpio, tar - even not work fine. I tried rsync -e, either not work.

A geek nearby provide a solution: tar -ix
in man tar:

1
2
-i, --ignore-zeros
             ignore blocks of zeros in archive (normally mean EOF)

It work perfect.
receiver

1
 nc -l -p 2000 | tar -ix

sender

1
 tar c .  | nc 192.168.1.1 2000

TODO: read source code of tar, find out what zero blocks really mean.

[1] http://ask.metafilter.com/133905/Why-did-tar-and-nc-not-play-nice