缘起: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界面黑底白字,扁平化设计,菜单项前面还带着雅致的小图标。那种“什么都没有,又什么都有了”的极简感,瞬间戳中了我。于是我找到了同款 ...








