@dongsuo #41 能给你一些帮助那就再好不过啦～ 就如我导员所说的，「选择不是只对只错」，不用太纠结过去的选择，脚踏实地一步步往前走吧，愿你我都能获得自己想要的。

tql 真的🐂

@coolcoffee 阿里适配还算积极，我 19 年就用过，但总体成熟度肯定不如 aws 了，要踩坑。

我是 19 年从安徽跑来深圳，当时的想法是破釜沉舟。
现在也 5 年多快 6 年了，虽然混得没 OP 这么好，但也还算不错。

去年我也在 v 站分享了我的一些流水账: https://www.v2ex.com/t/966753#reply57

现在环境确实不太好，但从我的角度看，历史的垃圾时间倒也算不上，近两年反而是我过得最开心的一段时间。
当然这很重要的原因跟我是孑然一身，没任何外部压力，选择自由度上大很多。

虽然工资也不算高，但偶尔甚至会疑惑，赚这么多钱干啥... 单身狗一只，平常能花点钱的也就是电子产品、徒步旅行、乐器这点爱好。
或许有这些原因，去年开始赞助我用过的各种开源项目、B 站上高质量视频的作者，钱不多，但积少成多，让个人开发者与小创作团队多条赚钱的路子，是我个人的一点小心愿。

但企业方面的产品，AWS 确实比国内一票云产商的东西更好用。
面向个人的话，国内的腾讯云阿里云，反而有许多做得比 AWS 更好。

terraform 基本能解决需要各种手动繁琐配置的问题，不过 AWS 本身的复杂度很难避免，用 terraform 也得一点点配参数。
AWS 的计费逻辑跟产品设计都很复杂...

我也是因为手腕疼，在公司是换了妙控板 + 带手托的鼠标垫，用着非常爽，手腕再也不疼了。
另外在家是买了 45% 倾斜的那种人体工学鼠标，实测手腕也不疼，用习惯了也挺舒服的。

cilium 需要规模够大才能体现出优势吧，否则用 flannel/calico 也挺 OK 的

个人 homelab 用的 fluxcd, 所有配置都公开的

https://github.com/ryan4yin/k8s-gitops/

赞！

#5 你 limits 跟 requests 都没配，这怎么让 k8s 调度，k8s 管理资源的核心逻辑是 HPA VPA 动态扩缩容，不是把旧的 Pod 删掉，在大机器上给你跑个新的。
建议找个 k8s 教程先学一学吧。

@cnt2ex 哇这个好啊，我可以直接把这个配置抄到我的 nixpak 配置里，这样体验是一致的，而且也能声明式。

#4

「前端加密是形式主义安全的要求，前端加密完全阻止不了被劫持或者被恶意浏览器插件直接注入 js 读取输入框里的明文密码。」

没有什么技术能解决所有问题啊，你不能因为一项技术没解决掉个别问题，就认为它完全是形式主义。
类似深信服之类的技术在你电脑里装它的证书从而监控你所有 HTTPS 流量的明文内容，而前端加密至少能保证你的明文密码不会泄漏给公司。
上面也有 v2 友提了，明文密码泄漏要比 Hash 泄漏严重得多，用户其他站点也可能因为你们前端没做 Hash ，被黑客一举攻破。

另外一点是，HTTPS 并不总是安全的，不要总觉得用了 HTTPS 就多安全，TLS 从 SSL1.0 迭代到现在 TLS1.3 ，一堆的弱密码，实际安全性还是得看客户端与服务端的两边的具体配置。

对 OP 引用的前一个帖子一些观点的反驳：

1. https + 后端加密入库足够安全：这得看具体的流量链路架构，单纯从你前后端看可能感觉都很安全，但中间是否过了 CDN 加速？是否做了 TLS 的边缘端及早截止（ https://0xffff.one/d/968 ）？即使你做这个决定时系统是够安全的，但 infra 团队不一定知道啊，他们对中间这些链路做的任何变更都可能会破坏你的安全假设。所以为了避免沟通成本，强制前端做 Hash 是很合理的选择。
2. 增加开发成本，没必要：前端对密码做个 Hash 就几行代码的事，调用个现成的库就行，这个东西很复杂吗？？？要增加多少开发成本？？？
3. 加密后导致密码强度的下降(因为密文的信息熵下降了)：所有 ASCII 字符数字符号加一起是 94 个，简单计算你的密码需要至少 40 个字符，它的排列数量才能超过 2^256 钟，我还从来没见过谁的密码有这么复杂...


如果你是在什么无所谓安全的小公司工作，公司也没啥要求，那你确实怎么折腾都无所谓，不用管什么哪里加密，想怎么写就怎么写，功能实现了就 OK. 但我个人还是建议养成一点技术上的品味。

本质上仍旧是成本跟安全的平衡，客户端弄个 Hash 就加几行代码的事，就能提升整条链路的安全性，何乐而不为呢？我不明白这事有什么可争的。

@amber0317 flatpak 主要是不够声明式，不过装个 QQ 确实 OK ，我最近在整的 nixpak 也是用了 flatpak 的 bubblewrap ，更可控些，缺点就是配置起来很麻烦。

我再折腾下吧，如果不好搞就换成 flatpak

成年人选择都要

firejail 有很多现成的配置能用，比较方便，但又被很多人喷它的设计有安全问题，不太敢用。

比较理想的可能是做到类似现在 Android/IOS 那种细粒度的 APP 权限控制，bubblewrap 能做到类似的效果，但是要慢慢调试，还挺麻烦的。

1. 采集卡连个手机平板当显示器
2. 整个 IP-KVM
3. 使用默认启用 ssh 的 live cd 启动系统，然后在路由器里查下新分配的 IP 地址，直接 ssh 上去用命令行安装
4. 使用 preseed 自动化装机，但这个在没有屏幕的情况下出了问题无法 debug ，感觉比较适合先调试好配置，再用来批量装机。参考 deiban 文档: https://www.debian.org/releases/bookworm/amd64/apb.en.html