还有意外之喜，居然有雪映白！
未来摸鱼的心情更愉快了hhh.
幸亏我机智，多问了句！

- 阅读剩余部分 -

一张图懂得已经看懂了。不懂的，我再多废话几句：
我买的是联想的拯救者，以前也用过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可能潜在的混乱和污染问题，这个仓库的更新我不会推送到原始仓库，就让本项目作为我的个人试验品好了

具体更新如下：

Fediverse Sync for Typecho - 更新日志

版本 1.6.5 (2026-06-18)

新增功能

• SOCKS5/HTTP 代理支持

  • 新增可选代理配置，支持 HTTP 和 SOCKS5 两种代理类型
  • SOCKS5 使用远端 DNS 解析（CURLPROXY_SOCKS5_HOSTNAME），避免 DNS 污染
  • 支持代理认证（用户名/密码）
  • 适用于中国大陆等网络受限环境

重构优化

• HTTP 请求统一重构

  • 将分散在 Plugin.php、Action.php、Api/Sync.php 中的 6 处原始 cURL 调用集中到 Utils/Http.php
  • 新增 postForm() 方法，统一处理 Mastodon/GoToSocial 的表单编码 POST 请求
  • Header 去重处理，避免重复 header 导致 400 错误
  • 代理逻辑由 Utils/Proxy.php 集中管理，一处配置全局生效

调试改进

• 增强 HTTP 层错误日志

  • 请求失败时自动记录 URL、HTTP 状态码、cURL 错误号和错误描述、响应体预览
  • Proxy 应用代理时记录代理类型和地址，便于确认代理是否生效

文件结构

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与论坛还在，开发可用易语言。

​互联网有记忆，我们也有，缺少的记忆欢迎补全。

在关闭Frp的tcp mux 后上传才正常持续，之前是小文件可以秒传卡100%，大就传一下等待一会儿就报错Network Error（仅使用Frp进行端口转发的情况下）如果再加上Nginx进行反向代理没有写明超时时间，默认60s就更完蛋了，给你报405/502/504等一串错误。
HK 大陆3网直连 200Mbps的VPS做转发，一个30MB的文件1MB分片已经传了十几分钟了，真的逆天啊我很难想想这性能瓶颈到哪里了，哪怕作为下载方的家宽服务器现在也有100Mbps下行，我本地直接5G流量居然还是这么龟速。 纯纯逆天。
折腾这个玩意真的让我力竭了，当然力竭的倒霉蛋也不只我一个，互联网上随手就能搜到类似的问题，而且最终说是解决的实际和没解决也区别不大，依旧是慢如蜗牛。

先来谈谈Frp TCP多路复用的逆天降速问题

看个帖子：tcpmux 会大幅降低链路速度#2987
看完你应该大致明白发生了啥，总之开发者们选择了稳定性，但是这在我的应用场景就很糟糕。
所以我最终选择了关闭TCP MUX。

Nginx 反代对Cloudreve的影响

首先，我刚才提过Nginx对前后端的默认的连接超时都是60s一超时就给前端返回504，所以你要么60s内传完，要么保障断开连接后自动重连。
当然，我们还有个更具备实操价值的办法😉：

  location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host; 
        proxy_redirect off;
        proxy_pass http://127.0.0.1:5212;  
        proxy_request_buffering off; # 禁用反向代理缓存
        proxy_read_timeout 3600s;   # 等待后端响应超时
        proxy_send_timeout 3600s;   # 发送请求体给后端
        client_body_timeout 3600s;  # 接收客户端请求体
        send_timeout 3600s;         # 发送响应给客户端

        client_max_body_size 0;     # 0 表示不限制请求体大小
    }

分片大小

在带宽足够的情况下，为了充分吃满带宽分片大小应该尽可能的大以提高[所求数据传输时间/协议开销时间]的值，拆分成小块发送意味着花费更多的时间在协议开销上。具体大小应该根据你自己的各级服务器带宽决定，如果带宽本身就很低或者波动明显，就适当调小维持稳定上传状态。
对于我的200Mbps上行的Frps和30上/100Mbps下的Frpc 我选择的分片大小是16MB。

Frps与Frpc 之间的协议效率

在理想的情况下，QUIC一定是最好的选择，如果网络波动明显只能退选KCP。但是考虑到实践中某些运营商对UDP流量极端的QoS策略，我只能选择TCP和基于TCP的协议。
在某些特殊环境下，开启流量加密是你不得不做的选择，但是如无必要加密和压缩两个都没有必要开，特别是设备cpu性能明显羸弱的情况下，开启流量压缩没有任何意义。

最后，看看更接近操作系统底层的地方

Linux之TCPIP内核参数优化

懒人方案：决定24H不睡迎接中秋节——顺便修一修linuxuser.site邮件服务器的严重不可用问题

厂商型号：YR-CP100
主板版本：CP102-MAIN-V2.2
主要芯片：RG200U-CN V3MF-D10-DDC（移远通信）
其他硬件：塑料外壳，3根FPC天线（疑似5G/4G),2根WIFI天线。1个USB Type-C 接口，1个RJ45网线接口。
开盖后取下主板风扇可见各个模块及2个SIM芯片（预计为移动和电信）还有一个空SIM芯片引脚，以及一个没有引出接线位置的SIM卡槽标识位置。

固件备份

经过不懈努力终于在一众工具中找到了我能正常使用的备份工具。
除了spd_dump是可用的，还有SPRDC_Core也是可用的。但是这两个工具对本设备仍然有一些概率性的玄学问题，比如莫名其妙的信号灯超时时间已到报错。
备份分区表：

