Thanks to everyone who replied with tarballs, zip files, pointers to
stuff in the archive, web links ... I will try (eventually) to thank
everyone individually as well, but in the meantime please accept this
broadcast. :-)
This has now become Yet Another Back Burner Project; I hope putting things
together into a reasonable github repo (or two) will happen without
too much of a delay.
This is a great group of people!
Thanks,
Arnold
> From: jsteve
> I'd say TripOS. There is some surce fragments but I never could get any
> BCPL to cross build anything.
I'm somewhat stunned to hear that, given that Martin Richards did both! What kind
of things are the compilers complaining about? (And I'm also kind of amazed that
Cambridge didn't make an effort to save Tripos.)
Noel
Might as well send this to the list:
There are Multics QEDX sources, but I haven't run across QED - however, there is an overview of it's use and commands in the General Electric June 1969 Multics Condensed Guide (http://bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-g…)
I pulled the QEDX source at put it at https://ban.ai/~jhj/misc/qedx/ for easy access - this is the MR12.5 version and last modified in 1989, sadly, I don't ever recall seeing the BCPL QED. [ I'll be sure to remember now if I see it. ]
[ Somewhat off-topic ] How about Yale 'Z' as long as we're talking editors? Or another editor (that I very much like) is the 'G' editor, which has a long history, originating on Honeywell 6000 GCOS/TSS, originally written in B: https://github.com/ascheepe/g-editor - works nicely today. There is also the Ecce editor, which includes versions in IMP, BASIC, C, BCPL, and FORTRAN at http://history.dcs.ed.ac.uk/archive/apps/ecce/ - bringing Ecce up on Multics is an item on my todo list.
-- Jeff - https://ban.ai/multics/
> From: "Nelson H. F. Beebe"
> a goal of a triplicated complete archive of the world's software
> history, including both open source and proprietary code. They report
> holding 200TB of data already, covering 80 million code projects.
I should ask them if they have a copy of MERT!
Now that we have Multics, ITS, PDP-7 UNIX and UNIX V0, etc MERT (which may
have been the first micro-kernel - although perhaps THE gets that palm) is
perhaps the most significant 'missing' OS.
If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's
been saved.) The THE system? (Ditto - although I know someone has saved the
last X8.) The Atlas OS?
Noel
> On Oct 6, 2018 ,jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote:
>
> Date: Sat, 6 Oct 2018 21:04:59 -0400 (EDT)
> From: jnc(a)mercury.lcs.mit.edu <mailto:jnc@mercury.lcs.mit.edu> (Noel Chiappa)
> Subject: Re: [TUHS] Unix source code archive in the news
> Message-ID: <20181007010459.9098E18C096(a)mercury.lcs.mit.edu <mailto:20181007010459.9098E18C096@mercury.lcs.mit.edu>>
>
> If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's
> been saved.) The THE system? (Ditto - although I know someone has saved the
> last X8.) The Atlas OS?
The Computer History Museum’s Donald Knuth digital archive project (http://www.computerhistory.org/collections/catalog/102726297 <http://www.computerhistory.org/collections/catalog/102726297>) contains a scan of a listing of the source code of the THE Operating System by Bron, Dijkstra, et al. The finding aid for the collection is here: http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index… <http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index…> — scan down for “Source code of the THE Operating System”.
I can only speak from my experience, but I think there was a more or less
official 1st Ed release. in 1993 I was working as a system manager
at UNSW I requested and receicved a Plan9 CDROM with about 5 inches of
printed manual (but unbound) manual from the labs.
Here is some bits and pieces about the Ed1 I scraped together some years ago,
including the artwork for the CD :-)
https://plan9.io/sources/contrib/steve/historic/1st-edition/
I also believe that the CD contained some music in RedBook form
(sadly I never got around to putting the disk in an audio cd drive).
If I am right, then this has been reissued.
https://bauhaus.bandcamp.com/
Everyone sing along now, Undead undead, undead...
-Steve
On Wed, Aug 29, 2018 at 1:07 AM Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
> On Tuesday, 28 August 2018 at 23:23:10 -0400, Theodore Y. Ts'o wrote:
> > On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote:
> ....
>
>
> Creeping featurism!
>
No, I think its really is that many programmers that touch different
applications felt the need to pee on the code to feel that they left their
scent. 😘
Seriously, IMO the problem is you can never know what someone else really
values, so be careful at what you change. Pike's 'cat -v' dissertation
b*tched at UCB for the some of the same issues. Somewhere there is a
proper middle ground ( I think of as having good taste elegance). BSD nor
Linux was no more 'perfect' that 6th or 7th edition. Truth is a much as I
pine for the elegance, I don't want to run either of the later as my
day-2-day system in today's world and I >>loved<< running them when they
were what I had.
Rob has a real point and many of the changes really *are gratuitous* and
there *are better ways of doing* many things than adding a switch to old
command and reusing it because you can. I also think the complaint of just
adding 'crap' because you could started with BSD but the cause wasn't that
people were bad -- there was address space relief over the PDP-11 and often
added a new switch/new functionality was easy to do, instead of creating a
whole new solution just deidcated to that problen only. FWIW: sendmail is
my best example (useful tool that it was - there were/are much more elegant
solutions - sendmail should have been 'headerwriter' and smtpd should have
been a seperate program).
Dueling switches and functionality (dec vs -f bs -F) I fear is sometimes
ignorance of the past. I fear there is some sort of belief we need to shed
the past because someone feeld the it gets in the way of the future (I'll
pick on my on son here - who things 2-3 years is 'old' and its time to
throw things away). Truth is sometimes it might. But I would rather
inject a stronger strain into the mix and let the users decide and for good
or bad, BSD did that to the original (v6/v7) and now Linux is doing/has
done it to much of BSD.
The compaint is the 'throwing the baby out with the bath water' behavior
that seems to often follow (see systemd issues on other mailing lists);
*i.e*. did you really gain something for this huge disruption. To me when
something really new/a great innovation comes that should be celebrated.
BSD gave us VM and a number of 'useful' new utilities, and eventually an
networking API (al biet not everyone liked it, sockets was good enough,
solved the problems and became a standard that allowed us to move on).
Mach (while Larry may not like the VM implementation), moved the bar for
the kernel's handling of memory a huge amount and almost won the uK war
(which IMO was a too bad). BTW: other kernels would do nice VM's too, but
Mach was generally available (open source if you will and really was the
system the moived it forward).
That said, I give the Linux folks great credit for the addition of modules
was huge and it took BSD and the other UNIX systems a few years really pick
up that idea in the same way (yes Solaris, Tru64 and eventually HPUX etc..
had something too but again - my comment about being generally available
applies).
So here is the issue, how to do move the ball forward? BSD, then Linux,
became the 'stronger strain' and pushed out the old version. The problem
is the ROMs in my fingers (like Dave) never got reprogrammed so some of the
'new' becomes annoying. Will I learned to like systemd? We shall see...
Clem
