> 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
> From: Larry McVoy
> The DOS file system, while stupid, was very robust in the face of
> crashes
I'm not sure it's so much the file system (in the sense of the on-disk
format), as how the system _used_ it (although I suppose one could consider
that part of the FS too).
The duplicated FAT, and the way file sectors are linked using it, is I suppose
a little more robust than other designs (e.g. the way early Unixes did it,
with indirect blocks and free lists), but I think a lot of it must have been
that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on
early Unix FS's, etc). That probably appoximated the write-ordering of more
designed-robust FS's.
Noel
> From: Diomidis Spinelli
> Arguably, the same can also be claimed for the networking system calls.
Well, it depends on exactly what you mean by "networking system calls". If
you mean networking a la BSD, perhaps.
However, I can state (from personal experience :-) that the I/O architecture
circa V6/V7 was not very suitable for TCP/IP internetworking (with its
emphasis on an un-reliable network, and smart endpoints). The reason is that
such networking doesn't really fit well into the 'start one I/O operation and
then block the process until it completes' model.
Yes, if you have an application running on top of a reliable stream, you
might be able to coerce that into the 'uni-directional, blocking' I/O model
(if the reliable stream implementation is in, or routed through, the kernel),
but lots of other thing don't work so well. (Think, e.g. an interface with
asynchronous, un-predictable, RPC calls in both directions.)
Noel
> Linus had the qualities of being a good programmer, a good architect,
> and a good manager. I've never seen all 3 in a person before or since.
No comment about Linus, but Vic Vyssotsky is my pick for the title.
He created the first dataflow language (in 1960!). He invented
bit-parallel flow analysis and put it into Fortran 2 years later.
He was one of the technical triumvirs for Multics. Ran several
big development groups at Bell Labs, and was 2 levels up from
the Unix team in Research. I could go on and on. What he
didn't do was publish; he got ahead on pure innate ability
and brilliant insight--a profound influence on almost all]
the original Unix crowd.
Doug
I dont know if it's worth even trying to find and mirror pre 1993 ( IE when cheap CD-ROM mastering was possible) GNU software?
Things like binutils, gas, and GCC can be tremendously useful, along with binaries for long "dead" platforms?
I know that I've always been super thankful of the GNAT people for having some pre-compiled version of the ADA translator which would also include GCC. Sometimes having some kind of native toolset is a big positive, when you don't have anything, especially earlier versions that have issues cross or Canadian cross compiling.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
OMG. I don't know how many times I've consulted the Unix
Tree and blissfully ignored the cross-links that come at
the top of every file--I'm so intent on the content.
Apologies for cluttering the mailing list about a solved topic.
Doug
>Date: Sun, 19 Feb 2017 20:58:59 -0500
>From: Clem Cole <clemc(a)ccc.com>
>To: Nick Downing <downing.nick(a)gmail.com>
>Cc: Jason Stevens <jsteve(a)superglobalmegacorp.com>,
> "tuhs(a)minnie.tuhs.org" <tuhs(a)minnie.tuhs.org>
>Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other
>Message-ID: <CAC20D2NM_oyDz0tAM2o5_vJ8Ky_3fHoAmPHn8+DOqNwKoMyqfQ(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
>On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing <downing.nick(a)gmail.com> wrote:
...
>Anyway, Tru64 is based on OSF/1 but also has a lot of DEC proprietary
>things (like TruClusters and anything Alpha specific) that goes beyond the
>based OSF license, so you need the HP clearance before any of that can be
>made available [same is true for HP/UX of course]. To my knowledge,
>DEC/Compaq/HP never released the sources to Tru64 (or HP/UX) to the world
>they way Sun did for Solaris, which in the case of Tru64 is sort of shame.
>there is some every good stuff in there like the file systems, the lock
>managers, cluster scaling, messaging, etc - which would be nice to compare
>to today's solutions. Since HP did have a bought out AT&T license, that
>clearly could have done so, but I do not think anyone left there to make
>that decision - sigh.
As far as I know only the TRU64 Advanced File System (aka AdvFS) has
been released to the OpenSource community, in 2008. Status now unknown
(to me)
See also
. http://advfs.sourceforge.net
. https://www.cyberciti.biz/tips/download-tru64-unix-advanced-filesystem-advf…
Cheers,
rudi
Wow that'd be incredible!!!
I'd love to see how Mach 2.5/4.3BSD compared to the Mach 3.0/Lites 1.1 that
is as close as I've been able to find... I know about the NeXT stuff, as I
have NS 3.3 installed although running it on 'white' hardware gets harder
and harder as PC's get newer and the IDE controllers just are too feature
ful, and too new for NS to deal with, beyond it can only use 2GB disks
properly. Obviously with no source or any way to get in to write drivers or
update the FFS on NeXTSTEP it's basically stuck in those P1 era machines, or
emulation. There is even previous a 68030/68040 cube based emulator for
running all the 'native' versions.
archive what you can, I can only contribute minro things I stubmle uppon,
mostly by accident.
> ----------
> From: Atindra Chaturvedi
> Reply To: Atindra Chaturvedi
> Sent: Friday, February 17, 2017 11:47 PM
> To: jsteve(a)superglobalmegacorp.com; tuhs(a)minnie.tuhs.org
> Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other
>
> Amazing - brings back memories. I was a Unix "enterprise IT user" not a
> "kernel developer guru" back in the day working at a pharmaceutical
> company and was responsible for moving the company off IBM 3090 and SNA to
> Unix and TCP/IP.
>
> Used to buy the new Unix-like releases as they were available to stay
> current - including the Mt. Xinu Mach 386 distro. I still have it and will
> happily send it to the archives - if I can be guided a bit.
>
> Ran the Mt. Xinu for many years as my home machine - it is pre-SCSI for
> booting ( needs ESDI disks ) but was very stable. So will need tweaking to
> boot/install.
>
> Happy to have worked in the mid-70 - 80's era when there were huge changes
> in computer hardware and software technology. I have my books and the
> software for all the cool stuff as it came out in those days - some day I
> will compile it and send it to where it can be better used or archived as
> history.
>
> Atindra.
>
>
>
> -----Original Message-----
> From: jsteve(a)superglobalmegacorp.com
> Sent: Feb 17, 2017 6:30 AM
> To: "tuhs(a)minnie.tuhs.org"
> Subject: [TUHS] Mach for i386 / Mt Xinu or other
>
>
>
> While testing a crazy project I wanted to get working I came across
> this ancient link:
>
>
>
>
> http://altavista.superglobalmegacorp.com/usenet/b182/comp/os/mach/542.txt
>
>
>
> --------8<--------8<--------8<--------8<
>
>
>
> Newsgroups: comp.os.mach
>
> Subject: Mach for i386 - want to beta?
>
> Message-ID: <1364(a)mtxinu.UUCP>
>
> Date: 2 Oct 90 17:12:19 GMT
>
> Reply-To: scherrer(a)mtxinu.COM (Deborah Scherrer)
>
> Organization: mt Xinu, Berkeley
>
> Lines: 24
>
>
>
> Mt Xinu is currently finishing up its release of 2.6 MSD for the
> i386.
>
> 2.6 MSD is a CMU-funded standard distribution of the Mach kernel,
>
> release-engineered with the following:
>
> 2.5 Mach kernel, with NFS & BSD-tahoe enhancements
>
> Transarc's AFS
>
> X11R4
>
> most of the 4.3-tahoe BSD release
>
> Andrew Tool Kit
>
> Camelot transaction processing system
>
> Cornell's ISIS distributed programming environment
>
> most of the FSF utilities
>
> a few other nifty things
>
>
>
> --------8<--------8<--------8<--------8<
>
>
>
> Was any of this stuff ever saved? I know on the CSRG CD there is
> some buried source for Mach 2.5 although I haven't seen anything on where
> to even start to compile it, how or even how to boot it... I know Mach is
> certainly not fast, nor all that 'small' but it'd be interesting to see a
> 4.3BSD on a PC!
>
>
> That's what the Unix Tree is for!
Yes, but it doesn't have cross links as far as I know.
What I have in mind is effectively one more entry in
the root. Call it "union" perhaps. In a leaf of that
tree, say /union/usr/src/cmd/find, will ne a page that
links to all the "find sources in the other systems.
I don't know the range of topologies in the Unix Tree.
For example, some systems may have /src while others
have /usr/src. That could be hidden completely by
simply not revealing the path names. Alternatively
every level in the union tree could record its cousins
in the various systems, as well as its children
in the union system.
Doug
If things are filed by provenance, one useful kind of
cross-linking would be a generic tree whose "leaves"
link to all the versions of the "same" file. All the
better if it could also indicate the degree of
relatedness of the versions--perhaps an inferred
evolutionary tree or a shaded grid, where the
intensity of grid point x,y shows the relatedness
of x and y.
doug
