一点小建议：对不懂/不能掌控的事情要格外谨慎，外面看起来很美，实际不是那么回事。资金量小，就不要期望当甩手掌柜，别人给你赚钱的好事，你要想到无数个20万在竞争这种机会，你凭啥接下和保住天上掉下的馅饼，别人都傻了么？20万不是什么大钱，如果是赚钱的生意，根本不缺你那点钱，凭啥给你分块蛋糕。

越简单越好，如果不想冒险和亲自动手做事，就别想高回报，能和通胀跑平就算幸运了。

@Pactzhao @sNullp @csx163 很多人所谓的演讲，如果你不怀着功利心去听，根本听不下去，多见的是忽悠，根本不是什么演讲。一个人演讲，要能打动与他没有任何利益关系的人才能算成功。

我见过演讲失败最多的两种情况：1）太着迷于自己的想法，却不懂表达，无法让人认真倾听，更别提共鸣；2）太精于演讲技巧，急于取悦听众，最后毫无实质内容和新鲜观点，听过就忘。很多创业者，产品都不太可能出众到Google/Facebook那种程度，在意图获取投资时，往往由于无法表达出要点，而泯然众人。

@hpowen 理由：奥巴马很靠谱，基本上承诺过的都做到了。
2008年的承诺：http://www.youtube.com/watch?v=ato7BtisXzE
今年克林顿的总结：http://www.youtube.com/watch?v=uzDhk3BHi6Q
奥巴马是个干事情的，人们也许对现状失望和抱怨，但是做了对的事，相信会得到支持的。

竞选：奥巴马的演讲就不用放了，共和党没有对手，第一夫人演讲也极为出色，
加上克林顿的努力，人们不可能忽视奥巴马的努力，让共和党摘了桃子。
罗姆尼那个样子太不真诚 http://www.youtube.com/watch?v=ueDQIpcNEUA

美国经济正在发生变化，天然气和页岩气革新把基础能源价格降低到过去一半以下，石油对外依赖度大为降低，这就足以让各种制造业利润飙升了，房产价格又低，经济重启的大障碍基本已经消除。只要不再轻启战端，经济复苏时控制好开支，那么所谓国债，也不成问题，中国印钞比美国多十几倍，而且完全内部消化，也没见崩溃。

@vincent1q84 罗姆尼的智囊团肯定比奥巴马豪华多了，但show得如何呢。实际正好有部政治纪录片，拍上届Sarah Palin的 HBO Films: Game Change， 国内也有引进 《改变规则》，改变一个人是很难的，培训、出谋划策只能在细节上做点花头，无关大局。

同样是show，取悦谁当然是最重要的，不show时所做的事情，和show对照一下便知人品。我不喜欢阴谋论，政治很肮脏充满阴谋，但总有人在肮脏中做正确的事，做事都遵循一定规则成例，这就够了。
如果做事的人能在合适的位置，那就更没什么可指摘的了。

Great work. 在想以后Python可以直接Import Julia as a module，工程计算编程从此不再痛苦 :-)

一直想做个winpe+linux双系统急救启动U盘，里面定制些工具，看了些量产定制的介绍文章，感觉很复杂、很折腾 ~~~

品牌盘都没啥区别吧，常用大容量U盘，芯片和主控性能都雷同，追求性能搞个SSD吧。

@DeepBlue 哦，“请过假辞过职“还好点，那我说重了。不过一般请假最起码提前两三天，辞职要提前一个月吧，不管公司大小基本都这样，与业务急不急没关系，就算私事太急，事后解释一下，合理的原因，相信多数老板都能体谅，良好沟通本来就是双方的事。

@lovebirdegg
https以性能为代价，如果网站需要用户流量，大部分资源最好http;
vpn只能保护合理区隔后的内部资源供员工访问，对要提供给其他用户的资源无能为力；
纯内网资源最好和公网区分开，用不同的服务器，即便跨地区用VPN，也别图方便和Web服务器混在一块。

做物理隔离最简单，VPN次之，上公网后安全没有一劳永逸，有的搞。
以linux中debian/ubuntu为例，最基础的：

1. 系统内核参数，改/etc/sysctl.conf 跳转参数。
2. 端口只开放 ssh/http/https， 改ssh 端口到其它数字，并fail2ban，
条件许可时ssh用ip白名单、纯证书访问。
3. 服务器内各进程权限独立，特别是私有程序编译时，除了守护进程用root，其它全部降权。
4. 用户权限与文件夹权限：关闭root登陆，管理员另起sudo用户名，web文件夹755 文件644
各种配置文件640加服务器Deny Access Protection，多用户隔离。
5. 如果允许用户上传文件，取消一切执行权限，最好放在另一台media服务器。
6. Hot Links/Reverse Proxy偷流量好防，DDOS被盯上就要出血，穷人解法用varnish/load balancer稍微挡一下，总之得烧钱。

网站程序自身还要具备各种Validation, SSL加密敏感交互，特殊字符escape，防SQL注入和XSS机制。
Tomcat 和 Oracle具体防护又是另外话题了，感觉运维里面很大一部分成本被安全占了。

