用户输入的密码就应该是明文（+TLS ） 传输

客户端 hash 没有意义。hash 后的内容成为了实际上的密码。如果我有能力 mitm 你的 tls ，我就有能力重放这个 hash 。结果上这个 hash 就是密码了。

就算服务端指定一个随机数做盐也还是没用。我可以 mitm 改掉你的客户端输入框，取得密码原文之后再加上盐来 hash ，再传给你。

以 TLS 可能失效为前提，那不就等于没有 TLS ，等于是明文？但是又想用某个办法来保护传输中数据，那不就是重新发明 TLS （或者打败 TLS ）？这就是密码学民科啊

TLS 的安全性当然需要研究，但那是专业密码学人士的问题。你作为 app 开发者，也就是 TLS 套件的用户，需要做的只有按照推荐设置配置你的 TLS 服务，然后及时更新 TLS 软件库而已。

@roufan1024 不好意思，我大学辅修就是经济学。
我只能告诉你你的问题经济学课本里都有。
关于你 3 楼的问题，建议你先学习名义利率和实际利率的差别，然后在学习一下货币的供给需求理论。

建议你学习一下宏观经济学，特别是西方经济学，别搞经济学民科。
分清楚 M0 和 M1 的区别。银行虽然持有大量的存款，但存款不属于银行，属于存款人。或者说，银行对存款人同时负有债务。存款人要求取出存款时，银行需要返还。
你的钱存入银行以后，大部分会被作为贷款借出，这个过程实际上是在创造 M1 的。这个比例叫做加乘系数。
财富也不等于钱。财富可以是各种有形无形的资产。钱只是一种交易媒介。钱是财富的一部分。

1. 可以，但是需要 arm 的软件包 /库。debian 官方源已经有很多软件了。其他一些软件需要你自己编译。另一些软件完全不支持 arm 。
2. 不需要。你要用也可以用，但是需要 arm 的 image 。原因同上。

run 了买郊区大豪斯，从源头上解决噪音问题

内存自己加就行了。怕兼容问题就全换，不要混用

@111qqz 1. 这不应该 oncall 做。邮件沟通转给对应组员即可

2.那就更应该安排专人负责。或者设计一套自动修整系统，解决一些小问题。

3. 那也分紧急不紧急。能用两天时间就说明没那么经济。oncall 第一任务是生产环境的 outage ，其次才是失败率。失败率剩下的不还是可用率嘛。真要是重要的问题，那也是老板负责，你有什么压力。

4. 那也是需要另外安排人做。我们组这种事情都是转给 pm 去解决的。因为 dev 控制不了用户爱怎么用。pm 却很需要了解用户需要什么功能。让 dev 做这个非常没效率。如果老板认识不到他的 dev 在干 support 和 pm 的活，那说明老板的工作没有做好。

5. 这就更是老板和 pm 的锅了啊。和其他组件如何交接，这是最初立项时就要商量好的事情。
缺 log ，缺工具，导致 Dev 浪费时间在 oncall 上，那就应该开发工具，保证下次遇到同类问题可以快速定位和控制影响。如果你有类似的想法，应该及时和老板反馈，商量如何解决同类问题。你看，visibility 这不就来了嘛。

oncall 的任务不是彻底解决问题，而是定位问题和恢复服务。这考的是产品整体架构，不是单人的技术水平。如果你们出了大事还没法恢复，你老板就完蛋了。

6. 和下游用户对接，这就是 tpm 的工作……

总之，oncall 事多是正常的，但是你没必要有压力。尽力而为就行了。

能干多少干多少，接不到的就不接。你们 oncall 没有 escalating queue 的吗？你接不到就让老板接。
你说的几种情况：
1. 用法咨询：写 wiki
2. 上线失败：上线期间安排专人另外 oncall 。因为上线时间是可控的，没必要依赖正常的 oncall
3. 非紧急问题安排新人去解决。反正不急，顺便给新人学习了。
4. 同样写 wiki 。你们组不是 customer facing 吧？写好基础的 troubleshoot 流程，交给客服人员处理
5. 你不帮我我也不帮你。他都不急你急什么？发邮件给老板，这是 long investigation ，让老板另外安排人
6. 让客服组去 follow up 。ticket 转给对应的问题组，交接完毕就可以走了。如果问题修完了还有其他问题，客服组会再来找你的。


总的来说，oncall 忙不过来永远是老板的问题，永远是流程的问题。你就是一打工的，尽力而为，不必紧张。

有人发过类似的事情，而且是全程：
/t/777316
/t/766730

我用的是 x10sdv 。缺点就是小板插不了多少 pcie 卡。但是你这要求其实足够用：
pcie 槽插一张 hba ，硬盘口就足够了
自带万兆电口
ECC 当然支持
自带远程管理，不用插亮机卡

还有一个 m2 槽可以插 SSD 或者转 pcie
如果实在需要更多 pcie 槽的话可以买 bifurcation riser


@ingredient amd 桌面版对 ecc 的支持很有限，也无法验证 ecc 是否实际有效，而且只能用 unbuffered 。服务器常用 registered ECC 。所以洋垃圾内存也是 reg ecc 量大便宜。unbuffered ecc 基本上都被 AMD 桌面玩家买走了。

浏览器获取中级证书不需要额外花费时间，是服务器在 TLS 握手时，应该发来证书链上除了 CA 的所有证书。CA 不需要因为 CA 发了也没用。
@whitehack #31 这些也是商业公司。可以选择不和任何人做生意也不给任何人提供服务。但是，这不能成为楼主说的签发假证书的理由。

