@daishuge 基础的 infra 看文档就可以了
居然是静态页面的话那完全没必要自己 infra ，serverless 平台可以轻易给你提供 HA 和 CDN
此外静态页面的话，可以看看 hugo 和 hexo 这些模板引擎

@flyqie 你用用看 ifupdown ，再看看 systemd-networkd 和 networkmanager
很多基础组件的选型 ubuntu 都更加现代，当然无论是 ubuntu 还是 debian 都可以自己更换基础组件

@zed1018 第三方仓库是第三方仓库

@nuII https://github.com/coredns/coredns/blob/master/plugin/loop/README.md#troubleshooting-loops-in-kubernetes-clusters
就算没有 workaround ，也是会 fallback 的

你要抓还是要改，只是抓的话基于 ebpf uprobe 的方案可以无视 ssl pinning
https://github.com/gojue/ecapture

debian/ubuntu 是常规选择，ubuntu 主要是技术选型更加现代（例如使用了 networkmanager 而不是 ifupdown ），但我觉得 deb 系它们的仓库里面东西感觉有点太少了，ubuntu 上你想装个 kubectl 它居然叫你去用 snap ，过于抽象
非常规选择的话，主要考虑 immutable os ，方便维护和规模化部署，常见的就是 fedora coreos 和 opensuse microos
但是它们没有解决在大量节点间进行系统环境更新的困难，我自己 Homelab 是跑的 NixOS ，更适合大规模的进行同步部署，但非 FHS 环境造成的问题导致它学习成本过高

我试了一下，问“穿背带裤，有数亿粉丝的，中国的“篮球巨星”是谁？”它真的会自动用 4o-mini
但是问一些复杂的问题它自动是 4o

@geekvcn 树莓派智商税...? 那些国产派甚至大部分不能用主线 mesa, 小部分甚至只能用神秘来源 mesa 的二进制, 而且大部分 vulkan 1.2 都支持不全, GPU 根本不能用
而且甚至还有很多用不了主线内核

AdguardHome 的全部功能就是一个 DNS 转发器+DNS Filter+前端，刨除前端部分，dnsmasq 都能实现过滤，而 mosdns/knot-resolver 则健壮的多
此外旁路由...非对称路由警告, 入站流量不能 Conntrack 警告

存储或交换密钥，比如说 matrix 就支持通过扫描二维码来传递端到端加密的 session key
还可以支持线下扫二维码来 verify 线上交换的密钥的真实性或者离线交换端到端加密的密钥

了解了以下，支持 switchdev 的话确实 vf 或者多个 pf （包括拆分后的）可以直接通过 linux bridge 片上交换
这么看 e810 确实是可行的，但是还是推荐 mellanox
楼主节点多的话建议整个交换机吧，少折磨自己（

说实话不太有，而且多 function/virtual function 片上交换是的 bridge 就可以实现 offload 的吗？
得用 openvswitch 和 openflow + switchdev 吧，你先确定能用上再说

v6 可以保证所有设备都具有公网 IP ，这对于实现零信任+零配置的完全点对点通信意义重大

如果要给 linux 平台开发 electron 软件，请务必考虑一下在 wayland 下的输入法问题，即便现在 xorg 还能用，但 wayland 也是趋势
而 wayland 下 electron 仅支持 text-input-v1 ，目前大部分 compositor 没有且不打算支持（但未来可能会更好，比如说 mutter 现在已经有了相关 pr ）
现状可以参考： https://www.csslayer.info/wordpress/fcitx-dev/chrome-state-of-input-method-on-wayland/
而 Tarui 则完全没有 chromium 所带来的问题

如果连一个不开 PMF 的开启 802.11k/v/r 的 WPA2-PSK 的 2.4/5Ghz 混合 SSID 都连不了 IoT 设备，那我觉得真的可以退了，折磨自己，虽然你的确可以单独开一个 SSID ，但考虑到 IoT 设备一般会有二层互联的需求，这等同于降低整个网络的安全性

@ChaosAttractor 修正 此外 FRP 等一般用于单一的静态 **端口** 的穿透（转发），而作为 Default Route 则需要能被三层路由原始流量的能力

这些都是 Linux 的容器化技术，内核层面依赖 CGourps 实现，它可以提供在同一个内核中隔离多个用户空间进程，你可以理解为 LXC 里面的进程和外面的进程性能什么都是一样的（当然也可以限制），只是所有东西互相隔离
共享内核意味着 0 额外性能和内存开销，只有里面的进程会占用内存
而 LXC 则是管理管理 CGroups 和各种 Namespace 隔离的用户空间程序，类似的还有 ContainerD 和 LXD ，Docker 和 K8S 则基于 ContainerD
此外它们支持嵌套，所以在 LXC 中运行 Docker 并无不妥，因为 LXC 一般直接用于替代 Hypervisor
但 LXC 的网络基于内核的 NetNS ，并且因为共享内核和非特权的设计使得 eBPF 和 iptables/nftables 功能受限，而且大概率你还需要 CPU 转发（虚拟化则你可以直通网卡），各种硬件卸载功能也受限（当然如果你在用最新最热的 Mellanox 网卡那支持的还蛮好的）
一般作为路由我觉得不太合适