至于桥接至同一个物理网卡(lower device)的多个虚拟网卡（ upper device ）能不能互通的问题，取决于工作模式。

参考自这篇博文（ https://suhu0426.github.io/Web/Presentation/20150120/index.html ）

VEPA 模式下 upper device 的帧会通过 lower device 发送出去，如果要折返（也就是 VM 间通信），需要外部 switch 或者 router 转发，除非 lower device 支持 hairpin mode 。

如果是 bridge 模式，Host 的网络栈会转发 upper device 间通信的帧而不会到达 lower device，通常都是用这个模式。

@cxh116
确实我搞错了，没有用 PROMISC 。
冲突的定义我查了下是采用共享介质通信时通过 CSMA/CD 避免同一介质下的两个 NIC 同时使用介质发送数据。
这玩意只有物理介质（双绞线、同轴电缆）时需要吧，虚拟网卡和网桥只是内核中的数据结构，不需要处理这些 PHY 层才存在的问题吧。
例如两个 VM 通过虚拟网桥使用同一个物理网卡发包，Host 内核网络栈处理完这两个帧之后再插入物理网卡的 TX Queue 中，物理网卡的处理器并不知道这些帧是从哪来的，只是按照 Queue 的顺序发送出去罢了。

虚拟机用的虚拟网卡默认是 macvtap+bridge，Host 内核用 CPU 处理包交换的事务，物理网卡工作在混杂模式。
如果是用 NAT 转发，Host 内核同样要使用 CPU 介入 NAT 事务，不过物理网卡就不需要混杂模式了。
如果想提高性能，可以用网卡的 SR-IOV，需要 Guest 安装专用 VF 驱动，网卡自行处理交换事务，CPU 基本不介入。

12v 的已经有产品了，叫监控集中电源适配器，可以输出多个 dc 圆头，本身是设计给监控摄像头用的，不过我认为在家用弱电箱里放一个带光猫路由器交换机什么的也是好主意。

笔记本一般用 19vv，这个产品不好找，如果有的话配合各种圆头转接头也是可以的。

无论用哪种都要注意电源额定功率是否充足的问题。

检查一下你的 I225-V 是不是有 bug 的 B1 版本，虽然 ASUS 说不会用老步进芯片，但真说不清楚翻车问题是不是解决了没。

