I've just added mr boxington to the harness I'm making and it went from 94s to 1s. Thank you, Jeff! github.com/krowkcom/krowk/pu…

i'm teaming up with @szkdash for working on packslip! he is the author of aqua-registry which mise has relied on for years for almost all of its tools—and it's been an incredible resource. if you're a vendor for a mise tool give packslip a look: it gives you more direct control over how mise (and future tools) integrate, and also lets you ship agent skills and shell completions tied to the version! also thanks to @YxxHero, @yohamta, @max_sixty, and @stefanprodan for being some of the first adopters of this new standard! packslip.dev

thanks @Mend_io for upgrading my OSS plan! mend.io/blog/mend-renovate-c…

i think this is fine if there is a dedicated sponsor track

impressive!

it can be much faster because it can safely parallelize fixers writing to the same files

no. it does have a different ui than cargo that doesn't show the entire history of each crate compilation (by design) but you can disable that with `MBX_DISPLAY=plain`

not yet, i only published it less than a month ago. i suspect it'll get traction if for no other reason than it gives vendors a lot more functionality and control in mise

the theming isn't that new, maybe 2-3 weeks old

you should setup packslip so mise users automatically get skills and shell completions tied to the turbo version: packslip.dev/

hk.jdx.dev – faster linting and git pre-commit hooks

a snappy screensaver absolutely makes an operating system better. preview should be fast. it should use minimal battery. it should close *extremely* quickly.

it absolutely matters: you want the preview to feel snappy, you want it to close extremely quickly. you want it to quickly close just after starting if the user happens to be at the computer.

think it's just the rule of three? en.wikipedia.org/wiki/Rule_o…

in case you're wondering why mr-boxington has a strawberry on successful builds—it comes from my daughter's original mr-boxington (the namesake for my tool)

use bazel if you want, however bazel doesn't coordinate two builds on one machine, doesn't back off when RAM runs low, and never cleans up output bases from deleted worktrees—all while not needing to ditch cargo in the first place.

it wraps cargo not rustc like every other tool mr-boxington.jdx.dev/compare…

exec is generic: PATH shims so make/autotools/scripts work too. For cmake-rs under mbx build we do use the launcher: github.com/jdx/mr-boxington/…. You're right that `mbx exec cmake` should too though.

kache never cleans up target directories on its own. You run kache clean when they pile up. mbx does it after builds: it removes a checkout's target once the checkout is deleted or has gone unused for 30 days, and removes the least recently used ones when they go over a disk budget. mbx wraps Cargo as well as rustc. Because it starts Cargo itself, it can do things a rustc wrapper can't: show build progress with cache hits and misses in place of Cargo's output, start a new checkout with the dependency builds another checkout already has (Cargo 1.100+), and optionally run test binaries within the same CPU and memory budget as compiles.