记录时代的洪流下,自我转变、家庭规划的十年。
长期使用多个券商的服务,回头看看,已经有十多年的时间了。这些年里,账户换过几个,投资的品种也不少。但是对于每一笔投资的实际收益情况,哪只盈利、哪只亏损,收益是在什么时间产生的,一直没有一条完整而清晰的时间轴。每次更换券商,历史信息都会出现中断,时间久了以后,很多数据只能散落在不同平台的交易记录和月度账单中。除了回顾过去,我也一直想知道,自己目前的投资收益到底怎么样,长期收益能不能覆盖未来的退休生活,当前的资产配置是否合理。这些问题,显然不能只依靠某一个券商提供的账户页面来回答,需要有一个统一、清晰,并且可以长期使用的管理平台。在当前 AI 快速发展的背景下,我一直考虑自己搭建一套投资管理系统,并将它部署在自己的 NAS 上。这样既可以把不同账户的数据集中起来,也可以将数据保存在自己能够控制的设备中,不需要依赖某一家券商或者某一个在线平台长期提供服务。直到后来,我在 GitHub 上看到了 Wealthfolio 这个项目。开始的时候,我完全是抱着试试看的态度进行安装。没有准备马上迁移全部数据,只是想先看看它能够管理哪些内容,是否适合自己长期使用。安装完成后,我发现它的基本功能已经能够满
昨天看到群晖正式发布 DSM 7.4,一时间有些心动。不过,对于家里的这台 DS218+ 来说,我其实一直奉行一个原则:稳定压倒一切。这台 NAS 已经承担着家里的大部分服务,包括 Immich、Podsync、Tailscale、Docker 等十几个容器,最近好不容易把各种环境都调试稳定。如果因为一次系统升级导致某个服务出现兼容性问题,后面可能又要花不少时间排查和折腾。因此昨天一直没有下决心升级。社区评价基本打消了顾虑今天上午又花了一些时间看看 Reddit 和各大论坛上的用户反馈。让我比较意外的是,大家对于 DSM 7.4 本身的评价其实不错。升级过程普遍都比较顺利,没有看到大规模翻车案例。Docker、虚拟机、常用套件基本都能正常运行,不少用户甚至评价说:“升级之后什么变化都没有,这反而说明它足够稳定。”真正引发大量讨论的,其实并不是 DSM 7.4,而是 Synology 对新功能 Storage Efficiency(存储效率) 的限制。Storage Efficiency 成了最大的吸引力原本我只是准备观望一段时间。但在了解 DSM 7.4 的新功能时,Storage E
今天尝试了一个 iPhone 网络定位测试方案:通过 Quantumult X 拦截苹果的网络定位请求,替换 Wi‑Fi/基站定位返回的坐标。它不是修改 GPS 硬件信号,而是影响苹果网络定位服务的结果。因此在室内、GPS 信号较弱时更可能有效;如果在室外,真实 GPS 信号很强,地图 App 可能仍优先使用真实位置。配置过程使用的工具是 Quantumult X,并导入 WLOC 的重写资源:https://raw.githubusercontent.com/Yu9191/wloc/refs/heads/main/modules/wloc.conf导入时需要放在 Quantumult X 的“重写资源(Rewrite Resources)”中,而不是节点订阅。导入成功后,MITM 主机名中会自动出现:gs-loc.apple.com gs-loc-cn.apple.com这两项配置正确,且应避免添加 *.apple.com 或 * 之类的全域规则,以免扩大 HTTPS 解密范围。证书配置由于定位响应使用 HTTPS,Quantumult X 必须生成并安装自己的 CA 证书。流程如下
最近跟风买了一个大疆的 4G 模块。一开始我只是想看看它能不能接到 NAS 上,用来做一个短信收发管理工具。结果一路折腾下来,发现这东西确实有点意思,但也不是“插上就能用”。一开始的目标我的初始目标很简单:把这个大疆 4G 模块接到自己的设备上,实现短信集中收发管理。最好可以放在 NAS 上,因为 NAS 长期开机、管理方便,也适合跑一些 Web 服务。后来又看到网上有人把这个模块识别成 Quectel EC25 后,配合 VoHive 使用,可以管理短信、eSIM、设备状态,甚至通过 Telegram 做通知,于是就开始评估是否要刷机或改设备信息。要不要刷机?刚开始比较担心“刷机”这个词,因为涉及固件、NV 参数之类的东西,风险不低。后来确认下来,这次并不是传统意义上的刷固件,而是通过 AT 命令修改 USB 识别信息。这个大疆 4G 模块本质上是移远 Quectel EG25-G 的变体,默认 USB ID 是大疆私有的:2ca3:4006 修改后可以让系统把它识别成更通用的 Quectel EC25:2c7c:0125 修改之后,Linux 内核就能比较自然地加载 optio
起因手机上通过某第三方客户端内嵌的 Tailscale 模块连回家里内网,延迟高得离谱——tailscale ping 动辄 300ms 起步,还会抖到 1.6 秒,速度慢到基本不可用。表面是"网络慢",深挖下去是一整条链路的问题。这篇记录完整的排查与解决过程,也算给自己留个底。第一步:定位根因——中继落在境外高延迟在 Tailscale 场景里几乎都指向同一个根因:流量走了 DERP 中继,而不是 P2P 直连。先在 NAS 上定位:tailscale ping 100.x.x.x # pong from node via DERP(hkg) in 381ms ... direct connection not establishedvia DERP(hkg)——中继落在境外节点。再看 netcheck:Nearest DERP: Hong Kong hkg: 145.6msNAS 到官方境外 DERP 就要 145ms,手机(蜂窝网络)到该节点又是一段,两段叠加加抖动,300ms+ 就是这么来的。P2P 直连没打通,全程依赖这个远距离中继。结论:得把中继点从境外换到境内。第二步
最近看到 Immich 正式发布了 3.0 版本。作为我 NAS 上最重要的应用之一,自然第一时间关注了一下这次的大版本更新。在升级之前,我先对比了一下 3.0 与我目前使用的 2.7 版本有哪些值得升级的新功能。为什么升级?官方这次 3.0 并不是一次简单的版本更新,而是一次比较大的功能升级。比较吸引我的几个新特性包括:内置 AI 修图(Image Editing),可以直接在 Immich 中完成简单的照片编辑,而不用再导出到其它软件。更完善的照片管理能力,包括更好的浏览体验和细节优化。搜索和 AI 能力持续增强,后续还有更多基于视觉模型的扩展空间。底层架构升级,数据库向量引擎等组件进行了优化,为后续功能提供基础。对于我来说,最有价值的还是修图功能。平时大量照片都是手机自动同步到 NAS,偶尔需要裁剪、调整亮度或者做一些简单编辑,以前都需要下载到手机或电脑处理,再重新上传。现在如果能够直接在 Immich 中完成这些操作,整个照片管理流程会方便很多。综合评估之后,我决定将家里的群晖 DS218+ 升级到 Immich 3.0。我的环境升级前的环境如下:NAS:Synology DS
前几集一直在通过各种细节铺垫悬疑,不断抛出新的疑问,忍不住一集接一集地看下去。只是剧情推进到中段时,女主各种“好奇害死猫”的操作,明知道危险还不断往前凑,看得人又着急又生气。当最后真相揭开的那一刻,前面的伏笔基本都串了起来,确实有一种恍然大悟的感觉。虽然结局有些超现实,但也正因为如此,还是可以留下比较深的印象。
家里 NAS 上跑着三个 podsync 容器,把一个频道转成播客音频喂给我的播客客户端。这套东西平时很省心,直到某天日志里开始反复刷同一条错误。这篇是完整的排障记录——之所以写下来,是因为过程里有三次方向判断被推翻,而每一次被推翻,都比一开始"猜对"更能说明这个系统到底是怎么运转的。一、现象日志里,某一个 feed 每轮更新都失败,其它 feed 正常:ERRO ... failed to update feed: https://www.youtube.com/channel/UC.../videos error="update failed: failed to parse duration : bad format string"注意报错里 duration 后面那个值是空的。而且它只影响 A01——后面的 A02、A03 照常下载,说明 podsync 是逐个 feed 更新的,一个挂了不拖累其余。损失面很小,但这条错误会一直刷,且只要触发条件在,就不会自愈。二、定位:三次推翻第一次判断:加个过滤把它挡掉 —— 失败第一反应是:列表顶部大概有一个
最近看到一篇关于”人生主线”的帖子:人生一定要尽早明确自己的主线。人生很多事情,其实没有标准答案。有人善于经营人际关系,在组织中不断向上发展;有人更喜欢独处,把更多时间留给学习、旅行、思考和兴趣爱好。这两种生活方式都很好。真正容易让人痛苦的,是既想拥有职位带来的资源,又不愿面对复杂关系带来的消耗;既想享受独处的自由,又希望得到所有人的认可。很多焦虑,并不是因为选择错了,而是因为一直想”既要,又要”。选择,本身就意味着放弃。只有接受取舍,人生才会变得轻松。人生就像一场长途旅行。我们无法拥有所有风景,也无法让所有人同行。真正重要的,不是一路上认识了多少人,而是把有限的时间留给真正重要的人,把有限的精力投入真正值得做的事情。当学会筛选关系、接受取舍之后,你会发现,生活不仅没有失去什么,反而变得更加轻松、更加从容。愿未来的自己,不再为了迎合别人而消耗自己。把时间留给健康,把精力留给成长,把爱留给家人,把热情留给真正热爱的事情。这,大概就是属于我的人生主线。
最近我的私有 VPS 被部署恶意程序的事件,对我最大的触动其实不是如何清除病毒,而是意识到另一个经常被忽略的问题——数据安全。以前更多关注的是服务器安全:关闭端口、最小权限、防火墙、监控告警……这些都很重要。但真正静下心来思考后发现,即使安全措施做得再完善,也没有任何人敢保证服务器永远不会出现问题。真正能够降低风险的,不仅是防御,更是可恢复能力(Recoverability)。因此,在完成 Sentinel 安全监控体系之后,我又开始补齐另一块短板——应用数据备份体系。为什么要做备份对于 我的 网站来说,真正有价值的并不是代码。代码可以通过 GitHub 恢复,可以重新部署;真正难以恢复的是:SQLite 数据库中的业务数据配置文件网站运行过程中不断积累的数据如果服务器被删除、磁盘损坏,甚至再次遭遇攻击,没有备份意味着这些数据可能永久丢失。所以这次工作的目标很明确:让任何一台服务器出现问题,都能够在最短时间内恢复业务。第一层:服务器本地自动备份首先为项目新增了独立备份脚本。备份策略分为两类:数据备份每天自动执行使用 SQLite Backup API 导出数据库避免直接复制正在运行中的
walker
万事随性而为,因好而研,因趣而学,从心所欲。脱离依赖,谋划将来,避免经济之险,迈向希望之光。