[Info-vax] HP wins Oracle Itanium case

[Johnny Billquist]

On 2012-08-23 20:41, ChrisQ wrote:
> On 08/23/12 17:46, Johnny Billquist wrote:
>
>> So basically, what you are saying is that when using the file system
>> interfaces, a file (on disk or anywhere else) is a stream of bytes (in
>> Unix).
>> I have no problem with that. It's just not the "lowest level of a disk",
>> nor can all I/O be done through the file system.
>>
>> Johnny
>>
>
> That's it. Most application programmers don't normally need to know about
> on disk structure, nor should they need to, as it's too low level. Only
> driver writers need to be concerned with block level code. Any file system
> is ideally layered on top of the driver itself and should be transparent
> to any structure imposed by applications above to be most generally
> usefull.
> The only way to achieve that is to say that the file system interface
> should
> be in some generic data size of the machine.

But then we come to the point where some streams of bytes are not the 
same as some other streams of bytes. Some can be seekable, others will 
hang instead of signal EOF when there is no more data, and so on... :-)

The stream of byte abstraction has its points, but it's not always a 
great solution. You do know that Unix also implements the stream of 
bytes paradigm for tapes? However, that idea is just so horrible that 
noone use it.

> Tape and comms are io, but they are a different can of worms :-)...

Yes. Stream of bytes paradigm just don't work very well in some situations.

	Johnny