？好怪，我不知道 @nothingistrue 一本正经地想要纠正我啥。

按照这个形式，这个案例确实是声称了文件有 12G ，确实没有分配物理的存储块啊？不管是 NTFS 层面的“压缩”手段，还是 NTFS 的稀疏文件，还是 Linux 啥神奇 Hack ，不都是实现这个效果的某种手段嘛。

我也没有深入各个文件系统不同的实现方式，

@nothingistrue "Size 11.7 GB ，Size on disk 138MB 。12G 资源已经分配了，后面是磁盘系统实际占用 138MB ，这个跟虚拟磁盘无关。"
----

对不起真的和虚拟磁盘有关。

香农老爷子已经明确告诉你了，信息的压缩比是有极限的。12G=>138MB ，显然大部分数据位都是 0 ，所以才能把那部分 0 的位置给压缩出来。这恰恰是虚拟磁盘才会有的特性。

@tool2d 这部分评论也适用于楼主。不信楼主你在虚拟系统里面随便放个 10GB 的视频文件再删掉，然后你再看看 NTFS 能给你压缩到多大。

----

从这个意义上，“它只是声称 12G” 一点毛病都没有。不论是 NTFS 层面声称 12G （但不占用），或者预留出 12G （占用）。反正真正原因是没有写入非 0 数据所以才看上去有这么牛逼的压缩比。

@qrobot 我不否认粘包实际不存在。我知道 TCP/IP 。但我觉得既然这么多人叫，那在别人都这么叫的语境下，借用这个术语表达他们的意思，我没意见。。。

为啥要这么纠结术语的纯洁性。DL 论文里面一堆（数学）术语乱用，只要该 domain 认同，不也就这么过来了。

只是声称这个文件有 120G 但是没有分配存储块而已。

@nekoneko 吗吗，你的言论有些“反粘包警察”哦。

所以其实我“粘包”打引号了。虽然 TCP 确实不存在粘包这个概念，但是在应用中这个“问题”确实存在。我是不关心这玩意儿到底用“粘包”这个术语，还是准确地“因为 TCP 是流式协议所以必须自己处理数据包分割的问题”这么长的文本描述。在我看来，入乡随俗，如果“粘包”接受度广，用“粘包”来代指上面这句话我没意见。

@ChoateYao 嗯我确实说错了，在通用模型里面属于第四层应用层。HTTP 和 WebSocket 都属于应用层。

另外如果看 HTTP 和 WebSocket 的关系，实际上 WebSocket 可以独立于传统的 HTTP 服务器单独使用，只不过 Handshake 这一步好像用了 HTTP header 。但如果一整个端口都用于 WebSocket 应用程序的话，其实可以忽略 HTTP 协议这玩意儿。

WebSocket 单独使用，你可以参考币的交易所协议。

TCP 确实有“粘包”问题。

所以为什么要死磕 TCP ？找个 TCP 上层的、有“消息”概念的协议不好嘛？比如 WebSocket ？

我有些反感粘包警察，是因为早就被标准化解决了无数遍，直接拿来就能用（比如 WebSocket 这个五层协议）的问题，非要当做现实中一个重大问题去翻来覆去地讨论。

@tool2d ？合着股东不挣钱来供着二次元小将是吧。

@murmur 毕竟新兴的宇宙互联网大厂都是娱乐的，怕什么服务质量有问题。

你要是支付表宕机一小时看不把人骂死。

算法工程师要负责到上线意味着没有统一的基础设施、算法部署平台，顶多来个 Kubernetes 集群就丢给每个算法组了。是，容器时代、Kubernetes 时代，每个算法组自己搭 Database 成为了可能，但是这样的不专业分工就导致了不可能每个算法组都有完善的质量控制和测试机制。

字节不还发生过实习生删线上模型的傻逼事情么，还不能说明这套体制有问题吗。

这就是迷信大厂了。

要我说字节就是小厂到大厂，身份转变了，管理没跟上。对外宣传算法工程师要负责到上线，很自豪的样子，其实就是管理方式低下，还在小厂的模式没有转过弯。

我来歪个楼。

Go：大道至简，泛型是邪道。

有，那叫 rsync 。

你这情况，要是失业了基本就不得翻身了。还是不建议买房。

@ligiggy ummm 很遗憾我已经脱离教材很久了。。。（今年 phd 毕业了

@ligiggy 我上面举的这四个例子都不怎么需要推公式，工业数据上又比较万金油，投入产出比 DL 高。当然它们基本没法处理图片 /NLP ，CV/NLP 还是神经网络得天下。

@ligiggy 其实现在 DL 比较成熟的也就 CV/NLP 。

大量工业数据没那么规整的，各种不同量纲、不同单位、不同性质的 heterogeneous data ，一般用树算法更舒服。经典的比如 RandomForest ，新锐的比如 GBDT 。除了这些树算法，还有就是 Bagging / Boosting 算法的思想得了解一下。

分情况。

* 如果是用树算法处理工业数据，一般不需要推公式，调参就行。
* 如果用神经网络处理图片数据，一部分工作者不需要推公式，用 PyTorch 搞就行。
* 如果用神经网络处理自然语言，推公式的比重会增大。
* 如果处理的是无监督学习，或者顶会不怎么覆盖的新领域上做深度学习，那就得会大量原理性的东西，做各种 regularization （ loss / 结构），不会公式基本寸步难行。

我只看到了楼主满脑子的大男子主义，恶心。