<?xml version="1.0" encoding="utf-8"?>
<Partitions>
  <Partition id="prodnv" size="4" />
  <Partition id="miscdata" size="1" />
  <Partition id="recovery" size="16" />
  <Partition id="misc" size="1" />
  <Partition id="trustos" size="1" />
  <Partition id="sml" size="1" />
  <Partition id="uboot" size="2" />
  <Partition id="boot" size="16" />
  <Partition id="system" size="53" />
  <Partition id="userdata" size="0xFFFFFFFF" />
  <Partition id="nr_fixnv2" size="6" />
  <Partition id="nr_runtimenv2" size="9" />
  <Partition id="nr_pmsys" size="1" />
  <Partition id="nr_agdsp" size="6" />
  <Partition id="nr_modem" size="27" />
  <Partition id="nr_v3phy" size="6" />
  <Partition id="nr_nrphy" size="3" />
  <Partition id="nr_nrdsp1" size="2" />
  <Partition id="nr_nrdsp2" size="2" />
  <Partition id="nr_deltanv" size="1" />
  <Partition id="ubipac" size="248" />
</Partitions>

这个东西的价格和性能符合我的预期，到的第一天内置移动卡5G测速150Mbps下 50Mbps上，不过这个WI-FI性能就比较怪异了，特别是延迟极端的不稳定，插线用倒是完全没问题，跟手机USB网络共享的热点延迟一致。

简单逆向分析

通过hexdump查看分区镜像文件数据头部的魔数（Magic Number）为：DHTB
xfox@fedora:~/Dev/YR-CP100$ hexdump /home/xfox/Dev/YR-CP100/all_part_backup/system_payload.bin -C | head -5
00000000 44 48 54 42 01 00 00 00 00 00 00 00 00 00 00 00 |DHTB............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000030 00 2e df 01 00 00 00 00 00 2e df 01 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
查询相关资料可以确定这是紫光展锐设备特有的DHTB分区格式Dynamic Hybrid Trusted Boot，根据已有信息，DHTB分区会把原始分区放置在DHTB数据头后。
直接使用ImHex编辑器查看整个system.img发现0x1000处出现了68 73 71 73 -> hsqs字样。
结合DS对hexdump回显的前几十行原始数据的分析：

根据你之前 hexdump 的结果：
在 0x30 处的值 00 2e df 01 (小端序为 0x01df2e00，约30MB) 很可能指示了**某个数据段的长度。**
在 0x1000 处出现了 68 73 71 73 (hsqs)，这很可能是**一个有效数据块的起始标志**，但它不是UBI格式。
因此，你的 system.img 结构很可能如下：
偏移量 0x0:    DHTB 文件头 (包含长度等信息)
偏移量 0x1000:  某个数据块开始 (可能是压缩的映像，如 squashfs)

所以确定原始分区是一个基于Linux的SquashFS只读压缩文件系统，通过dd命令取出原始分区:
dd if=system.img of=system_payload.bin bs=4096 skip=1
SquashFS分区镜像可以直接挂载。

确定架构

cat /etc/os-release
ID=unisoc-initgc
NAME="unisoc-initgc-distro"
VERSION="udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
VERSION_ID=udx710-module-unisoc-initgc-1.0-w25.38.5:10.52.14-user-native
PRETTY_NAME="unisoc-initgc-distro udx710-module+unisoc-initgc-1.0+W25.38.5:10.52.14+user+native (sumo)"
DISTRO_CODENAME="sumo"

从Yocto sumo的时间点看貌似是2018年的老版本了，Linux Kernel 4.14.98估计是厂商提供给开发者的SDK。
比较有趣的是，解包后里面开发者写的后台PHP代码基本上和安全俩字没什么关系，连我这个纯外行都能看出来有明显的漏洞，群友们表示尝试过修改镜像并刷回但是因为没有厂商提供的证书签名启动不了。
所以后续Crack完全没必要改来改去硬刷镜像，理论上可以通过Web渗透完成既定目的。

2026年1月26日，Got Shell！

昨天通过对后台PHP代码的查看确定了后台处于不设防的状态:

    function quoteArgument($value) {
        return empty($value) ? "'null'" : "'{$value}'";
    }

    function quoteArgument_int($value) {
        return empty($value) ? "0" : "'{$value}'";
    }

    function execShell ($cmd) {
        $result = shell_exec($cmd);
        $json = json_decode($result);

        if ($json->result === 0)
            return "success";
        else
            return "error";
    }

今天一通尝试，终于构造了post请求拿下了root shell，看/usr/bin有adbd看起来可以启用adbd.
/etc/init.d/下发现了adbd-init 当然，默认是没启用。

2026年1月27日

扒拉到/etc/usbenum/usbenum.ini

[machine]
machine=udx710-module
[property]
virtualcn=0
diag=1
log=1
debug=1
usbch=mode0
iq_vser=close
udc=29100000.dwc3
afterpowerloss=1
#virtualcn 0-rndis|1-ecm|2-ncm|3-mbim|4-8*AT|5-1*ecm|6-2*ecm|7-3*ecm|8-4*ecm|9-1*ncm|10-2*ncm|11-3*ncm|12-4*ncm|13-test

看上去我完全有机会使用USB cdc-ncm 替换RDNIS，当然...前提是能修改好镜像。
似乎可以通过overlay完成对SquashFS的写入存储？但是一改/etc/fstab就涉及现有鸡还是现有蛋的问题了，早于系统启动之前完成修改是不可能的，最终还是得诉诸于修改和重新打包刷入system镜像。