> 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
Hi all, I think the current layout of the Unix Archive at
http://www.tuhs.org/Archive/ is starting to show its limitations as we get
more systems and artifacts that are not specifically PDP-11 and Vax.
I'm after some suggestions on how to reorganise the archive. Obviously
there are many ways to do this. Just off the top of my head, top level:
- Applications: things which run at user level
- Systems: things which have a kernel
- Documentation
- Tools: tools which can be used to deal with systems and files
Under Applications, several directories which hold specific things. If
useful, perhaps directories that collect similar things.
Under Systems, a set of directories for specific organisations (e.g. Research,
USL, BSD, Sun, DEC etc.). In each of these, directories for each system.
Under Documentation, several directories which hold specific things. If
useful, perhaps directories that collect similar things.
Under Tools, subdirectories for Disk, Tape, Emulators etc., then subdirs
for the specific tools.
Does this sound OK? Any refinements or alternate suggestions?
Cheers, Warren
Hi all, to quickly answer one recent question. If you want to upload
something Unix-related for me to archive, you can anonymous ftp upload to
ftp://minnie.tuhs.org/incoming/
Nobody can list the directory contents, so it's good for sensitive files.
If you upload something called xyz, can you also add xyz_Readme which might
describe e.g. what the thing is, where it came from, file format (e.g.
floppy images), how to install it, any other useful information.
If you think it can be added to the public Unix Archive at
http://www.tuhs.org/Archive/, or if the file definitely can't be added
and I should move it to the hidden archive, also say so. Also feel free
not to disclose your identity.
Cheers, Warren
P.S Work has become busy this year. I might call for people to help
out with the curation. Any volunteers? Discretion is a pre-requisite.
