Tag: 软件

因为 vitest 只能用 node 运行，所以 不得不吧 easy-office-2 的里所有直接调用 Bun Api 的代码全部改成兼容 Node Api 的形式。

质疑 node，理解 node，使用 node，但是我依然讨厌 node。

最近清理了一波电脑。浏览器用 Helium 替代了原来的 Chrome。代码编辑器用 Zed 替代了 VSCode。输入法从 Rime 换回了 macOS 原生的拼音输入法。

关于 Zed，我已经在我支持用 Rust 重写世间万物提到过了。这两天实际编码体验非常好，不过我写的毕竟还是 JS / TS，工具链全部基于 Node，内存开销并不低。Zed 本身的内存占用也不低，启动倒很快。希望 Rust 社区继续发光发热，继续改造 JS / TS 工具链，把 Node 干掉。说到这里我又馋 deno 了……

Helium 和 macOS 原生拼音输入法的体验都不错。Helium 本身是基于ungoogled-chromium，使用体验和 Chrome 差不多，但没有 Google 服务的捆绑，开销更低。

至于 Rime，更像是一段插曲。当初是因为 macOS 原生拼音输入法有 Bug，会导致莫名其妙的死机，我才换到 Rime 的。现在 macOS 原生拼音输入法已经稳定了很多，Rime 高度个性化的优势在我这里也不算优势，从零开始培养一个惯用的输入法对我来说也很麻烦。除了不喜欢 Tahoe 的液态玻璃效果，我对 macOS 原生拼音输入法没有任何不满。

再次尝试使用 Zed。

2 年前刚学编程那会体验了一下 Zed，因为生态不完善没有继续使用。现在 Zed 写 Svelte 已经没啥问题了，也支持 GitHub Copilot。基于 Rust 的编辑器，运行速度没得挑。

原本以为没有 Foam 插件，处理我的 markdown 笔记会不方便，结果发现 Zed 有类似的 markdown oxide 插件，功能类似。

现在编码体验非常流畅，舒服了。

Rust 大法好。我支持用 Rust 重写世间万物。JS / TS 生态就应该用 Rust 重写，把 language server 什么的都重写了。现在电脑里剩下的 node 进程基本都是 language server。

「低耦合，高内聚」是软件设计的法则，目的是让复杂的软件尽可能模块化。这样设计出来的软件，可以做到，一个模块出问题，另一个模块正常运转；或者改动一个模块，不影响另一个模块。

在我看来，搭建工作流、SOP，或者就是日常使用软件，也应该遵循这样的原则。毕竟你也不知道，未来你工作流里的某个软件，会不会出现更好的替代品。

所以，把自己完全封锁在某个生态里，无异于断绝新的可能性。

Google 的 NotebookLM，好用👍

Anton Putra在 YouTube 上发了一条视频，对比了 FastAPI (Python) 和 Node.js 的服务端性能表现。第一轮是测试单纯的 Get 请求，第二轮是测试 PostgreSQL 数据库的写入。两轮测试下来，Python 的综合性能表现差不多是 Node.js 的 1/10。

一般来讲服务端的性能瓶颈都在数据库 IO，很少会遇到 CPU 瓶颈。Anton Putra 测试过不少语言和服务端框架，Python 是为数不多能在测试中段就能撞上 CPU 性能墙的。而且撞墙以后也没有恢复，后半段被锁死在 50% 的 CPU usage 上跑完了全程，也不知道为什么。

FastAPI 已经是 Python 生态内性能比较好的框架了，我真不敢想 Django 这种老乌龟得慢成什么样。没有 jit，再加上 gil 的限制，Python 的性能真的……配不上它今天的江湖地位。

最关键的是，Node.js 在 JavaScript 生态内的性能也不突出，甚至可以说是比较拉胯的……

又心痒痒了，想试试用 htmx + Python 写写小项目。

不过 Python 的速度真不行，感觉 Bun 会好很多。

但是 Python 的 Ai 生态更好，JavaScript 生态圈内优质的 Ai 开源项目太少了。

好纠结啊。

大语言模型「懂不懂你」取决于它能获取到多少你有价值的数据。所以能无感，或低门槛的让你把有价值的数据交给它至关重要。

从这个角度看，微软、谷歌是最有潜力打造出真正基于大语言模型的生产力工具。前者有 office 这个全世界最受欢迎的办公套件，后者也有一套用户基数很大的办公套件，以及持续收集用户数据的搜索引擎和浏览器。

国内在这方面最有潜力的还是字节跳动。飞书虽然市占率不高，但是飞书已经基于豆包推出了知识问答，可以全量获取用户飞书内的所有聊天记录、文档、知识库等数据。

字节在这方面唯一的短板是不像 OpenAI 能做开放平台打通第三方服务（让腾讯和阿里把自己的数据开放给字节？这不可能），也不像 Google 本身就是一个小商业生态系统，用户能在里面满足一部分需求（现在已经打通了 Google 酒旅和 YouTube）。

腾讯也掌握了微信这个数据富矿，可惜微信里大部分都是聊天这种垃圾数据。企业微信和腾讯文档本身产品力不行，远远不如飞书好用。我甚至怀疑他们底层的数据架构也不如飞书开放灵活，想要打通、整合，可能还需要付出一点代价。

阿里有钉钉，但是我不清楚钉钉文档有多少人在用。在我的印象里，钉钉文档应该远不如飞书那么好用。而且钉钉文档的底层数据架构应该也不如飞书。现在钉钉文档 AI 也不能全量获取用户数据，还需要用户手动导入知识库，支持的格式也有限。

所有基于 Electron 开发的软件似乎都会在 macOS Tahoe 遇到水土不服的问题，包括但不限于卡顿、发热。Electron 是最常用的跨平台开发框架，也就是说，包括 VSCode、Cursor 在内的很多常用软件都会中招。

成因似乎是 macOS Tahoe 的 WindowServer 组件有 Bug，在渲染带阴影窗口时存在严重性能回退，所有带阴影 Electron 窗口会异常消耗 GPU 资源。

暂时没有看到关于 Chrome 的反馈，但是我感觉 Chrome 在升级后资源开销也变大了。

苹果 💊。

毫无意外，macOS Tahoe 和 iOS 26 就是一次计划报废。新增加的毛玻璃特效在当下这个时点看不出交互上的必要性，反而会持续消耗计算机的算力。我观察了一下我 MacBook 的 GPU 用量，此前闲时用量很少超过 20%，升级到 Tahoe 后，闲时大概 30% 左右，CPU 闲时用量此前很少能超过 20%，现在也来到了 30%。苹果这边是真没活了，就想通过这种方式催促用户换新设备。