中国有 wosign 啊，那事后来也就被 ban 了一年。wosign 的资质还是在的。但是这事无论你有没有 CA 你都一样完蛋了。
除了 CA 还要有证书透明度服务。这也是西方的哦。
也就是说你唯一选择就是自建全套服务。原理上来说并不难。实际操作上嘛，非常时间非常手段，审计跳过就好了。反正都是要改配置（就算不改 CA 也要禁用透明度要求）。放飞自我以后自签也不是什么问题嘛。你看 12306 还不是用自签用了很久。

@felix021 #27 这依然不可以接受。除非你们有专业人士能复制审核要加入的中级证书。中级证书不需要加到 CA 列表，只有 CA 才能加。楼上已经说过了，是对方服务器没有正确配置 chaining ，正常情况下是服务器会把除了 CA 的两个证书都发过来。
你的服务器的安全运作全都可能依赖 ca-bundle （虽然 Linux 通常还有 gpg 签名，但问题是你不知道还有什么别的程序也用到了）

这不是一个运维问题，这是一个安全问题，影响的不仅仅是这个客户，还有你平台的安全和其他客户的安全。。

解决办法我也说过了，给客户请求单独指定 ca 文件，不可以动操作系统的 CA 。

* 4 不是 oscp 是证书透明度日志

我怎么觉得楼主是来反串黑的？
1. 技术水平拉跨，中级证书和根证书傻傻分不清楚。中级证书不是给你加到 CA 储存里用的。
2. 安全意识薄弱：PaaS 平台，客户给什么 CA 你就敢往平台上加？且不说中级证书的问题。就算客户需要自签 CA ，为什么不给让客户自己在应用里带上 CA bundle ，然后允许客户自定义 curl 库所用的 CA ？
你就不怕有恶意用户或者客户 CA 泄漏，然后你们自己的平台管理被黑？
3. 同样安全意识薄弱：让用户加白名单。当然这事算是小巫见大巫。我还见过很多银行和金融机构让客户加白名单的。但是错误的做法就是错误的。找个机会修掉，把技术债还一下也就算了。还要拿出来讲？
4. 你知道 wosign 的牌子是怎么臭掉的吗？因为 oscp 发现它未经允许签了一张证书。就算是内部测试，这也是不可接受的。各大浏览器直接把它的 CA 踢掉。
正规 CA 签发证书不是你自己电脑装个 OpenSSL 就想签什么签什么。人家是用专用的密码机。要是这层保护破了，那这家公司直接就没了。而建立一家新 CA 需要先挂靠在已有的 CA 下面，建立起相应的信用之后，各大浏览器才会把它加到 ca-bundle 里。
5. 不信任系统 CA 情有可原。cert pinning 了解一下？但是话又说回来，只有管理员权限才能导入 CA ，如果管理员权限本身不可信，这个问题已经超出了 TLS 的安全模型以外。因为 TLS 保护的传输过程，但保护不了本地不可信的客户端。我要有管理员权限我都随便看你内存了，还搞什么 CA ？

大家不要把安全相关的问题当成是编程问题。安全领域和编程隔着山呢。安全相关的内容留给专业人士去讲。

如果 TTL 板带灯的话，可以看一下 tx 的时候灯闪不闪。再测一下空载有没有电压，有可能少了上拉电阻。如果是的话，你需要给它一个 3.3v 的上拉。

@cubecube 3v 不是这样用的。是给本身不带电的设备供电。你这样接会搞爆 TTL 或者路由器的供电。

@505243267 实际耗电就是这么多。
能量守恒定律怎么学的？
取暖器放在房间里，输入的所有电要么变成热，要么变成吹出去的风。但是风也是关在家里的，所以最后还是变成热。

@xtinput 取暖器就这么简单一电阻负载，哪这么多幺蛾子？就算是 PTC ，也不会说电压降功率反而高的情况。电压降，温度降，电阻升，电流又降回来了，最终会在稍低于正常功率的位置达到均衡。
大电流电表会多走也是 bull shit 。电表不是电流表，是计算实际功率。而且居民电表只计算有功功率。

那消极怠工会被开除吗？

@liuzhiyong 1. 你自己说是推荐信，又觉得懵逼。我只是说，人家不一定是对你有什么意见，他没当是推荐信来写，你不必多想。

2. 微软的 principal 范围可以很广，基本上整个中层都是 principal 。管人的就是 manager ，不管人的就是 engineer ，两边都有的就是 tech lead 。

principal 确实是强人，但是从整个公司来说算不上大佬，算中佬。我这种 sde1/2/senior 那就是细佬，都是搬砖的底层。

在我看来，微软里称得上大佬的应该是 distinguished 或者 fellow 这样的。fellow 两只手就能数过来。distinguished 也不过百人。
为什么我觉得 principal 不算大佬呢，因为我 M1 （直属老板）是 principal ，M2 也是 principal ，M3 还是 principal 。所以我说整个中层全都是 principal 。当然，principal 的 ladder level 也就是数字级别，会有区别。但是这个数字外人看不到。只看 title 来说，看不出具体是什么级别 。

principal engineer 人数比 principal manager 少，但是权力和薪酬都是很相似的。因为微软的定级逻辑就是一样的贡献一样的级别。

升 principal engineer 会更难，因为 IC 到后期很难 justify 你一个人写码就能有这么大的 impact 。manager 相反，手下的 impact 就是 manager 的 impact 。

3. 如果真是学校的推荐信，那人家基本上是会给写的。明说不给写的，要么是真有仇，要么是为人刚正不阿，不想写就坚决不敷衍。其实明说不给写的都是好人，至少不会浪费你一个推荐信名额。
瞎写的基本上就是不记得有什么可写的。但是也算脸熟不好意思翻脸，就不咸不淡写两句。反正申请学校时一般都是默认 waive visibility ，他随便写，你也看不见。