@lesismal #35 关于续传，他没问我也就没说，实现上一般有一个 bitmap 控制文件写入情况，你说的所有问题用一个 bitmap 就能解决了。另外如果不想用 bitmap ，创建的时候指定文件类型为稀疏，然后直接询问系统哪些块是稀疏的，直接从稀疏块开始，也是可以的。

@jifengg #8 我以前做过多线程下载器，关于文件分配，直接向 OS 申请预分配一块存储空间就行了，预写入 10G 那是 HDD 时代老 Windows 的东西。关于线程调度，直接开个 BlockingQueue<<Index, ByteBuffer>>然后由专门的 Writer 负责写就行了，其他下载线程只需要负责把下到的 block(比如设定每个 block 为 512K)挂到 queue 上就完事

IDM 那种分文件下载再合并，对于大文件下载来说是不可接受的开销。除了菜逼我不知道还有什么理由会这样做

@huixia0010 #6 动动脑子啊，你说的这种问题分多个文件就能解决？

实际上除了 IDM 主流下载器都是不需要合并的

没有为什么，就是写代码的太菜，连 pre-allocate+seek 都不会

证书有限定用法的，用法代码不对直接报错

@cloudzhou #119 不如直接叫 Anal 吧

GiB 不是 GB

@evan9527 #22 好好好，射胶是吧

@Jackeriss #79 按理说小米生态不比华为小，甚至更大，没和华为一样做 nas 确实有点奇怪

@frankilla #59 华为这家厂商非常封闭，本身又有手机和 pc 业务，很缺乏中立性，导致第三方设备体验不佳

LLM 推理很吃显存带宽

https://github.com/ninehills/llm-inference-benchmark/blob/main/LLM%E6%8E%A8%E7%90%86%E4%BC%98%E5%8C%96.md

@serafin #32 微软给了，到现在系统里面仍然留着 VFAT 无损转 NTFS 的命令

@xinmans #20 这种用法你可以直接去掉价格的两个 0

要不你把嵌套虚拟化开一下看看

@comexb #36 +1 电网的成本大头都在输电和配电上，很多地方发电端都快饱和了

K30Pro 刷海外版

如果没有电磁力，你我都不用存在了😅