@skywinger @DeepBlue
制度建设绝对是个很深奥的东西，好的公司都有自己内部氛围或“文化”规范员工行为，绝对不允许散漫作风——尽管很多科技公司看起来对员工很“放任”，但那是建立在员工自觉“高产出”基础上的，不信你去Google混日子看看，能不能混下去。

媒体永远只会报道Google/Facebook之类大公司的豪华办公室、健身房、自由风气、遗属拿员工一半薪水，不报道他们在创业时有多苦逼，后期员工是从多少牛人中筛选出来的，每个人的工作效率有多高，为Google创造了多少产值。

我认为员工积极争劳动权益和更高待遇是对的，员工不是老板无需体谅什么创业难处，但如果把散漫作风、消极怠工当成“一分钱一分力”的敷衍借口，只能害人害己。再说，处理私人问题，是以伤害职业作风和他人信任为必要前提的吗？我不觉得，只能说还没长大，做事自私、随心所欲。

@dhysum 根据经验，GIT文件夹体积膨胀很快，打包速度很慢，并不适用于备份。

增量备份，基于git packfile的 https://github.com/apenwarr/bup 更适合，python写的.
采用 rolling checksum algorithm (similar to rsync) 分割大文件.
直接写packfile，避免git的repacking过程，速度更快.
支持ssh远程拷贝，增量备份，par2冗余备份，fuse访问等.
就是命令行很丑，文档太少。。。

Bup里面也提到： Unfortunately, git itself doesn't actually behave very well for bup's use case (huge numbers of files, files with huge sizes, retaining file permissions/ownership are important), so we mostly don't use git's code except for a few helper programs. For example, bup has its own git packfile writer written in python.

@feiandxs @eric_q @likuku @lanisle @Livid @rhwood

现在觉得 http://aws.amazon.com/rds/mysql/#features 之类的服务远比EC2吸引人，而且无法替代，Automated Backups (to any second), Multi-AZ Deployments, Read Replicas 这些企业级特性，自己很难做到同等性价比(特别是和Reserved Instance比)，算算时间和人力成本就要头晕了，Linode VPS ---> Amazaon AWS 或者 直接AWS 看来是最佳路径了，可靠性要求稍微高点，独服的性价比就不明显了，这里面的隐藏成本多高大概只有像@feiandxs 折腾后才清楚吧。

看了下阿里云的RDS，还有很长的路要走，跟自维护DB Server没拉开明显差距。

@feiandxs 嗯，有向aws迁移的打算。本来搞独立DB Server就是为了减少横向扩充服务器带来的维护成本，特别是人力。但从架构上看，网络延时问题尚无成熟解决方案，代价会更高，这里就是云计算的优势了。

这个需求倒是挺罕见的，如果不需要很精确，也不太麻烦吧：

1. 分析邮箱域名：http://tldextract.appspot.com/api/[email protected]
{"domain": "google", "subdomain": "", "tld": "co.uk"}

可用regex 或 类似 https://github.com/john-kurkowski/tldextract 这样的库(主要对五花八门的tld识别较好)提取Domain和TLD信息，根据TLD过滤只接受.com .com.xx .co.xx 等邮箱

2. 建立一份公司名称和品牌白名单或常见公共邮箱黑名单，用第1步里得到的域名进行关键词匹配，把.com邮箱再筛一下。

如果不严格限制在500强以内，我觉得黑名单要好搞些，世界上主流.com邮箱就那么十几家，什么gmail yahoo hotmail 之类，最多根据访客来源地添加些该国公共邮箱服务商，一过滤基本差不多了，只要不是twitter这样大客户量的服务肯定够了，少数漏网的手动更新列表加黑吧 x_x

有个叫 Christensen 的教授发现和总结了大公司的创新困境 The Innovator's Dilemma
http://en.wikipedia.org/wiki/Clayton_M._Christensen
http://en.wikipedia.org/wiki/Disruptive_innovation

作者所经历的，是每个大公司迟早都会发生的，包括Google这样的伟大公司。这是非常合理的，
如果大公司内部不僵化、不过度业绩导向，还会有创新型小公司的活路吗？

直接用Memcached Cluster，不用转成HTTP API，挺好的，就是1MB限制比较那个。

@ncesun 这个还真是够狠的歪招 :D，可是他们多半不会放在什么正经论坛上，根据Google最新打击盗版的政策，只会被拖累。

@ElmerZhang 传统Memcached缓存方式对纯动态网站确实没啥改善，可是最新Feature支持直接访问InnoDB，把Mysql当NoSQL用，等于@Livid所说的API，现在没有Benchmarking数据，但理论上，简单K-V省去SQL查询，复杂关系查询可并行SQL，缓存与数据库内生一致，都会大幅提高性能。

http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-with-memcached.html

用反向代理缓存页面，让APP和DB服务器处于相同Datacenter，只是避开问题并没有解决问题，我不清楚反代对动态网站性能有多少影响，但不觉得更有优势。