People using my name in vain.

Almost everything in Unix can be dealt with as a stream
of characters. I believe this is the primary design goal.

Which has nothing to do with how you typically treat the
subject, ie:

[link|http://z.iwethey.org/forums/render/content/show?contentid=102657|http://z.iwethey.org...?contentid=102657]

You use the "record" vs "stream" aspects of the underlying DEFAULT
programming/system paradigm as a base for arguing the stupidity
of attempting to deal with the data in any other way.

It also has nothing to do with real world usage. Yes, I love
my pipes. So what. I nead a RECORD of data, not a byte.
And sometimes I need to jump back 523,333,123 records.
Yup, that's a 1/2 a billion RECORDS. Not bytes, records. Maybe 2K
records. And I wasn't buffering the damn things, I was reading one
at a time (or a BLOCK of records at a time), or jumping to an indexed
location.

Almost ALL Unix access I do revolves around record style access,
which falls unto your mainframe programming paradigm.

People who code religiously because that is how the OS "wants"
it have no business coding at all. At least not in anything that is
time sensitive.

Another area is low level block mode devices which the OS
attempts to hide the hardware from you and treat as a stream.

If you go with it, it "works", but will be abysmally slow. Try writing
data to a tape drive using the "stream", and not upping the blocking
factor since the default is so slow. Major suckage.

The hardware is almost always "block" level. Evern your terminal
driver handles a LF terminated "block" of data at time, unless you set
it to "raw" mode.

Before intelligent serial boards (digicom, etc), Unix character mode terminal
handling SUCKED. 25 users typing away could swamp a Unix box due to the
overhead of the character processing. It was a lovely abstraction that
required a huge amount of hardware to actually use.