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.
