adoal

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

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

主要是看这个话题放在什么节点下。很容易说着说着就按技术节点和按照职场节点来看的人谈不到一起了。

你在前面那贴里说，一个 EoL 了好几年的 Windows 服务器，还在用，那被利用了安全漏洞活该……要知道，很多在生产环境的服务器，操作系统 EoL 了继续用的安全风险代价是低于升级、迁移带来的不确定性代价的，甚至还有业务系统开发时遇到操作系统的特定 bug 就按这个 bug 的行为做下去的（可能是来不及等补丁，也可能是开发的人根本就没意识到是 bug ，靠猜测式编程），导致操作系统打补丁都会把业务系统打挂掉。Linux 要好得多，毕竟 SSH 的协议和组件都比较简单专注。虽然历史上也有很扯淡的漏洞，但比起 Windows 来还是放心得多，赌一把也不是不行。

更悲哀的是，这种草台板子式的信息化服务，很可能颤颤巍巍地支撑着一些国计民生服务的公共服务单位运行。甲方和乙方都觉得指不定哪天会挂掉，但不敢动。不动就不动，没爆就好。

@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 会把后面汉字连上的情况吧）；中文标点符号后是西文的，加（方便断行识别）。

我自己管理的服务器从来不封或者改管理端口。但是遇到法人单位的中心机房在网关设备上封 22 和 3389 的，因为，各下属二级业务单位的信息化共用机房，我能把这些管理端口上的安全配置做好，但跟我用同一个机房甚至同一个网段服务器的其它单位，往往是没有技术部门的，负责信息化的是综合办公室里一个文科出身的副主任或者普通科员，一切都靠技术能力浮动范围很大的业务系统开发厂家来搞。然后导致很多 root 弱密码进入。所以管理部门一刀切了，我也没办法。

其实花钱是最简单的办法

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

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