事情要从给家里老人祝寿说起，说来惭愧，我连他老人家今年何寿都不知道。
老人家前些年因为脑血栓中风半身不遂，吞咽能力也差，稍微硬的完全嚼不动，随着年龄增大大脑功能进一步退化现在大小便也基本失禁，虽然表面上还能跟你沟通几句，但是长久接触就会发现记忆力和逻辑思维已经大受影响，简单些说就是老年痴呆了吧。
我认为自己算不上什么孝顺的人，父亲倒是十里八乡有名的孝子。老人家在我们家住了一段时间，后面因为脑子糊涂了总和父亲起矛盾不愿意待在我家。又辗转在我姑姑和大哥哪里呆过一段时间，最终还是回了老家搬迁后的房子。

回家祝寿

家里其他人都要上班，刚好我辞职在家要躺一个月，于是5.21买了点他老人家能吃的水果自己骑着两轮回了老家，上楼还没进门就闻到那股屎尿味了。 他坐在床边，裤子看上去是湿的，脚底下是一片腥臭混着不明絮状物的液体。 仔细一观察裤子形状我就确定他是拉裤子了，和他沟通换一条，刚开始还不愿意说吃完饭再换。“今天过生日，您肯定也希望自己干净体面些不是？” 也可能是孙子buff加成吧，我劝他一般比我爸劝好使。总归是劝动了，从楼下问了长辈衣物在哪 “又尿裤子了？”沉默一秒，“嗯” 转身回了楼上取来裤子，准备更换。
拉开裤子，果然，黄色的排泄物堆在裤兜。 气味刺鼻难闻，我没戴手套，也没戴口罩。好在也不是第一次遇到这情况了，早些时候也不少给幼儿园小孩子擦屁股，不算太慌。 我本想把裤子拖拽下来，但是地上的排泄物太过刺鼻，我差点就没忍住吐出来。 和他说了一声先去取了拖把，把地面简单处理了一下，减少令人作呕的气味。
中途他老人家吆喝着“快掉下来了！快掉下来了！” 好吧，总算是取得阶段性的胜利。楼下窸窸窣窣的脚步和说话声音传入房中，客人们也陆续到了。我关紧房门，终于是把裤子给他扒了下来。臀部沾黏着大片的黄色排泄物，又是一场攻坚战。
“好久没用纸擦屁股了” 他冷不丁的蹦出这句，让我有点懵逼。“那拿什么擦？” “不擦...”
我略微停了一下手上的动作，卫生纸擦了擦难以擦干净。
只能去找来一个看上去可能接过雨水的塑料盆，拿刷子和84快速刷干净打了盆水手忙脚乱取了说不清是拖布还是毛巾的毛巾替代品回房间。
打湿毛巾替代品用力擦洗臀部和肛周。 涮一涮，反复几次，再换了换水继续重复。擦到末尾，姑姑也到了把门打开接着我的工作继续。
“咦，怎么不戴手套？让我来！”
后面画面主题变成了他老人家的孝顺闺女和略显游手好闲的孙子......
在长久但没几句的尬聊后，除了身体不便的老人家大家陆续上桌。

无效的催婚

终于，催婚环节也到了我身上。我亲爱的亲友们开始讲述婚后给自己家孩子带娃的天伦之乐。 小侄女确实很可爱，可惜我在幼儿园呆过对小萝莉和难对付的魔丸法术抗性很高了，这点可爱是不可能推动我这个死宅的。如果不知道这个可爱的小萝莉的爷爷是前教体某大领导，我或许会对这些所谓的“天伦之乐”有些期待吧。
毕竟很难想象拿皮带抽出来我这种拿着大专文凭的网瘾少青年的父亲能把下一代带出来个什么好样。 上完学，学过教育学和心理学过后的我 对教育出合乎我或者说社会大众期许的下一代实在没多少信心。
恐怕只能带出烷基八氮的后代吧。
在我表达出“时代不同”和长辈们的”丁克同事现状示例“作了对冲之后，小萝莉的父上开口说了点有用的 “不管你谈不谈对象，总要保持向上的态度不能颓废放弃总要充实提升自己“ 这不是原话，但是意思是这么个意思。
这大道理倒是完全没错，我还是很认同的，还是年轻人的更懂年轻人的沟通方式啊。所以在6.1参加完同学的婚礼之后，我还是得去找个工作干着，不可能一直在家坐吃山空。

