Re: ancient OS history, ARM is sort of channeling the IBM 360

According to Scott Lurndal <slp53@pacbell.net>:

Is there?   It's trivially easy to impose a record structure
on a stream of bytes, and all the unix file access APIs allow
direct access to the device without extra buffering if desired,
subject to some alignment constraints.

>
At the time Unix was written, the big advantage of byte stream text was
that there weren't any trailing blanks so you fit a lot more data onto
a disk than you did with 80 or 132 character fixed records.

>
That was one advantage.  Consider, however, that byte streams fit
quite well into the unix pipeline paradigm and that may have been
the driving force behind the non-record-based I/O facilities in
Unix,...

Pipelines work equally well with fixed length records.  They were
familar with byte streams from PDP-10, Multics, and other systems
they'd worked with.

These days although Unix-ish systems still let you read or write
arbitrary text chunks, in practice everyone uses I/O libraries that do

>
I've been writing unix and unix-like operating systems for almost
four decades now.   I would disagree with the "everyone uses I/O libraries";
while stdio provides buffering, high-performance applications such
as the Oracle RDMB don't use stdio - they directly access the device
(unix raw devices, or linux O_DIRECT) and handle all their own buffering.

Yes, of course databases do their own I/O, designed to be aware of the
disk structure.  Some I've seen use files, some want to take over the
entire disk partition and read and write the special file.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly