@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 用的混淆，我觉得都可以接受。

Taskmgr?

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

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

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

的确 删除文件一直是个老大难问题
一般来说单线程 rsync 是最快的
你后台 io 够的话，试试多线程 rsync ，find 限制深度 然后用 xargs/parallel 去删

日历？重复性事件

无脑 es 吧，数据量大了 水平扩展起来也方便。
或者 Cassandra 这种。

@ZField 技术栈过于先进了, 考虑下传统的 imgui?

如果喜欢+高兴，就不算乱花

我觉得是排序导致的，把 order by 去了可能时间上会差不多。最直接办法还是看看 explain, 盲猜 in 过滤一堆数据，但是因为你最后是 datetime 排序，所以这个排序做了一个临时表去排。
理论上数据库应该是能利用索性查这个的，但是你用的数据库可能就傻傻的都查出来再排了。

技术上，wifi 的名字是 essid, 还有个类似于 mac 的 bssid.
要是软件安全性好，完全可以识别出这种攻击，但是防御效果也有限。

大部分程序员，可能对网络和文件系统接口都不熟。
现代操作系统提供的网络基本上都不会出现传输错误，现代操作系统也都会提供 seek+随机写的功能。
对于 preallocate 会有各种实现方式，不过提供的结果基本一致，也就是实现了随机写。另外，即使不依赖 seek ，也可以有 mmap 这样的方式实现随机写。
再说从网络下载到磁盘，大部分操作系统也会提供 zero-copy 或者类似 pipe 的功能，即使没有，IO 操作时基本上也是使用一个固定 buffer ，比如 64k ，不会把全部内容放到内存再操作。
再说一下状态恢复，类似数据库一样，分片的下载状态一般是单独存放，比如 aria 、flashget 或者迅雷，只有分片下载完成后再去更新状态，这样即使程序崩溃，也可以下次启动从恢复点续传。
最后补充一个极端的例子，BT 下载每次传输单元是 16KB ，难不成要创建一堆 16KB 的文件，然后完成之后再合并？从文件系统的效率角度来说，从 socket 读并且单独写入一个大文件，这里可以只需要频繁调用 read(socket) + write(fd)。 但是如果是一堆小文件，你需要频繁创建和关闭文件，这两个操作在大部分操作系统，尤其是 HDD 上的文件系统，开销会非常大，你的顺序写操作会变成随机写，同时如果你的操作系统安装了杀毒软件，杀软也会在文件关闭时进行扫描，结果就是更慢了。

一般程序员在软件设计和实现的时候，都会倾向于使用资源需求最小并且吞吐量高的方案。所以当小文件没有明显优势，而且特殊场景下资源开销和性能都有明显损耗的情况下，选择大文件是一个比较自然的方案。

类似的需求还有比如数据库，就像如果网络客户端发送了一些 INSERT ，你是把他们写入小文件然后再合并呢，还是直接放到大文件中。这里的就会有和网络下载类似的权衡，当然也有不一样的地方。

@kenvix 你以为这样的程序员是段子？他其实是认真的，就感觉没啥讨论下去的意义。