#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

首先通过 du / df /ncdu 定位到是谁占用了存储，如果是 Mongo 数据那就得看数据能不能删除，或者机器能不能扩容了。

如果是日志太大，docker compose 有参数可以限制日志文件大小：
https://stackoverflow.com/questions/39078715/specify-max-log-json-file-size-in-docker-compose

清理日志这方面，可以停机的话就直接 docker-compose down 再 up ，停机会有问题的话可以直接 root 用户下运行这个命令把日志清空:

echo '' > /path/to/log/file

我也遇到了，两个账号同时在我刚开的 issue 下回复了一模一样的内容，我感觉就问题就都删除掉了

bitwarden 需要自建 server ，如果喜欢 keepass 这类 serverless 方案的话，我比较推荐 pass ，完全基于 gpg 实现的，跨平台支持也很好：

https://www.passwordstore.org/

neovim 再配合个 tmux/zellij ，远程开发没任何毛病。

@spf13579 我以前也对平铺有点畏惧感，以为必须脱离鼠标。
后面用上 i3 后才发现，鼠标仍然可以正常用啊，再记住几个常用快捷键，使用就没任何困难了。
neovim 也一样，没必要一步到位纯键盘操作，感觉配合鼠标使用也挺爽的。

顺便我现在用的也是 hyprland ，主要动画效果做得不错。

补充：
yazi 配合 neovim 可以很方便地对文件夹与文本文件做各种搜索、修改、选择与其他各种批量操作，zoxide 用于快速跳转，rofi/wofi/anyrun 这类启动器配合插件也能实现计算器、运行 shell 命令、表情搜索、翻译、中英字典、网络搜索等功能。

这套我用得挺舒服的，yazi 的批量操作功能相当强大，多选复制粘贴、批量重命名，用了都说好~

@spf13579 #2 深度点的 Linux 用户可能感觉大都用上 Window Manager 了，本来也不咋 care GUI 的东西。

GUI 的东西我不了解，我都一年多没用过 GUI 的 File Manager 了。
TUI 方面一个可能的解决方案是：yazi + fzf + zoxide + neovim + rofi/wofi

https://github.com/sxyazi/yazi (一个相当强大的 TUI 文件管理器，配合 kitty/wezterm 使用体验绝佳)
https://github.com/ajeetdsouza/zoxide (#8 推荐过了)
https://github.com/AstroNvim/AstroNvim (一个 neovim distro)
https://wiki.archlinux.org/title/Rofi (应用启动器)

nix 没有 namespace 这种东西，但有个 profile.

profile 的实现逻辑是，所有包都是从 /nix/store 中引用的，所以重复的包不会导致任何数据被重复保存，这也是中心化存储的好处之一。

中心化存储的缺点是需要基于引用计数等方式做软件包的垃圾回收，因为卸载一个软件包实际并不能立即从存储中删掉它，还得确保这个版本的包没有被其他环境引用。

而且每个软件的不同版本都保存在不同的文件夹中，从而能够在 /nix/store 中共存...

大概是这样

（不小心发出去了，继续）应该知道，编程语言的包都是中心化存储在 ~/.m2 node_modules ~/go 里面的，而且不同的软件包能够共存（请忽略掉 python...）。

nix 同样如此，所有软件包都存在 /nix/store 里面，而且不同版本