虽然 5.4 已经算是比较新的内核了，不过 AMD 的 Platform 驱动通常都要比 Intel 慢半拍，试试去 ( https://kernel.ubuntu.com/~kernel-ppa/mainline/) 换个更新的内核，例如 5.9.X 。同时更新 linux-firmware ( https://packages.ubuntu.com/hirsute/linux-firmware) 能新就新

之前帮同学搞小新 Air14 锐龙版的硬件问题就是把升 kernel 和 firmware，完美解决，顺带拯救那块老掉牙的 RTL8822CE

继续划分的话只能用 Statefull DHCPv6，但不是什么设备都支持用这个分配地址（ Android 明确不支持）
openwrt 的话可以将 lan 和 wan 全设成 RA+DHCPv6+NDP 中继模式
Linux 网关可以用 radvd+ndppd
这两个可以在所有下游用同一个 /64 前缀，但没法再划分子网

@chaixiaomu 金融套路就是通过预收一年租金按月付房东房租形成资金池（加上融资），资金拿去扩张房源扩大市占，垄断后提价收回亏损。
很多互联网公司都是这种套路，只要**保持一定增速**，预收的年租金足够偿付房东月租，这个击鼓传花可以一直玩下去，而且确实有成功案例。
但是一旦维持不了增速就会资金链断裂，就是不加速跑就会死的那种。
如果公司觉得玩不下去就可以规划掏空资产跑路了，反正什么老赖限制这玩意从来都是只对老实人有效，找背锅侠什么的也不是不行。

先猜测不是笔记本,清盘安装单系统。
搞清楚是 uefi 还是 legacy 引导，我只讲前者，建议在 BIOS 设置只使用 UEFI 引导，免得出各种麻烦。
自定义安装位置，将所有盘的分区表都改成 GPT(GUID)，删除所有分区。
在 1ssd （假设设备名是 sda，根据实际情况调整）创建一个 100MB 的 EFI 系统分区(sda1)，挂载为 /boot/efi(这部可能不需要)。然后 1ssd 剩余空间创建 ext4 分区(sda2)，挂载为 /。引导器安装至 sda1
如果打算多块盘合并成一个大文件系统用(LVM/BTRFS/ZFS)，建议装完系统再弄，然后自行编辑 /etc/fstab 挂载点，打算用 lvm 的进系统安装 kvpm 工具创建 LVM PV 。

另外拿 openwrt 来说，它的防火墙默认拦截入站 IPv6 流量，只放行部分 ICMPv6 、DHCPv6 、IPSec 的入站数据包。像 Windows 的防火墙默认也是拦截不属于本地子网的入站 IPv6 流量。
但是如果没有上面说的那些防火墙，然后还把网络服务绑定到[::]还不加任何密码保护的那就真的有被爆的风险，IPv4 靠着 NAT 反而没有这种担忧，所以有些习惯确实要改一下。

我这边测试的结果是路由器通过 PPPoE 通过 SLAAC 生成一个 /64 地址，并通过 DHCPv6-PD 获得一个 /56 前缀。
理论上可以 DHCPv6-PD 一层层分发这个前缀到 /64 为止（更长的前缀不支持 SLAAC，只能用 statefull DHCPv6 ），openwrt 就可以详细设置下游的前缀长度和子前缀
例如一级路由 PPPoE 获得前缀 240e:1234:1100:ff00::/56，LAN 侧分配前缀 240e:1234:1100:ffe0::/60 (ip6assign=60,ip6hint=e)
二级路由在 LAN 侧继续加前缀 240e:1234:1100:ffe8::/62 (ip6assign=62,ip6hint=2)
三级路由继续加 240e:1234:1100:ffe9::/64 (ip6assign=64,ip6hint=1)
其他家用路由估计的 native IPv6 估计都是固定分配 /64 stateless/statefull DHCPv6 了。

考虑下 ovpn 的 tls-crypt-v2 功能，不过这需要最新的软件，而且要自行解决没有公网地址的问题。
如果你是打算自建 frp 服务器，那不如直接把 ovpn 服务器建在云服务器上，终端和群晖运行 client，ISP 没理由管这种出站连接。

这玩意就是适配了 ML Framework，有没有用上 NPU 不知道，不过顺带让老 Mac 上的 A 卡能用上 tensorflow 了。

WebGL 好的前提是 Web 应用前景好。
至于后者的发展状况嘛，大厂都去搞 APP 和小程序去了。
这跟有没有 5G 还没什么关系。

@systemcall
1. Miracast 本身的渣压缩已经可以让我忽略缩放带来的影响了。
2. 通常支持 DP Alt Mode 的手机会保持原比例，也就是会有缩放，但不会有任何延迟和编码带来的画质损失，如果手机有做诸如桌面模式的适配效果更佳，不过操作依然复杂。

所以最舒服的方案是买个 16：9 的支持 DP Alt Mode 或者 HDMI 的平板接电视。

没有适配投屏就只能用系统投屏方案了，通常智能电视都支持 Miracast 投屏，不过画质很一般，介意的别用这种方案。

比较靠谱的是找支持 DP Alt Mode 输出的手机，配合转接头连电视，不过这方案也就比电视盒子强一些。

@VKRUSSIA
先确定光猫上用的 libc 是 musl/uclibc/glibc
如果是 musl 可以考虑用>14.07 openwrt 的 mips sdk 来编译，可能需要带上依赖手工复制上去。
如果是 uclibc 用<14.07 的 openwrt 的 mips sdk
如果是 glibc，用一个足够古老的 mips-linux-gnu-gcc 工具链编译
具体方法没法简单说请。

试一下把除了微信之外的所有程序的存储权限都设成拒绝试试，如果没出现再逐步放开权限。

你直接说你要在上面跑啥吧？

证书用的是 Let's Encrypt，槽点略多