@nomagick 优胜劣汰

@nomagick 和金融行业的关系是什么？

每天洗两次，脱发变慢了

单块 16T 的盘够你存了，直接用硬盘盒子
硬盘柜处于不上不下的中间产品，需要多块盘的人，大概率会用 nas ；不需要多块盘的人，用硬盘盒就行了。

B200 、H100 、A100 ，8*GPU+4 或 8*400G 网卡机型，能买到哪个买哪个，其他歪路子浪费时间。

@skylancer 不用猜为啥，我自己用 xdp 撸一个 pppoe 报文转发，就几个 memcpy ，没发现难在什么地方。
你指的 nat 加速是指什么？你理解的 nat 加速是指，conntrack 不用 CPU 下发？

@villivateur 允许私企自己拉光纤

因为这不符合社会主义特色啊，这资本主义的东西，在中国不可能实现的；别说和 ISP 建 peer 了，即使在同一个数据中心园区，明面上都不允许不同公司在不同楼之间自建光缆。
这套方案在资本主义国家适用，比如 starhub

@villivateur 现在宽带费用是合理的，现在宽带用的 PON 网络设计上就是堵你所有用户不会同时使用。举个例子，一个 10G EPON 非对称，下行 8.5Gbps ，上行 850Mbps ，下联可能接 20 几户，就是赌。如果给你 guarantee 带宽，那浪费基础设施不说，体验上不会有太大区别。
你可以回忆一下，什么时候感知到“拥塞”了，即使你觉得网络卡，你如何判断是服务器问题，还是 PON 网络拥塞了

@jones 一根宽带一天 30 块钱，成本 10 块，一个身份证 5 根，这是普通人能做到的；运营商内鬼更多，这不是三瓜两枣

内容是加密的，协议层不是加密的，现在识别 PCDN 是靠 dns 、域名特征识别
不过更多的地区压根不识别，上传过大直接掐。

内容不加密是不可能的，几年前某个平台，内容没加密被投毒了；后面 PCDN 内容从存储那刻就加密了。你也不想刷抖音刷着刷着蹦出来反对平子的视频吧

不要给老人太多钱。
换句话说，“诈骗”就是让不符合智商的钱重新分配，上一辈人的认知无法掌控这么多的钱。
每个月给他一点零钱，打电话给顺丰禁止发到付件；微信支付宝各开一点亲密付。

+1
理论上微信给公安部做了数据备份？既然钱都花了，不如开放给用户赚点本钱，用户删除就标记一下软删；和公安审计也不冲突

15PM 首发买的，循环 600 次，95%（昨天刚校准），一直冲 85%，出门的时候充满

x86 软路由换成 b610-4e 直接拨号，单纯为了杜绝浪费

多虑了，pppoe 没有加密且头部固定，encap 和 decap 你就简单理解为 memcpy 了二三十个字节。
“硬件加速”可以简单理解为快慢路径，慢路径是 CPU ，快速路径是硬件，以一个最简单的，从你电脑 ping 1.1.1.1 来说，硬件上记录了两条表项，分别是正向 nat 和反向 nat ，
正向： 从 接口 A 进来的 源 IP 是 192.168.1.100 目的 IP 是 1.1.1.1 协议是 ICMP 的报文 NAT 成 源 IP100.64.0.11 （你 pppoe 接口的 IP ）目的 IP1.1.1.1 从接口 B （你的 wan 接口）出去
反向就是上面的表项反着下一条，来把 wan 收到的报文 nat 成你的 IP

想象一下这个过程：
1. 硬件表项需要 CPU 参与，流程简单描述是 硬件表项 miss ，upcall 到 cpu ，cpu 根据 iptables 的配置处理完成之后，下发到内核 conntrack ，再下发到硬件
2. 家用路由器硬件表项是有数量限制的，通常 16K 到 64K ，意思是超过这么大的连接数之后，就会超时老化置换掉一部分连接

硬件加速比软路由有优势的场景：
1. 连接数小且单个连接存活时间长且流量大

以上所有处理过程都是 ns 或者 us 级别，人肉不可感知，所以，直接用 x86 软路由，灵活性和可扩展性都吊打家用和中低端企业级路由器

看你的网络环境，不同的网络环境有不同的最优解。比如 aws 的 lightsail+cloudfront ，在部分地方的部分运营商有极佳的体验；而且才 5 美元一个月。
你可以先买个非自建服务器的机场，选几个延迟低的线路，然后自己去对应线路开 vps 自己搭

@Ploter 会，有的是容器化的组件

1. 不要删除 LVM 分区
没想到删除 LVM 的理由是啥，Thinpool 非常适合 PVE 的场景，大部分容器和虚拟机都用不满磁盘，并且 thinpool 对性能几乎没影响。我建议保留 thinpool ，新加的磁盘也用 thinpool ； lvm 处于灵活性和性能的平衡点。你这个配置，用 500G 机械盘去装 pve ，120G ssd 重新创建一个 vg 和 thinpool 给对存储性能敏感的负载

2. 确实没必要

3. 能用 lxc 就用 lxc ，lxc 的性能是 kvm 无法比的（计算、存储、网络，lxc 的性能都吊打 pve 的 kvm 方案）；除非你涉及到 kernel 的开发，否则能用 lxc 就用 lxc

最后，实在不建议在这种硬件上折腾，花个小 1000 搞个 n100 小盒子来玩比较好

@PaulSamuelson 这个是 cloudflare 的地址，不用刷。刷 https://chrome.googlenav.cn/400135/ChromiumSetup.exe 这个吧
我从备案上还找到另外一个 https://chrome.py010.cn/ 有 android 的兄弟扫一下看看地址

@yulgang 它这个源站带宽还怪高的，都打不满的