@sucaiking #9 imgur 可能把你 block 了。换个节点试试

开源的另一层意思是：本质上没有人为你的体验负责，你需要为自己负责；因为你有查看、修改所有东西的自由，你也要为之付出代价。

如果一个发行版什么都不需要用户做就能满足大多数人需求，它必定是高度耦合的、定制化的、难以修改的。例如 Ubuntu 等，macOS 也算一个这样的系统。Windows 则是因为用户基数太大了，前人栽树后人乘凉。

如果你连「安装桌面主题」「下很多插件」的时间成本都难以负担，也不能接受 Ubuntu 的极少「小 bug 」（相对其他发行版来说真的很少了），并且没有动力去付出学习新知识的成本，那么我觉得 Linux 并不适合你。还是老老实实用原来的系统吧。

先纠正 1 楼的回答。

> 久了卡应该是常驻的应用被优先安排到了虚拟内存

「虚拟内存」是指「用户进程不能访问真实物理内存地址，只能看到分给自己的内存映射」，是操作系统的一种设计。你指的应该是「交换空间」/「页面文件」这种技术。

在 SSD 上，一般应用（如 QQ 、微信）换入/换出交换空间只需不到 200 毫秒时间，和楼主说的「十几天」的跨度应该对不上。

> 久了后还是会被移动到虚拟内存里

操作系统一般不会闲着没事把软件移动到交换空间里，最多在闲时进行内存压缩。但这也不影响性能。

----

然后回答楼主的问题。对系统流畅度造成压力的一般就是 CPU 、内存和 I/O 三大部件。先说结论：最可能出问题的是内存。

1. CPU：随着运行时间增长，一些设计不良的软件更可能进入一些错误状态（例如某软件每小时发生一次并发访问，而开发者根本没考虑并发问题。随着运行时间增长，程序越来越可能发生死锁或死循环）。然而这样的情况少之又少，一般来说异常的进程会直接占满 CPU ，很容易被察觉。

楼主说的「占用接近 100% 的 cpu 」「所有软件 cpu 没怎么占用(10%)」，我猜是指看到的瞬时占用。这个数值没多大意义，和卡顿与否无关，需要取一段时间的平均值。可参考 Linux 上的 load 。

2. 内存：类似的，一些设计不良的软件可能发生内存泄露（微软自己的 explorer.exe 和 dwm.exe 到今天还会偶发内存泄漏问题，更不要说一般开发者了），这是最主要的原因。内存泄漏将持续增加资源占用，最终触发内存交换，拖慢系统速度。

这里比较重要的指标可能是提交总量，75% 应该是物理内存的实际占用，大量交换可能已经发生了。

3. I/O：主要是 SSD 、显卡、网卡等。这个就看具体设备的驱动是否有缺陷、是否经过完备的测试了。

天气软件最重要的还是数据源和准确度吧。

当地气象局：应用商店搜 xx （城市名）+ 气象。特点：第一手信息，天气实况最为及时；

中国气象局公共气象服务中心：中国天气网、MSN 天气。特点：国家官方，较为权威；

国家气象信息中心：气象实况 METEO LIVE 小程序。特点：国家官方，信息较为专业丰富。

AccuWeather （华风爱科合作）：中国天气 App 。特点：使用 AccuWeather 技术，相对准确；

墨迹风云：墨迹天气 App 、小米天气 App 。特点：服务时间长的商业产品，较为稳定；

彩云科技：彩云天气 App 。特点：自研 AI 模型预测，较为准确。

莉景科技：莉景天气 App 。特点：侧重气象对自然摄影和天文摄影的影响，提供云量、霞、雾凇预测服务。

其他来源：Open Weather 、Weather Channel 、AccuWeather 、Flowx 、天文通、晴天钟…… 一般都是 NCEP GFS 之类的通用国际气象模型，看看就行了。


可能整理有误，烦请指正。

AnyType 理念先进得多，还是去中心化+加密。可以了解一下。

没必要。


Docker 是应用容器，这决定它就是用来跑单个应用而非系统的，在设计上其他场景里就只会带来不方便，例如不可变的资源配置和端口映射等；

无头系统容器的解决方案一般是 Canonical 的 LXD 或者更开放的 Incus ，支持运行时配置和资源调配，都是基于 LXC 和 KVM 两套接口。

