[TUHS] Re; Mach for i486 / Mt Xinu or other

[TUHS] Re; Mach for i486 / Mt Xinu or other

[Doug McIlroy]

> 2)      **Most** Operating systems do not support /dev/* based access to SCSI.
>         This includes a POSIX certified system like Mac OS X.
> 
> 3)      **Most** Operating systems do not even support a file descriptor based
>         interface to SCSI commands.
>         This includes a POSIX certified system like Mac OS X.

Had Ken thought that way, Unix's universal byte-addressable file format
would never have happened; this mailing list would not exist; and we
all might still be fluent in dialects of JCL. dd was sufficient glue
to bridge the gap between Unix and **Most** Operating Systems.
Meanwhile everyday use of Unix was freed from the majority's folly.

Doug

[TUHS] Re; Mach for i486 / Mt Xinu or other

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]

Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Had Ken thought that way, Unix's universal byte-addressable file format
> would never have happened; this mailing list would not exist; and we
> all might still be fluent in dialects of JCL. dd was sufficient glue
> to bridge the gap between Unix and **Most** Operating Systems.
> Meanwhile everyday use of Unix was freed from the majority's folly.

Ken was lucky as he did not need to honor constraints from other operating 
systems.

Hard disks are also much simpler to use than optical media with complex meta 
data.

BTW: do you know why UNIX did create something that is completely 
non-extensible like cpio or hard to extend like tar? We had to wait until 1997 
for Sun to propose a nice extensible archive format that has become the base 
for the POSIX.1-2001 TAR extension headers.

Do you know why UNIX had a "ps" command that could be used to create random 
junk output in 1982 because there was no interface to get reliable process 
information? At the same time, UNOS written at Charles River Data Systems by 
former AT&T engineers could do this right already.


Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/