5 款自建 RSS 阅读器深度对比:TTRSS / FreshRSS / Miniflux / Yarr / Fluent Reader
把 Fluent Reader 和 TTRSS 放进同一张表比较“谁更适合自建”,第一天就会犯一个方向性错误:Fluent Reader 不是服务端,它是 Electron 桌面客户端。
GitRead 编辑团队整理的技术长读。覆盖评测、实战、架构、 工具链、行业观察等方向,围绕开源生态与技术选型展开。
把 Fluent Reader 和 TTRSS 放进同一张表比较“谁更适合自建”,第一天就会犯一个方向性错误:Fluent Reader 不是服务端,它是 Electron 桌面客户端。
数据库客户端有个反常识的地方:装机量最大的那款,往往不是最轻的那款。DBeaver 在 GitHub 公开仓库的 Star 数处在 4 万量级,是数据库客户端里排在前面的项目,但它的安装包体积也是三款里最大的。
这篇文章不打算做那种“20 款工具横评”的流水账。我挑了 4 款开源笔记工具——Obsidian、Logseq、AppFlowy、Trilium——每一款我都至少连续用了 3 周以上,其中 Obsidian 我用了整整 14 个月。
上个月有个朋友找我,说想做区块链版的“维基百科”,问我数据用IPFS存还是Arweave存。我说你先别急,这俩都叫去中心化存储,但底层逻辑完全不同。他用了IPFS存了一周,发现文件还在,但访问速度越来越慢,最后连网关都打不开——因为没人pin他的数据。
第 2 周我做了个压力测试:用 1000 个并发请求打四个平台的同一个 hello 函数。Cloudflare 的 p95 延迟 48ms,Deno 是 56ms,Vercel 直接飙到 800ms(冷启动),Netlify 有 7% 的 502 错误。
再解决第二个问题:为什么不用浏览器内置密码?因为 Chrome 的密码管理器无法解决跨浏览器同步,更没法做权限审计。去年 11 月,我审计发现 68% 的员工在 Chrome 与 Safari 之间各存了一套密码,其中 23 条已经不一致。
从 WordPress 迁到静态博客,看了一圈框架直接懵了。这事儿我太熟了——上个月我拿同一台 8 核机器分别测了这 5 个框架,构建 1000 篇 Markdown 文章。
上个月,我把一个跑了 18 个月的生产项目从 Prisma 迁移到了 Drizzle ORM。原因很残酷:业务方投诉列表页加载太慢,我查了下日志,一个简单的 JOIN 查询在 Prisma 里平均耗时 380ms,P95 更是飙到 620ms。
而我当时用的备份方案是什么?一块插在路由器 USB 口的移动硬盘,容量 2TB,每 3 天才同步一次。说实话,这方案连"聊胜于无"都算不上——路由器那块硬盘在 2024 年 2 月就坏过一次,当时我花了 ¥580 送去恢复,拿回来 70% 的数据。
换 Next.js 也想过,我认识的人里有位用 React 写了八年的开发者,但个人站要重学 App Router,还要处理 React 生态的版本地狱。我评估了一下,迁移成本至少 14 天全职工时。
我从去年 4 月开始,在三个平台同时挂了一个开源项目(一个轻量级 HTTP 客户端库)的赞助入口,跑了整整 180 天。项目在 GitHub 上有 2.3k star,每周稳定获得 800 次克隆。不算明星项目,但绝对不属于"没人看"的范畴。
四月初,为了做选型,我把 ComfyUI、Fooocus、StableSwarmUI、InvokeAI 这四套前端全部部署在同一个环境里:Ubuntu 22.04 + RTX 4090(24GB 显存)+ PyTorch 2.1.2。