jdx retweeted
Made a mise extension for RayCast a few weeks ago and it just got approved.
Thanks to @jdxcode for making mise such a pleasure to work with.
raycast.com/lachieh/mise
jdx retweeted
1,049,817 open-source code reviews in September, a new monthly record!
That's 2.49x April's volume and up 14.4% from August.
"Not using it today would be like racing Formula One without a seatbelt or helmet." – @tannerlinsley, creator of TanStack
jdx retweeted
Created "btop for io", inspired by "why the hell is cargo so slow on btrfs"
Top: all volumes showing bytes/s, iops and r + w latencies, diamond marks p99
Bottom: reads and writes detail view for a single volume
github.com/jbellis/iodyne
jdx retweeted
🔴 Live today at 4pm CET with @jdxcode, creator of mise 🛠️
youtube.com/watch?v=aPg44O9i…
jdx retweeted
Mr. Boxington by @jdxcode has saved the day.
Before using it my machine was getting CRUSHED having multiple agents writing Rust. I would get alerts constantly of the HDD being full. Problem solved!
jdx retweeted
btw, thank you @jdxcode for mbx, it brought my compile times down ~40%
jdx retweeted
mbx is my new favorite thing (pools target/ artifacts across your worktrees), everyone who runs rustc should install this.
installation was a bit involved (I have a corner case dev env) but your agents can figure it out, nbd.
jdx retweeted
bro it's not that deep, use nix of the system and gui apps and mise for the tooling (python/rails/typescript) whatever.
#Omarchy #NixOS
我们来简单讨论下 Omarchy 引入 Nix/NixOS 的技术难题，由 Claude Fable5 提供辅助思考。
---
对 agent 来说，Nix 解决的是「环境是隐式状态」这个难题。
Nix 包管理器本身就提供三条性质：环境即数据（读 flake.nix 加 lock 就能完整理解环境）、失败可归因（构建失败只可能来自 derivation 输入）、默认沙箱构建（无网络、依赖只读）。
只有当需要「整个系统是一个闭包」时，才需要上 NixOS。
在 Arch 上装 Nix，你得到的是一个 /nix/store，里面放项目级或用户级的环境。但内核、initrd、systemd 单元、/etc 下的配置、用户账户、bootloader，这些仍然由 Arch 用可变文件的方式管理。系统层是命令式的，pacman -Syu 之后 /usr 就变了，没有 lock，没有回滚。
NixOS 做的事是把这一层也变成构建产物。
configuration.nix 求值后输出一个 store 路径 /nix/store/-nixos-system-...，这个路径的依赖闭包就是整个系统：内核、所有服务的单元文件、/etc 的每个文件、每个用户的环境，全部从这个根可达。
切换配置就是让 bootloader 和 /run/current-system 指向新路径，
回滚就是指回旧路径。所以"系统是闭包"的具体含义是：系统状态本身有一个哈希，可以 diff、可以 fork、可以指回去。
对 agent 来说区别在于：
Nix-on-Arch 时，agent 改开发环境是可归因的，改系统服务不是；NixOS 时两者都是。你是否需要后者，取决于 agent 会不会碰系统层。
假设 Omarchy 集成 Nix 或 NixOS，Nix 的用户量会随之上升，底层 C++ 实现会被更多使用路径触发出更多 bug。
Nix 的复杂度集中在工具层：求值器要吃下整个 nixpkgs，daemon 协议、沙箱、store 都是有状态的复杂组件，规模压力会直接落在这些地方。
到时候上游能否跟上修 bug 的节奏，Omarchy 是否愿意投入资源推动，都是未知数。
用 Rust 重写 Nix 是一条出路，但难度不在代码量。
Nix 语言没有规范，C++ 实现就是规范。
nixpkgs 又要求兼容 2019 年的 Nix 2.3，每一处行为差异都需要人裁决是必须复现的怪癖还是可以修正的 bug。
差分哈希能精确指出不一致在哪里，但不能替人决定改哪一边。
Rust 重实现 Snix 从 2021 年的 Tvix 算起已推进五年，仓库到 2026 年 7 月仍在更新，但仍处于早期阶段，没有可替换 Nix 的完整方案。devenv 在 2024 年宣布切换到 Tvix，2026 年 3 月发布的 2.0 实际走的是 C FFI 绑定 C++ Nix 这条路。这是目前最有分量的下游给出的答案：先包住 C++，不等重写。
需要说明的是，Omarchy 集成 NixOS 目前只是一种可能性假设。DHH 在 2025 年 8 月表示，他认可 Nix 做应用级开发环境，但不接受它做整机管理。
那么 Omarchy 现在依赖的 Arch 生态是否有相似问题？
有一半，而且是不同的那一半。
Arch 的复杂度在包层不在工具层：pacman 和 libalpm 是几万行 C，逻辑简单，规模压力基本不落在它们身上。
Arch 的债在别处。
PKGBUILD 是任意 bash，makepkg 的行为就是规范，「没有规范」这个问题比 Nix 更严重，只是没人试图重写 makepkg。
更近的风险是 AUR：Omarchy 大量依赖 AUR，AUR 没有审核，用户量上升等于攻击面上升，2025 年已出现过 AUR 包投毒事件（印象中，不确定）。至于上游团队小，Arch 核心开发者同样是几十名志愿者，两边一样。
Arch 没有的是 Nix 要解决的那三条性质本身。
Arch 是可变的 /usr、滚动更新、没有 lock、没有闭包、没有回滚。「失败可归因」在 Arch 上不存在，一个包升级把系统搞坏时，agent 能拿到的信息就是「某台机器上某个隐式版本」。这不是 pacman 用 C 写的问题，换成 Rust 也一样，因为缺的是机制。
所以，继续留在 Arch，agent 友好性的三条要靠上层自己补，同时继续承担 AUR 的供应链风险。
换到 Nix，三条现成，代价是接一个有治理碎片化（cppnix、Lix、Determinate Nix 三个分支并存）和嵌入接口问题的 C++ 单体（没有库，但应该可以用 rust 做 ffi 绑定）。
按前面的推论，是的：
集成 Nix 包管理器，不换 NixOS。三条性质拿到手，DHH 不想要的整机管理也不碰，AUR 那部分攻击面可以让 agent 控制的安装走 Nix 而不走 yay。
但现在 Omarchy 依赖 misa，如果换 nix 就存在职责重叠，硬要并存会出可能会起冲突，比如： .mise.toml 说 Ruby 3.3，flake.nix 说另一个，agent 读哪个？这直接破坏"环境即数据"。
mise 短期内不会被换掉，因为已经被 Omarchy 基金会赞助了。
Rails 世界的 gem 带大量 native extension，Nix 下打包 gem（bundix 那套）出了名的痛苦；mise 装个预编译 Ruby，系统库直接从 Arch 拿，简单得多。DHH 的受众是 Rails 开发者，他不会为了纯度把这条路堵死。
所以，到底如何引入 Nix/NixOS ，感觉是个难题啊，看 Omarchy 团队怎么解决？
jdx retweeted
just restored 255gb of storage thanks to mbx
mr-boxington: I've been a rust dev for years and these things always bugged me but I've now fixed them.
- target/ always filling up with no auto-pruning
- worktrees don't share build cache
- can't run multiple cargo builds in parallel
- remote cache uses too much disk
- ci is too slow
mr-boxington.jdx.dev/
jdx retweeted
Yes what could possibly have happened
jdx retweeted
jd’s tooling stack is killing it for both utility and security. At the very least you should consider using `aube`.
latest release of mise now embeds aube for installing npm packages (à la `mise use -g npm:prettier`) by default
this is done for improved compatibility (not relying on whatever `npm` you have installed on your machine) but more importantly for security because aube has the strongest security defaults of any node package manager.
Technically you can even install npm packages without node now, which probably has some narrow use-cases for non-node projects distributed via npm.
jdx retweeted
Using mise bootstrap on both linux and macos now, thanks @jdxcode. I deleted so much bespoke garbage from my own scripts
jdx retweeted
It’s so good! Moved off of chezmoi last week github.com/jclem/dotfiles/bl…
`mise bootstrap` is coming out of experimental in the next release: mise.jdx.dev/bootstrap.html
jdx retweeted
Git your clones ready. Marvin guides us into a new multiverse of coding soon. Let the rebellion begin. 🤖
jdx retweeted
In 2007, Linus Torvalds said "If you're not distributed, you're not worth using." For Git hosting to sustain through the era of agents, we must now return Git to its original promise: Decentralization. My thoughts 👇
entire.io/blog/how-version-c…
jdx retweeted
there's a comprehensive database called OSV that tracks all known-malicious packages on npm
currently Nub (and Aube) is the only package manager that checks it during version resolution. everything else will happily install a pwned version.
jdx retweeted
npm v12 (coming next month) throws if there are any unrecognized fields in .npmrc
this is in the category of "totally needless breaking change" that absolutely drives me nuts as a longtime maintainer myself. there is no benefit here. npmrc has allowed custom fields since 2010.
jdx retweeted
First macOS update after migrating from home-manager to Mise.
It feels good not having to fix a broken Nix / home-manager installation. Things just keep working now.
jdx retweeted
I have completely removed Nix from my system
It's nice in theory but full of footguns and the UX is HORRENDOUS
I don't have infinite time to configure my dev env, so switching to Mise is 100% a better solution
I'm completely sick of Nix and its broken package manager that I'm switching to Mise by @jdxcode
I was already using it to manage Node.js versions but now there's experimental support for installing Brew packages (without needing it installed!) and it works great
Can recommend
jdx retweeted
I love mise + hk combo by @jdxcode. It is the perfect UX. It's been a while since I fell in love with a tool that much. I've been converting all my projects to it.
I spent the last couple of weekends hand-rolling a `mise-fy` Skill that I am sharing... ♥️
github.com/sherifabdlnaby/sk…
