''The trouble with layers and layers of computer software is that sooner or later you lose touch with reality.''

Reality. That's what's going on with the physical stuff that
makes computers go.  CarverMead points out that all
computation is a physical process.
Why not exploit the myriad effects of ChargeCarriers
passing through material, instead of overcoming them?

But I digress.  Right now I'm thinking about efficiently
transferring information from block storage devices.
What in the world is my ThinkPad doing as it sits there
blinking my disk light while it boots?  A few bytes here,
a few bytes there, that's what it's doing.
I'd love to put a StripChartRecorder on that light and find out
what the real DutyCycle is.  Then again, it probably lights
up while it seeks.  I'd need to monitor the actual transfer.

Some people seem to understand this and get it right...

* RogerBates -- collected control variables needed to open a drawing.
* BillCroft -- piggybacked control flags in full data packets.
* ParcPlace -- save an image without traversing it.
* JefRaskin -- booted the CanonCat from all sectors of a diskette read sequentially.
** regardless of whether this means a full track read or a small boot, such things pre-date Jef's work on the CanonCat by years and years; let's not Canonize people for standard practice
* ChuckMoore -- a filesystem abolitionist from the beginning, he strongly prefers to record source code and all persistent data using block storage.  Whether using a block cache (a la demand-paging systems today) or full memory image (a la ColorForth today), Chuck gets extremely efficient I/O by eliminating unnecessary filesystem intervention, which from personal experience with both filesystems and direct-access methods, I agree is unnecessary.
Since this page was created June 9 1995 and hasn't significantly changed since then (typos fixed 3 times, is all), I probably shouldn't bother to comment...