自带的 systemd? 复制一份 service 配置文件，配置好目录和启动命令。
systemctl start/stop/status/edit xxx

缺点是看不到端口，不过你可以把端口写在备注里，使用 status 的时候一样也能看到。

候补还是有用的，确实是更公平了。
“先来后到” 是公平的没啥问题，但是它公平的前提是每个人都要在同一个起点。
候补这个功能能让大多数没法刷票的人、有概率购买到车票。我觉得是没问题的。
然后车就这么多，肯定会有人买不到合适的票，上不了车，这个除了增加班次和座位，也无解了。

现在这个时候就先别找工作了，安心等等年后再看吧。
把注意力转移一下，不要焦虑抑郁了。

可能不是重启了，是自动休眠了，pve 好像有 bug ，休眠后好像唤醒有问题，如果是这样的话关掉休眠就好了。
ltsc 更新的频率已经很低了，更新后自动重启的概率很小。
换成 server 版的也是个解决办法。

我自己也经常遇到，有时候找个项目，点开 github ，发现已经 star 过了。我 github star 里面有大概 500 多个仓库，里面可能有 1/10 一点印象也没有。

@xudashan 看了一下，不是上周的项目。提交记录和 PR 记录，最早可以追溯到 2019 年，实际的项目启动时间甚至更早。搜索了一下，这个项目 v 站上也有很多人推荐过，我自己也有点印象。我感觉还是你以前看到过，随手给点了 star ，后来太久没关注就忘了

要么以前点错了，要么以前点过现在忘了。

最近刚换了魅族 21 。系统体验感觉还是不错，可以明显感觉到产品在设计的时候是有在打磨系统体验，而不是在简单的组合拼接定制应用程序。

贴一个罗翔的视频： https://www.bilibili.com/video/BV1r3411v7Ta/
他的这个观点我是赞正的。

感觉这个问题无解，要么牺牲掉一部份内存，要么放弃 dump 。
如果限制容器使用 2G 内存，这个时候设置 MaxRAMPercentage=25.0 ，那么 JVM 它就只使用 0.5G ，浪费了 1.5G 。

我感觉 oom dump 这个操作，是不适合放在容器里面执行的，一个原因是，dump 没控制好的情况下，会占用非常多的 CPU 资源，磁盘读写的压力也比较大。另外 dump 的时候也没办法处理请求，但是容器还是会接收请求，再加上重复的触发 dump ，就会有中断。而且有时候还没 dump 完，容器就因为健康检查被结束了，dump 了个寂寞。

所以我选择 java 在容器中时，不要 dump 。发现有内存泄漏的时候，再单独跑实例去复现问题，再执行 dump 。

还有个就是尽可能的测算出程序保证正常性能的情况下，到底需要多少内存，根据这个来指定值，应该是比较合理的方式。

那个财富榜单是要充值才能上的，某种意义上可以说是个“广告位”。

挂代理应该是体验相对来说最好的（ 在路由器上开代理 )，本地的客户端无感。

@tomjam 那这就不太清楚了。。

感觉像是梯子不行

如果不在乎代码加密问题的话。感觉用 venv 不如用 python 的 embeddable 安装包，解压就是一个 python 环境，也不需要其他的依赖，双击就可以运行。把程序包放在一起，再配合一个 run.bat 脚本。

所以有没有可能，在你的这种场景下并不适合用 docker-compose 来调试程序，程序调试的时候，直接在本机跑和调试，应该是最方便的。看了你的 docker-compose.yml ，也是感觉不用 docker-compose 应该是一个更好的选择。

手上的键盘已经用 6 年了，国产的 niz 。

不知道为啥这么设计，但是不得不说，适应了之后，这套键位确实舒服。可能是向下使用的频率更高吧，加上正好食指也放在 J 上，H L 对应左右，也是相当有趣的，还有就是，H 需要移动手指，正好向左移动也是一个低频操作。

感觉设计这个键位的人也是个人才，它没有采用 WASD 这样的上下左右。