Edit Diaries.

Signed-off-by: SilverAg.L <caclx@outlook.com>

.vscode/settings.json

@@ -1,6 +1,7 @@
 {
     "files.exclude": {
-        "**/*.webp": true
+        "**/*.webp": true,
+        "**/*.avif": true
     },
     "editor.tabSize": 2
 }

README.md

@@ -1,17 +1,20 @@
 ## SilverAg.L 的玩具城
-说人话就是咱的个人博客。不考虑英翻，NO ENGLISH VERSION!
+基于 [vuepress-theme-hope](https://theme-hope.vuejs.press/zh/) 滴[个人博客](https://agxcoy.shimakaze.org/)。没有英文版本。
 
 ---
 
-<p align="center">
-    <img src="https://img.shields.io/badge/license-MIT-blue" alt="license - MIT">
-    <img src="https://img.shields.io/badge/license-CC--BY--NC--SA--4.0-lightgrey" alt="license - CC-BY-NC-SA-4.0">
-</p>
+![MIT License](https://img.shields.io/badge/license-MIT-blue)
+![CC-BY-NC-SA-4.0](https://img.shields.io/badge/license-CC--BY--NC--SA--4.0-lightgrey)
 
 本博客收纳的文章统一采用 CC BY-NC-SA 4.0 协议共享。
 
-**欢迎就本博客上传的「随记」「综述」中的错误、不足之处提出 Issue 批评指正；或者看不顺眼了，丢个 Pull Request，也是极好的。**
+如有想法，还请移步 [GitHub 讨论区](https://github.com/AgxCOy/AgxCOy/discussions)。
+如有疑问、友链需求，还请移步 [Issues](https://github.com/AgxCOy/AgxCOy/issues)。
+如欲改进，也欢迎起号提 Pull Request。
+
+「冇嘢猴肛，我係傻居居。」
 
 ### 特别鸣谢
-- [神羽 @SnowyKami](https://github.com/snowykami)
 - [岛风 @frg2089](https://github.com/frg2089)
+- [神羽 @SnowyKami](https://github.com/snowykami)
+- [苏阳 @Twisuki](https://github.com/Twisuki)

docs/diaries/dress/maid-2512.md

@@ -0,0 +1,25 @@
+---
+article: false
+---
+
+# 年将尽，随几张女仆装
+
+如题，2025 也快结束了。今年我的精神状态感觉更糟了些。但万幸，女装——或者说穿上可爱的衣服——依旧是我内心想要去做的事之一，我也依旧愿意为此付出精力。
+
+之前总说在减肥，目前看来 XXL 已经是我的极限了，再减似乎效果也不太明显的样子。但即便如此看着我的自拍也还是觉得怪怪的。也许我的身体条件本就不适合吧。
+
+![黑巧-1 =300x](./maid-251231-1.avif)
+
+![黑巧-2 =300x](./maid-251231-2.avif)
+
+![黑巧-3 =300x](./maid-251231-3.avif)
+
+![黑巧-4 =300x](./maid-251231-4.avif)
+
+![白巧-1 =300x](./maid-251231-5.avif)
+
+![白巧-2 =300x](./maid-251231-6.avif)
+
+![白巧-3 =300x](./maid-251231-7.avif)
+
+![白巧-4 =300x](./maid-251231-8.avif)

docs/diaries/wbsy/about-me.md

@@ -85,8 +85,28 @@ date: 2025-05-16
 
 银这个设定实际上直到去年才给她勾个轮廓——**白丝魅魔猫娘少女**。乍一听这四个词组合在一起很违和。说实话我也觉得（
 
-首先说说“魅魔”吧。既然银这个字有着一层谐音关系（所谓“银梦”嘛），那么我就往涩涩的方向去考虑了。所以给她的定型是魅魔元素。  
-但一来我说话做不到大多数黄油的魅魔那么“诱人”，二来我养成的猫娘口癖根深蒂固，这就决定了**立绘主体仍然是猫娘**。那么怎么办呢？那就把猫尾巴替换成魅魔尾巴罢。“猫娘身上”的“魅魔尾巴”，很奇特的组合对吧（  
-剩下来的要素就很简单了：白丝一般显得清纯（相对地黑丝会显得诱惑一些），穿在“摇着魅魔尾巴的猫娘”身上增添些反差感；少女嘛……可以保留一些卡哇伊的感觉。（但实际想象起来好像更偏雌小鬼一点）
+相比前面两个反映我不同时期的、特点鲜明的自设，“银”这一形象就相对一以贯之，同时又很随性了。大约在初中我就误入当时流传的所谓“本子库”[^benziku]，所以涩涩也算是我一直以来的隐藏属性，如今启用这个自设也有种借谐音梗的题发挥的意思。
 
-设定上魅魔尾巴非常敏感，只是碰触就会浑身战栗的程度。若是摸上那么一两下说不定就开始发情了吧。
+[^benziku]: 具体的经过已经淡忘了，我的博客对涩涩的话题也比较含蓄。可以确定的是，“本子库”、“兔纱子”、“魔法少女”这些关键词是我早期的朦胧印象，后来形成的题材偏好（或者说 xp）也是基于这个印象所做的建构。
+
+至于这个轮廓为什么这么左右脑互搏，只能说是基于自身经历导致的历史惯性吧。钙设是猫少年嘛，加上我认识的老朋友们普遍爱发猫猫表情包，所以我的口癖不可避免地也倾向于喵来喵去，忽然摘掉“猫”这个元素反倒不知道怎么表达了（毕竟我做不到真像魅魔那样妩媚）。但我又希望能够突出涩涩的要素，所以最终形象就是点缀上白丝、魅魔尾巴、猫耳猫爪的少女啦。~~但自己想象的时候感觉更像雌小鬼一点（）~~
+
+设定上魅魔尾巴非常敏感，只是碰触就会浑身战栗的程度。若是摸上那么一两下说不定就开始发情了吧。
+
+> “诶嘿嘿…身体绵软被搂在怀里什么的……嘿嘿…  
+> “可是……为什么呢？光是咀嚼着文字想象，身体就酥酥麻麻的……  
+> “好羡慕……好烦躁……  
+> “你是怎么看我的呢，氯喵？你会要我吗？  
+> “好想再被你抱着……抱在怀里，就像…就像……”
+> ::: right
+> ——Ag
+> :::
+
+---
+
+## 后记
+事实上我确实没想过它们之间会有什么社会关系，毕竟本质上都是我在网络上的皮套而已，它们都是我，却又不完全是。但真的做出决定，“既然我本来就没活，索性把身为创作者的我，叫做‘氯’的我给埋葬了吧”，这么做的时候，我的内心还是会觉得痛苦，仿佛真的失去了重要的人一般。
+
+基于这样的感情，我才决定写下这一篇随笔，完善这几个自设的形象。至于每个设定底下的自白，更多地是对[友链 PR](https://github.com/Twisuki/blog/pull/4) 里的小对话做一个扩写，很抱歉我并不擅长写一个完整的故事，只能像这样侧面地刻画 CaCl~2~ 和 AgCl 这两对之间的亲密关系。
+
+不论钙、氯还是银，都是我精神世界的投射，也都寄托了我的愿望或是欲求。也许我就是很享受被人家说可爱、就是会为喜欢的事情不顾一切、就是会代入本子里的女孩子、就是想要“身体绵软被搂在怀里”呢？哪怕只是想象，只是在被窝里小声呢喃着“想要”，只是在博客里发癫、写一篇篇的碎碎念。

docs/diaries/wbsy/nas-media.md

@@ -0,0 +1,164 @@
+# Jellyfin 真的好用吗？
+
+我的结论是：实则不然。但 DIY 这一块本就是矮个子拔高个，也没那么多平替可以挑。
+
+> [!important]
+> - 本文字里行间夹带着作者的私货，行文并不严谨，谨慎阅读。
+> - 本文有关的折腾流程时间跨度较长，经验之谈不说没有，也只能说碎得跟渣一样。~~所以不是笔记而是大作文。~~
+
+## 硬件加速，硬件呢
+
+我是 Linux Docker 部署的。由于因特耳的核显驱动闭源，**官版 Docker 容器搞起来后还需要`exec -it`进去装 Intel 驱动**；即便是`nyanmisaka`版开箱即用 Jellyfin 镜像，也需要**手动映射渲染节点**[^renderD128]。
+
+[^renderD128]: 非要映射整个`/dev/dri`也可以，那样后续仍然**可能**需要进入容器里创建`render`组。并且由于`nyanmisaka`版镜像并没有对用户组做特别设置，如需映射渲染节点做硬件解码，就**不允许指定用户（组）运行**。
+
+::: details docker-compose.yml
+以下是最简配置。如果预计暴露到公网上，建议再加上额外的安全措施，**尤其注意收紧容器的执行权限和性能分配**。
+```yaml
+services:
+  jellyfin:
+    image: nyanmisaka/jellyfin:latest
+    container_name: jellyfin
+    network_mode: 'host'
+    volumes:
+      - jellyfin-config:/config
+      - jellyfin-cache:/cache
+      - /home/http/media:/media:ro,nosuid,nodev  # recursive 'rx'
+      # - /dev/dri/renderD128:/dev/dri/renderD128
+      - type: bind
+        source: /usr/share/fonts/opentype
+        target: /usr/local/share/fonts/custom
+        read_only: true
+    devices:
+      - /dev/dri/renderD128:/dev/dri/renderD128:rw
+      #- /dev/dri/card0:/dev/dri/card0
+    restart: 'unless-stopped'
+    # environment:
+    #   - JELLYFIN_PublishedServerUrl=
+    extra_hosts:
+      - 'host.docker.internal:host-gateway'
+volumes:
+  jellyfin-cache:
+    driver: local
+  jellyfin-config:
+    driver: local
+```
+:::
+
+## 媒体库组织
+
+我还是更习惯树形文件系统，媒体库还是太难为我了。那样的话，事情或许也很简单——许多成品 NAS 都有自带视频、相册之类的浏览功能。但很遗憾，自己装的 Ubuntu Server 自然什么都没有。
+
+我针对的还是 Jellyfin “神奇”的资源组织方式。就像[这篇《基于 Jellyfin 和音流的 nas 影音库搭建及踩坑》](https://sspai.com/post/90896)所说，“为什么不直接读取音乐标签进行专辑聚合”呢？
+
+### 元数据刮削：一笔糊涂账
+
+然而事实上，即使真的能做到自动专辑聚合，元数据本身的刻录和查询也是一片混乱。上面援引的博文推荐 MusicTag 这个工具，但同是从网易云那刮削，下载下来本是《紫罗兰永恒花园 OST》的曲目能给它识别成《凹凸世界五周年》，也是给我看笑了。更别说国外的 MusicBrainZ 数据库有相当一部分冷门曲目并没有收录（尽管 Spotify 等平台能够找到）。
+
+![误刮削](./musictag-misfetch.webp)
+
+::: tip 音乐库最简方案
+文档这么说：我管你怎么整理，我只知道**是同一张专辑就该塞在同一个文件夹**。
+
+那么事情也好办，就按专辑名来呗。好比如：`music/{album or "[standalone]"}/{artist1,artist2} - {title}`。
+
+- 为什么要`or "[standalone]"`？
+  - 不单独收纳**没有专辑**的单曲，结果就会被淹没在大几百首、好几页的“歌曲”页面。
+
+- 要是有专辑重名了（比如两张专都叫`Fragrance`）？
+  - 没招，默认合并（甚至可以看到重复的曲号，都是第六首）。只能手工分离（`Fragrance - SoundzImage`和`Fragrance - Hatsune Miku`）。
+:::
+
+但比起前面所述的国内外两桌草台班子，更令我恼火的当属大把大把的、查无此人的“黑户”。怎么来的？音声、网文、3D 动画。
+
+> 我的整理方式和 acgdb 类似：3D 区、音声区（作者分发、油管录播、DLsite 正作）、书目区（漫画和文集）、写真区、插画区，此外新增音乐区。
+
+3D 区无论玩恋活还是 MMD，既有图集又有视频，无法按媒体类型区分。即便真要分，它算电视节目？电影？MV？分不明白。
+
+音声区大量的音频资源，摆烂一点直接用电子书库、按文件夹访查也不是不行，但显示出来反倒是专辑名（或者说 DLsite、系列作品名）更显眼，而非每一集的标题；若要用音乐库收纳，就得改造一番目录树适配它那个“一个专辑只有一个目录”的原则，工作量也不小。
+
+至于书目区，正经出版物想获取元数据并不难。相对的，“不正经”读物呢？网文可以依靠豆瓣之流；同人文只要作者有公开发布，留心寻找也是能记下元数据的（同人圈子对打 Tag 这件事很看重）；那么只剩下来源不正经、题材也不正经的“那种”作品了。它们流通的地方通常都是论坛这种早期网络社区，只知道个标题（很难说发帖人就是作者，万一是二道贩子呢？甚至文件名也不一定就是完整标题）。What can I say?
+
+偏偏这种不在台面上的“资源”我收纳了不少，哪怕有自动化工具，后续校对也是个体力活，何况很多资源只能一件件手工入库。饶了我吧。
+
+### 电子书：吃力不讨好
+
+小说漫画，或者说书籍媒体库，只能说真搭一个私人图书馆大概也和 Jellyfin 别无二致——满满的工作量。可能甚至有过之而不及。
+
+> 不禁想到米哈游创始人蔡浩宇的“快乐守恒定律”：你做的过程中如果很轻松快乐，那么你做出来的结果未必能给人带来快乐。  
+> 媒体库编排是不是也要“苦其心志、劳其筋骨”，才能有好的观影体验呢？但话又说回来，这种家庭影院通常都是自己管理自己用，费那么大功夫组织这些文件，观赏的体验又能改善多少呢？
+
+我相信大多数\*并不在乎资源来源\*的读者去找网络上流通的小说肯定优先去找 txt、doc(x) 这种容易打开的格式。但现有的私人图书馆，无论 Jellyfin 这种顺手实现的，还是 Kavita 这种专用的，**都不支持这些格式**。Calibre 也许可以，但**书目的元数据就成了另一桩麻烦事**。
+
+::: tip 最简方案
+那当然是通通转换成 pdf，单纯当作文件管理器那样访问文件夹、文件最简单。**但 pdf 对移动端并不友好，文字内容并不能自适应，更多还是用于漫画**。
+:::
+
+进阶一点的方案主要围绕 epub 电子书，毕竟漫画这块 pdf、epub、`.cb*`压缩包三者的页面版式不可能差太多，翻页起来其实没什么区别。
+
+::: info 压缩包漫画
+漫画本质上就是一页页的画嘛。许多网站本就提供试阅，给这些图片打个包也就是顺手的事。像我这样存储空间拮据的（主要还是[协议不通用](recents-11172025.md#硬件购置)），只能是哪种最节省空间就选哪种咯。
+
+Jellyfin 本身支持`.zip` `.rar` `.7z`。如果你打算另起炉灶，但选配的服务不支持这样通用的后缀名，也可以改变后缀：
+`.cbz`即 zip、`.cbr`即 rar、`.cb7`即 7z、`.cbt`即 tar。
+
+至于元数据，Jellyfin 文档指出**只有 epub 书籍才允许元数据集成在文件里**，对于这种漫画压缩包，需要另写`ComicInfo.xml`。也就是说，**每一本、系列的每一话，都需要单独的文件夹放置元数据和本体**。
+:::
+
+现有的 epub 编辑器并没有像写哔哩哔哩专栏（或者像 Word 文档）那样自动编纂页面的能力，操作起来更像是手搓 Web 三剑客（HTML、CSS、JavaScript）。所以，**图方便的话更建议在线转换**`.txt` `.doc(x)`文档。
+
+::: details EPUB 内容物
+epub 的 mimetype 通常标`application/epub+zip`，说明其本质是压缩包。解压出来通常分这么几块：
+- `mimetype`：资源类型标识，内容如上。
+- `META-INF/container.xml`：标明电子书（OEBPS 包）的根目录。
+- `OEBPS/`
+  - `Images/cover.*`：封面
+  - `Styles/*.css`：网页排版
+  - `Text/*.*htm*`：反正必须是 HTML。
+  - `content.opf`：电子书的元数据、内容物信息。
+  - `nav.*htm*` `nav.opf`：电子书的目录。前者为 epub3 标准，后者为 epub2 标准，通常在`content.opf`里特别标注。
+  - `Fonts/` `Audio/` ...：其他内容。
+
+所以我称编辑 epub 这件事为“手搓网站”，因为本来就需要按章回编排 Web 内容，这 OEBPS 的目录树也很有网站的味。
+:::
+
+::: warning 书目目录索引
+和 Calibre 等阅读器不同，Jellyfin 对目录的跳转**以 OEBPS 包为基准**，而不是以目录文件为基准。如果发现 Jellyfin 里**点目录里的章标题没有反应**，你需要用 Sigil 等编辑器将`nav.*`移动到`OEBPS/`目录下。
+:::
+
+::: note 文件组织
+实测结论是：可以不像漫画那样遵循官方文档“一书一目录”的要求，但**应尽量避免“一目录只有一 epub”的情形**。像以下情形 Jellyfin 会误判：
+
+- Books
+  - 正经的
+    - 《时间简史》.epub
+    - 毛泽东
+      - 《实践论》.pdf
+      - 《矛盾论》.pdf
+    - 《葬送的芙莉莲》.pdf
+  - 不正经的
+
+扫描结果是：“不正经的”和《时间简史》。其余读物无法直接访问（可能仍能搜索到）。
+:::
+
+## 穿透与反向代理
+
+如今连网易云也改得不知为何物了，于是我随身听的需求便也转向 Jellyfin。最简单的方法可以是 ZeroTier，但安卓有“同一时间只允许一个 VPN”的限制，所以在群友指导下搞了内网穿透（FRP）。
+
+此后，我遇到了子网划分的问题。起初这个问题并不起眼，直到我在户外同时尝试走 ZeroTier 和穿透，我才发现 frp 连上之后似乎更像是在本地回环，而 Jellyfin 似乎**对本地回环不设限速**。
+
+> ~~写着写着总会变成报流水账。~~
+
+AI 对此的解法是在 frp 这里记录下真实 IP。我选配的服务商支持 Proxy Protocol，也更推荐这么实现。但在实地测试后，发现 Jellyfin 并不直接支持 Proxy Protocol，那么就只能在 frpc 跟 Jellyfin 之间多加一层 nginx 做反向代理了（frps 显然我是动不了的）。
+
+方法很简单，frp 侧仍旧启用 Proxy Protocol，在 nginx 里剥离真实 ip。参见[官方文档](https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/nginx)。
+
+后来考虑到挂 web 的静态资源安全（防止意外删改），就顺势收紧 Jellyfin 容器的权限和性能分配。其中桥接网络让我想起最初的小巧思：我把 frp 挂在中间机器上，流量物理上不走内网不就好了。最终搭起来看了一眼日志，貌似连`nginx`都不需要了：
+```log
+[2026-03-09 10:08:57.650 +00:00] [INF] [23] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "172.17.0.1" closed
+[2026-03-09 10:08:58.280 +00:00] [INF] [28] Emby.Server.Implementations.HttpServer.WebSocketManager: WS "172.17.0.1" request
+[2026-03-09 10:09:00.493 +00:00] [INF] [24] Jellyfin.Api.Controllers.UniversalAudioController: ...
+[2026-03-09 10:09:00.495 +00:00] [INF] [24] Jellyfin.Api.Helpers.MediaInfoHelper: ...
+[2026-03-09 10:09:00.495 +00:00] [INF] [24] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIP: "172.17.0.1", IsInLocalNetwork: False
+```
+注意到最后一句`IsInLocalNetwork: False`，它似乎并不认为 Docker 容器的桥接网段是内网网段。这样一来连 frp 隧道都不需要动，天然就完成了我的小巧思。

docs/diaries/wbsy/recents-11172025.md

@@ -0,0 +1,37 @@
+# 碎碎念#1
+最近折腾了不少东西，心情也起起伏伏。《如我所书》取自崩铁的同名词条，个人也倾向于记录那些“能成篇的”专栏；咱这主题又没动态功能，思来想去还是写到这充当《记忆的质料》吧。
+
+## 可爱一点的博客主题
+既然说到博客主题，就顺便唠唠好了。我个人还是觉得`vuepress-theme-hope`偏向项目文档一些，当作博客虽然也可以 !!（甚至 MarkDown 扩展相对很齐全）!!，但……怎么说呢，可爱不起来（
+
+我个人还挺宅的，主题这方面也想稍微萌系一点。不说非得特别可爱吧，至少想一眼给人那种二次元的印象。在 GitHub 上搜了一些二次元主题，要么是 Mizuki 二创（或者说 Fuwari 三创？），要么缺胳膊少腿。像有个 BA 主题只能塞推文，要动态和友链还得另搓；另有个 Miracle 主题虽然视觉上挺优雅的，但 MarkDown 扩展支持又一言难尽。
+
+> 好友：自己搓个吧（  
+> 我：呜呜，补会（
+
+所以还是接着套这个模板吧。
+
+## 名为无所谓，实为破罐子破摔
+前一阵发现“无病呻吟”这块连续塞了四篇负能量。事实证明，写小作文并不能解我的铃[^mentalIllness]，充其量延缓我的症状。当然我的症状归根结底缘于内耗，解释起来又要去讨论我的“失败史”，不妨就这么总结吧：
+
+- 咕咕咕的怠惰：只要没有 DDL !!（骗你的，没奖惩的 DDL 也照样）!!，就能以月、年为单位地拖。
+- 懒汉做学问：要用什么学什么，主打一个经验主义。
+- 自以为自知之明的无知：从来就没（能够）客观评价自己，要么眼高手低，要么把自己贬得一无是处（现在也一样）。
+- 在失败的斜坡上短道速滑：独立创作遇上瓶颈滑坡成“毫无创见”，考研坠机滑坡成“这辈子也就这样了”，刚干活一个月犯了事（虽然并非小事）滑坡成“千古罪人”，……
+
+于是一面写小作文痛批自己，一面发现自己仍然每况愈下，就这样磨洋工过了半年。最后与其说是释然、“无所谓”，更像是破罐子破摔、“随便怎么样吧”。说起来这“千古罪人”的帽子也不过是前同事跟我开玩笑说说的，只是我这人容易当真，我现在的确认为自己是个罪人，值得一呜呜伯爱死的那种。
+
+[^mentalIllness]: 我个人觉得精神困境还是“解铃还需系铃人”的处理逻辑。不过最近也见证了一些无力处理这类困境、不得不求诊的例子，还是“说起来容易做起来难”啊。
+
+## 硬件购置
+今年说实话不太适合装机（）双 11 前后内存涨、硬盘涨，现在甚至 CPU 也涨。不知道各位觉得 2T 固态理想情况得是多少米，我是借着我哥的天猫超市中秋礼券、红包、优惠叠起来，咬咬牙 680 买下铠侠的 SD10 2TB。!!说实话更希望再便宜点，最好是 648（雾）!!
+
+另一边，我去年的推流姬也摇身两变，先是作为我上班的消遣（RDP 远程），然后又拿来当 NAS（当然也不单纯为了存储）。NAS=Network Attached Storage，没盘怎么组 Storage，所以先是搞了块 500G 2.5 寸 CMR 薄盘，到这里为止说实话还称得上好活。
+
+本年暑期，有群友出一台 4 盘位蜗牛 C 款小闷罐，我则用《原神·空月之歌》的两个版本代肝作为交换（当事人称作“灵活的支付方式”）。等实际接盘了我才发现所谓的扩展性在我这推流姬上困难重重：我这推流姬并没有那么多 IO 接口给他扩（也就 2.5 寸 SATA、m.2 SATA、NGFF WiFi，那两 SATA 实测也不支持 PM 功能），随附的 miniPCIe 转 8654 也用布上（最开始甚至尝试用 mSATA 转接板连这个转接卡）。
+
+最终只能考虑 USB3.0 去接 SATA PM 板，一拖五。结果又发现这机箱本就是残花败柳，四盘位坏了两。属于是“前景不错，但有前景不太可能”。推流姬的板 U 太垃圾导致的。
+
+---
+
+虽然还有很多话题想唠，但真要写起日记吧，记忆却蒙上一层薄雾，回忆不真切。以上是记得比较清楚 ~~（或者说耿耿于怀）~~ 的几件，姑且落笔一叙。

docs/notes/Maintenance/ArchInstall.md

@@ -172,7 +172,7 @@ pacman-key --populate
 在**联好网的新系统**里配置`archlinuxcn`源：再次打开`/etc/pacman.conf`，末尾添加如下小节
 ```ini
 [archlinuxcn]
-Server = https://mirrors.tuna.tsinghua.edu.cn/archlinuxcn/$arch
+Server = https://mirrors.cernet.edu.cn/archlinuxcn/$arch
 ```
 并安装 CN 源的签名密钥和 AUR 助手：
 ```bash
@@ -218,7 +218,7 @@ sudo pacman -S pipewire gst-plugin-pipewire pipewire-alsa pipewire-jack pipewire
 跟完前面的内容之后，你便拥有了一个无 GUI 的终端 Arch 系统。但作为日常使用的话，图形桌面肯定必不可少。
 
 本文与那两篇参考外链一样**采用 KDE 桌面环境**。当然除了 KDE 之外，你也可以考虑 GNOME 桌面环境 ~~（只是我用腻了）~~；
-也可以考虑散装方案（比如`hyprland`~~，只是我没折腾成功~~）。
+也可以考虑散装方案（比如`niri`，部分配置可参见 [aglab.dotfiles](https://git.liteyuki.org/AgxCOy/aglab.dotfiles)）。
 
 ```bash
 # 分别安装 xorg 套件、sddm 登录管理器、KDE 桌面环境，以及配套软件

docs/notes/Maintenance/ArchUEFI.md

@@ -67,9 +67,9 @@ UEFI 固件首先会**遍历各硬盘的 ESP 分区**，并在其中查找`\EFI\
 ::: info
 实际上`bcdboot`工具会在 ESP 分区里同时写入`bootx64.efi`和`bootmgfw.efi`。前者即回退路径启动项。
 
-有关`bootx64.efi`、`bootmgr(.efi)`和`bootmgfw.efi`的关系可能有些复杂，[微软文档](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/bcd-system-store-settings-for-uefi?view=windows-11)也只隐晦地给出了一部分，谷歌了一圈各种观点都有。本着实事求是的原则，我不会糅合这些观点提出假设，只附上几个问题：
-- Windows 的`bootx64.efi`分别在本机 Windows、WinToGo 和 WinPE 中起到什么作用？它是否真的等同于（或者等价于）`bootmgfw.efi`（或是`bootmgr`）？
-- 到底是 fwbootmgr（即`bootmgfw.efi`）调用 bootmgr，还是反过来呢？二者是谁“悄悄地”为 UEFI NVRAM 添加原生启动项？
+有关`bootx64.efi`、`bootmgr(.efi)`和`bootmgfw.efi`的关系可能有些复杂，谷歌了一圈各种观点都有。本着实事求是的原则，我不会糅合这些观点提出假设，只附上几个问题：
+- `bootx64.efi`、`bootmgfw.efi`（或`bootmgr`）分别在本机 Windows、WinToGo 和 WinPE 中起到什么作用？三者之间是否存在等价（即功能上可以替代，乃至文件哈希相同）？
+- fwbootmgr（即`bootmgfw.efi`）与 bootmgr，是谁“悄悄地”为 UEFI NVRAM 添加原生启动项？
 :::
 
 ## 启动加载器（以 Grub 为主）
@@ -193,7 +193,7 @@ echo 'root=UUID=... resume=UUID=... rw loglevel=3 quiet' > /etc/kernel/cmdline
 
 ::: info [GPT 分区自动挂载](https://wiki.archlinuxcn.org/wiki/Systemd#GPT%E5%88%86%E5%8C%BA%E8%87%AA%E5%8A%A8%E6%8C%82%E8%BD%BD)
 跟 [@Vescrity](https://github.com/Vescrity)讨论的时候我俩都觉得分区 UUID 太长了，于是他尝试省略掉`root=`参数。  
-就结果来看还真可行，顺带附上他的折腾记录：[Yukitoha Blogs：从统一内核镜像启动](https://vescrity.github.io/post/UKI/)。
+就结果来看还真可行，顺带附上他的折腾记录：[《从统一内核镜像启动》](https://vescrity.github.io/post/UKI/)。
 :::
 
 ### ii. 预设文件

docs/notes/Maintenance/JellyfinFileOrg.md

@@ -1,221 +0,0 @@
----
-category: 折腾流程
-tag:
-  - Jellyfin
-  - 影音服务器
-  - 媒体库
-  - 刮削
-  - 文件管理
----
-
-# 影音服务器——有关 Jellyfin 的文件归集
-
-> [!important]
-> 本文仅探讨音、视、图、文在纳入 Jellyfin 媒体库时应该如何整理、刮削，**并不涉及工具本身的部署以及媒体库的建立**。如有需求还请另行查找教程，或翻阅[官方文档](https://jellyfin.org/docs/general/installation/)。
-
-> ~~Emby 支持文件夹，Jellyfin 不支持，Emby 赢一半！（~~
-
-Plex 怎样我不清楚，但 Emby 对文件摆放的要求的确是比 Jellyfin 宽松得多的。但在好友的撺掇下，我还是换用 Jellyfin 了。~~……然后，就被 Jellyfin 的刮削和文件结构要求气晕。~~
-
-::: note 我个人的大致分类
-- 电子书（Books）
-  - 漫画（Comics）
-  - 小说（Novels）
-- 音频
-  - 音乐（CloudMusic）
-  - 音声（DLsite、ASMR 虚拟主播的录播转码）
-- 视频、图片
-  - 音声（实写录播）
-  - 画师的差分图（Fanbox、Patreon，等等）
-  - MMD
-  - 可爱的女装照（不是我的，我的[都发出来惹](../../diaries/dress/readme.md)）
-
-虽然上述一些内容的说法已经比较直白，但真的点出来是什么东西就还是有点超过了哈。
-:::
-
-有人可能会问，为什么音声会分音、视频呢？呐就要讨论下 Jellyfin 的媒体库了。
-
-## 媒体库的类型
-
-无论 Emby 还是 Jellyfin（我想 Plex 也一样），对于媒体内容的界定通常比较分明。这当然可称得上一件好事，但视频不仅仅是影片，音频也不仅仅是歌曲。对于没办法归类成“剧集”的，尚有“家庭视频和照片”这种分类，这也就能够解释为何我把视频和图片归为一大类；然鹅对于没办法归类成“专辑”的，私密马赛，我莫得选择。
-
-![Jellyfin 媒体库类型 =180x](./jellyfin_content_type.webp)
-
-然后……接下来就讲讲音乐、书籍、家庭视频和照片怎么整理文件夹结构吧。电影和节目这块网上应该也有不少教程。“混合电影和电视”这一项据官网称**已经弃用，不推荐选**。
-
-::: tip 或者参考这些博客
-毕竟我是死宅嘛。!!死宅真恶心。!!
-
-- [《利用 Jellyfin+Bangumi 打造更舒适的动画媒体库》（初之音）](https://www.himiku.com/archives/deploy-a-more-comfortable-animation-library-with-jellyfin-and-bangumi.html)
-- [《打造你的同人音声媒体库》（Hinata Rin）](https://blog.hinatarin.com/2021/09/27/build-your-own-doujin-voice-media-library/index.html)
-:::
-
-## 书籍
-
-::: details 官方给出的电子书摆放
-```
-Books
-├── Audiobooks
-│   ├── Author
-│   │   ├── Book1
-│   │   │   └── Book1.flac
-│   │   └── Book2
-│   │       └── Book2.mp3
-│   └── Book3
-│       ├── Book3.aac
-│       ├── content.opf
-│       └── cover.jpg
-├── Books
-│   └── Author
-│       ├── Book4
-│       │   └── Book4.epub
-│       ├── Book5
-│       │   └── Book5.epub
-│       ├── Book6
-│       │   ├── Book6.epub
-│       │   ├── cover.png
-│       │   └── metadata.opf
-│       └── Book7
-│           └── Book7.pdf
-└── Comics
-    ├── Plastic Man (1944)
-    │   └── Plastic Man #002 (1944).cbz
-    ├── Attack on Titan (2012)
-    │   └── Attack on Titan #001 (2012).pdf
-    └── Comic (2008)
-        ├── ComicInfo.xml
-        └── Comic #001 (2008).cbr
-```
-:::
-简而言之，对于每一“本”书，最好**单独开辟一个文件夹**，然后文件夹里**只摆放该书的单文件“合订本”**（比如`Books/王道24寄网/王道24寄网.pdf`）。
-
-但这么分在我看来十分甚至九分的抽象，因为我手里的大多数小说和漫画都莫得有效的标签，甚至绝大多数是由纯文本导出 PDF 而来。因此，比起官版墨迹的组织方式，不妨就按各人的阅读习惯组织起来，不支持的格式导出成 ~~PDF~~ EPUB，就可以了。
-
-> [!note]
-> 旧版 Jellyfin 的 PDF 阅读器在 PC 端有可能加载不出来。而且就阅读体验来说或许还不如下载到手机里用 WPS 阅读。~~所以服务器端真的没有像番茄免费小说那样的电子书架吗（~~
-
-## 家庭视频与照片
-
-这一分类也是差不多的随性。官方也莫得文档来强制约束应当是什么样的文件组织。以《绝区零》铃妹的一组差分图为例：
-
-![《家庭视频和照片》 =180x](./jellyfin_home_visual.webp)
-
-## 音乐
-
-然后就是重头戏了，音乐。开篇我提过，我借助音乐媒体库还托管一些同人音声，那么对于音声的管理也是同样的。
-
-::: details 官方给出的音乐摆放
-```
-Music
-├── Some Artist
-│   ├── Album A
-│   │   ├── Song 1.flac
-│   │   ├── Song 2.flac
-│   │   └── Song 3.flac
-│   └── Album B
-│       ├── Track 1.m4a
-│       ├── Track 2.m4a
-│       └── Track 3.m4a
-└── Album X
-    ├── Whatever You.mp3
-    ├── Like To.mp3
-    ├── Name Your.mp3
-    └── Music Files.mp3
-```
-:::
-
-### 歌曲的刮削与组织
-
-::: info 媒体刮削
-刮削——或者我更愿意称之为“打标”或者“tagging”——指的是从特定渠道（一定是互联网吗？未必）获取到这份音/视频的元数据信息（作者、标题、流派、专辑、发行年份，等等），并且填充进媒体文件的附加信息位（通常位于文件尾部），又或者单独整理成`.nfo`之类的数据库的行为。
-
-这一词不仅限于音频，视频也是有元数据信息的，比如内嵌字幕（不同于剪辑、特效软件直接打在视频流上的文本框字幕）。
-
-非要说的话，我更倾向于：“刮削”一词不过是老烧们捏出来唬人的，所谓的专有术语罢了。
-:::
-
-我的歌曲大多下载自网易云，通常来说都是刮削好的`mp3`和`flac`文件，但也有些许例外，比如 VIP 歌曲复制链接跑去在线工具抓取下载得来的音频文件，呐怎么办呢？
-
-之前看到的[《基于 Jellyfin 和音流的 nas 影音库搭建及踩坑》（少数派）](https://sspai.com/post/90896)一文推荐了“音乐标签”这么个工具，支持从网易云、QQ 等多个国内源抓取、刮削音频。此外，Mp3tag（[官网下载](https://www.mp3tag.de/en/download.html)、[官方文档](https://docs.mp3tag.de/)）也可以从 MusicBrainz 等国外源抓取、刮削。
-
-个人建议刮削阶段还是用国内源比较好，因为接下来我要讲一个“洛天依作品集”的故事：
-
-![洛 天 依 作 品 集 =420x](./luotianyi_question_mark.webp)
-
-但刮削工具也并非万能。比如《紫罗兰永恒花园 OST》的很多歌就被“音乐标签”那软件霍霍了个遍：
-
-![《凹凸世界五周年》 =420x](./musictag_misfetch.webp)
-
----
-
-刮削完了需要按上面的官方要求组织这些歌曲，毕竟 Jellyfin 不支持读取音乐标签自动聚合（这点在上面援引的博客中也吐槽了）。我个人用 Mp3tag 做批量重命名。相比起音乐标签，Mp3tag 重命名时允许用函数格式化字符串，比如`$replace`、`$num`，方便一点。
-
-Jellyfin 的音频搜集**仅以专辑为依据**。官方文档自己也说“as long as each album is contained within one folder”，翻译过来就是“只需确保一张专只在一个文件夹（子树）”。所以文件结构自然也以专辑为准。
-
-::: details 分碟
-顺带一提，基于上述准则，以及我自己组织音声的实践来看。有如下几种错误例，Jellyfin 会拆分成多个同名的专辑：
-1. 同一张专按分碟**分成多个文件夹（树）**，违反单子树要求
-  ```
-  Author
-    \AlbumA Vol.X
-    \AlbumA Vol.Y
-    \AlbumB Vol.X
-  ```
-  这种情形会在媒体库里拆出两个 AlbumA（分别为盘号 X 和盘号 Y）。
-
-2. 非数字光盘号（音乐专辑诚然如此，然鹅音声有 Omake）
-  ```
-  \Album
-    \Vol.1
-    \Vol.2
-    \Vol.Omake
-  ```
-  这种情形 Omake 会被拆出去，也就是两张封面一样的 Album 专辑。
-
-3. 文件夹不显式标明盘号，指望用`.mp3`文件里的盘号让 Jellyfin 自动刮削
-  ```
-  \Album
-    \Asahina Akari POV
-    \Mahiro Yuzuki POV
-    \Mahiro Yuri POV
-  ```
-  Jellyfin 会这么看：把 Album 当成 Artist，把三个 POV 当成三张独立专辑。也就是拆成三张同名专辑。
-
----
-
-正确的组织方式应为：
-```
-Author
-  \AlbumA
-    \Vol.X
-    \Vol.Y
-  \AlbumB
-```
-~~所以说就不能直接读音乐标签做自动聚合马？~~
-:::
-
-### 音频音声的刮削与组织
-
-不同于歌曲的刮削，音声**通常是没有标签**的。所以，首先需要人为对这些音声进行分类：DLsite 贩售的？主包的订阅限定？还是说有什么特征，是剧情音声？催眠音声？普通的奥数魔刃？
-
-如果有些音声实在没有头猪，至少也用“散装”之类的文件夹包起来，**尽量确保所有的“文件”都被文件夹收纳好，避免裸放在媒体库文件夹下，也避免文件夹和音声文件混着存放**[^mixed_album]。
-
-[^mixed_album]: 避免音声文件和文件夹混在一起，是因为：
-    - 假若该文件并没有任何标签，那么只能在 Jellyfin 音乐媒体库的“歌曲”那一页翻来覆去才找得到；
-    - 假如该文件有打标签，那么所有和它混在一起的文件夹，里面的音声分类（哪怕自身有打标）均会被覆盖为该文件的标签。
-
-::: tip 理想的文件树（简化版本，但仍可能加载较慢）
-```mermaid
-flowchart LR
-    A(["音声"]) --> B(["DLsite"]) & D(["订阅限定"]) & E(["音声录播"])
-    B --> B1(["RJ416817"]) --> n1(("\*.mp3"))
-    D --> D1(["希丝奈cisne"]) --> D11(["24-11"]) --> n21(("\*.mp3"))
-    D1 --> D12(["八月舰长音声"]) --> n22(("\*.mp3"))
-    E --> E1(["mahoulelys"]) --> n3(("\*.mp4.mp3"))
-```
-或者说，尽可能保证所有的**文件**均在平衡树的叶子节点处。
-:::
-
-分类完毕之后，再对这些音声做批量的打标。
-
-DLsite 上贩售的音声可用 Python 第三方库`dvtag`打标（从 DLsite 获取元数据可能需要代理），具体可参见开篇的参考博客；像音声录播通常就以主播为单位收纳好；至于可能存在子文件夹的订阅限定，可以用 Mp3tag 批量为这些音声的作者、年份字段打上标注，或是在专辑字段打上“谁谁的限定音声”，都行。

docs/notes/Maintenance/SelfHosted.md

@@ -211,7 +211,7 @@ geox-url:
 
 - `webmin`：提供 WebUI 以配置服务器的系统，以及监测服务器的性能占用。
 - `aria2`与`AriaNg`：提供直链、BT、PT 下载支持。参见[《手把手教你使用 Docker 搭建 aria2+AriaNg，打造自己的离线下载服务器》（博客园）](https://www.cnblogs.com/wqp001/p/14709997.html) [^ariang_baidupan]。
-- `jellyfin` `emby`：影音服务器。有关 Jellyfin 的刮削会专门另开一篇讨论。
+- `jellyfin` `emby`：影音服务器。个人觉得就*资源管理的便利性*而言，Jellyfin 并不算好；但 Emby 白嫖着用也不见得操作有多舒服。
 - `vscode-server`：控制端可利用 VSCode 配合 Remote-SSH 插件连上服务器，做些跨平台开发……或者 Linux Native 开发。~~真有人在 Linux 编译 MSVC x86-64 吗？有的话浇我。~~
 - `ssh`：Xshell 做些命令行活计，Xftp 做些文件交换活计。
 - `nfs`：和前面 Windows 一样，可以挂共享文件系统。

package.json

@@ -10,15 +10,15 @@
     "up-deps": "pnpm dlx vp-update"
   },
   "devDependencies": {
-    "@vuepress/bundler-vite": "2.0.0-rc.24",
-    "@vuepress/plugin-docsearch": "2.0.0-rc.118",
-    "@vuepress/plugin-remove-pwa": "2.0.0-rc.118",
-    "katex": "^0.16.25",
-    "mermaid": "^11.12.1",
-    "sass-embedded": "^1.93.3",
-    "vue": "^3.5.22",
-    "vuepress": "2.0.0-rc.24",
-    "vuepress-theme-hope": "2.0.0-rc.98"
+    "@vuepress/bundler-vite": "2.0.0-rc.26",
+    "@vuepress/plugin-docsearch": "2.0.0-rc.124",
+    "@vuepress/plugin-remove-pwa": "2.0.0-rc.124",
+    "katex": "^0.16.35",
+    "mermaid": "^11.12.3",
+    "sass-embedded": "^1.97.3",
+    "vue": "^3.5.29",
+    "vuepress": "2.0.0-rc.26",
+    "vuepress-theme-hope": "2.0.0-rc.103"
   },
   "packageManager": "pnpm@9.15.3+sha512.1f79bc245a66eb0b07c5d4d83131240774642caaa86ef7d0434ab47c0d16f66b04e21e0c086eb61e62c77efc4d7f7ec071afad3796af64892fae66509173893a"
 }

vuepress.config.ts

@@ -25,7 +25,7 @@ export default defineUserConfig({
     [
       "link",
       {
-        href: "https://unpkg.com/",
+        href: "https://npm.onmicrosoft.cn/",
         rel: "preconnect",
         crossorigin: "",
       },
@@ -33,7 +33,7 @@ export default defineUserConfig({
     [
       "link",
       {
-        href: "https://unpkg.com/@agxcoy/lxgw-wenkai-vp-hope@latest/style.css",
+        href: "https://npm.onmicrosoft.cn/@agxcoy/lxgw-wenkai-vp-hope@latest/style.css",
         rel: "stylesheet",
       },
     ],