……有啥好看待的？橙汁可以保存一年，橙子能么，成本当然高了。

容量 N 的大顶堆。要带位置的话元素里加上位置信息即可。

@dramakevinzz 哦，我也误解了，以为你说的是 JUnit 之类的 assert 。
Java 自己的 assert 断言说实话我代码读到现在还没有见人使用过。（也可能是我读得少……

写测试的时候用 assert 。
assert 一般意味着不满足 assert 就是程序质量有问题，或者是发生了必须要立刻终止程序的严重事态（比如内存数据被篡改，等等）。

仅为个人理解。

这事让我想起了挺久以前的一个事。有家亲戚找我们家在某个单位托一下关系帮一个忙，家里人就去帮了，忙死忙活花了钱托了更多的关系总算勉强给人搞定了。后来亲戚表示帮忙的结果不是很理想，觉得我们家对他们家不好，连个最好的结果都没给人家，就背地里埋怨。

你跟我说 mingw64 里没有 rsync 我可就乐了（狗头

升级表结构，找支持 db migration 的数据库抽象层。
升级文件多这个没办法，自己写一个升级器？应该也不难的。

@ryd994 主要是激光打印效果好，就这点就吊打喷墨了。用喷墨大概还是图成本……
我是运气好拿到一台二手的，不用心疼钱包。

有一台 3180cdw ，非常方便，打文档打支票打标签纸什么的都行。

中文汉字配中文标点。
个人不是很理解喜欢中文汉字和英文标点混搭的操作。
话说还见过英文词句配中文标点的操作，读起来非常不适。

在 Org 里开的项目，归属于 Org 而不是个人。如果你把你的项目转移到一个 Org ，那就表示你认可把这个项目献给这个 Org 。如果以后因为各种原因 Org 决定违背你的意愿删除这个项目，你只能怪自己眼睛瞎了。

存放非代码内容没事，但是存放版权文件就等着号无。

这个应该算是 behavior question 吧。
比如说移植远古屎山到新平台，比如性能不行要分析调优，比如说工期太赶来不及完成，等等。
工作上总会遇到各种问题吧，总不能每天都一切顺利一点问题都不出吧。

西数的大容量盘都是日立产的，只有 6T 和以下的盘才是西数产的。
UDMA CRC 错误是磁盘接口到主机之间发生的错误，通常是数据线有问题，也可能是接口松动之类，如果是服务器的话则可能是背板问题。
其他数据问题不大。

> 这数值也太夸张了

这些数值的具体意义只有厂家知道。比如他可能是个浮点数，也可能是个分数，甚至可能本身就没有意义，总之你我都是不知道这个数字的含义的，纠结也没有用。

要是有一千次下载的需求又想省钱的话就搓 BT 种子吧。
不管是国内还是跨国去国内，带宽流量费都不便宜。
便宜的又大多辣鸡。

目前正在用。这也不是已经被淘汰的软件啊……

连在网络上的存储就叫作 NAS ，有什么不好意思叫的。
不装个 i5 R5 也好意思叫电脑？不弄个 3080Ti 也好意思叫游戏主机？不装个 2.0T 发动机也好意思叫车？

有什么不好意思叫的。
我还能说，不是 EMC 和 Netapp 之流的也好意思叫 NAS 吗。

产品有高端有低端不是很正常么。高端服务关键业务市场，低端服务普通家用人群。

然后像#61 以及其他人说的一样。

视频的帧是它的硬性特征。你播放视频的时候，就是一帧一帧播放的，你不可能脱离帧的概念去编码。
比如播放蓝光光碟的时候，播放器是逐步读取文件，一帧一帧解码的。
不可能先花 20 分钟，把整个光盘 50G 内容全部读取出来，然后在 256G 的内存里解压缩，然后再开始播放吧？
算法必须要有办法把解码每一帧的数据限制在一定的范围内。
比如你要解码第 10000 帧，那么就必须要在读取 10000 的前后几十帧之后就能解码出 10000 帧。
再比如串流播放，像是直播，你不可能先让观众等个半小时，等直播结束了，打包熵编码完了以后再播出吧。

现在的视频编码器技术都是那些电视台或者视频音频相关的企业资助开发的。
就算你说的能突破宇宙极限的熵编码存在，谁投钱给你去研发呢。
你说 NHK 或者 BBC 投几千万给你研发一个让观众等半小时才能看到节目的编码技术吗？

没钱还开发个 P 。

其实就算是视频编码圈子内部也是这样。你看看 VP9 ，没有商业环境支撑，现在是什么个鬼样。这已经是有谷歌这个金主投钱的结果了。反观 x264 x265 这种商业产品，有钱才有动力开发，才能把编码标准发挥到比较好的状态。HEVC 2013 年定稿，x265 2013 年就开始开发，到前几年就已经成熟了基本停止开发了，最多折腾些 HDR 之类的新技术。AV1 2018 年定稿，现在还是半个笑话，连个成熟好用的编码器都没有，至今还只在在线视频网站内部用。

我又仔细读了一下你的帖子，再补充一些吧。

无损压缩本质上是从数据里尽可能去掉冗余数据，尽可能让残留的数据接近信息熵极限。
视频编码有很多步骤都是去掉冗余数据，减少信息量的行为。
你说的运动预测帧内预测频域变换这些，都属于去掉冗余数据，减少信息量的行为。

熵编码是无损压缩算法里比较低效率的一种，因为它是介质特征无关的编码。
一个工程师拿到了熵编码以后，他肯定会想办法去改进它，比如增加对介质特征有关的处理。
你说了「通用压缩方法还没有发现这些重复」，就是因为这些重复数据不能被通用压缩方法所发现，而需要针对特征的算法来辅助发现。

比如说有一张图片，我们做一个淡出淡入的效果，从图片过渡到全黑画面，30 帧。
这 30 帧，每帧的数据都不一样，因为他们的亮度不一样。
如果你要直接做熵编码，效率就非常低，因为熵编码不会考虑大段数据同步偏移的情况。
而视频编码器就可以针对这种场景进行优化。

不管熵编码效率有多高，视频编码器总是能站在熵编码的基础上继续进行改进，加入针对特征的处理。