家里长辈可能还是有必要去看看的，年纪大了，可能是见一面少一面，谁都不知道是不是最后一面。哎

2024 年了，就试试 systemd 吧，不要再看 10 年前的教程了。
不过我猜你找的可能是 tmux 。

@daisyfloor 是的，我现在也是比较早的那批用户，你看下你的账号下有没有绑定邮箱的吧，之前买断过的用户都送了一个终生的 pro 订阅。这个订阅是根据邮箱走的，绑定邮箱就行了。

以前 enpass 是买断的，后来改成订阅制。然后他们就把原来买断的用户升级成了终生的 pro 版本，和邮箱绑定。

现在是只要新设备安装后，用邮箱验证一下，就能解锁 pro 。

我用的就是 openvpn ，上面说的三点需求基本都能满足。

缺点就是 ldap 支持好像不太好，虽然用 pam+ldap 可以勉强实现用账号密码登录，但是貌似配置后不能推送路由和设置固定 ip(可能是我配置得不对)

不过总的来说问题不大，就是设备第一次连接的时候需要生成一次证书，设备都是固定的那几台。

用 lua 脚本去实现比较方便。我有个网站就这么做的，访问一个特定的 url 后，lua 脚本里面获取客户端的 ip ，把 ip 加入到白名单，白名单有效时间几个小时。

xx@opsc:/data/www/lua$ cat save_ip.lua
-- save_ip.lua
-- 获 取 客 户 端 IP 地 址
local client_ip = ngx.var.remote_addr
-- 设 置 shared dictionary 的 名 称 和 键
local dict_name = "ip_dict"
local dict_key = client_ip
-- 设 置 过 期 时 间 为 3600 秒 （ 1 小 时 ）
local expire_time = 28800
-- 将 IP 保 存 到 shared dictionary 并 设 置 过 期 时 间
local ok, err = ngx.shared[dict_name]:set(dict_key, true, expire_time)
if not ok then
ngx.log(ngx.ERR, "Failed to save IP in dictionary: ", err)
ngx.exit(500)
end
ngx.header.content_type = "text/plain"
ngx.say('Added: ', client_ip)
ngx.log(ngx.INFO, "IP saved: ", client_ip)
xx@opsc:/data/www/lua$ cat check_ip.lua
-- check_ip.lua
--
-- nginx.conf: lua_shared_dict ip_dict 10m;
-- 获 取 客 户 端 IP 地 址
local client_ip = ngx.var.remote_addr
-- 设 置 shared dictionary 的 名 称 和 键
local dict_name = "ip_dict"
local dict_key = client_ip
-- 设 置 白 名 单 ， 这 里 假 设 白 名 单 为 一 个 Lua table
local whitelist = {
["127.0.0.1"] = true,
["10.10.0.1"] = true,
-- 添 加 其 他 白 名 单 IP
}
-- 检 查 是 否 在 白 名 单 中
if whitelist[client_ip] then
ngx.log(ngx.INFO, "IP is in whitelist: ", client_ip)
else
-- 检 查 shared dictionary 中 是 否 存 在 客 户 端 IP
local ip_found = ngx.shared[dict_name]:get(dict_key)
-- 如 果 IP 不 存 在 ， 则 返 回 403
if not ip_found then
ngx.log(ngx.INFO, "IP not found: ", client_ip)
ngx.exit(403)
end
ngx.log(ngx.INFO, "IP found: ", client_ip)
end

我倒是希望 google 能老老实实彻底删除，而不是标记删除。

不说用户体验怎么样，不得不说这个键盘的候选词广告想法确实超前，不光超前，还实现了。

根据输入内容，直接用候选词的方式推送广告，从源头出发拿到用户的一手数据，直接甩掉了各种中间商。速度也更快，更精确的投送。

可以说是真 nb 呀

自带的 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 。

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