Roomberg's Claim

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.

Post #109,347 by deSitter 7/11/03 10:17:31 PM Reply	Roomberg's Claim At the party I stated at one point "Everything in UNIX is a stream." Barry instantly chimed in "No it isn't - that's your prejudice." I never heard him explain this, but I've been trying to figure out what isn't a stream. That was the whole beautiful point of it. It was radical because the machines of the day were record oriented. Turning everything into a stream of bytes vastly simplified the interfaces. -drl
Post #109,350 by ChrisR 7/11/03 11:17:45 PM Reply	The file system is stream oriented.... ....and the interprocess communication tends to pipes (also a stream), but it does rely on signals (which are not streams). But the bigger problem with viewing "everything is a stream" is that it ignores that data structures can be abstracted on top of the stream process. Witness the World Wide Web, which rides on top of tcp/ip and http, but is a stateless system which communicates via a stream but is not really a stream per se.
Post #109,409 by CRConrad 7/12/03 6:01:44 PM Reply	i.e, as true - and as dumb - as "it's all just 1s and 0s!"
Post #109,424 by boxley 7/12/03 7:10:46 PM Reply	everything in unix is a file which can be streamed questions, help? [link\|mailto:pappas@catholic.org\|email pappas at catholic.org]
Post #109,475 by CRConrad 7/13/03 2:48:46 PM Reply	Same thing, just as (stupidly) over-simplified as Ross'.
Post #111,647 by broomberg 7/27/03 7:43:21 PM Reply	I gotta hit this forum more often 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.

Welcome to IWETHEY!