写的很好，条理清晰。作为一个用户，从自身利益角度，支持 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 感谢解惑，后面折腾下看看。

名字还挺多，这个在我的互联网记忆里叫仓鼠症。
备份策略可能难以实施，一般备份的都是个人创造的、不可再生的资源。能够从网络下载到的一般很难被分类为不可再生，除非真的是孤本，下载的很困难，这又涉及一个评估和分级问题。另外，影视资源一般比较大，备份的话成本也有些高。

睡一觉醒来可以理解为充满电，恢复精力。早睡早起就是把最有电，最有精力的时间留给自己，比迫于生活消耗完自己大把精力和时间，晚上留给自己两三个小时垃圾时间强多了。
有些人可能早起犯迷糊，还是看个人体质。本质是定位自己最有价值时间段，然后想办法用到自己最想做的事情上。

一直有个困惑，刮削会更改原文件，PT 就无法保种了吧。

先限定一下是仅限内网自建，还是说可以选择公网服务。

在用 Azure DevOps Server ，推荐 Gitlab 。

@cabbage 没记错的话，Windows 是有原生容器的，不需要 Linux 虚拟机支持。当然，基于 windows 平台封装镜像的应用相对较少。

好用，但有缺点，所有没有真香。
主要缺点就是噪音，并且是长时间噪音，烘一次一两个小时。如果屋子比较小或者安装位置没有较好的隔音，整个房间都能听到声音，半个小时就忍忍了，一两个小时基本算难受级别了。
整体上能处理好噪音就推荐，不太好处理噪音北方倾向不推荐，南方倾向推荐。