你姐夫有不同看法，难道你没有？说出你认为是右手的理由

996 黑名单

一加 3 不支持

@sexoutsex2011 才用一半空间，速度不至于这么低。可以看看黑果机有没有 intel 的 nvme 驱动可以装。

“连续”读写超过缓存大小才会降成缓外速度，楼主这个测试用了多少 g 的数据？不会比缓存大吧，还是说硬盘装满了？

习惯问题，等你搞过 1 年 winapi 开发，你会发现其他的 api 都是渣渣。

其实*也 google 不到

进程被 system call 阻塞了，除此之外还没见过-9 kill 不掉的处于 running 状态的用户进程。

@Osk 这种也只是系统错误而已，挂个 pe，直接拷出来重装系统就行了

@nicevar 必须要 d 盘这么傻的软件我是不会装的

@andyhuzhill 在数学意义上私钥（ d，n ）并不能很容易的计算出公钥（ e，n ），或者说从私钥计算公钥和从公钥计算私钥的复杂度是完全一样的。之所以你实际操作中从私钥可以能计算出公钥是因为现有的 rsa 库（比如 openssl ）都是选取 e 为 3 或者 65537 （为了效率考虑），私钥的 n 你知道了，e 只有两种可能，所以公钥自然就知道了。所以这不代表 rsa 算法中的公钥私钥不是对等的。

打个比方，道路右行和左行其实没有区别，但是我国交通法规定必须右行，你在实际中硬要左行，那出事故的概率肯定要大大高于右行，但你得出个结论说因为左行事故发生率高所以我们必须右行，这就是本末倒置了。

@3dwelcome 是的，在实际应用中，公钥用来加密，私钥用来签名，不能互换，这是规范。但就楼主所问问题而言，RSA 算法在数学上公钥私钥其实没什么不同，任选一个作为公钥，另外一个就是私钥。任选一个用来加密另一个就可以用来解密。

@3dwelcome 并不是签名不可以加随机 padding，是没有必要。实际上加了 padding 也不应影响签名验证的结果，因为验证过程其实就是解密后比较 hash 值的过程，而 padding 并不会影响解密的结果。

@3dwelcome 签名其实也是加密，只是加密的对象是数字摘要。

就 RSA 算法而言，私钥公钥是完全对等的，一个用作加密，另一个就可以解密。但实际应用中，为了性能考虑，对私钥公钥有不同的要求，比如 openssl 的公钥中的 e 就简单取了 65537，就是为了计算方便。这时候公钥私钥就最好不要互换。否者安全性得不到保证。

刻石头上

@xfspace @BOYPT 不一定要中间人吧，如果有 server 端的私钥，理论上可以直接解密 wireshark 抓的包啊。中间人是在没有私钥的情况下才需要的。

nmcli connection modify "your-wifi-name" connection.autoconnect-priority 20
最后的数字设置的越大优先级越高，可以为负数，默认加入的 wifi 优先级是 0

@megachweng 这种写法 g 在每一次循环结束后就被释放掉了，因为它没有被任何已存在的对象引用到。解决方案就是加上 parent 参数，或者给一个与 table 相同生命周期的对象引用一下，比如在创建 g 后添加到父控件的一个 list 成员里 self.btnGroups.append(g)，这样 g 就不会被释放了