内网搞个电视直播（ 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 的某些接口。

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

@JensenQian ntr 狂喜！

日历？重复性事件

无脑 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 你以为这样的程序员是段子？他其实是认真的，就感觉没啥讨论下去的意义。

我大学时有个类似的习惯，就是读维基百科，当时有维基百科离线版，做成类似词典那种。
我就一直 BFS 看，每次看到崭新的领域就觉得爽。
就单纯的爽

一般都是写到一个大文件吧，下载到单独文件，相当于 IO 两次，除了某些场景下，现在的 OS 对于这个没有特殊差别。
但是对于真的大文件，比如 10GB 以上的，你这种写两遍的操作会占用两倍的磁盘空间，而且对于 HDD ，一边读一边写会巨慢。
所以，这么做，单纯的是菜（不会 seek ）。