浏览器不支持(未启用)JavaScript,本页面的某些功能无法正常使用
稔谷·刊 Cover

稔谷·刊

东西成文 知趣成采

参小智

数字也能成精 幻觉切莫当真

宁嘉

码上抽象 弦时妄想

折腾NAS五年,我眼中的家用云与未来个人计算

开个新坑,分享我对家用云服务的心得和思考。 网上常用 NAS、HomeServer、HomeLab 来称呼这类产品,我更愿意叫它家用云服务——它聚焦于个人与小团体的数字化体验,区别于企业级的公有云和私有云。 2021年回老家时,我临时起意买了个黑盒子,一路拎着进家门,从此一发不可收拾。5年间,保守估计折腾了1000小时,大致相当于我花在跑步上的时间,成了我的两大业余爱好之一。如今我日常维护着2台NAS,加上主机、Mac Mini,以及若干网关路由和VPS。 自托管的代价:从1000小时到"无人值守" 为了更直观理解本文的主旨,我先分享一下这1000小时折腾的"成果",也算个人碎碎念。主要围绕网络、安全、应用三个维度展开。 网络:复杂的冗余方案 为了实现"无人值守",我构建了一套复杂的冗余网络: * Tailscale(自建中继)和 WireGuard 在不同场景下切换使用 * 蒲公英组网作为备用,

AI改变学习方式—附OneNote和NoteStation迁移到Obsidian指南

我并不爱记笔记,但是要学习的多了,就不得不:打开、写、保存。 记笔记效率太低,哪怕只是复制粘贴,也得花时间整理格式;技术知识又很容易过时;而且我几乎从不回看笔记,笔记只是在记录的哪一刻稍微加深点记忆,之后就再也不打开了。反倒是对记过的知识点又经常搜资料、查文档,感觉效率更高,也相当于复习。 一、AI出现之后,学习链路被彻底改写 生成式AI改变了这一切。不再需要频繁用搜索引擎,不再需要盯着官方文档逐页翻,当然,特别新的偶尔还得手动查一下,至少对重要的信息要自己验证一下。 因为LLM压缩了公共知识,它还能调用工具,比如搜索工具、MCP工具、CLI工具。还有一个常被忽略的点:LLM的注意力机制和人类非常不同。跟人对话,一连串问题甭管说得多重要,对方大概率只回最后一个;而LLM能一次性把所有问题都答全,除非上下文长到几十万字,出错概率才会明显上升。这种特性天然适合高效学习和记录,因为学习本来就是由一连串问题或大纲扩展而成。 那么,还需要记笔记吗?理论上,LLM回答的都是公共知识(除非导入私有知识库),确实没必要记——没记住?再问一遍就行。但AI有幻觉问题,

浅尝领域驱动设计:DDD是AI编程-上下文工程的良好框架

传统上,搭建一个后端WEB项目从MVC+三层架构开始,而见识过AI的效率后,只要提示得当5分钟的生成就顶过我一天的工作量,因此我写了个DEMO,又写了个文档,然后就试图让流行的AI工具帮我快速实现。不出所料,在没有严格限定和充分审查的情况下,AI很快把项目改得面目全非,它能实现一个勉强能用的DEMO(所谓的氛围编程),但几乎不可维护。 然后我不得不重构项目,并开始思考:什么是AI介入后端的良好范式? 就这样我不由自主的走上了领域驱动设计(DDD)的路线,以下是我的一点探索和浅见。 在我看来,DDD 是后端项目负责人想要掌控项目和IT企业想要掌控核心资产的黄金实践。DDD理想情况下需要项目负责人具备领域专家的业务能力,它更适合那种在垂直领域扎根并依赖底层技术创新来扩展业务的项目。现在它也适合AI辅助编程,当然也可以通过AI辅助、迭代调整来逐步建立领域知识——关键是要有"追求理解业务本质"的意识。 依赖倒置:让业务逻辑不受框架绑架 传统三层架构的依赖链条: UI层 → 业务逻辑层 → 数据访问层 → 数据库 换个ORM框架?改业务代码。数据库从MySQL换P

开源 NamBlog:一个博客外壳下的体验编译器

写作的裂变:从静态文本到动态原型 现阶段,我们见证了许多生成式 AI 带来的范式转移:聊天、绘图、编程等等。我关注写作这一行为,写作的定义也在悄然地裂变。过去,写作意味着生产静态文本;现在,写作是在设计可交互的数字体验原型。过去,作者交付的是内容;现在,作者交付的是调教 AI 的规则。 差异将体现在交互方式和对资源整合的想象力上。聊天对话框把思维压缩成线性 prompt,是 AI 时代的“命令行”,能用,但远远不够。我们需要一种能同时承载人类意图的模糊性和机器执行的精确性的媒介——一种既是底稿又是源代码、既写给人类也写给 AI 的双重文本。 这就是为什么 Markdown 值得被重视。它可以被视为是一种允许留白和扩展的社群协商式的符号中介层。那些 #、*、![]() 不是死板的语法规则,而是人机对“如何共同理解一段文本”达成的动态协议。那些排版是为了流畅阅读,也可以为了工作流编排;那些嵌入块是思维关联,也可以是微服务容器。 受此理念驱使,我开发了一个实验性项目。

