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

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

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

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

不能。你需要的是网络拓扑规划咨询，而不是买一个你自己也不知道怎么玩的设备。

不喜欢写代码，跟不喜欢写业务扯皮，是一回事吗？

凤凰项目：一个 IT 运维的传奇故事.pdf

sub folder 方式需要下面的程序或者至少它用到的 web 框架按照“我知道自己有可能被苦逼的主人放在一个 sub folder 下面，所以有配置选项让我按照 sub folder 来生成 URL”设计过才行，并不是前端反代做了改写就能搞定的

建议用教育网的。教育网的镜像站不存在商业成本压力，唯一问题是有没有稳定的维护团队。这年头还活着而且在规模变大的教育网镜像（就差直接报清华金枪鱼身份证了），都是久经考验的。

你在家里装虚拟化环境，虚拟机能桥接后直接上网，是因为网络接入的功能是在路由器上完成的，公网 IP 是在路由器的 WAN 侧，ESXi 和虚拟机都是在路由器的 LAN 侧，连外网是路由器做 NAT 搞定的。所以托管到机房同样也是需要一个路由器，唯一区别是路由器在家里用的 PPPoE 认证，ISP 动态分配 IP ，到了机房，是在路由器上直接做 WAN 侧配置。

最简单的方法是再带一个路由器进去，WAN 口插上机房的网线，LAN 口接到服务器上，然后路由器做一个端口映射，把 ESXi 的 web 管理端口暴露到外网。这样你可以在家里登录 ESXi 后安装虚拟机。

你提到的 ESXi 里建内网，是个理论上可行的高级办法。但是，我记不得一个纯纯的 ESXi 在没装 vCenter 的情况下能不能建没有物理端口的 vDS 了……大概是不行的。而且，即使用了这个办法，并不是桥接一下就能上网的，仍然需要一个“路由器”，只不过这个路由器是要创建一个双网口的虚拟机来担任。

当然，如果机房能给你足够 IP ，甚至直接给你一个网段，那你随便桥接好了。你贴过来的信息，看不出来是给的单个 IP 还是整个网段。

另外的另外，虽然哦我提到“把 ESXi 的 web 管理端口暴露到外网”，这个只是顺着你能快速方便操作的思路来的，其实并不建议这样做。

竟然有一种槽点太多以至于不知道从哪里开始吐起的感觉。

你需要的不是 VLAN 怎么建的操作指导，而是需要先做网络规划。

导师不管选题的？

@SillyAdam 对内网服务确实是个很实际的需求。自己维护一个给内网用的 CA 其实还是很麻烦的，能用 well known CA 链还是不要自己折腾为妙。而且，你说的不信任 DNS 记录权限给工具还算好的了，这是你自己评估之后的结果。还有一种扯蛋的情况是，DNS 是信息化部门负责的，开通域名要按 A 记录逐条签署安全责任书申请审批，根本不下放子域名解析权给二级业务单位。

这事有段时间被开源社区铺天盖地骂

如果打算用 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 ，但跟现在互联网流派的架构还是有很大区别的。虽然从互联网生态出来的架构师鄙视和抵制这种架构，但……其实没有绝对的谁先进谁落后，根本上还是有锤皆钉吧。