@crab 服务端不需要保留密钥，将密钥传递给接受端之后这个密钥就可以废弃了

gentoo 做服务器，有够拼的......
已经被 centos 惯坏。反正我认为 Linux 下各家都差不多，不过如果是做开发，不是要稳定运行的服务器，那么 Ubuntu 比较好，毕竟社区支持不是吹的

@lzhtony 刚刚点到你空间看了下，话说你还在找 vps 么，我这有个私人的 aws ，日本线，可合租（我平时用于搭梯子）

@9hills 有些私活不签合同的，有合同的话肯定要按合同来。

失眠+感冒

@9hills 私活的话有些客户要求是比较奇怪的，不按他的来不付钱都有可能。而且要源码的客户一般直接验收最后的源码和工程文件、编译出来的程序等，才不管你做的时候存哪里，更不会要求把代码放到某个 svn 。

@l0wkey 邪八，，，是我想的那个么？好老的站了

@kingwang
http://coolshell.cn/articles/4758.html
http://coolshell.cn/articles/933.html

自己维护一份，然后给客户无法维护的源码（酷壳那有几篇经典文）

@harry890829 单纯的字符映射用概率学可解。（统计每个密文出现的频率，与正常字符频率比较）
现在的加密多是使用随机字符作为加密因子，与明文做一定的运算得出密文，如此一来即便对方知道密文知道运算方法，缺失了最重要的因子（密钥），也无法反向还原出原文。
最简单的例子，原文按 ascii 转换为 16 进制并排排列组成一个 N 位大数（比如 AB 就写成 0x6162 ），我用一个 64 位的随机数做密钥，与此大数相乘，得到密文，如果你没有这个密钥，即便知道密文与加密方法，也无法反向算出原来的明文

为什么一股浓浓的骗 idea 的感觉。
1.真心招人的话，应该会让人直接到公司所在地面，这么大的公司不至于来回路费都不舍得报销。

2.视频面试这种东西不是万不得已不会用的，一来既然都到需要面对面交流了，视频面试效果肯定不如当面交流；二来会使得求职者感受不到公司氛围，也感受不到公司诚意，很容易流失掉人才。不过正好碰到公司的关键时期领导没时间，或者路费成本过高采用视频面试倒是可能

3.至于没时间的说法，一个总监级别的人如果没安排好时间就约别人而且情况还不止一次，那我倒怀疑这个总监是怎么上位的了

4.面试总共交了 4 个文案 /方案

5.3 天都联系不上用人部门也是醉了，明摆的涮你

6.8 月的部分基本就是让求职者知难而退了，本来不好意思明着拒绝，后来实在被逼的没办法，只好说没职位空缺了

这事儿个人想法：
最开始的招聘是想骗方案，但是没想到有个求职者毅力太高（ 5.17-6.17 隔了一个月还在折腾这事），那就顺便再骗一次方案吧（视频面试。也可能当时有了点招人的想法，不过没几天又后悔了），接下来就是拖了，不过耗了这么久，直接拒绝似乎不太好，让人知难而退吧；最后被逼的没办法，只能明说没岗位了

大学生毕业求职时借招聘骗方案很常见，大公司弄个招聘会，轻轻松松拿到上百种方案还不需要支出多少成本

以上乃个人胡编乱造之想法，谢绝一切查水表

@lecher 大概明白了。多谢指点

@lecher 我们几个都算是创始人，区别只是其中两人是发起人而且投入资金比较多，暂时分配到大股东的 50%就是用于扩招与融资的
我倒是比较赞同按工资乘风险系数算入投资成本，在网上也有看到算期权
另外你谈到工资这块，我们也有点纠结，因为现在几个人有点分歧，大部分人认为现阶段不发工资，把钱用于需要的地方，个人生活消费自行解决，小部分认为应发部分工资维持基本生活（现阶段主要支出为设备支出与固定成本）

@zdkmygod 不管是不是注册，明文密码在邮件传输过程中有被截获的可能。
一旦邮件被截获，不管最后是不是用密文储存，别人的目的已经达到了，可以拿着你的密码去社工、去充实字典等等

LZ 不遮下名字么 2333
密码明文储存，数据库一被爆就是大事

@hellogbk 另外，我建议是单纯使用统计信息统计每位用户的约会信用就好，用户自己会判断是否接受请求的（一个烂人品的用户肯定会被淘汰）。由此引发的就是，你需要一个手段限制马甲号，比如国内的就使用手机号，国外的使用脸书等，账号不能发起自己国家母语的学习约会（主要防止国内人注册小号逃避评分统计）
评价系统慎用，会被刷的

@hellogbk 将选择主动发起一对多或者一对一甚至多对一多对多约会的权利交给用户。也许你认为的不平等对于用户来说并没有那么重要，甚至会有用户认为不能一对多反而是一种遗憾（比如希望利用多方交流设计对话场景来提高自己语音水平）
将选择权交给用户，保证每人都是平等自愿的原则下，你的这个问题反而成为一个吸引用户的亮点

@hellogbk 个人认为，与其想办法在用户失约后如何处理，不如想办法减小由于用户失约对另一方造成的损失甚至避免失约损失。比如发起方发起约会，确定约会时间，接受方可以不止一人，这样多人赴约情况下，即便其中一人失约也不会耽误发起方时间降低用户体验，而发起方可以视自己能力接受多个或单个赴约请求（在赴约方进行申请时，而非到了约定时间）