老年人的无奈你无法体会

聊了这么多，只是想提醒大家，养儿防老不可靠，也不现实。
至于机器人养老之类的玩意，也许未来成本进一步降低会逐渐普及。
但是打铁也需自身硬，你要么有钱，要么保持好身体。 可惜就现在的社会用工环境，有钱和身体好这俩对大部分普通人都是不可兼得的。 但是你要是不注意，还玩命压榨自己，那很快你就知道职工医保也不是万能的了，伤身体的是你痛苦的也是你。
我现在都记得厂里一个师傅，在外面干了十几年，胃熬夜熬坏了。三十多岁看着跟四五十岁的人一样老。
至于积谷防饥，这条也不算可靠，因为政府会通过货币贬值的方式收割你，不要以为攒钱就能解决问题了，当然你说买实物黄金，那看看现在金价自己盘算吧，这个我是真不懂。

Linux内核遵循一切皆文件原则，Flutter开发遵从一切皆组件Widget的原则。

应用界面由组件与组件的嵌套堆叠构成，组件按照布局作用有布局组件（如Center，Column）和一般组件（常见Text，MD风格组件：Scaffold，floatingActionButton）

布局组件

Flutter提供的布局组件命名及其作用与前端CSS样式/Python Tkinter中的布局样式组件类似。
Center 是一个布局 widget。它接收一个子 widget，并将其放置在父 widget 的正中间。

StatefulWidget和StatelessWidget

按照状态区分则分为有状态组件 （集成自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算法直连回家测试 ：

这真的是爆杀了。
为了方便对比，下面是同客户端本地测试

2026-05-14

这很奇怪，因为我发现在我利用Hysteria2 猛跑了十几GB后整体网络情况（裸连）极大的好转了，连Frp转发在原有参数下速度都恢复了理想水平。我在上述测试之前已经重启了路由器和NAS，所以这种好转看上去和设备重启没有任何关系，唯一有关系的只是凌晨这个特殊的时间点和Hy2的使用。

今天刷BOSS直聘看到有一个招游戏视频数据的，去问了问主要收集主流3A 游戏（SteamTop 2000）的游戏画面和键鼠交互操作。
看了看其他招聘岗位，大概知道未来会怎么样了。
也许在不久的未来，已经沦为黑奴的人工游戏搬砖/跑刀 这些底层行业未来会在AI搬砖的挤兑下彻底失业，提供情绪价值的陪玩才能在夹缝中勉强生存下来。
这和中央对数字经济的近期新闻态度契合，不愧是行业冥灯指谁谁死。🤣
经济萎缩的时代，AI的时代，资本主义的时代，蓄水池释放后逐渐干涸的时代。

在关闭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邮件服务器的严重不可用问题

我很少在博客提及自己的家庭，但是我今天实在忍不住，既是吐槽也是感叹。

发现有些父母真的不懂得放手。

不懂得量力而行的父母们

就好像是当下社会的某种规训一样，相当多的父母对后代的托举完全凭靠他们自己所处的视角，且对自身人际关系定位与现实普遍存在巨大偏差。狭隘视角与定位偏差最终常常让有意识的托举后代变成了无意识的坑害后代。
以我为例，当我明确告知我的母亲自己要辞职的时候，她开始疯狂的寻找各种途径试图为我找下一份工作，即便我明确告知我已经有方向不需要她提供任何帮助也无法阻止她。
这一度给我造成巨大的心理压力和骚扰，终于在今天我不得不再次删掉她的微信以阻止她泛滥的“母爱”。这种糟糕的情况并非第一次发生，坦白来说删掉微信中断一般联络方式肯定不是对双方最好的选择，甚至可能是最烂的选择。
但是接受过历史教训（沟通无效）的我已经不愿意花费精力选更好的选项了，我明确的感受到自己正在变得更自私自利，而这种自私自利又仅限于对待父母。

失去自己人生还要破坏孩子的人生吗？

