@liuidetmks DH 算法本身不具备身份鉴定功能，一般要和数字签名结合才能防止中间人攻击。

@liuidetmks 真正的端到端加密只会在端生成密钥，是不会经过网络传输的，服务端也破解不了传输的内容。

@liuidetmks 再仔细看看，key 只在 AB 端生成，不会经过网络传输，包括服务器都是不可能知道的。所以即使服务器自己就是“黑客”，它也不可能知道 AB 两端用 key 对称加密后传输的是什么内容。

去看 Telegram 的端对端加密算法:
https://core.telegram.org/api/end-to-end

是基于下面这个算法：
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

总结下就是：
1.服务端给客户端提供两个数(x,y)
2.客户端 A：
生成随机数 r1，计算 m=pow(x, r1) % y
3.客户端 B：
生成随机数 r2，计算 n=pow(x, r2) % y
4.A 、B 互相发送结果 m 、n
A 计算 key=pow(n, r1) % y
B 计算 key=pow(m, r2) % y
这时，两个 key 是相同的，后面用这个 key 做对称加密即可

注：y 要足够大，x 、y 、m 、n 都是公开的，但是只要 r1 、r2 不泄露，别人想要计算出 key 的值难度很大，包括服务端。

alias please='sudo'

小米根目录有个 miad 文件夹，删除，用一个 txt 改名为 miad，不要任何后缀即可取消。

https://github.com/2dust/v2rayNG/issues/930

@Paaranoia url 肯定要换啊。。。或者不写

1.看 gradle 版本，5.0 以下就不是我说的问题，5.0 及以上看第二条
2.到卡住的那个仓库看有没有 metadata.xml 、pom.xml 文件，没有的话就是我说的问题
3.加上下面的配置就 ok

metadataSources {
mavenPom()
artifact()
}

可能是你的 gradle 版本太高，仓库里又没有 metadata.xml 文件，高版本的 gradle 认为这个仓库不存在，就下不下来，加 metadataSources 试试。

repositories {
maven {
url "http://repo.mycompany.com/repo"
metadataSources {
mavenPom()
artifact()
}
}
}

https://docs.gradle.org/current/userguide/declaring_repositories.html#sec:supported_metadata_sources

用 Group 关联两个 view，运行时拿到 referenceIds 遍历设置 click 事件

https://stackoverflow.com/questions/46743944/use-group-in-constraintlayout-to-listen-for-click-events-on-multiple-views

@brendan 不知道换哪个，docker 用户，M1 不支持

@Donno0 保留维修凭证，指不定后期会有免费维修的计划呢。不过即使换了用两年估计还有有黑线的问题

楼主看看这个回答

https://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach

@sujin190 好像说反了，docker 单机情况下默认是 bridge 模式，改成 host 模式才是直接使用的宿主机的网络

https://docs.docker.com/compose/compose-file/#driver-1

别用 java8，相关配置去掉

https://developer.android.com/studio/write/java8-support

识别验证码，两年前写过一个，https://github.com/lonnyzhang423/zhihu-captcha 。
训练出来的模型识别成功率 95%以上，撸了一波知乎的数据，后来知乎换成滑块验证码就没用了