@ryd994 经提醒突然发现 docker 的-p/-P 参数映射的端口原来也是走 bridge 网络的端口转发。我一直以为是本地直接作映射的。也就是说即使使用-p 参数映射端口，这个数据报实际上的路径也是
外网->eth0->docker0->bridge->container
而不是
外网->eth0->container 的咯？

看看 log，确定是入站还是出站的问题？ sshd 进程的状态？不是很懂 iptables 输出的这个东西，只了解一点 iptables 的命令，无责任建议。

@YvesX 话说，吸睛，吸金这俩词看的我真的难受。

@Hzzone 我想知道机架式服务器的散热和噪音你怎么处理了？

话说，AppStore 有个 6 块钱的 Magnet。功能一样。何必再去破解破解的。
https://itunes.apple.com/cn/app/magnet/id441258766?mt=12&ign-mpt=uo%3D4

看了楼主前面的回帖记录，感觉楼主可能要走弯路……

歪楼，个人用户买机架式服务器…还要加游戏显卡…怎么感觉怪怪的

@zmj1316 我去，这个解决方案有人成功么？确定黑客不会"黑人问号"，然后觉得智商受到了鄙视，然后怒删你们的数据么😂

看起来很不错呀

哦，对了，上面说的这些都是针对大规模信息盗窃的防范。假如是针对特定用户，其实社会工程学的可行性要高得多。做技术很容易陷入一切问题都想通过技术解决的怪圈，但人的问题才是核心问题。

目前非对称加密的私钥不能"依靠"帐户密码生成，是筛选出来的大质数。其次，加盐是为了避免彩虹表"爆破 /碰撞"，盐没有过期这一说。而且能够使用彩虹表的前提是你已经被拖库了。第三，MD5(大约)十几年前就被我国山东大学的王小云教授带领的团队提出的密码云碰撞算法破解了，所以现在大家都用作签名而非加密。SHA1 则是位数不足导致以现在的计算机可以在可接受的时间内算出来所以被抛弃使用了。希望说"不知道具体用什么方法"之前可以先去查一下。
勘误结束，来谈谈用户密码的加密，这里存在一个问题，我们需要保留用户密码的所有信息么？如楼上某人所说，我们其实不需要保留用户密码的所有信息，熵减也是可接受的，只要熵减后的取值空间仍然足够大且分散，保证不同密码生成的 hash 值碰撞的几率足够小，不会出现我们密码不一样但是 hash 过后的值是一样的就可以了。也就是说密钥 /加 /解密算法的具体应用其实包含两方面，还原或验证，而用户用密码登录这个过程，我们需要从 hash 值"还原"出用户的原始密码吗？不，我们事实上只需要"验证"就可以了，验证的成本比还原要低的多，而对于窃取了你数据库的黑客来说，他必须还原或近似还原(记得熵减么？)出原始密码才行，那么他破解的成本要比我们验证高的多。
这里有另外一个问题，计算时间的问题，hash 算法往往是位运算级别的运算，非对称加密算法则往往涉及大数运算，这个中间的差别可是数量级级别的。你要考虑这中间的计算成本计算时间，黑客不能接受，但是你系统的用户就可以接受了吗？基于同样的理由，你的算法里面的客户端产生私钥这一条，所需的时间可能也是用户不可接受的(假设你需要的是一对足够健壮的 key-pair，比如 2048 位)。
那么最后说结论，综合起来，平衡破解难度与计算成本，目前广泛采用的方式仍然是 hash 算法，辅以每个用户独立的盐，以及 N 次迭代 hash，来放大彩虹表制作所需的成本以及难度，来避免被破解。建议参考，PBKDF2，bcrypt，scrypt。
回到问题的起点，我们目前所讨论的一切都是数据库被拖库以后的"补偿"安全措施，那么你为什么不避免数据库被拖库呢？安全问题的每一个链条都要做好。补丁要及时打，漏洞要及时补。碰到 0day，才是这个补偿安全措施该发挥威力的时候。
谈谈现实情况，现实情况是，绝大多数的用户密码泄漏事件都是因为用户在不同网站采用了相同的密码导致黑客拿别的网站泄漏的密码，轻松撞库撞出用户的密码。诚然这个是用户的安全意识问题，但是整体提高从业者的能力与安全意识，才是杜绝我前面这句话里的"别的网站"出现的一大措施。这也是我在这里普及这些安全知识的初衷。
以下则是对楼主的建议，尝试对业界现有方案进行质疑和挑战的精神值得鼓励和赞扬，但是前期功课一定要做好，这是对你自己负责也是对看你帖子的网友们负责。了解现在的方案是怎么提出和演化成现在这个样子的也很重要，以上几点做不好，很容易滑入民科的深渊，只谈挑战权威，不讲实验结果与事实，缺乏基本的理论知识和学术素养。
以上所有内容限于个人立场和眼界所限可能有谬误，还请楼下朋友斧正。

Ubuntu 升级把桌面升挂掉我遇到很多次了。症状类似，只有 xfce 可用，不知道什么鬼，我也尝试过各种方法，越来越感觉不必浪费生命在上面，我后面再碰到就直接装新版本，不再追求升级了。

两年前碰到过类似的情况，debug 到凌晨都没有什么头绪，第二天起床什么都没做就好了…从此之后，我就对微信的东西有了敬畏之心。

@imnpc 京东不是泄漏了很多嘛

不太喜欢这种招聘形式

@hronro 之前没有关注这个工具，我当时用 flex 需要手写 flex，-webkit-flex, -webkit-box 三套，心有余悸。感谢，赶紧加入工具链。

@mogutouer 以前 DW 我不用是因为自动生成的代码不符合我的预期，特别是在不同浏览器环境下。而如果自动生成了代码再去手动改，往往会改出奇奇怪怪的 bug。反而不如自己手动去写。前端里面 css 各种奇奇怪怪的 hack 方法，不同属性组合带来的各种副作用是 css 难写的一大原因。好在现在有了 flex(兼容性就…)，不用再去 hack table 或者 float 来布局。不过花在前端开发里时间最多的我一般是调兼容性。