li2150

@zonghua 前一段时间我玩 Tiny Core Linux 的时候似乎有过类似问题， MariaDB 一启动就要 128M 。我当时是把 my.cnf 里的 innodb_buffer_pool_size 改成了 40M ，内存问题似乎有了不小的改善。您若有兴趣，不妨一试。

据网络上说，如果内存充足， innodb_buffer_pool_size 的大小最好是全体 innodb 数据库的 1.6 倍，而 innodb_log_file_size 则被建议设置为 innodb_buffer_pool_size 的 25%。似乎也可做为调整时的参考。

@zonghua 我也是不知道怎么配置 Apache+Mysql 。以前在 Ramnode 上搞了个 128M 内存的，一年多来都没啥问题。反正这小服务器就组里几个人用，负载极小。结果这两天不知道出了什么事，内存频频耗尽，每次都是砍掉 Mysqld 。本来想到搬瓦工上搞个 256M 的将就将就，却看到了内存 1G 的，于是果断下手。哈哈，这下应该不用担心内存耗尽的问题了。

@zonghua 我刚整了个凤凰城的，现在感觉还行，不过这个点儿大概当不得准，先当两天梯子再来汇报一下日常使用情况。

理论上来说瓶颈应该还是国际线路、美国国内的延迟应该不大吧？这两个城市离得也不算太远。

您这个页面打开很快啊，在洛杉矶？

我觉得应该推广这么一条原则：凡是因为觉得某软件太流氓想要找替代品的，优先推荐开源替代品。

其它大企业的谁知道啥时候会浪起来，当年搜狗也是老老实实做人的。

有点没看明白，只对第一句话做点评论。

如果是足够强的加密算法，加密后的结果应该是准随机的。所以“原始数据的任何一个加密结果都是该散列函数的一个碰撞”等价于“任何一组随机数据都是该散列函数的一个碰撞”。

除非加密算法和散列函数共享同一个key？不过这样应该不是楼主的本意吧。

抛砖引玉，求指正。

@tencoldays 顶一下，现在改练囚徒健身，肌肉没啥变化，不过腰椎改善了不少。

通常来说，连平常跟股市八竿子打不着的人都开始关注股市的时候，这股市就不应该再进了。

同样个人胡言乱语，绝不负责。

记忆中好像2月2号发了个公告说第二阶段即将开始，两个月就结束了？

@dedewei 要是这样那250条、500条大概都不太够吧。这两天尝试了一下，正常使用每天10条左右，但是今天整理了一些资料条目，使用量突飞猛进，不由得让我暗暗担心呐。

姑且先贴个邀请链接，如果有哪位朋友能支援一下就感激不尽了。

https://workflowy.com/invite/2c808f10.lnx