也可以用 PVE 或 ESXi 等虚拟机管理器，但这就要求重装系统，看你自己选择。

@w568w 添加 LSP 服务器的过程也很清晰，实际上只需要修改 mason-lspconfig 的配置，最短只需要添加一行（第一步）：

1. 在 mason.nvim 官网上查询 lsp 服务器名称，在 mason-lspconfig.nvim 处添加新的包；
2. 在 nvim-lspconfig 文档里查询对应的配置选项，在 mason-lspconfig.nvim 处配置 lsp 服务器；
3. 重启，完成包的安装，结束。

弄清楚关系就好理解了，每个插件都是各司其职，互相功能没有交集：

# LSP

nvim 自身有 LSP 支持，能够根据不同文件类型启动并连接到对应的 LSP 服务器。

- nvim-lspconfig：nvim 官方维护。收集了常见 LSP 服务器的配置选项，提供统一的 Lua 配置接口，用于更改服务器的具体设置；

# 自动补全

- nvim-cmp：提供自动补全 UI ，可以添加插件，从不同源获得补全建议；

- cmp-nvim-lsp：nvim-cmp 的一个插件，为 nvim-cmp 添加 LSP 源；

# 包管理器

- mason.nvim：一个包管理器，用于安装不是 nvim 插件的其他包和二进制程序（例如 lsp 服务器）；

- mason-lspconfig.nvim：mason.nvim 的一个插件，用于方便地启用和配置 mason 下载的 lsp 服务器程序。配置接口仍由 nvim-lspconfig 提供；

# 其他

- lsp-zero.nvim：没用过。看了下是个懒人配置包，没有特别去用的必要。

详细说明一下你是什么发行版，安装了哪些软件。

Linux 服务器没有统一的清垃圾方法，请求他人提供一个一键清理脚本是不现实的：作为系统管理员，你应该知道自己的服务器上装了什么，因为每个文件都直接或间接是你自己亲手敲命令造成的，也不是别人给你偷偷塞的。

先用 gdu 确定大文件占用部分，然后用对应的方法来清理。例如 var 占空间大，多半是因为 docker 镜像下载了之后不知道要删除，按楼上的命令操作即可。

@w568w #2 仔细读了一下 spec 原来是统一的，那没事了。

补充一句：感觉最后可能会演变成，第三方库分为 return 派和 raise 派各自为政……

这个错误处理的设计是出于什么思想？看起来很像 Ziglang/Rust 的「错误即返回值」模式和传统的 Exception 模式杂糅在一起……

如何保证不会提高处理错误的复杂度？原先只需要考虑一种错误，现在要同时考虑两种可能的异常程序流了

@ysc3839 #12

> MasterKey 漏洞不足以实现权限管理

我去查了一下，发现了一些分析的博文 [1]。LBE 是否单纯利用此系列漏洞实现权限管理存疑，但当年的 Android 权限管理并没有现在这么严格，以此漏洞作为跳板实现 ROOT 提权应该是可行的。

[1] https://blog.csdn.net/androidsecurity/article/details/13293789

补充一下上面的评论。

LBE 是第一个提出主动防御概念的，当年也是红极一时。

刚才搜了一下，LBE 安全大师大概 2013 年左右提出 [1]，利用最广泛的应该是当年的签名漏洞 MasterKey [2]：Android 系统对 .apk 包内同名的文件，只会校验第一个文件的签名，因此可以对系统应用创建第二个 classes.dex 来绕过签名检测、获得系统签名权限，360 极客版应该也利用了类似的漏洞。接下来要做的事就很简单了，Hook 不同 API 在原生层面是很容易实现的事。

360 极客版 14 年推出、17 年停更 [3]，LBE 安全大师 19 年停更 [4]，现在 LBE 唯一运营的产品应该就是 LBE 平行空间了。

360 极客版另一个学习的应该是 oasisfeng （即「绿色守护」开发者）的休眠机制，可以说是集众家之长的成果。今天，这些功能都已集成进 Android API 或国产 ROM 底层了，极客版们自然就不复存在。现在是 Magisk/KernelSU 、Xposed 的时代。


[1] https://sspai.com/post/19595
[2] https://nvd.nist.gov/vuln/detail/CVE-2013-4787
[3] https://bbs.360.cn/thread-15205527-1-1.html
[4] https://www.lbesec.com/#/products/2