如果打算用 Python 的话，走前后端分离模式用 fastAPI ，走传统的后端渲染模式用 Masonite

另外，当然，docker 可以在一定程度上掩盖这些混乱的问题，当然，也只是掩盖

#9 文件未知 => 文件位置

我尽量用（以及要求乙方的团队来我这里做项目实施时用）发行版打的 deb/rpm 包，或者开源软件的上游“原厂”打的 deb/rpm 包。因为这样的包在文件布局上符合 FSH ，这样我可以凭着经验找到自己需要的文件未知，不论我没用过的什么新软件，都不会给我制造 suprise ，增加心智成本。

如果你见过在同一个项目同一台服务器上 /usr/local/software_name 、 /opt/vendor_name/software_name 、 /home/vendor_name/software_name 、 /srv/project_name/software_name 共存，并且 software_name 有的带版本号有的不带，而同一个 software 的 bin 、config 、logs 都在这个形式不可控的前缀路径下，而且更特么要死的是有的软件会好几个版本都装着，不话点心思根本不知道实际跑的是哪个，软件的启停要登录进去手工开，甚至 nohup 挂后台……然后交付的文档里并没有更新到跟实际情况一致时，你就会像我一样认为，FHS 大法好，FHS 大法妙，FHS 大法呱呱叫。

根据我的经验，terminal 还是不要用浅色了。因为 terminal 里除了配色本身的 theme 之外，还有终端应用程序根据 ANSI 16 color 配出来的应用程序 theme ，比如 ls 的 DIR_COLORS ，这种 theme 一般都是根据深色方案设计的，普通文本是暗色，强调文本是亮色，放在深底色上效果很好，放在浅底色上，强调的反而看不清了，因此需要给支持 theme 的终端应用程序逐个做浅色适配，不支持 theme 的就只能忍着。

把功能齐全的关系数据库仅仅当一堆表用，做单表 crud ，或者少量几个表之间做一层直接匹配的关联查询，其实用 ORM 和直接写 SQL 也没啥区别。用 MySQL 这种残疾货跟用 Oracle 也没啥区别。

ORM 搞不定的是那种，很多老式的业务系统，业务逻辑有很大一部分写在 SQL 里，子查询、窗口函数、触发器、存储过程、CTE 甚至递归 CTE……老式系统里，可能没有 B/S 结构，是 C/S 的，本机运行的 exe 客户端直连数据库，主要是起 UI 的作用……当然，也可以 B/S 方式用 WebUI ，但跟现在互联网流派的架构还是有很大区别的。虽然从互联网生态出来的架构师鄙视和抵制这种架构，但……其实没有绝对的谁先进谁落后，根本上还是有锤皆钉吧。

@Serino 同格兰仕微波炉，快了 10 多分钟了。这玩意不带 RTC ，每次重新上电后需要设置时钟。设置完了运行一段时间后就不准。好在只是个添头功能，平时也不会用它作为依据。

太庙不配

对于普通人来说，外语也没啥娱乐的用途。正经的普通人谁赶在字幕组出资源之前看点生肉啊，谁直接下场去和外网网民对线啊。

我的是两家一样的

另外，看答案似乎分为两个流派三条道路：1️⃣终端仿真程序 + session manager + ssh 协议连接功能的一体化工具； 2️⃣终端仿真程序和 ssh 协议连接功能解耦，不谈论前者，后者用标准的 openssh ； 3️⃣终端仿真程序和 ssh 协议连接功能解耦，不谈论后者，前者推荐一个自己用得顺手的终端仿真程序。

哪有什么现代化 SSH 客户端。只有用了前端技术栈做 UI 的手感黏黏糊糊的新派垃圾，和用了原生 UI 技术栈但手感也越来越黏黏糊糊的老派垃圾。

enable 作为孤立的单个词不好翻译，本质上是盲目追求 word-by-word 翻译的问题

这样你这一贴就小而美了

前 7 段和最后一段都可以删掉

比如 HA 和备份，不管你用不用容器，都要自己做。除非你用的容器镜像是已经考虑了的。

没有什么绝对的合适不合适。

容器化解决的问题是什么，不能解决的问题是什么，带来的新问题是什么。

不用容器时的哪些问题在容器里能解决，用了容器仍然要自己解决的怎么解决，容器带来的新问题怎么解决。

这些问题想清楚了就有数了。

加一个带串口控制的 UPS ，断电时靠 UPS 的电让服务器自主关机

并不是孤立地说这事很“危险”。当然可以安全的。但是你这样做了还要安全，自己需要像专业网安人员那样花很多精力做配置和长期维护。也就是说为安全付出的脑力成本明显大于不放公网。

至于用 qc……当然也不是 100%的安全，但是人家有专业团队做维护，而且通过 Saas 方式平摊了到每个用户的维护成本。