小硬盘插着用浪费电浪费盘位。去卖了买两片 16 或者 18 先用着好了。话说为什么新买还要买 4T 这种小硬盘？真有钱……

去年上了 128G ，再也不用要打开游戏就要把所有的软件关掉了。

@mschultz #24 说得我开始怀疑 3 个月到底是不是 90 天了……（狗头

源代码就是源代码，这没什么歧义吧。
你 A 继承了 B ，又没改过 B 的源代码，怎么能算改过源代码呢。
继承和重写，和源码有什么关系。
继承和重写是编译期和运行期的东西，你的类还能跑到别人项目里改人家源代码？

CPE 主要是许可证污染性上有区别。Apache2 是个宽松许可证，并不污染衍生作品。

上面写了原因，你可能以前标记过类似的邮件为 spam 。
如果你标记 Google 为 spam ，那以后 Google 给你发邮件自然会进垃圾箱。

红帽和龟壳？

@O5oz6z3 不考虑成本，火星都能给你送人上去。
你真不考虑成本，那都不用管 GIL 了，直接堆机房堆起来……还纠结什么性能问题，对吧。
这个前提太没有意义了。

而且就算不考虑成本，那也应该先去写 C 扩展。你看那么多年过去了，C 扩展的高性能库一大把，GIL 问题还没彻底解决，这是为什么？当然是因为写 C 扩展比较便宜简单啦……

成本。
你来写吗？
如果你不写，那可能别人也不想写，太多工程量了。
而且你都用命令行开关切换了，那不就成运行时判断了吗？
运行时判断会影响性能的，真要做的话还不如分开两套 binary 。

当然上面说的 C 扩展本来就没有 GIL 也是因素之一。
真要做 CPU 密集型操作不如写 C 扩展。

@justaname 你说得没错，做成镜像再读确实可以读出数据。但是我觉得这个代价太大了，先不说这么多大容量的磁盘你得先买一大堆同样大小的硬盘来放镜像，就说你恢复数据的过程就很花时间，况且也不是保证能恢复的，如果损坏的地方是文件系统区块，一样会丢很多的数据。
unraid 之类是数据盘完全独立，没坏的磁盘数据就完全不会丢，用 raid 是做不到这点的。

五年十年可能有些乐观了，我司的 nas 组起来用了三四年就出现过三次坏一块盘，一次坏两块盘的事故。客户的生产机上也出现过几次做了 raid5 结果连坏两块的情况（ raid5 不是我做的）。我倾向于平均四五年就会至少遇到一次，除非你每 3 年把所有的硬盘都换新一遍。

越通用就越不专业。为什么要自虐去用通用的东西？
卡车能载重，公交车能载人，小汽车操控灵活，跑车速度快，飞机能飞。
然后你要弄一个既能载重，又能载人，又操控灵活，又能飙车，又能飞的交通工具？

还有一种可能是谁家电工瞎瘠薄接，零地接反了。别问我怎么知道的……

StartAllBack
ExplorerPatcher
都可以试试。不要慌，总会有人帮微软擦腚，把砍掉的功能加回来的。

@x97bgt 网卡应该只吃 dumb 字节流。你发送的时候要自己根据协议把数据转换成字节流，然后接收方根据协议把字节流转回来。
当然通行的做法还有一律使用网络端序（大端序），免得两端扯皮。

我觉得你这还算好的。我们这些远程工作的，半个月不和人面对面说话都算正常……

觉得贵，不买，让他卖不出去，才能倒逼他降价。
觉得贵你还买，还疯抢，他降价他有毛病啊。

还堵嘴，谁堵你的嘴了？这一百多层楼里有多少人让楼主闭嘴的？
用前人的一句话来说就是，你喊破喉咙都没人来鸟你。

就一个笔记本电脑，搞得像是不买就要饿死了要活不下去了，干啥呢？

我是头一次看到有人说 localhost 跑 20MB/s 挺快的。

@LeeReamond ffmpeg 切割既可以重编码也可以复制流，看你怎么写参数。
复制流就只能切 GOP 边界，重编码则是精确切割但是全部重编码。
如果你 ss to 写在输入前面，然后编码用 copy，就是复制流。
如果你 ss to 写在输出前面，然后编码用 x264，那就是重编码成 x264 。
（应该没有记错吧。）

GOP 是很难去凑参数单独重编码的，除非你知道原始编码器用的参数，然后用一样的参数去重编码不完整的 GOP，否则后续 GOP 可能会因为参数不同而花屏。

盲猜内存不足，内存不大的前提下还开内存盘，把物理内存里的数据都分页到硬盘上，降低系统性能。
高提交，低物理内存占用，通常就是物理内存的数据被寄出去了。看起来内存占用少，实际上都分页出去了。

@LeeReamond 如果正好切在 GOP 上的话当然没问题。
实际上，非精准切割就是切在 GOP 边界上。

PS: 音频其实也有自己的「 GOP 」，只不过音频的帧比较小，所以切割的时候不会距离太远。
比如 AAC 在 48khz 下一个帧长 21.3ms ，这 21.3ms 也是没法切开的。