和 pve 对标的是 hyper-v server ，或者说 windows server with hyper-v ，用来装在服务器上做虚拟化集群的，可以没有 GUI （没错，windows server 也可以没有 GUI ），即使有，也很少需要在服务器的 console 上直接操作。
windows 10 上装 hyper-v ，虽然跟服务器是一样的 hyper-v 核心，但产品定位不一样，是以本机桌面操作为主，小规模的虚拟机应用。Linux 生态下跟这种用法对标的，应该是装一个 Linux 发行版的桌面组件，在里面做各种日常工作，需要用虚拟机运行其它系统时通过 libvirt 或它的 GUI 前端启动 qemu+kvm ，而不是用 PVE 。

靠纯 nginx 的配置可以做到，不过麻烦，不如上一个 API 网关，kong 或者 apisix

普遍现象，这玩意就是模拟一个显示器，支持更多分辨率是增加成本的。
负责任的卖家会在采集卡详情页介绍提支持哪些分辨率的。

@felixcode 我怀疑甚至可能是用了某些云服务商（尤其是国内），只有 old stable 甚至 old old stable ，毕竟当前的 stable 是 bullseye ，python3 是 3.9 也不算旧了

no silver bullet 啊。

作为一个从互联网时代之前走过来的甲方老运维，见过太多只想用主流的工程型编程语言写业务功能、当一个“纯程序员”而避开运维、安全、数据库等关联知识的人了。然而，除非是有一个完整的大团队，纯程避开了的这些事有专业角色来承担，否则，在大多数小团队里程序员多少也都要承担一些的，没有真正的纯程。

还是抽空静下心来循序渐进了解一些运维知识吧。至少，知道生产环境下的要求除了要用编程语言正确实现业务功能之外，还有很多其他靠考虑的东西。稍微学一些，反过来也对你的开发有帮助。运维看起来知识点多且杂乱，难以速成，但没有什么太大的难点，慢慢攒经验也好的。

当然，云服务商的 PaaS 、application engine 以致 serverless 之类的确是解决你痛点的好办法。但是你自己也清楚，这些好东西也各有其应用场景和限制，不一定总是适用。

人在刚需之外总会有一些不是很刚但也不是可有可无的弹需。
不同的人、不同的人生状态，这些弹需可能会侧重不同方面。

C:\Users\用户名\Documents 保存好，腾讯系聊天软件微信和 QQ 没任何问题

Linux 内核有 watchdog API ，可以 ioctl 统一操作，前提是有驱动
如果主板是 ITE 的 superio ，那大概是 it87_wdt

@wellsc 白马非马，rpy 也算 py 吗？

推荐这本
https://www.ituring.com.cn/book/2622

所以问问题最好是直接讲清楚原始需求，而不是自己先猜测一个解决办法，再问这个解决办法如何实现。

@pugaizai 所以我说这是一个 X-Y 问题，你需要做的是学习操作系统运维知识，而不是找一个没有操作系统就能运行的 Python……事实上不论是 MicroPython 还是其它几个 toy 级的无操作系统 Python 实现都不是你需要的东西。

另外，Debian 11 里带的 Python 3 是 3.9 版，不算低了吧。

写作业？

@also24 可以理解为把 Grub 作为一个丐版的操作系统……

@pugaizai 然后装了一堆 Python 包，体积也会大起来，尤其是其中还有非纯 Python 实现的包，依赖额外的 C 库……这些 C 库的 build & install 折腾死人，然后你发现还不如用一个正常的发行版

Python 这种连自举都不能的语言哪配得上“==操作系统”……
要么你用 MicroPython 的单片机，不过那玩意不论是性能还是生态应该都不是你想要的东西。
你可能不是科班出身，对计算机系统的理解有问题。操作系统这玩意，从业务角度是看不到也不需要的，但如果没有它，你自己要做的事就太多了。正是因为信息系统的分层架构模式，才能让写业务的人专心写业务不用关注底层技术实现。如果没有操作系统，又想运行 Python ，那 Python 解释器的实现者可能要自己去处理各种硬件的底层操作，而且还要适配各种硬件。你轻轻祭起你认为“只要……就好”的 Python 写出业务代码“岁月静好”，但代价是底层的 C 库、操作系统在“负重前行”处理了让人望而生畏的肮脏细节。

其实这是一个 X-Y 问题，你提出的“只需要运行 Python”并不是真正的需求，不如讲一下为什么不想要操作系统……如果是嫌运行在正常的 Linux 发行版里体积大的话，那就可以用轻量级的发行版，实在不行还可以自己做裁剪（尽管以你的知识水平和经验目前这个做法不现实）。但是操作系统的基础组件是逃不掉的，很多 Python 包依赖的下层 C 库也是逃不掉的。

可以用更轻量级的发行版比如 Alpine……

咱就不提操作系统作为一个管理硬件的抽象层很难去掉。就说在操作系统里运行的程序，也许你写业务代码只直接用到 Python ，但用的功能模块还要依赖各种 C 库，所以 pip 之外的 C 库包管理也是必要的。

@fantix 用 Rust 自己轮一个后端感觉不是很有必要，毕竟 PG 的“后端”已经足够强大和成熟，而且 EdgeDB 针对的主要痛点不是后端，而是前端。不如（假如你们团队能搞定 PG 上游的话）对 PG 重新做架构，把语言 parser 和网络协议 listener 都解耦出来，语言上想用 SQL 用 SQL ，想用 EdgeQL 用 EdgeQL ，网络协议上想用 PG wire 用 PG wire ，想用基于 HTTP 的就用基于 HTTP 的……

看标题就想到了 EdgeDB ，没想到居然是开发者的贴