大学就是教知识的，人情世故这些为什么要轮到大学来教？这事情关大学什么事。你不如说让医院不要给孩子看病，而是要教孩子人情世故。公交车司机不要开公交到目的地，而是在车上教孩子人情世故。电影院不要放电影，而要给孩子看人情世故。

人情世故和他们有啥关系啊。

@westerndream 不是说充电器，是说不少手机走 PD 协议只能 9V2A 。

NAS 是接入网络的存储。
你的台式电脑如果有存储又接入了家里的网络，那他就可以当做一台 NAS 。
一台专业的 NAS 会专门为存储和网络功能特化。
比如说存储的话，可以做成多个盘位，可以做热插拔，可以插 HBA 卡支持超过 10 块硬盘，等等。
网络的话，可以加装万兆甚至 25G 网卡，提高上传下载的速度。
还有一些其他的辅助功能，比如私有云软件给你存储照片，共享编辑文档之类的。
耗电也可以优化，比如说用核显，用低功率上限的电源等等。（电源效率和负载率也有关系。）

至于电脑开着电费吃不消这事，其实电脑也有省电的。比如 Dell 的 SFF 桌面电脑，待机也就不到 10W 。

@westerndream 100W 充电速度拉低到 18W 实在是得不偿失，还不如花 20 分钟把手机充满再换去充别的设备。
多口 PD 每个口功率也有限，充笔记本走 PD 如果限制功率的话也会很慢。
我之前买了好多个 2A2C 的 100W 头子，实际用下来感觉完全没用。

普通 PD 毕竟只能 9V3A ，跑满也就 27W ，安卓都 60W 朝上甚至 100+W 了，而且很多用的是浮动电压电流供电。PPS 也只能跑出 9V5A 45W 。

我现在是一个 OPPO 的双口 100W ，A 口充手机，C 口接 C 线充其他设备。

epub 不就是 zip 里包 html 嘛……

RAW 分区就是没有格式化的空分区。你随便创建一个 HFS 分区然后不要格式化就行了。

@icyalala
对，不过多道检查校对工序，以及每一道都用水平更高的工作人员，是可以让正确率接近 100%的。
不过现在的主流就是削减人手减少成本，在一般人发现不了的情况下尽可能省钱。

字幕组已经衰退得差不多了，反正有正版中字，字幕组早已沦为自娱自乐的活动了。

举个今天刚看到的例子。
原文：弟は晒す
意思：弟弟暴露自我（指将内心的心理活动暴露给亲友）
AI 翻译：弟弟是用来出卖的

我这么说吧。GPT 或者其他 AI 可以达到 90%的正确率。
但是一个比较优秀的字幕翻译人员能做到 99%的正确率。
如果你不介意 AI 在 10%的句子上翻错意思，甚至翻出完全相反的意思，那现在的字幕已经足够可看了。

至于字幕延迟两三天，这个和有没有 AI 没有很大的关系。主要原因是那些工作人员不是你的奴隶，不需要在一两天内放弃掉他们自己的工作、生活和家人，而来给你做字幕。特别是有点能力的工作人员，通常在现实生活中也是在很重要的岗位里工作，他们也会有工作忙的时候，加班的时候，回到家也要陪家人，做家务，休息娱乐放松，而不是要在电脑前为了这些事情连轴转就为了让你早一天看到字幕。

外语翻译本身是一个价格高昂的工作，只是现在有各种因素（比如劣币驱逐良币等）导致翻译成本迅速下滑，优秀的翻译人员别人不愿意请，反正花 1000 块钱请你做到 100%质量，和花 200 块钱找个大学生兼职做到 90%质量，不懂的人也看不出来。AI 翻译可以轻松替代后者，但是代替不了前者，如果你希望看到 100%正确率的东西，依然需要外语能力很强的人负责校对纠错。就看你是不是纠结这点错误量了。

能造，但代价是什么呢，钱啊。你投 50 亿进去搞，马上就能给你搞出来差不多的东西。
CUDA 壁垒算什么，只要有钱，把 CUDA 上的生态全部重新搞一遍出来就行了。

但现实是，没有钱。

这其实很像 iPhone 上的生态。人家是第一个造出来的非开源智能手机系统，于是手机 App 必有 iOS 的份。安卓是第一个造出来的开源智能手机系统。你看看 Windows Phone ，第二个造出来的。第二个，而不是第一个，所以就寄了。

AMD 现在的定位就是想搞第一个开源的显卡计算生态（ OpenCL/ROCm ），能不能搞成就看天了。但是他有个很大的弱点，就是企业不一定买账开源生态。企业不是普通用户，对开源项目的选择考量是不太一样的。

@wxf666 #35 上 TB 的数据怎么处理都是会很慢的。（一秒 10w 条数据可能到不了）

我建议用第三方数据库纯粹是因为这样对实现的要求最低，不需要你搞大内存服务器，不需要自己开发复杂的算法，全部用已知的成熟的方案，你只要插上一堆 SSD 然后干别的事就行了，等个几天数据就都跑完了。算法简单所以要根据需求修改起来也简单，可维护性也好。（用人话说就是，工程师不需要加班，让服务器加班就行。）

现实当中从 SSD 读取数据到内存也是要花时间的，这么大的量级还要跑前后依赖的操作，我是觉得快不起来。

（如果能并行 map reduce 倒是能快不少，但这里不太行。）

我能想到的两种不同的做法。
第一种，在内存不足的情况下，放弃掉内存，直接用 SSD 读写。
在 SSD 上开一个数据库（比如 MySQL 或者 Postgres ），把已经存在的 hash 写到数据库里。
然后流式扫描每一行，取 hash 比对数据库，如果存在 hash 就跳过，不存在就写到结果集里并添加到数据库。
要快速稳妥可以用两种不同的 hash ，比如 xxHash 做一次过滤，SHA1 做二次检验。

第二种，在内存不足的情况下，分批处理。
多次流式扫描每一行，取 hash ，每次只处理 hash 第一个 hex 字符相同的那些数据。
第一次只索引和处理 sha1hash[0] == '0'，第二次只索引和处理'1'，这样可以把内存需求降到 1/16 ，缺点是 hash 计算也会是 16 倍。
稍微优化一下的话，可以在第一次遍历的时候在数据上追加 sha1hash[0]作为分区标记，这样后面 15 次就不会重复计算，缺点是会每行多一两个字节，而且要多写入一次磁盘。

我司就是写 Java 的，很多项目到现在还窝在 JDK6 甚至 7 的语法里还没有升级，主版本还是 8 ，升级到新 JDK 还很遥远……

https://www.willhaley.com/blog/custom-debian-live-environment/

以前做 rescue cd 的时候参考过的教程。
他用的是 debootstrap 创建一个新系统，但克隆老系统的操作是差不多的。
不过 live cd 是只读的，cookie 迁移过去也不能更新啊，还是得另外划一块用来做存储。

@ExPensive5678 差不多。首发是 2/2 拿到的机子，那时候价格和国内差不多，性价比还是很高的。

官网直接下单，首发价，$669 。