The first copy to RAM was a sequential image copy, thus not bottlenecked on seeks despite spinning platters.
The second copy from RAM was a file copy with a lot of random I/O, but not bottlenecked on seeks because it was reading from RAM.
Bulk writes tend to be more efficient. They might have made temporary configuration changes to make that end faster, or not if they lacked the appetite for the extra risk.
This is going to look bad. I'd better tase the corpse so I can claim I tried non-lethal means first, but the guy was unstoppable and I had to kill him.
I think the most dangerous advice I got was to avoid DTOs and similarly domain-behaviour-free object graphs. That corner of the .NET world at the time called such a model an 'anaemic domain'. Instead, we were encouraged to model problems with objects for every noun, methods for every verb, arguments for every adjective, and all the code dealing with them attached to the class.
It worked fine while our domain remainded small, but got ghastly quickly.
The Sun 3/50's pixel buffer was world readable and writable by default, and in console mode had an area at the bottom not affected by scrolling. One could invert random horizontal bars across the screen, transpose the bitmap, or apply a sine wave to persuade the user the massive TV set on top of their workstation was broken. Or, fade text in and out as if the machine was commenting on the user's ineptitude. Much fun was had by all.
> It's like static linking an entire operating system for each application.
You say it like it's a problem, but that's the most concise description of Docker I've yet read. It rhymes with the way all the fed up oldies using Go like its static linking.
Most mysteries come down to loose dependency declarations and semver stuffups, sometimes in combination. One of your deps' deps takes a ~ on one of its deps, that dep makes a breaking change and changes its version from 0.3.2 to 0.4.0… boom. Your fresh npm install on workstation #2 inhales the breaking change and doesn't work, but workstation #1 still works fine.
Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
It's a machine. It's a lot more predictable than you think.
Everyone thinks they can pay after the release. If you cut those corners hard, though, you'll often regret it before your release. Cut harder still, and you won't even make it to the end-of-sprint demo before there's a knock at the door.
On the other hand, there's every reason to believe the "Go [a]Way" prohibition on certain language features will leave Go 2 insufficiently attractive vs Go 1 to overcome the switching costs, dragging out any migration period. See also: Python 3.
Many correlate "sane" with "statically typed". [1]
JacaScript can cope perfectly well with modules A and B relying on different versions of C. It'll often cope even if A calls B with an object it got with C, or some other module broadly compatible with C. Static typing proponents aren't comfortable with the idea, so it's not "sane" to them. Sane or not, many argue it's not just not slowing down the Node community, but actively contributing to its explosive growth.
In C#, you get MethodMissingException if A.DLL and B.DLL refer to different copies of C.DLL and A calls B with an object it got from C, even if the copies of C.DLL are identical.
1: Perhaps I should contrast with strong typing, not static typing. Meh.
We rolled our own Flux library before they published any code, dodging singletons and gaining mock-free testability. I just re-wrote it, but will check Flummox out.