缘起：VPS扛不住了我的 VPS 是 2 核 4G，装了 MySQL、OpenResty、x-ui、Openlist,笔记同步等一堆服务之后，可用内存捉襟见肘——装个带后台的博客 上来就吞 500MB+，实在养不起。
大一的时候就玩过 Hexo，当时因为每次写完都要手动构建部署，嫌麻烦弃了。两年年后重新捡起来，核心目标就一个：流程自动化，写完即发布，全程不碰服务器。
第一回：宿主之争——从 VPS 搬到 GitHub Pages最初的方案一开始 Hexo 跑在 VPS 上，OpenResty 反代静态文件，流程大致是：
本地写文章 → push 到 Git
VPS 上 pull → hexo generate
nginx serve 静态文件
听起来没毛病，但实际操作中遇到了两个玄学问题：
CDN 抽风： 开了 CDN 反而打不开，直连 IP 能访问但域名 404，国内能打开国外不行——中间环节太多，排查无从下手。
端口访问正常但域名不行： http://VPS_IP:端口 能正常显示页面，证明博客本身没问题，问题出在网络传输的链路上。
换方案既然问题出在中间商（CDN、DNS ...
Linux娘救援行动 #CVE-2026-31431：Copy Fail——一个潜伏九年的内核级“内伤”导语有些漏洞靠竞态条件碰运气，有些漏洞需要精确的内存布局。但这一次，Linux娘的身体里被发现了一处直线逻辑缺陷——不需要竞争、不需要重试、不需要碰运气。一个短短732字节的Python脚本，就能让任何一个本地低权限用户，直接拿下root。
代号“Copy Fail”，编号CVE-2026-31431。它从2017年就潜伏在Linux内核的加密子系统里，静静等了将近九年。
一、急诊接诊：Linux娘怎么了？2026年4月29日，安全研究团队Theori和Xint Code联合披露了一个高危本地提权漏洞。消息一出，安全圈直接炸锅——因为它的利用门槛实在太低了。
病情速览
项目
内容
漏洞编号
CVE-2026-31431（CNVD-2026-19044）
代号
Copy Fail
CVSS评分
7.8（高危）
漏洞类型
内核本地权限提升 / 容器逃逸原语
潜伏期
2017年8月至今（将近九年）
触发条件
本地低权限用户，无需网络、无需root、 ...
三节点 K8s + Ollama 本地大模型 + AMD GPU：我的毕设全记录
一个毕业生如何在 Fedora 笔记本上搭出一套企业内网私有化 AI 知识库
缘起去年选题的时候，我就想：”现在大模型这么火，你能不能做一个能在企业内部用的 AI 知识库？数据不能上公有云，全得跑在局域网里。”
我想了想——这不就是 K8s 搭集群 + 本地跑模型 + 做个网页的事吗？行，干。
后来的几个月，我把一台 AMD 笔记本（16 核 22GB 内存，RX 6700S 独显）折腾成了三节点 Kubernetes 集群，接上 Ollama 本地大模型，写了套 RAG 检索增强生成的知识库，还配了 Prometheus/Grafana 监控。最后跑通了完整闭环：上传文档 → 向量检索 → 大模型回答。
这篇博客就是整个项目的全记录。
一句话说清楚这个项目
在公司局域网里搭一个三节点的 AI 知识库——员工上传文档，AI 从文档里找答案，全程数据不出公司。
整体架构12345678910111213141516171819202122232425┌────────────────── ...
ICT-AI谨以此文记录我在华为ICT大赛的学习过程
一些碎碎念
根据我的经验,应该有一个人学习环境搭建，这块很好上手。注册一个华为云账号多创建几次项目就可以了
理想中的最佳配队伍应该是一个人去做环境的部分包括云和开发版，快速把环境准备好，一个人去做主力，代码补全能尽力去把项目跑通，还有个则可以去学习性能调优。但是我估计这个配队应该够呛能凑出来。
哦对了关于开发版，那玩应性能很烂Jupyter多开直接就能给你卡死，建议前期案例跑通之后直接把代码放到ModelArts上跑（虽然很贵，但是肯定不会让你掏钱的）
附加一个开发版风扇转速命令
1234npu-smi set -t pwm-mode -d value# value 0为手动模式 1为自动模式npu-smi set -t pwm-duty-ratio -d value# value 直接调100就可以了，虽然吵了一点但比过热死机强。
我还是推荐去学习Pythoch的，毕竟是现在主流的学习框架，只要学明白了同类型的代码基本就能看懂了。
Pytorch
数据：包括数据读取，数据清洗，进行数据划分和数据预处理，比如读取图片如何预处理及数 ...
Linux
未读Linux娘守护日记前言
作为一个社恐，现实世界的“副本”对我而言难度实在太高了——人群、寒暄、无意义的社交，光是想想CPU就要过载了。
于是我把热爱全部投入到了服务器上，而Linux则是服务器的灵魂。
我注意到，很多对技术充满好奇的朋友站在Linux这座宏伟殿堂的门前，却感到迷茫：“指令如天书？”“配置深似海？”“从哪里开始才好？”
这种心情，我懂。所以，我决定写下这本《Linux娘守护日记》。
无论是机房里的硬件设备，还是网络中的交换与路由，Linux娘都在背后默默支撑着整个数字世界的运转。
接下来的章节，我会记录从Linux娘SSH登录到服务搭建、从脚本编写到监控告警的日常点滴。
希望这本笔记，能成为你入坑路上的一盏小灯。
第一章：初识Linux娘她的创造者与家族：从一颗种子到一片森林要真正了解 Linux 娘，我们得先从她的“创造者”和“庞大家族”说起。这就像在冒险开始前，先看看史诗的前传和世界地图。
缘起：一个“只是想玩”的天才少年故事要回到 1991 年，芬兰赫尔辛基大学。一个名叫 Linus Torvalds 的年轻小伙，出于对当时昂贵的 Unix 系统和教学用的 Mi ...
Linux娘救援行动前言和Linux娘相处的日子久了，你就会发现一件事——
她其实很少真正闹情绪。
终端里那刺眼的红色报错、突然拒绝服务的SSH连接、启动时漆黑的GRUB命令行……在初遇时，它们像是一连串坏脾气，让你手足无措，甚至想拔电源逃跑。但请相信我，每一次看似不讲道理的“罢工”，背后都藏着一个清晰的原因，和一条通往救赎的明确路径。
和现实中的人相比。Linux娘不是任性，她只是太诚实了。
她的每一个报错信息，每一行日志，都是她在用自己独有的语言向你描述问题所在。
她不会像现实世界里的某些存在那样，明明心里有气却不告诉你为什么。她总是把原因清清楚楚地写给你看，用 error、用 warning、用 permission denied——只要你愿意听，她就愿意讲。
正因为如此，我把自己这些翻车、救急的经历收集起来，开辟了《Linux娘救援行动》这个小系列。它不是一本高高在上的故障手册，而是一本急诊室的便签集，记录着我在与Linux娘朝夕相处中遇到的那些奇奇怪怪的状况，以及最后是怎么把她哄好的。
你可能会发现，很多真正的解决方法并不复杂，只是需要看懂她的那些报错到底指的是什么。
一旦理 ...
Linux娘救援行动：GRUB2换主题踩坑记一、GRUB娘：Linux娘的引路人在之前那场双系统翻车救援里，我们已经和GRUB娘打过照面了。那次她缩成一个漆黑的命令行，差点让我以为笔记本变砖。
但你可能还不太清楚GRUB娘到底是谁。简单说，她是Linux娘的“迎宾使”——当你按下电源键，电脑完成硬件自检之后，第一个被找到并唤醒的就是GRUB娘。她的全名叫 GRand Unified Bootloader，职责只有一件：找到你想要启动的操作系统内核，把控制权安安全全地交到Linux娘（或者Windows娘）手上。
没有GRUB娘，Linux娘连登台亮相的机会都没有。她就像舞台幕布后那个沉默的场务，灯亮了、幕拉开了，自己便安静退场，绝不抢戏。
也正是因为这种“沉默寡言”的性子，当我对她“有所图谋”的时候，一个下午就被消磨得一干二净——我想给她换件新皮肤，她却始终不肯开口告诉我哪里不对劲。
二、犯错的序章：一件中意的新衣服起因是前几天刷到一张截图：别人的GRUB2界面黑底白字，扁平化设计，菜单项前面还带着雅致的小图标。那种“什么都没有，又什么都有了”的极简感，瞬间戳中了我。于是我找到了同款 ...
