mayli

@newtonMiku 教育网一般有 iptv 具体怎么做的不大清楚

内网搞个电视直播（ IPTV 那种）

限速打开吧，到峰值再 QoS ，开个开源镜像站。

搞个集群跑 PCDN

其实利用率不高没啥问题，就两端 iperf 24/7 压测呗

一般来说，业界会使用成熟的加密算法和方法来进行验证，也就是不会自行发明轮子。例如安全密码验证会使用类似 bcrypt 和 salt 之类，为了增加安全性引入 2fa 。这种经过验证的安全性技术，用起来一般都不容易出现安全性问题。

对于题主的不信任 https ，进而选择在客户端进行“加密”，在安全性分析逻辑上其实属于“混淆”。因为客户端代码和逻辑都是可以被逆向和检查的，从传统的安全性上来说，基本上属于事倍功半的行为，而且一般情况下，系统的复杂度与漏洞数成正比，可以说系统越复杂存在的漏洞就会越多。引入一个这种技术，大概率是面向 KPI 的 feature ，而不是真的传统意义上的安全。比如说，你如果是客户端实现加密，是否需要引入 salt 或者 key ，那么这个 secret 是否也会通过所谓不安全的 https 通道传输到服务器，这个 secret 服务器需要明文还是可以进一步 hash ，这些都是当造轮子时需要考虑的问题。

当然，另一角度也可以说，我这是特别强力的混淆，就像 D 加密那样，没人可以逆向。这么说也行，不过对于实际场景来说，解决明文用户名密码泄漏的 2fa 技术已经足够流行和有效。即使在 http 情况下，也能一定程度避免 replay attack ，所以大部分公司没有必要投入资源去实现客户端加密。

所以和大部分计算机系统一样，当一个方案已经足够好，另一个方案没有明显优势的情况下，就不会被替换。

另外关于第三方的论点

> 重要的是，各个流程链条上，各自尽量做好自己环节的事情，三方厂商做好自己这一层，出了问题它是要赔钱的，我们不能确保三方一定不出问题，所以自己方负责的链条也做得安全强度更高，有错吗？

“我们不能确保三方一定不出问题”这个思路倒是正确的，但是大部分工业场景是妥协的结果，也就是预算情况下的最廉价解决方案。比如 TCP 本身已经保证不会丢包和乱序，在 tcp 初期，这个 tcp 第三方因为不被信任所以好多程序会自己发明个网络协议。但是 2024 年，不会有程序在 tcp 层上面再去检测乱序或者丢包，大多数情况下，文件传输后，算一下整体的 hash 就够了。妥协的结果就是，大部分的底层结构已经足够可信，对于登陆安全性方面，fidelity 用的明文，chase 用的混淆，我觉得都可以接受。

至少 10 年内的高通芯片应该是内置 fm 模块的，但是大部分手机取消 3.5 耳机口，没天线也就没法收听了。
另一方面是大部分非城市地区 fm 质量差，用户少，所以使用频率也不高。
最后，流媒体冲击下，大部分普通民众抖音快手短视频应用，可以使用流量业务，利好运营商。
反正汽车 FM 在新势力也基本快没了，就快成为时代眼泪了。

Taskmgr?

同样推荐 kitty, 不过菜的话就别玩了

3a 这个价格有些不自信，感觉至少定价 299 ，后期才有打折促销的空间。毕竟开发了好几年的游戏了。

@juniorzhou 感觉目前应该没啥更优的解法了，普通的文件系统可能要删更久，大部分文件系统都没有对删除一堆小文件做特殊优化，每个删除都是个复杂的原子操作。除非你可以不走 linux 的文件系统，直接调用某些 gpfs 的某些接口。