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.
I work in an environment like this now, and it's fine, because we have a review culture. I don't think that technology can every impose a cultural shift by itself.
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.
what I felt was rude was not the thing Bundler said but the thing Bundler does. if you know people are expecting rubygems to be the default, you don't tell them "oops you forgot to type rubygems, sucks to be you." you just make it the default.
you had an issue open for this on GitHub but it was closed with very little explanation. mind if I reopen it?
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.