indirect
Joined 18 years ago
Karma
78
Submissions
6
Member since
Aug 11
Recent submissions
Comment · 8 months ago
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.
Comment · 1 year ago
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.
Comment · 13 years ago
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.
Comment · 14 years ago
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...