最重要的写前面:
手头有 RT3070 芯片的卡的同学注意了. 专门为 Beini 1.0 Final 编译的 monitor & injection 可用的核心和 initrd 都在这里.
用 aireplay-ng -9 看起来还凑合, 只是能发出去的级别, 离破解什么的还有点远.
另外, 信号强度显示不准确好像是 ralink 驱动的通病.

http://rapidshare.com/files/356473864/rt3070-beinitest.tgz

md5sum: 31345f5603c752b8d06aee668e58c75e

下载解压并覆盖原文件即可, rt3070-config 文件给会编译的会员参考使用.

本人不对是否能够启动或网卡是否能工作做任何保证.

compat-wireless-20100331.tbz2
source from git://prahal.homelinux.net/git/rt2×00.git branch rtt3070v2-next-debug.
Special Thanks to Alban Browaeys & Benoit Papillault.

Newer patches are available in patchwork.kernel.org & branch rtt3070v3-next-debug, which are currently not applied.

–

编译核心.

现代的核心可以把所有的硬盘都模拟成 scsi / sata. ata 的驱动已经不做为推荐了.
去掉那些没用的东西, 搞了好半天. 当然最简单的方法就是对照 make modules_install 的列表去删除.
“/” 键是你在 make menuconfig 时最好的伙伴.

–

kernel 和 git.
kernel 开发有主线和支线.
主线: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
各种支线存在的目的是对不稳定的代码进行开发和测试, 满足一定条件后方可进入主线, 主线中的代码能够得到较好的维护, 关注者比较多.
这个页面讲的就很清楚. http://linuxwireless.org/en/developers/process

这次用的是直接开发者的 git.
(实际上太慢, 别用这个命令)
git clone git://git.popipo.fr/home/benoit/rt2x00.git

推荐的做法, 唯一的缺点是需要两份存储空间.
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git clone --reference linux-2.6 git://git.popipo.fr/home/benoit/rt2x00.git

