AI 比较容易搞定从青鸟/达内/蓝翔/etc 出来的转码程序员所从事的工作。

ibkr

至于 eunm 会不会更快，当然是不会。类型系统的完备性，不是为了性能，而是为了有更严谨的数据一致性约束。也就是减少程序的 bug 。但有些人认为这是多余的负担。

数值类型只有作为基数（表示数量多少）和序数（表示先后顺序）使用时才有大小的语义。作为枚举类型的值，没有大小语义。

你可能以为，一个业务流程状态是序数，因为你很清楚流程是一路流转下来的。但实际上的流程，中间可能有分支、回转、跳跃。比如因为有特殊要求中途补付一些钱，比如物流弄丢了重新发货。这里每个节点使用的数字，只是为了把这个节点和其它的区别开，并没有任何大小的意义，所谓的 1 与 2 之间，只是莫某个节点与另一个节点之间，1 不是 1 ，2 也不是 2 。

换个角度想，如果用文字类型来描述，难不成能你也要让业务流程中的每个状态的名字恰好是按字典顺序从小到大？为什么用数值类型你就要有这种追求呢？

我非常讨厌一些互联网行业“毕业”后做信息化的人以及盲目追随互联网布道的原生信息化人。

@BreadBig varchar 也有 varchar 的问题。这个类型在不同数据库上的长度计算单位不一样，有的是字节，有的是字符。

连管晨辰都不敢安装

@Aluhao 如果你是做业务逻辑比较复杂的信息化类型应用，新项目可以考虑上 PG 了，体验一把在严谨的数据库上认真设计数据模型、靠数据库的约束机制来保证一致性是什么样子。反正 PG 属于那种不太熟也不会踩出怪坑来的稳妥玩意儿。

人家在特定业务领域做了多少年，早就有有醇厚香浓的屎山积累。

不需要带 GUI 的 session manager 、在纯粹的终端仿真器里敲 ssh 命令的人，可能是做开发或者不接触业务系统运维的纯 infra 技术人吧。
如果是需要做业务系统的服务器运维，当你所在单位有 x 个业务部门，每个部门有 y 个系统，每个系统有 z 个服务器的时候，乘起来的数量滚动几屏。只靠在.ssh/config 里写一堆 Host……写完谁记得写了个啥。用各种乱七八糟的业务名词，做技术的人哪记得住，就算能敲补全都不知道先输入个残缺不全的啥片段再补起，简直是春池嫣韵。这时候，有个 GUI 的 session manager ，从树形结构里一堆写好的狗屁条目里视觉匹配出技术人不擅长记忆的业务名词，感谢 Xerox PARC 发明了 GUI ！

@Cu635
https://ecology.chinauos.com/adaptidentification/notes/#info?type=%E7%BB%9F%E4%BF%A1%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%93%8D%E4%BD%9C%E7%B3%BB%E7%BB%9F

后缀有 d 的只到 1050

@Cu635 但是如果有信创要求的话 Deepin 的社区版是不行的，真得要 uos ，而且 uos 也分桌面版和服务器版，服务器版有 a 、e 、d 三个分支，分别来自 Anolis 、Euler 和 Debian ，但 Debian 的这个版本只到 v1050 ，后面 1060 、1070 都没有更新。不知道只是暂时的还是就这么断了。

富文本不加。

纯文本首先采取“从主”原则。
主文种是西文的，局部嵌入中文，加。
主文种是中文的，局部嵌入西文词句，不加；但 URL 后是中文的，加（相信 v 友们都遇到过一些论坛里自动识别的 URL 会把后面汉字连上的情况吧）；中文标点符号后是西文的，加（方便断行识别）。

其实花钱是最简单的办法

@june4 因为网站要面对开发者不可控的浏览器种类，兼容性是必须要处理的，而做桌面软件，如果能通过确定的运行时环境来保证内嵌的浏览器行为是可控的，自然可以省掉兼容性处理的成本，无非就是衡量一下因为体积给用户带来的反感而导致的潜在损失和为了处理操作系统自带 webview 兼容性问题导致的成本哪个更重要罢了。

“小工具类的也上 electron 怎么好意思的”倒是说到点子上了。比如做特定平台的小工具（不涉及跨平台兼容性适配），界面又想用 web 技术栈，还是可以考虑的。Tauri 确实不适合所有场景，但也不是没有场景可用。

另外，16 条千兆宽带，这个总带宽，恐怕大多数 V 友是没经验的。有经验的又大多是搞机房内部网络的。单从你讲得不是很详细的语言，也不好妄断该怎么做。

想多了，证书文件只是普通文件，对 Linux 内核来说跟其它文件没有什么不同。
不如先找一个能登录的其它用户，加入 ssl 组，看看能不能打开证书文件。