一张图懂得已经看懂了。不懂的，我再多废话几句：
我买的是联想的拯救者，以前也用过ThinkPad。
在我接触过的所有厂商的设备里，联想是唯一一个我装好Fedora/Debian后发现什么驱动都不需要额外安装也能正常用下去的操作系统。
甚至，我在Windows下不想用中国官方特供充斥广告的狗屎图形化驱动软件的时候不得不换了开源替代拯救者工具箱 Lenovo Legion Toolkit
的同一时间，不管是屏幕亮度，键盘背光亮度（Ctrl+Space）还是性能模式切换按键（FN+Q）都已经有完美的快捷键支持。 你能理解Linux下体验先天比Windows更好这件事吗？
买设备回来是为了使用，如果他不好用，那就是💩。
实践证明联想某几条产品线在Linux发行版上体验就是比别家好。
当然，我写这篇文章不是夸联想，目的是告诉你现在Linux发行版使用体验在什么设备上更好。
毕竟，有些东西是从社区长出来的，联想还不配让我拿开源社区无偿劳动的成果给它贴金
首先，在你的终端尝试一条命令：plasma-discover --backends packagekit-backend --mode Update
如果不出意外的话，你的Discover会直接弹出到更新页面并快速的加载完成，这就证明你和我遇到了同一个问题：Flatpak后端拖慢Discover更新页面
那么最快的解决方式显而易见了：sudo dnf remove plasma-discover-flatpak
默认情况下 Fedora KDE Discover会在打开更新页面时加载所有可用后端进行更新包括：packagekit，Flatpak ，Snap
众所周知，后面这俩常见的默认仓库服务器地址在境内可用性处于薛定谔的猫态，你可以进行如下尝试：
xfox@Loong5-76s:~$ flatpak update
正在查找更新…
没有更新。
正在为远程仓库 fedora 更新 appstream 数据
如果你没有使用TUN 模式全局代理我猜你会卡在这个界面很久直到忍不住按下⌃C，Snap也同理。
在任何情况下，优先使用系统原生适配的软件包而不是Flatpak和Snap。Debian就用apt和deb包，Fedora就用dnf和rpm包。
这也是为什么我现在极其厌恶Ubuntu，现状就是Ubuntu正在故意使用Snap替换关键的软件包增大OS资源开销，并且Snap Server并不开源也没有开源替代完全依赖Canonical。Flatpak性能比Snap更好并且允许用户自己搭建新的仓库替代Redhat官方仓库！
综合安全和性能开销，推荐遵循如下降序安装使用软件：
原始软件包 > Flatpak > Snap > Appimage
所以，如果你不得以必须使用更糟糕的软件包，宁可去配一下Flatpak镜像源也最好别碰Snap
我承认我偷懒了，两年前4.2寸墨水屏电子价签改造记录——持续更新 这篇文章当初放了大家鸽子。
作为弥补，我抽空选了这几天晚上带凌晨，把原先可用的代码里的主要内容（寄存器数据等）喂给了DS，然后开始VibeCoding疯狂Debug，总算出了一版能用的。
主要适用于BLOZI 的4.2inch 红白黑三色电子价签，曾经该公司尿崩的时候在淘宝/咸鱼有较大规模流出，当时不做完整一是确实没资料无法彻底整明白，二是整明白了发出来除了让奸商涨价没什么屌用。
这个时间点，货早就出完了，这个规格的价签估计也早就停产换代了，发出来供手上还有留存的垃圾佬娱乐。
仓库地址：epd4in2_dev — ESP8266 驱动 4.2 英寸 三色墨水屏（400×300）
你可能已经发现我的Mastodon上刷了一大串帖子，这正是刚才测试文章同步造成的。
同步使用了项目：FediverseSyncForTypecho 原始仓库为：jkjoy——FediverseSyncForTypecho
原仓库不支持使用代理完成网络请求，使得该插件在某些Mastodon站点被GFW屏蔽的情况下完全无法使用。
我的仓库把Release版本号刷到了1.6.5 主要增加了对http和socks5代理的支持。也是顺便测试借助DeepSeek 彻彻底底Vibe Coding了一回，确实很方便，花小钱办大事，比自己慢慢扣效率高太多了。
本次Vibe Coding使用Visual Studio Code搭配DeepSeek V4 for Copilot Chat
这个项目我自从看到GS在用就注意到了，当时就下载测试发现不支持代理试图自己添加代理支持（简单写死的）可惜学艺不精没一直扣完，太简陋不想公开最终拖到了今天。
我已经尽自己所能的审查了AI生成的代码，但是为了避免Vibe Coding可能潜在的混乱和污染问题，这个仓库的更新我不会推送到原始仓库，就让本项目作为我的个人试验品好了
具体更新如下：
SOCKS5/HTTP 代理支持
CURLPROXY_SOCKS5_HOSTNAME），避免 DNS 污染HTTP 请求统一重构
Utils/Http.phppostForm() 方法，统一处理 Mastodon/GoToSocial 的表单编码 POST 请求Utils/Proxy.php 集中管理，一处配置全局生效增强 HTTP 层错误日志
FediverseSync/
├── Utils/
│ ├── Proxy.php # 增强：支持 SOCKS5+HTTP 代理类型选择
│ └── Http.php # 增强：新增 postForm() + 代理集成 + 日志增强
└── Plugin.php # 新增5个代理配置项留几块老硬盘，偶尔通电可以看到过去的自己在忙碌什么。
因为酷Q ，我第一次接触到了Docker和基于Openbox窗口管理器和Wine 的Linux下Windows服务软件运行方案。
我是中国境内较早一批接触并实用AI chat模型的非计科高中生。
那时候腾讯还在ai.qq.com持续测试传统NLP 算法的chat模型，即便效果远不能与现在的LLM相比拟，这些现在可以称为古董的早期产品还是给当时的我还有其他朋友带来了极大的震撼。
那年，眺望世界已经不能依靠原版shadowsocks实现，新的替代者是Trojan
那年，Discuz是境内主流论坛服务软件。
那年，Python有了一个国产IDE NovalIDE。
那年，SSH 还是XShell Plus的天下。
那年，PanDownload 和无私分享的cookies拯救无数被百度云盘困住的用户。
那年，PCL替代不掉难忘的旋律
那年，联机侠跨越时空提前挤占了网易的用户空间
那年，我第一次玩孤岛危机2 大型开放世界FPS游戏。
那年，第一次体验COD 4颠覆性游戏制作水平
那年，激活Windows只需要启动AAct 。
那年，酷Q与论坛还在，开发可用易语言。
互联网有记忆，我们也有，缺少的记忆欢迎补全。
光猫路由一体机拨号是一个极其糟糕的设计，运营商既不愿意普及高性能硬件NAT的设备又不愿意用户自己使用路由器拨号。
这个问题淘宝花30块钱就可以解决，专业的事情交给专业的人做。
在花小钱之后我的宽带体验明显有了质的提升，首先是ping 延迟明显比之前光猫拨号再接路由器低了5~8ms
此外，之前光猫拨号会存在长时间使用后延迟异常超高抖动丢包率的问题也迎刃而解。
顺便也算绕开了光猫里的老大哥的眼睛（我给你光模块供电就算了，我还得自付电费审查自己是吧，我有病吗？）
我的是RTX5060 laptop，不管是第三方软件还是Nvidia 自己的app都无法识别到。
我猜是Windows的傻逼更新自动替换驱动把我驱动甘飞了，当然最近一次使用Windows也就是下了Todesk花30让人帮忙处理光猫的时候，最近一个星期我都在用Fedora。所以要么是Windows作妖，要么是Todesk在瞎搞。
个人倾向于前者。
下载DDU：Download Display Driver Uninstaller (DDU) Official Latest Version
按下Shift 再点击重启
重启后选择进入安全模式（藏得有点深，可别点成清除数据恢复Windows了）
在安全模式打开DDU 第一次启动会自动启动选项弹窗：
注意大弹窗下的高级设置：
勾选：
安全模式下是无法安装N卡驱动的，重启后自动退出安全模式。
此时直接安装驱动仍然会识别不到驱动，需要通过Lenovo Legion Toolkit 或者你在OEM提供的其他官方工具（亦或者主板勾选）切换到独显直连模式才会使得Windows正常识别到显卡。
此时设备管理器会显示一个微软基本显示设备实际上就是你那个没装驱动的显卡，正常安装驱动即可。
Linux内核遵循一切皆文件原则，Flutter开发遵从一切皆组件Widget的原则。应用界面由组件与组件的嵌套堆叠构成，组件按照布局作用有布局组件（如Center，Column）和一般组件（常见Text，MD风格组件：Scaffold，floatingActionButton）
Flutter提供的布局组件命名及其作用与前端CSS样式/Python Tkinter中的布局样式组件类似。
Center 是一个布局 widget。它接收一个子 widget，并将其放置在父 widget 的正中间。
按照状态区分则分为有状态组件 （集成自StatefulWidget）和无状态组件（继承自StatelessWidget ）
有无状态，主要区别在于是否需要在应用运行期间动态改变数据并更新UI。
属于不可变组件，创建后所有的属性、UI 呈现均固定不变。它不依赖任何随时间变化的数据
生命周期：简单，仅包含一个 build() 方法。
性能：性能开销低，不需要管理状态和触发重绘。
常见场景：静态文本（Text）、图标（Icon）、静态图片以及页面头部导航栏（AppBar）
class MyStatelessWidget extends StatelessWidget {
@override
Widget build(BuildContext context) {
return Text('这是一个无状态组件');
}
}特点：可变组件，在生命周期内可以持有、改变状态（State），并在状态改变时自动刷新、重新构建 UI。
组成部分：包含两个类，一个继承自 StatefulWidget，另一个继承自 State。UI 的逻辑和布局写在 State 类的 build 方法中。
状态管理：通过调用 setState() 方法通知 Flutter 框架数据已改变，从而触发 build 重新绘制界面。
常见场景：复选框（Checkbox）、输入框（TextField）、计数器、网络请求加载中状态等需要根据用户交互或数据更新而变化的 UI。
MyStatefulWidget extends StatefulWidget {
@override
_MyStatefulWidgetState createState() => _MyStatefulWidgetState();
}
class _MyStatefulWidgetState extends State<MyStatefulWidget> {
int _counter = 0;
// 函数命名下以划线开头表示该函数是一个私有函数，否则默认为公共
void _incrementCounter() {
setState(() {
_counter++; // 改变计数器数值并触发UI更新
});
}
@override
//重写build方法
Widget build(BuildContext context) {
//返回一个可以检测手势的小部件：GestureDetector
return GestureDetector(
//onTap属性指定接受点击事件时调用私有函数_incrementCounter()
onTap: _incrementCounter,
child: Text('点击次数: $_counter'),
);
}
}众所周知，境内三大运营商跨网以及境内外Qos问题非常严重，以至于使用Frp时都不得不受限于严重的丢包导致互联网速非常低下。
过去两天的测试发现，QoS不仅影响UDP，甚至TCP也会出现严重的丢包。
具体测试可见：佬友们，中国连不通来了。
这样极端的QoS使得即便用户通过VPN加密数据连接回家也无法获得更好的带宽。
既然本质是QoS的高丢包率导致的，我们就针对性考虑使用更好的拥塞算法以达到预期带宽。
更好的拥塞算法，近期毫无疑问指的是：Brutal 了
Brutal： 这是 Hysteria 自有的拥塞控制算法。与 BBR 不同，Brutal 采用固定速率模型，丢包或 RTT 变化不会降低速度。相反，如果无法达到预定的目标速率，反而会根据计算的丢包率提高发送速率来进行补偿。Brutal 只在你知道（并正确设置了）当前网络的最大速度时才能正常运行。其擅长在拥塞的网络中抢占带宽，因此得名。
BBR 的特性是慢启动和基于 RTT 变化的带宽估算 这一算法具有更好的普适性，因为设计为无须考虑双端带宽值，理论上可以更好的自适应调整到最高带宽。但是在高丢包环境下，BBR就显得有些无能为力了。
使用Brutal的首选自然是Hysteria2了，所以我的最终链路方案就是：
Client —> NAS hy2 Server -> NAS Cloudreve
测试证明这一选项能真正拉满本地上行：我将客户端设置为30Mbps UP后Hy2可以轻松的把向NAS的上传速率拉到30Mbps。
也就是说，使用Hy2 Brutal模式下可以真正把NAS的下行带宽充分利用，必经大部分时候客户端上行也不会超过NAS下行的100Mbps
Shadowsocks-libre 直连回家的测试：
Hysteria2 Brutal算法直连回家测试 ：
这真的是爆杀了。
为了方便对比，下面是同客户端本地测试
这很奇怪，因为我发现在我利用Hysteria2 猛跑了十几GB后整体网络情况（裸连）极大的好转了，连Frp转发在原有参数下速度都恢复了理想水平。我在上述测试之前已经重启了路由器和NAS，所以这种好转看上去和设备重启没有任何关系，唯一有关系的只是凌晨这个特殊的时间点和Hy2的使用。