打发下时间，探索下爱好，也没花太多钱，不至于上升到伪需求、消费主义这个层级。就算最后闲置了，也算是探索爱好的成本了，不用太有心理负担吧。

主要是做好服务隔离或降级方案。保证在玩具全部挂了的情况下，最基本的光猫、路由、无线是可用的，即自己折腾不影响最基本的使用。不管是简单的插拔网线还是高级的自动降级，至少要有一个方案的。

在用红米，很少看到广告。可能是当小爱用，从不关机只待机的原因。当然，视频软件里的广告很多，这个应该不能算硬件或系统的广告。

看品牌的话，CHH 有网友似乎更推荐铭凡。

推荐微软的 Mouse without Borders ，用了好几年了，生产力工具。
https://www.microsoft.com/en-us/download/details.aspx?id=35460

前排提醒，那个免费 10G 流量有坑，仅限 5G 网络。在信号不好的地方，手机自动降级到 4G 时，使用的流量不在这个套餐中，如果你没有通用流量套餐，那么就是按照 0.29 元 /MB 计算，已经被坑了 10 块钱了。如果你没有通用流量兜底，这个免费就很鸡肋，毕竟谁也不能时刻盯着手机的网络情况。

写的很好，条理清晰。作为一个用户，从自身利益角度，支持 OP 的观点。但从逻辑上看，理由似乎值得商榷。
- 第一个理由，PON 的技术优势在 FTTR 场景无法体现，不代表整体上有劣势。对于运营商来说技术优势无法体现应该不是重点，技术一致性、基层维护经验和成本可能会重点关注。从纯技术角度看，一个技术方案在该场景无法体现技术优势，自然会给出场景不适配结论，但从商业运营角度却不一定，技术方案只要不是特别的拉胯，在商业决策上的权重应该不会特别高。
- 第二个理由，当前的宽带安装，运营商默认提供的设备性能一般也较低，仅满足基本的路由、交换、无线功能，有需求的用户仍需要额外购买路由、交换、无线设备。所以，运营商默认提供的 PON FTTR 设备无法满足较高用户需求是符合预期的（是否符合预期要看用户实际支付的费用），按照当前逻辑，有需求的用户可以额外购买主从光猫（ OLT\ONU ）。这个理由里面似乎更应该关注利旧问题，有特殊需求的用户在现有 Ethernet 方案下，有一套自己的内网解决方案和设备，这些无法在 PON FTTR 方案下完全复用，对用户来说是需要考虑的沉没成本。
- 第三个理由没什么问题，对用户来说还是兼容性、利旧成本问题。对于产业来说，可能就是技术标准、利益之争了。往上追溯甚至可以到 ATM 和 Ethernet 之争，过于宏大无法评价。

两种场景：
- 有一个 k8s 实验环境，跟着教程学学基本概念。
这个场景主流 CPU 加 64G 内存的配置就够了，kind 、minikube 创建实验环境也很方便。甚至更真实一点的，手动搭建 3 节点控制平面+3 节点工作平面的高可用集群，也可以用虚拟机搭建出来。偏下层的集群搭建学习和偏上层的应用部署学习，应该都是够用的。
- 以 k8s 平台为核心的 homelab
上一个场景中的集群一般是实验集群，随意创建销毁。这个场景里会试图去维护一个所谓的“生产级”集群，部署一些希望能够稳定运行的“业务”，学习一些实际运维 k8s 集群的经验。硬件选择有 2 个方向，一是集中式，找个二手服务器，配置拉满，基本就是上面配置的放大版；二是分布式，上面的配置可以再来几个，好处是可以再研究学习一下虚拟化集群、裸金属配置、超融合等场景。

那就不用贵那个静音机柜了，要好的解决只能物理隔离了。没有地下室、储物间比较难办了。

- 背景疑似机翻内容农场
- 7890 点睛之笔
- 看不懂报错，权限不足仍执行了 2 次 git clone
- 看不懂报错，在首次 pip 报错内容疑似无法连接代理（图片中缺少一位 IP ）时考虑换源
- 推测代理未正确配置或开启，第二次 pip 仍会报错
- 责任全在 GFW

@CodersZzz 静音机柜有考察好吗？最近也在找静音机柜，淘宝上有一家就是太贵了。似乎普通机柜自己加点隔音棉应该也有效果。
另外，Dell 太新的服务器固件已经不支持风扇手动调速了，老一点的服务器风扇调速后噪音应该还算能接受。

隔离政治讨论经济的确是缘木求鱼，但应该也是无奈之举，毕竟在网上讨论政治就像上公共厕所。OP 应该只是想闲聊一下“身边的经济学”，看看大家盲人摸象的看法和结论。

fine tuning 和 text embedding 会有很大的却别吗？似乎大部分的文档助手、客服助手类 chatbot ，有 text embedding 就可以做到相对专业的协助了。

感觉对容器，或者说 docker 的支持没有其它发行版好呢，至少在 docker 官方文档中 SLES 只有 s390x 架构的支持。当然，实际装的时候还是装的上的，suse 官方也有文档。

中小公司 gitlab 一个就够了，基本涵盖了研发管理全周期了。没有 gitlab 还好说，有 gitlab 还要使用 Jenkins 的，真的有点舍近求远了，除非是有特殊场景。部署目标就常见的 ssh 、docker remote 、k8s api 基本都够用了。

目前在维护的项目就是 spring cloud alibaba on kubernetes 。
- spring cloud + kubernetes 怎么看都有点“皮裤套棉裤”的感觉，有点奇怪但也是历史项目迁移到 kubernetes 最简单的路径
- 有状态的组件比如 eureka 、nacos 等，在 kubernetes 集群上组建自己的集群实现高可用，比较麻烦，特别是服务注册加上拓扑感知等场景，目的是高可用，实现手法却很不高可用的感觉
- spring cloud kubernetes 是个方向，理想的路径应该是 spring cloud 退化到 spring boot + service mesh + kubernetes 的结构，就是把微服务这个东西基础设施化，由研发侧转到运维侧。但涉及到各种人力、技术、资源匹配问题，推进起来应该也比较困难
- 独立的 spring cloud 也有优势，不用和 kubernetes 耦合，非 kubernetes 或非容器化环境也能部署，交付上可能有一点优势
- 有状态组件最好排除在集群外，或者在较稳定的集群上做刚性资源配置或绑定。云端的话建议使用现成的云服务，rocketmq 、redis 、nacos 云厂商都有提供，比自建稳定性会好很多

md5 太粗暴了，好久之前用 python 写过一段算海明距离的图片去重脚本，网上搜搜应该有很多，简单的去重也够用了。

nerdctl 了解一下。

@BAT 感谢解惑，后面折腾下看看。