关于SSD，一般容量越大速度越快，因为一般来说大容量相当于同等型号小容量的raid0组成。如果你是双硬盘，64G应该是够用的，只是如果128G的话，普遍快一点，而且可以基本上不靠第二块硬盘，这个基本上mac和win7都受用。
关于mem，如果是mac，如果要开发比较大的东西，或者设计类，尤其是虚拟机，那么不用考虑，必须上8G，否则4G自己得考虑一下，如果没有大型应用lion是基本上够得。
如果是win7，如果不用重型ide开发，不虚拟第二个win7或者同等消耗的os（只虚拟xp或者同等消耗的os），不玩近期出的大型游戏，不用大型设计类软件，4G肯定是够用了（和mac的条件差不多，只不过这样的条件下lion的话是4G基本够用，win7是2G就基本够用）。
综上，ssd如果经济允许，最好直接100G或以上。mem，如果不用重型ide，大型设计软件，大型游戏，尤其尤其是虚拟机的情况下，4G lion基本够，win7已经有多了，都可以考虑memdisk了。以上是我自己的经验。

@flypen 这个不是map reduce么？

@yibie wine嘛。
LZ直接wine一个notepad.exe不错哦，很满足需求吧。
呵呵呵

于是觉得github真是一个好地方，自己做任何coding之前，最好先search一下，如果满足就用，不完全满足就fork一个然后加加或者改改。

正常，等你觉得一个想法不错然后付诸实践之后，才发现已经有完善的实现好的版本，而且比你自己想的还周到，然后就郁闷了。waste of time。
如果发现有一点点不满足自己的需求，于是很纠结，是改呢还是改呢还是⋯⋯

@zythum 4G内存也好意思路过。

不过chrome在大量tab的情况下，本来就有些不太稳定的感觉。

用chrome就不要怕占内存，呵呵

这个userscript是chrome only的。

还有我的ajax-submit userscript，整合ctrl+enter回复功能
UserScript： http://github.com/yyfearth/yyfearth-chrome-repo/raw/master/userscripts/v2ex-ajax-submit.user.js

@cvforl 是不是最好还要3D全息的

@iray1991 你应该问@xhacker
这个字典目前中文基于dict.cn，英文基于google dict
以前因为google dict有中英文例句很好，而且这个排版很舒服，用的很多
现在我用mac字典的dict多了，因为方便，而且google dict已经关闭了。

早该这样了

这个是很早的版本，记得小学玩过，现在还记得那些关卡

还不错，可惜只有第一关，东西太少

还是喜欢sublime2

@Hyperion 一次性salt，不管再怎么长，如果泄露出来的话，只要针对性的建立一次彩虹表，就ok了。当然，不泄露的话，salt长点问题也不大。
对于salt的时候，分2个情况，一个是存储密码的时候，一个是校验密码的时候。2个时候可以采用不同的策略。

@rfwert343 其实我完全可以理解这种东西出来的意义。因为在国内，我们已经无法使用emule，bt，只能依靠迅雷离线这种东西，所以大部分人用这个完全就是为了搜一个emule地址，然后去迅雷离线碰运气。所以，只要有人做出可以“没有限制，尽可能多”的搜出emule地址的emule客户端就很有市场了。
所有迅雷离线的资源几乎永久保存在迅雷服务器里面，但是无法通过查询得到（由于法律限制），其他人只要通过bt种子、emule地址就可以下载到。
迅雷只要通过用户共享，就可以得到其用户通过迅雷或者其他软件下载来的新资源，并上传服务器。
“制作种子功能的迅雷就只能下载到http和ftp资源”，绝对不止的，迅雷有共享的功能，他和bt emule不一样，几乎是强制共享，除非关掉p2p功能（也不能保证没有上传）。

@hq5261984 随机的salt可以分开或者合并保存。而且仅仅在数据库的时候使用。
比如 hash=sha(password+salt)+salt,在验证的时候，则要把这个salt取出来，进行校验。
这样，即使db被盗，彩虹表也没有用，只能针对某个用户单独建表就划不来了。
用username可以作为这个salt的一部分，不过由于username长度不是很长，而且不够随机，而且在db没有泄露的时候就已经已知了。
如果是客户端hash，就不能随机salt，除非吧salt也传过去（可以用timestamp，然后校验2者）
服务器端用于持久化，就可以考虑加入随机salt，可以吧这个salt存为一独立字段，或者像上面一样，合并在一起。