我的家庭算得上是网友们所谓的“原生家庭”了。
在我看来，我的父母早已经失去了自己应有的幸福人生，猜疑和夺利让他们的婚姻成为一种痛苦。这种痛苦不止浸透他们自己也极大的浸染了作为后代的我。想起来之前在幼儿园工作时同事说的话：“我害怕把自己的痛苦带给后代。” 我不知道他们是否害怕，但我现在已经不在乎他们害怕不害怕了————也不太在乎他们过的怎么样。
曾经，那条小鱼在乎。可现在小鱼已经累了，太阳太大 即将晒枯了那小小的水洼，拼尽全力跃出的小鱼也许会跃到大海继续遨游，也许只是跌在沙滩上成为无数鱼干的一部分......

开机F2 临时断电再拆了后盖把TiPlus 7100 装上关掉安全启动，先切换到显卡混合输出不然刚从3060换过来不然驱动必定水土不服花屏。
进Fedora后dnf reinstall akmod-nvidia xorg-x11-drv-nvidia-cuda然后再dnf update.
还得去改一下/etc/grub.d/里的自定义启动项配置避免硬盘识别顺序不符合预期造成无法正常引导。
依旧可以参考：解决Fedora41 Grub2 无法通过os-prober自动添加Windows启动项的问题 这次比较好的是os-prober识别到新机硬盘的Windows11了。
修改后重新sudo grub2-mkconfig -o /boot/grub2/grub.cfg
切到Windows11后上机先卸载联想辣鸡全家桶，留个Legion Zone即可。不值得探讨
9k啊，但愿尸体机拆散卖配件挂鱼能回点血。

有趣的是，我发现Fedora下y7000p这个电源键灯色和KDE 桌面环境里的性能选项是同步对照的，内核对此显然有一定适配。
然后我就想起来这个有点眼熟的项目：johnfanv2/LenovoLegionLinux 我之前用鸡哥的时候找开源替代就曾误打误撞找到过这个同类项目，没想到我也有用得到的时候。

后续

在备份原厂Windows11 镜像的时候发现原厂安装了一堆AI向的辣鸡软件，毫无例外的哪怕是本地运行的也需要登录。Dism++ 备份出来的67.6GB wim镜像里面估计不少是屎，但是当时没空单独处理了。 上传到阿里云盘进行云备份的时候发现上行很快6~8MB/s，下行只有200~1000KBps，这就我们抽象的广电卡，下载被QOS成屎，上行反而没人管。 如果短时间内大量传输，基站还会把广电从5G踢回4G，过几分钟又恢复5G。

时隔多年，我这台二手蛟龙5 76s终于炸鸡了。
前几天更新过驱动后，昨晚高负载打逃离塔克夫没注意打开游戏模式，然后直接弹出经典提示快速转到无限重启，随后经过数个小时的多次尝试确认设备可能因为CPU过热虚焊导致无法开机。
鉴于自己没有BGA焊台这些专业设备，这台二手鸡哥算是半步管材了，不过用了这么久也勉强算得上寿终正寝。
在Linux.do问了问佬友们意见，再让DS结合互联网评价的各待选热门款笔记本通病最终选择了联想的Y7000P。（没错这违背了我不买联想的原有计划。）
综合价格因素去淘宝一个非官方店铺9000软妹币下单了99新的Y7000P 2025 32G+1TB 的版本。

为啥打破预期买联想

坦白来说我本来首先考虑了机械革命的极光X和蛟龙16Pro，但是这俩通病太严重。高负载积热蓝屏+黑屏重启的问题这俩高概率中奖，还有设计散热垫厚度有问题导致过热USB断连的，扬声器杂音。
至于隔壁华硕天选也不遑多让天选Air 2025查到有键盘漏电问题，给人电麻了还没好好处理。天选6Pro 更逆天C壳鼓包+充电口松动+屏幕闪屏。
直接排除黑屏精灵及HP全系产品后，再看看隔壁戴尔，也是没逃过频繁蓝/黑屏，还有出现键盘失灵。
那么最后我选的Y7000P呢？它也不是一点问题没有，相反问题更恶心。R7000P我没敢买，怕积热重蹈覆辙，Y7000P 2025用上了14代酷睿，这代缩缸问题无需多言。
我敢选是因为现在是2026年，英特尔已经发了微码更新并且老奶奶过马路的联想也终于是在一片骂声里把微码更新慢慢同步上去了。
😂2026年买个好用的笔记本电脑这么难，我真的是没想到。
经济下行，产品质量也下行了，又或许只是以前就烂但是我不知道？