indirect

Just the good parts of reproducible builds: the security and assurance of signed and provable inputs, without the misery of constantly repairing your build system.

I guess I wasn't sufficiently clear in the post, but the part I think is interesting is not that tmpfs and SSD bench at the same speed. I am aware of in-memory filesystem caches, and explicitly mention them twice in the last few paragraphs.

The interesting part, to me, was that using the vfs crate or the rsfs crate didn't produce any differences from using tmpfs or an SSD. In theory, those crates completely cut out the actual filesystem and the OS entirely. Somehow, avoiding all those syscalls didn't make it any faster? Not what I expected.

Anyway, if you have examples of in-process filesystem mocks that run faster than the in-memory filesystem cache, I'd love to hear about them.

I used to work at a shop that used Gerrit[1] to manage our master branch. Pushes directly to master were rejected, and all commits had to be signed off by a developer other than the author, confirming that a) the tests passed and b) the functionality had changed as advertised.

Motivation to review started low but got quite high once developers wanted their own code merged. Motivation to merge other things without checking started high, but got low extremely quickly once the merger had to fix the tests if they merged a failure.

I sometimes wonder if it's somehow possible to get either one of those (extremely positive) trends in a "modern" github-based workflow.

1: https://code.google.com/p/gerrit/

Bundler's "condescension" was a real error message, albeit a terse one. I expanded it 18 days ago. If you think it's still condescending, please suggest a better way of phrasing the error.

https://github.com/carlhuda/bundler/commit/abdc6374bd18488d0...