然后 git checkout rt3070v2-next 即可.
(另一个 Git Repo: http://git.prahal.homelinux.net/?p=rt2×00.git;a=summary)

–

initramfs 问题 (请用 root 用户以免损坏设备文件)
解压:
zcat ../tinycore.gz | cpio -i
重新压缩:
find . | cpio --quiet -H newc -o | gzip -9 -n > ../tinycore.gz

又过了一年, 在偶不需要 Reco 和 Reader 的时候, 把它们的设计与实现过程公开一下.

Reco 是一个基于内容的 delicious 条目推荐系统.
Reader 是一个定制阅读器, 为 iphone / ipod touch 做了优化, 与 Reco 紧密联系. 有阅读/标记 Reco 条目和 RSS, Json 供稿源的能力.

Reco Changelog:
2008.2.7: 1.0, 使用 3000 多个已收藏条目进行训练, 基本推荐功能(link, tags, score), 只依赖内容的推荐.
2008.3.6: 1.05, 推荐排重, 并有重复次数显示, 条目最多只推荐两次(数据基础建立).
2008.4.4: 1.07, 不再抓取 rss, 改用 subscription.
2008.4.19: 1.1, 历史记录.
2008.4.20: 1.2, 统计功能, 界面定形(此后除了统计项目的小幅改动外, 没有任何变化).
2008.7.31: 1.5, delicious.com 上线, 抓取方式更新.
2008.10.11: 2.0, 存储重构, 使用 sqlite2 作为数据库, 弃用 subscription. (1.5 更新引入的 bug)
之后发生的事情对推荐没有太大影响, 也没有突出的新版本.

从这个 Changelog 上可以看出, 偶最初使用 Delicious 的 subscription 作为条目来源.
关于网页内容抽取的问题已经公开. 正文内容判定方面偶不想说.

关于 Tags 的评分:
可以参考贝叶斯垃圾邮件过滤器的实现. 说白了就是朴素贝叶斯.
但这里先验概率的计算方面, 因为条目数量有限所以用了一个函数做了处理.
函数 f(x, y), x 是 Tag 中所含的总条目数, y 是该 Tag 条目通过次数. 显然 x 大于等于 y.
x 越小, 函数值越接近 0.5, 其中 f(0,0) = 0.5.
x 越大, 则函数值越接近于 y / x, 但设计中函数的值域并非是 0 到 1, 以免过度影响结果,
Tags 的评分经常会碰到特殊情况, 如 Tags 过少/过多, Spam 等情况. 这个问题碰见的时候有一点点数学知识就能解决.

此外每个 Tag 还对应有修正值和限定值.
修正值一般在 0.4-0.6 之间, 默认是 0.5(对概率无影响), 用于临时提高某 Tag 权值用. 限定值与上面的函数值域有关.

对网页内容做分析, 形成一个概率数值作为初始值.
阀值因人而异, 因情况而异. 确定一个阀值之后对照训练判断即可.

关于数据的收集:
2 pass 的方法. 看到条目两遍而不收藏就判定为反例. 具体的实现不详述.

关于推荐成功率:
一段时间内的推荐成功率 = 一段时间的收藏数 / 一段时间推荐的条目数(判重后)
不要期待超过 20% 的成功率.

Reco 亮点总结:
概率方法计算, 容易微调. 对所有(新来的)条目概率做计算, 好的留下坏的靠边. 直奔目标, 不走协同推荐的弯路. 单纯的协同推荐不会知道偶需要的是什么.

缺点:
计算量大.
输出量大. (虽然是可调的, 但从启用到得到满意结果需要较长的过程)

之前的讨论文章:
delicious.com 10,000 items & introducing Reco.
delicious.com 10,000 items(2): fcicq 的收藏守则
最近的 Collaborative Filtering 实践结果.
谈谈 SPEAR 算法.

–

Reader Changelog:
在话说阅读器系列(共 5 篇)中有涉及. 以下时间不一定准确.
2009.2.25: 从抄鲜果 iphone 版页面开始. 只留下有用的 div.
2009.2.27: 1.0, 话说阅读器 和 话说阅读器 (2) 中有说明.
此时的 Reader v1.0 是基于 sqlite 数据库的阅读器, 阅读结果直接反馈入数据库.
2009.3.8: 2.0, 可参见豆瓣相册 和 话说阅读器 (4).
Reader v2.0 只读入 json (Reco 的输出已调整为 json 格式, RSS 可转换为 json 读入), 输出 json 配置文件. 运行速度明显加快.
2009.3.xx: 2.1, 完成 Filter 项目. 小的细节修正.
Filter 项目读入 Reco 的输出和 Reader 的配置文件, 负责判重并将 Reader 的推荐数据反馈给 Reco, Reco 不再负责判重任务.
从此 Reco, Filter, Reader 各司其职, 有些 Unix 味道.
2009.6: 停用 Reader.
2009.11: 结束整个推荐系统的使命.

Reader 亮点总结:
解决阅读问题.
数据收集快速准确(只记录收藏标记情况和当前阅读位置, 有撤销功能).
适合 iphone 平台, 页面干净简单, 加载速度快, 点击区域大, 误操作少.

缺点:
功能少, 除了与 Reco 结合之外其它方面没有跟上.

举个例子做开头.

twitter 最重要的功能是什么? 最重要的当然是把那一句话输上, 提交.
m.twitter.com 就是最小功能的 twitter, 就连 dabr 的功能都比它多.
偶没有去试用新出的这些国产微博, 它们在只支持 wap 手机上的表现如何偶也不知道.
如果有机会的话, 可以比较一下桌面完整版产品和手机/移动版有什么区别.

把这个步骤反过来看一看. 在产品上做加法加法加法, 把功能做上了,
但移动版就从设备上限制了页面的无限扩张. 从信息架构等一系列方面都是挑战.

能够在移动版产品中留下的特性都是能够经受住考验的.

–

针对 MobileSafari 做过优化的网页已经有不少了.
iphone / ipod touch / ipad 的触摸屏体验确实非常好,
良好的 css 和 javascript 支持, 开发也比较轻松.
Android 略差一点, 但相对也还不错.

不过要问了, WinCE 上效果如何? 某些定制浏览器又如何?
实际上这个和可访问性 (Accessibility) 也有关联.
在这方面做的好, 那么兼容性也会好. WAP 不涉及这个问题.

当然了, 后做移动版也会发现很多以前不会注意到的问题.
做桌面版和移动版都是技术活, 哪个都不轻松.
迷迷糊糊的做哪一个都是不行的.

–

试试看, 做一次这样的实验, 先做出移动版, 再做桌面版.
偶是这种方式的受益者, 只是不想继续说下去了.
炒个冷饭, 把原来没说的说出来.

老读者可能知道有一个 reco 项目.
过些时间会考虑把里面更深的细节公开一下.

ps:
半年多之前的一篇文章. 因为这一篇的发布, 它离开了最近 20 篇.
Google.cn, 请离开中国大陆, 让 Google.com 成为真正的资讯窗口.

当时发表的时候有人笑话偶, 为啥写这些无聊的玩意.

ps2:
偶的解答系列为啥停了?
现在很多人都已经认识 NoSQL, 对 key-value 数据库有了更深的认识. 以偶的旧观念障碍你获得新知, 这是偶不愿意看到的事情.