有没有哪怕是 NAT 之后的 ipv4 连接？有的话我觉得我可以整一个

@Mohanson
@lp10
Updates for the CentOS Linux 8 distribution continue until the end of 2021; users can choose to switch over directly to CentOS Stream 8
邮件里面的说法：
If you are using CentOS Linux 8 in a production environment, and are
concerned that CentOS Stream will not meet your needs, we encourage you
to contact Red Hat about options.

分母

因为你需要一整个 aarch64 的 chroot 环境来保证你的 aarch64 elf 可以运行

试了一下 /proc/cpuinfo 依然可以访问，但是内存信息我确实不知道哪儿来的

In reply to #1
还是假定你想要管理的是日志，其实可以考虑 split 工具，可以一开始就把输出到标准输出（管道）日志按照一定大小分割并且存档。
但是无论如何，剪裁一下文件都是元数据操作，应该不管怎么搞都不会带来冲击，都是暂时写进缓存等到下一波元数据更新的时候一起更新磁盘。
In reply to #4
@XiLingHost 这样不行，老的 fd 不会失效，空间不会被释放。
In reply to #39 #21
@no1xsyzy @vuuv 如果是日志文件的话打开的时候应该有 O_APPEND 属性，那样无论 file pointer 怎么样问题应该不大，不会产生稀疏文件，要是打开日志没用上述属性，建议跟开发者对线。

debug 配置下编译产物运行会相当慢是预期行为，因为开启 debug 会禁用绝大多数优化行为

上个 5950x/5900x，全核心跑编译，内存低于 16G 就十有八九次次 OOM 了

客户端上 2.5G 网口 /万兆网口+支持链路聚合的万兆交换机可破

我觉得这样的需求使用 cgroups 更加合理，你应该限制单个用户的 slice 整体的 cpu.shares (或者是 cpu.weight, 对于 cgroupv2) 保证在用户之间争夺 CPU 时间的时候能按照用户（而非进程）公平分配。

当然，服务器整个占用爆炸的时候会导致相应性下降，想要保证响应性的话，这时候应该考虑所有用户设置占用上限，比如 95% 这样的数值（会浪费性能）

性能和功耗不是简单的线性关系，因为这款 GPU 是低功耗也并不意味着简单的放大规模提升功耗可以获得相应的提升。

这就是“边际效应”

到了高性能阶段，为了 10%的性能提升，需要的可能是远不止 10%的功耗提升，以及相应的架构改进。

扩大和缩小概率一样？你可能希望无论是扩大还是缩小概率分布都均匀（生成一个线性变换），抑或是一边均匀另一边按照幂函数映射（你原先的做法就是 best practice ），或者两边都不一定均匀但是要满足幂函数变换下的不变（ exp(2, rand())）。

更一般的情况更为复杂（比如你需要指定某一侧具有复杂的概率密度函数形式）那就需要先计算出 pdf/cdf 做专门的生成器了（ Inverse Transform Method ）

Adobe Flash 在国内不是被重橙代理了吗，并且其依靠捆绑安装、广告等盈利，按照这个逻辑微软中国提供纯净的 Flash 或者是 Chrome 等直接抛弃 Flash 存在不正当竞争？

Google 数据导出我记得可以导出到别的云服务？

前两个东西不需要驱动，PCIe Root Complex 是 PCIe 系统的中心，连接 CPU 和内存和其他设备，Bridge 是负责桥接两个 bus 的硬件，比如你的南桥负责下属 PCIe 总线与 CPU 直连的总线之间的桥接，对这些东西的支持没人会把它做成模块。是直接内核负责的: https://github.com/torvalds/linux/tree/master/drivers/pci

第三个应该是 Host Bridge 的不同功能，这和 configuration space 有关，可以理解成这个设备在软件层面可以看成不同的设备，没准有的需要驱动，有的不需要。这的看相应的文档，每个究竟是什么作用。

常用 btrfs 有一段时间了，再加上有段时间折腾超频电脑意外死机次数不少，这时候 btrfs 鲁棒性还是不错，没遇到过死机重启导致的文件系统问题。但是对于少数个例遇到文件系统炸了其实也有可能，尤其是前些年到处听说 btrfs 会炸但是现在感觉好些了。

至于 QNAP 文章中提到 btrfs 导致性能下降（对比 ext4 ），拿一个没有 cow 没有 checksum 的文件系统和一个 cow+checksum 进行对比是当然的结果，但是取决于是否愿意用这些性能换取 cow 和校验的收益。

至于无法区分快照存储区以及数据存储区？ btrfs 下大家都是子卷，本来就是一回事...也就没有什么快照或数据存储区的东西了。追踪子卷 Exclusive 占用在 btrfs 下只需要 btrfs fi du -s 即可

然后 QNAP 觉得 btrfs 的快照不如 ext4+块级快照就有点令人摸不着头脑，我猜他可能指的是 btrfs 的快照作为子卷假设可读写然后也会被勒索软件橄榄？那确实是个问题，只读快照或者一开始就规划子卷结构把让快照的子卷不被挂载就没问题了。

但是 btrfs 现在确实并非完美，具体已知问题可见： https://btrfs.wiki.kernel.org/index.php/Status 看着自己的使用场景决定要不要用吧

可以考虑转卖给需要的人

主流发行版都支持，但是不是所有硬件厂商都做了这件事情

具体靠的是 https://fwupd.org/ 提供的服务，就戴尔和惠普在积极推进，很多厂商还在观望