Csharp 14 与 DotNET 10 的杀手级特性:成为并超越脚本语言

当我首次在控制台运行 dotnet run my-app.cs 时,产生了一种久违的兴奋感,C# & .NET 这个传统上被视为笨重的编程语言与开发平台,突然拥有了脚本语言的灵魂。不再需要繁琐的 .csproj 文件,不再需要复杂的项目结构,一个 .cs 文件就能完整表达所有意图。这在开发体验上是非常不同的,更是 C# 生态的一次重要突破。 为此,我创建了一个开源项目 CsharpFileScripts,专门探索这项技术的创新边界。今天,我想系统性地分享这项技术,以及它为什么值得你尝试。 什么是基于文件的 C# 程序? File-based C# Programs 是 C# 14 与 .NET 10 引入的革命性特性,允许将整个程序封装在单个 .cs 文件中,无需项目文件即可直接编译运行。 #:package Colorful.Console@

一文诊断 Docker 容器权限问题与最佳实践

前言 在 Docker 容器化部署中,Permission denied(权限拒绝)是最常见的障碍之一。无论是容器启动失败,还是宿主机无法修改挂载的数据文件,其本质往往归结为宿主机与容器内部用户身份的不对等。 本文将深入剖析 Docker 权限管理的底层机制,提供从架构设计到具体配置的完整解决方案,并覆盖 SELinux、NAS ACL、Docker Volume 等特殊场景的处理策略。 ⚠️ 适用环境说明 本文主要针对 原生 Linux 环境(包括 Ubuntu/CentOS 服务器、群晖 DSM、威联通、Unraid 等)。 对于 Windows 或 macOS 上的 Docker Desktop 用户,由于虚拟化层自动处理了文件所有权映射,通常无需进行复杂的权限配置。 1. 核心机制:Linux 内核的

认清Matrix协议的“创新困境”

我已经使用matrix很长时间了,为它做了几个项目,成了重度用户和开发者,也加入了一些房间讨论。最近一次交流不太愉快,却也促使我转变思维,不再聚焦于社区和我自身的需求,而是从外部视角获得清晰的观点!这应该是我最后一篇专门写Matrix的博文,特别资讯专栏(如脚本更新)仍会通过邮件和房间推送。对于这篇文章,欢迎不同看法。 “客户端实现”:一个看似美好却充满陷阱的提议 在Matrix生态中,当讨论新功能(例如“联系人别名”)缺失时,一个常见的观点是:协议本身是极简、稳定的骨架并提供了一定的扩展性(自定义事件),功能创新应该由客户端在骨架之外自行实现。 这个观点在技术上“正确”,但它回避了作为一个“生态”在实践中要解决的核心问题。依赖客户端自行实现,隐藏着三个陷阱: 1. 体验的割裂与标准化的必要性 Matrix的核心价值在于联邦与互操作性。一个功能(比如“投票”)如果只在一个客户端上实现,那它对生态而言几乎是无用的、体验是分裂的。为了让其他客户端也能参与投票,这个功能最终还是需要通过MSC(Matrix Spec Change,协议规范变更

从低效联邦到神经中枢,探讨Matrix的独特价值

一、对联邦网络的错误幻想 在很长一段时间里,我(以及许多人)对Matrix这样的联邦网络抱有极大的热情。我们渴望一个开放、自主、去中心化的“下一代社交平台”。我曾深入研究它,寻找并设想各种创新的应用,试图把它打造成一个更好的“微博”或“微信”。 然而,这些尝试“低效且低价值”,理由和许多人的感受一样: * 没有“流量”: 作为一个内容创作者,在上面得不到反馈。没有读者增长,没有互动,没有收益。 * 没有“效率”: 作为一个内容消费者,找不到好内容。没有算法推荐,发现机制原始,信息密度极低。 * 没有“连接”: 作为一个网络平民,早期互联网论坛和聊天群那种田园牧歌式的氛围不复存在,只有边缘化、匿名化的流动ID。 联邦网络如果是为了模仿或替代主流平台,无疑是失败的,需要换个角度。 二、为什么觉得Matrix“没用”? 在找到正确的方向之前,先绕开那些让我们感到失望的“坑”。 坑1:

Synapse 部署:Python脚本映射路径长期方案

近期 Synapse 发布了 1.141.0 (2025-10-29) 版本,此版本的 Docker 镜像已基于 Debian trixie 和 Python 3.13。 🚨 问题所在 这次底层系统的更新,导致了 Python 软件包的安装路径发生了变化(从 python3.12 变为 python3.13)。 如果您之前使用我博客的中文搜索脚本,通过 docker-compose.yml 中的 volumes 来硬编码挂载自定义 Python 脚本,您的 Synapse 服务在更新后将无法启动。其他外挂的python模块同理,例如shared_secret_authenticator(网桥认证模块), 旧的、已失效的配置如下所示: volumes: - ./py_

优化 Matrix Synapse 的 oEmbed 链接预览功能(不重要)

oEmbed 是一种让第三方网站通过 URL 嵌入外部内容(如视频、图片或网页摘要)的格式。它包含两方: * 消费者(如社交媒体)向 提供者(如 YouTube)请求嵌入内容; * 提供者 返回 JSON/XML 格式的数据,包括媒体、标题、摘要等信息,供消费者直接展示。 Matrix/Synapse 支持通过 oEmbed 协议为消息中的链接生成丰富的图文预览。虽然 Synapse 内置了一套规则,只有但可能对某些网站的支持不佳或显示信息不够全面。这时,我们可以通过引入第三方的 oEmbed provider 列表(如 https://oembed.com/providers.json)来增强此功能。 但在配置过程中,可能会遇到一些问题,以下是解决方案和已知限制的总结。 配置中的常见问题 在使用

如何在 Matrix 中实现消息过期(自动删除)

本教程提供两种在 Matrix 中实现消息自动删除的方法。方案一需要服务器管理员权限,效果更底层;方案二通过机器人实现,只需房间管理员权限即可。 方案一:通过服务器 Retention 功能实现 (需服务器权限) 此方案通过配置服务器底层的数据保留策略,让服务器从数据库层面定期清除过期消息。 第一部分:服务器端配置(管理员操作) 1. 编辑配置文件: 打开你的 Synapse 服务器的 homeserver.yaml 配置文件。 2. 添加 retention 配置: 参考以下配置在文件中添加或修改: # 消息保留策略,存在于房间级别,遵循MSC1763 retention: # 开启 retention 功能 enabled: true # 配置清理任务,定期从数据库删除过期事件 purge_jobs: # 这个任务每一小时运行一次,清理最长生命周期小于等于3天的消息 - longest_max_lifetime: 3d

Blumid:开发一款为纯粹阅读而生的 Ghost 主题

酝酿许久,我终于完成了这款一直想开发的博客主题——Blumid,也就是你现在所看到的模样。它基本完整实现了 Ghost 官方提供的所有功能(如搜索、会员、内容卡、原生评论等),更在设计理念和功能细节上倾注了大量心血。 Blumid 的核心是“内容优先”。在这个信息过载的时代,许多博客追求海报级的视觉冲击力,但这往往会分散读者的注意力。Blumid 选择克制与优雅,旨在通过柔和的视觉引导,为读者创造一个沉浸、愉悦的阅读环境。 如果你喜欢这款主题,欢迎你: * 前往 GitHub 下载并安装到自己的博客上:code-gal/Ghost-Theme-Blumid * 点亮一颗星 (Star)✨ 来支持这个项目。 * 订阅我的博客,以充分体验它的所有特点,重点在精心设计的侧边栏。 设计理念 我将 Blumid 的核心风格概括为 “晶莫渐变”,旨在突出内容本身,并提供舒适的视觉体验。 * 模块化与现代感:内容以清晰的圆角卡片形式组织,信息层

Matrix 评论系统:我为 Cactus Comments 开发了些新功能

Cactus Comments 是一款独特的开源评论系统,它利用去中心化通讯协议 Matrix 作为后端,这赋予了它超越传统评论组件的巨大潜力——无论是实现网站实时聊天、集成 AI 智能客服,还是作为微博客(Microblog)的内容发布渠道,其扩展性在同类开源项目中都难得一见。 然而,原项目已停止更新,我为其注入了新的活力:不仅修复了原有缺陷,更独立开发了一系列实用新功能(我的分支目前尚未合并到主干)。 经过持续打磨,这个新版本已经相当完善。本文将为你详细介绍我带来的新特性,并提供一份结合新功能的中文安装教程。你可以在我的个人博客上体验。 请注意:为了服务器的稳定,体验前需要注册。因为访客模式可能会对自托管的 Matrix 服务端造成难以预估的压力。 新版 Cactus Comments:都有哪些亮点? 🚀 核心升级 * 架构更新:重构了构建配置和依赖,现已支持在 Node.js v22+ 环境下进行开发和部署。 🖼️ 媒体功能大升级 1. 安全媒体支持:新增 isAuthenticated 选项,