From dfevans at bbcr.uwaterloo.ca Fri Sep 12 13:53:43 2003
From: dfevans at bbcr.uwaterloo.ca (David Evans)
Date: Thu, 11 Sep 2003 23:53:43 -0400
Subject: [pups] IPv6 on 2.11BSD
Message-ID: <20030911235343.A2240@bcr10.uwaterloo.ca>
Har har, I know.
Anybody even looked into doing a port?
--
David Evans (NeXTMail/MIME OK) dfevans at bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo "Default is the value selected by the composer
Ontario, Canada overridden by your command." - Roland TR-707 Manual
From macbiesz at optonline.net Wed Sep 3 08:26:15 2003
From: macbiesz at optonline.net (Maciek Bieszczad)
Date: Tue, 02 Sep 2003 18:26:15 -0400
Subject: [TUHS] SIMH compilation problems
Message-ID: <000001c371a1$3a742770$03fea8c0@maciek>
I was having some problems compiling SIMH on FreeBSD. The reason is, all
the sources have stray MS-DOS carriage returns (^M), while UNIX only
uses line-feeds (^J). This causes GCC to misread some of the code. I
suggest you convert the sources to UNIX text format.
Once I correct all that, the code compiles fine for me.
BTW, why is networking not supported on FreeBSD? Does the pcap driver
not work?
--
Maciek (macbiesz at optonline.net)
From kawasaki at kawasaki3.org Wed Sep 3 11:52:21 2003
From: kawasaki at kawasaki3.org (moto kawasaki)
Date: Wed, 03 Sep 2003 10:52:21 +0900 (JST)
Subject: [TUHS] SIMH compilation problems
In-Reply-To: <000001c371a1$3a742770$03fea8c0@maciek>
References: <000001c371a1$3a742770$03fea8c0@maciek>
Message-ID: <20030903.105221.45519267.kawasaki@kawasaki3.org>
Hi,
From: Maciek Bieszczad <macbiesz at optonline.net>
Subject: [TUHS] SIMH compilation problems
Date: Tue, 02 Sep 2003 18:26:15 -0400
Message-ID: <000001c371a1$3a742770$03fea8c0 at maciek>
macbiesz> BTW, why is networking not supported on FreeBSD? Does the pcap driver
macbiesz> not work?
bpf might be what you need.
thanks.
moto kawasaki <kawasaki at kawasaki3.org>
From rp at servium.ch Wed Sep 3 22:39:28 2003
From: rp at servium.ch (Rico Pajarola)
Date: Wed, 3 Sep 2003 14:39:28 +0200 (CEST)
Subject: [TUHS] Re: SIMH compilation problems
In-Reply-To: <20030903020020.5179B1F98@minnie.tuhs.org>
References: <20030903020020.5179B1F98@minnie.tuhs.org>
Message-ID: <20030903123928.49D8C40E980@enigma.cybertime.ch>
>I was having some problems compiling SIMH on FreeBSD. The reason is, all
>the sources have stray MS-DOS carriage returns (^M), while UNIX only
>uses line-feeds (^J). This causes GCC to misread some of the code. I
>suggest you convert the sources to UNIX text format.
use 'unzip -a' to automatically convert text files when unpacking.
>BTW, why is networking not supported on FreeBSD? Does the pcap driver
>not work?
on FreeBSD you can't send packets directly over bpf (at least not
the same way you can on Net-/OpenBSD). I have patches to make it
use libnet for sending packets. It's a bit rough, but it works. I
can put them up somewhere if anyone is interested.
--rp
From list-tuhs at cosmic.com Thu Sep 4 03:50:04 2003
From: list-tuhs at cosmic.com (list-tuhs at cosmic.com)
Date: Wed, 3 Sep 2003 17:50:04 +0000 (UTC)
Subject: [TUHS] Re: SIMH compilation problems
References: <20030903123928.49D8C40E980@enigma.cybertime.ch>
Message-ID: <slrnblcaec.qgd.mirian@trantor.cosmic.com>
On Wed, 3 Sep 2003 14:39:28 +0200 (CEST), Rico Pajarola <rp at servium.ch> wrote:
>
>on FreeBSD you can't send packets directly over bpf (at least not
>the same way you can on Net-/OpenBSD).
FreeBSD certainly does let you send packets over bpf. If you open the
device (e.g. /dev/bpf0) for both reading and writing, you can write()
a buffer to the device, and the contents of that buffer will be sent
verbatim from that device. I do this all the time for protocol
testing.
I'm not running NetBSD or OpenBSD currently, so perhaps they support a
richer interface than FreeBSD does, but the essentials are indeed
there.
--Mirian
From kstailey at yahoo.com Thu Sep 4 11:38:00 2003
From: kstailey at yahoo.com (Kenneth Stailey)
Date: Wed, 3 Sep 2003 18:38:00 -0700 (PDT)
Subject: [TUHS] SIMH compilation problems
In-Reply-To: <20030903.105221.45519267.kawasaki@kawasaki3.org>
Message-ID: <20030904013800.52906.qmail@web10001.mail.yahoo.com>
--- moto kawasaki <kawasaki at kawasaki3.org> wrote:
>
> Hi,
>
> From: Maciek Bieszczad <macbiesz at optonline.net>
> Subject: [TUHS] SIMH compilation problems
> Date: Tue, 02 Sep 2003 18:26:15 -0400
> Message-ID: <000001c371a1$3a742770$03fea8c0 at maciek>
>
> macbiesz> BTW, why is networking not supported on FreeBSD? Does the pcap
> driver
> macbiesz> not work?
>
> bpf might be what you need.
>
> thanks.
>
> moto kawasaki <kawasaki at kawasaki3.org>
NetBSD not FreeBSD supports networking with SIMH PDP11 and VAX.
There were changes made to bpf to support writing packets. On FreeBSD it's
still read-only.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From kstailey at yahoo.com Thu Sep 4 11:46:24 2003
From: kstailey at yahoo.com (Kenneth Stailey)
Date: Wed, 3 Sep 2003 18:46:24 -0700 (PDT)
Subject: [TUHS] Re: SIMH compilation problems
In-Reply-To: <slrnblcaec.qgd.mirian@trantor.cosmic.com>
Message-ID: <20030904014624.45815.qmail@web10002.mail.yahoo.com>
--- list-tuhs at cosmic.com wrote:
> On Wed, 3 Sep 2003 14:39:28 +0200 (CEST), Rico Pajarola <rp at servium.ch>
> wrote:
> >
> >on FreeBSD you can't send packets directly over bpf (at least not
> >the same way you can on Net-/OpenBSD).
>
> FreeBSD certainly does let you send packets over bpf. If you open the
> device (e.g. /dev/bpf0) for both reading and writing, you can write()
> a buffer to the device, and the contents of that buffer will be sent
> verbatim from that device. I do this all the time for protocol
> testing.
It's actually the pcap library not the bpf driver that can't write in FreeBSD
but can in NetBSD.
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpcap/pcap-bpf.c
versus:
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/libpcap/pcap-bpf.c
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libpcap/Attic/pcap-bpf.c
> I'm not running NetBSD or OpenBSD currently, so perhaps they support a
> richer interface than FreeBSD does, but the essentials are indeed
> there.
>
> --Mirian
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
From wkt at tuhs.org Wed Sep 10 08:02:30 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 10 Sep 2003 08:02:30 +1000
Subject: [TUHS] Fwd: Helping in the battle against SCO
Message-ID: <20030909220230.GA70691@minnie.tuhs.org>
All,
This e-mail below was prompted by an interview I gave about
the SCO thing for an Australian paper:
http://www.theage.com.au/articles/2003/09/09/1062902037394.html
----- Forwarded message from Ulrik Petersen <emdros at yahoo.dk> -----
Date: Tue, 9 Sep 2003 19:44:51 +0200 (CEST)
From: Ulrik Petersen <emdros at yahoo.dk>
Subject: Helping in the battle against SCO
I saw a recent article in the Sydney Morning Herald in
which a Dr. Warren Toomey (presumably you?) was quoted
as saying that the TUHS has several members who have
access to old copies of UNIX source code.
Please ask these people to try out one of the three
"shredders" which can compare sourcecode from Linux
with other sourcecode, and, if possible, analyze and
publish the results.
One of these shredders is written by Eric S. Raymond.
Here is a link to an article in which he calls for
action by people with access to UNIX sourcecode:
http://www.eweek.com/article2/0,4149,1257617,00.asp
The program itself can be found here:
http://www.catb.org/~esr/comparator/
Regards,
Ulrik Petersen, Denmark
----- End forwarded message -----
Anyway, I think it's a good idea, so I'd like to hear from people
who have access to recent AT&T code. My GPG and PGP keys are at
http://minnie.tuhs.org/warren.html and on most keyservers if you
so wish to use them.
Thanks,
Warren
From macbiesz at optonline.net Wed Sep 10 11:14:27 2003
From: macbiesz at optonline.net (Maciek Bieszczad)
Date: Tue, 09 Sep 2003 21:14:27 -0400
Subject: [TUHS] Fwd: Helping in the battle against SCO
In-Reply-To: <20030909220230.GA70691@minnie.tuhs.org>
Message-ID: <000001c37738$e6e18880$03fea8c0@maciek>
Here are my results of a comment analysis between the contents of Linux
kernel 2.5.73 and SVR1 + SVR2.
Matches for [number of array dimensions in auxiliary entry]:
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h
Matches for [info about tv section in auxent of symbol tv]:
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h
Matches for [number of characters in a symbol name]:
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h
Matches for [text size in bytes padded to fw bdry]:
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/aouthdr.h
./sysv/tape1/src/head/aouthdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/aouthdr.h
Matches for [number of characters in a file name]:
./include/linux/coff.h
./sysv/tape1/include/syms.h
./sysv/tape1/src/head/syms.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/syms.h
Matches for [file ptr to raw data for section]:
./arch/mips/boot/ecoff.h
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/scnhdr.h
./sysv/tape1/src/head/scnhdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/scnhdr.h
Matches for [base of data used for this file]:
./arch/mips/boot/ecoff.h
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/aouthdr.h
./sysv/tape1/src/head/aouthdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/aouthdr.h
Matches for [base of text used for this file]:
./arch/mips/boot/ecoff.h
./arch/ppc/boot/include/rs6000.h
./include/linux/coff.h
./sysv/tape1/include/aouthdr.h
./sysv/tape1/src/head/aouthdr.h
./vaxsysv/vax-svr1/src/cmd/adb/vax/a.out.h
./vaxsysv/vax-svr1/src/head/aouthdr.h
--
Maciek (macbiesz at optonline.net)
From matt at aclaro.com Thu Sep 11 06:18:15 2003
From: matt at aclaro.com (Matthew Mastracci)
Date: Wed, 10 Sep 2003 14:18:15 -0600
Subject: [TUHS] Fwd: Helping in the battle against SCO
Message-ID: <3F5F8707.7070504@aclaro.com>
What about comparing SVR1/2 to 2.4.x? SCO seems to be picking on the
early 2.4.x codebase. This should also pick up the SGI code comments in
the malloc() function that were recently publicized, though I'm not sure
which version Linus removed the code from.
Matt.
From wkt at tuhs.org Thu Sep 11 09:17:40 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 11 Sep 2003 09:17:40 +1000
Subject: [TUHS] Fwd: Helping in the battle against SCO
In-Reply-To: <3F5F8707.7070504@aclaro.com>
References: <3F5F8707.7070504@aclaro.com>
Message-ID: <20030910231740.GA82319@minnie.tuhs.org>
On Wed, Sep 10, 2003 at 02:18:15PM -0600, Matthew Mastracci wrote:
> What about comparing SVR1/2 to 2.4.x? SCO seems to be picking on the
> early 2.4.x codebase. This should also pick up the SGI code comments in
> the malloc() function that were recently publicized, though I'm not sure
> which version Linus removed the code from.
> Matt.
Yes we can do this. But I'm suspecting that SCO has found lots of BSD
code in both Linux and their codebase. SysVR2 didn't have any networking,
so we probably won't get much similarity. Anyway, we can try!
Warren
From norman at nose.cs.utoronto.ca Thu Sep 11 09:59:07 2003
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Wed, 10 Sep 2003 19:59:07 -0400
Subject: [TUHS] Fwd: Helping in the battle against SCO
Message-ID: <20030911000259.F34D91E83@minnie.tuhs.org>
I don't see how any diffing we do will make any difference
`in the battle against SCO.' If we find cases in which Linux
has incorporated System V licensed code, that will certainly
be meaningful; but if, as seems likely, we don't, SCO can
just say their tools are better than hours. And besides, it
is SCO who have brought the complaint, so both legally and
ethically it's up to SCO to prove the case, not up to others
to disprove it, no matter what fearsome roars SCO emit.
Comparisons done by others are certainly interesting, and I
don't want to discourage anyone from doing them; just don't
expect it to make any difference to the lawyers. (Not that
I'm one, of course.)
Norman Wilson
Toronto ON
From luvisi at andru.sonoma.edu Thu Sep 11 10:41:49 2003
From: luvisi at andru.sonoma.edu (Andru Luvisi)
Date: Wed, 10 Sep 2003 17:41:49 -0700 (PDT)
Subject: [TUHS] Fwd: Helping in the battle against SCO
In-Reply-To: <20030911000259.F34D91E83@minnie.tuhs.org>
Message-ID: <Pine.LNX.4.44.0309101738100.2092-100000@gladen>
On Wed, 10 Sep 2003, Norman Wilson wrote:
> I don't see how any diffing we do will make any difference
> `in the battle against SCO.'
[snip]
Some ways that I can see it being a good thing to do:
If SCO holds up a piece of common code and the good guys have no
response, that is bad.
If SCO holds up a piece of common code and the good guys already know
that it actually came from BSD, and are prepared to demonstrate such,
that is good.
If SCO holds up a piece of common code and the good guys already know
that it was contributed to Linux by SCO/Caldera themselves, and are
prepared to demonstrate such, that is good.
If there is infringing code, it should be taken out of Linux as quickly
as possible.
Andru
--
Andru Luvisi
Quote Of The Moment:
Heisenberg may have been here.
From svedeh at catworkx.de Thu Sep 11 18:30:16 2003
From: svedeh at catworkx.de (Sven Dehmlow)
Date: Thu, 11 Sep 2003 10:30:16 +0200 (CEST)
Subject: [TUHS] Ancient Mosix patches
Message-ID: <Pine.LNX.4.56.0309111011400.1845@cat-pc-094.catworkx.de>
Hi,
I'm searching for patches form:
- "UNIX with Satellite Processors" for Unix 6th Edition
- "MOS" for Unix 7th Edition
- "NSMOS" for AT&T Unix system V release 2
and all other ancient Mosix Versions (yes, the Mosix project changed
it's name several times).
Any hints?
Sven
--
"Security is just a state of mind"
From grog at lemis.com Fri Sep 12 03:25:46 2003
From: grog at lemis.com (Greg Lehey)
Date: Thu, 11 Sep 2003 10:25:46 -0700
Subject: [TUHS] Fwd: Helping in the battle against SCO
In-Reply-To: <20030911000259.F34D91E83@minnie.tuhs.org>
References: <20030911000259.F34D91E83@minnie.tuhs.org>
Message-ID: <20030911172545.GC946@adelaide.lemis.com>
On Wednesday, 10 September 2003 at 19:59:07 -0400, Norman Wilson wrote:
> I don't see how any diffing we do will make any difference `in the
> battle against SCO.'
It could. There's a lot of confusion out there. The people on this
list have a much better understanding of the technical issues than
just about any other group of people I can think of.
> If we find cases in which Linux has incorporated System V licensed
> code, that will certainly be meaningful; but if, as seems likely, we
> don't, SCO can just say their tools are better than hours.
FWIW, the first example that SCO showed in Las Vegas on 18 August does
appear to be derived from System V.3 malloc(). See
http://www.lemis.com/grog/SCO/code-comparison.html for the details.
Also, if anybody else can confirm or deny my analysis based on code
inspection, I'd be *very* grateful.
Summary: the first example showed a slightly modified version of Third
Edition malloc() being used for a slightly different purpose in the
SGI ia64 port only. The slight modifications tracked those in System
V.3, suggesting that SGI derived their code from System V, and not
from an earlier version. On the other hand, the differences in System
V.3 were removed again, and in fact the Linux community had already
removed the entire code before SCO "revealed" it.
> And besides, it is SCO who have brought the complaint, so both
> legally and ethically it's up to SCO to prove the case, not up to
> others to disprove it, no matter what fearsome roars SCO emit.
No question.
Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers
From grog at lemis.com Fri Sep 12 03:32:32 2003
From: grog at lemis.com (Greg Lehey)
Date: Thu, 11 Sep 2003 10:32:32 -0700
Subject: [TUHS] Fwd: Helping in the battle against SCO
In-Reply-To: <Pine.LNX.4.44.0309101738100.2092-100000@gladen>
References: <20030911000259.F34D91E83@minnie.tuhs.org>
<Pine.LNX.4.44.0309101738100.2092-100000@gladen>
Message-ID: <20030911173232.GD946@adelaide.lemis.com>
On Wednesday, 10 September 2003 at 17:41:49 -0700, Andru Luvisi wrote:
> On Wed, 10 Sep 2003, Norman Wilson wrote:
>> I don't see how any diffing we do will make any difference
>> `in the battle against SCO.'
> [snip]
>
> Some ways that I can see it being a good thing to do:
>
> If SCO holds up a piece of common code and the good guys have no
> response, that is bad.
Agreed. That doesn't apply to either piece of code they've shown so
far. This is http://www.lemis.com/grog/SCO/code-comparison.html
again.
> If SCO holds up a piece of common code and the good guys already
> know that it actually came from BSD, and are prepared to
> demonstrate such, that is good.
That's the second example :-) The question I've asked SCO is: how
could you have missed the Berkeley license agreement at the beginning
of this file? SCO have backed off claiming that this is System V
code, and claim it's just an example of their code comparison
techniques. But on slide 15 of their presentation
(http://www.vangennip.nl/perens/SCOsource_Briefing_II.2.pdf), they
clearly claim that it's System V code. This suggests that SCO have
recognized their error, though they haven't yet had the decency to
apologize to the BSD community.
Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers
From roger at rops.org Fri Sep 12 23:37:10 2003
From: roger at rops.org (Roger Willcocks)
Date: Fri, 12 Sep 2003 14:37:10 +0100
Subject: [TUHS] Re: Fwd: Helping in the battle against SCO
References: <20030912020015.37FA91F52@minnie.tuhs.org>
Message-ID: <021701c37932$f7b62160$dc32a8c0@barney>
Here's yet another version of the malloc routines: k_malloc/k_mfree in
http://www.tu-chemnitz.de/informatik/osg/lehre/vorl_BS.SRC/malloc.c
I wonder where these routines were 'borrowed' from? The code appears to be
intermediate between 32V and SVR4, containing assertions and using
mapstart/mapsize, but without spl calls.
--
Roger
From macbiesz at optonline.net Sat Sep 13 08:53:11 2003
From: macbiesz at optonline.net (Maciek Bieszczad)
Date: Fri, 12 Sep 2003 18:53:11 -0400
Subject: [TUHS] UNICOS
Message-ID: <000001c37980$a4937d90$03fea8c0@maciek>
I am in contact with someone that is looking for UNICOS system sources
from (1984 to April 1986). Does anyone have or know where to locate any
such sources?
--
Maciek (macbiesz at optonline.net)
From norman at nose.cs.utoronto.ca Tue Sep 16 06:39:31 2003
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Mon, 15 Sep 2003 16:39:31 -0400
Subject: [TUHS] Fwd: Helping in the battle against SCO
Message-ID: <20030915204355.EB9311E5D@minnie.tuhs.org>
Andru Luvisi:
If SCO holds up a piece of common code and the good guys have no
response, that is bad.
If SCO holds up a piece of common code and the good guys already know
that it actually came from BSD, and are prepared to demonstrate such,
that is good.
If SCO holds up a piece of common code and the good guys already know
that it was contributed to Linux by SCO/Caldera themselves, and are
prepared to demonstrate such, that is good.
If there is infringing code, it should be taken out of Linux as quickly
as possible.
======
I'll grant all those points, but if the idea is to defang SCO, the
effort still seems fruitless to me.
System V and Linux both contain appallingly large volumes of code.
(On a list that discusses the UNIX of the 1970s, perhaps I can say
that without creating undue ruckus.) The odds are that quite a
lot of the code is similar. Should we really spend months and months
tracking it all down and trying to declare where each line came from,
or should we wait until SCO declares a specific set of cases that matter
(as they must do sooner or later or abandon the court battle)?
When one is faced with an enormous set of possible computations, of
which only a handful are likely to be needed in the end, lazy evaluation
is usually the better choice.
It does seem sensible to me for the Linux community to do its best to
hunt down any infringing code, and to try to assess whether there's a
serious problem lurking that nobody had noticed. But that ought to be
a matter of basic ethics, having nothing to do with SCO. I doubt it
is likely to make much difference to the court battle anyway: SCO's
claim is that the infringing code is there now, that it was put there
deliberately at IBM's instigation to do harm to them, and that the harm
already exists; removing it now won't change any of that. I think it's
a good idea to remove any infringements that are there now, even if they
are trivial ones; but let's not fool ourselves that it will pull SCO's
fangs to do so.
Norman Wilson
Toronto ON
From wkt at tuhs.org Tue Sep 16 08:48:53 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 16 Sep 2003 08:48:53 +1000
Subject: [TUHS] Lexical comparator, was Re: the battle against SCO
In-Reply-To: <20030915204355.EB9311E5D@minnie.tuhs.org>
References: <20030915204355.EB9311E5D@minnie.tuhs.org>
Message-ID: <20030915224853.GA27957@minnie.tuhs.org>
On Mon, Sep 15, 2003 at 04:39:31PM -0400, Norman Wilson wrote:
> It does seem sensible to me for the Linux community to do its best to
> hunt down any infringing code... But that ought to be a matter of basic
> ethics, having nothing to do with SCO. I doubt it is likely to make
> much difference to the court battle anyway... I think it's
> a good idea to remove any infringements that are there now, even if they
> are trivial ones; but let's not fool ourselves that it will pull SCO's
> fangs to do so.
For me it's not just a matter of defeating SCO, it's also one of sheer
indignation in the face of Saganesque FUD ("billions and billions of
lines of code"). I seriously want to know if there's even the tiniest
possibility that SCO is right, or if they're are just Smoking Crack Often.
While we're on the topic, I saw esr's code shredder/comparator that works
on lines of code. This isn't going to work if variables get renamed etc.
I'm writing a code comparator that works on a lexical basis, comparing
C tokens. It's only going to be proof of concept (i.e. slow), but I
should have it done by week's end and I'll pop a notice in here when it's
ready.
Cheers,
Warren
From norman at nose.cs.utoronto.ca Tue Sep 16 10:02:52 2003
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Mon, 15 Sep 2003 20:02:52 -0400
Subject: [TUHS] Lexical comparator, was Re: the battle against SCO
Message-ID: <20030916000703.635F31E5D@minnie.tuhs.org>
Warren Toomey:
For me it's not just a matter of defeating SCO, it's also one of sheer
indignation in the face of Saganesque FUD ("billions and billions of
lines of code"). I seriously want to know if there's even the tiniest
possibility that SCO is right, or if they're are just Smoking Crack Often.
That's fair enough. Just remember that no matter how much you scan
the code, you can't beat the FUD campaign by doing so. SCO can just
claim their tools are better than yours, and continue to stonewall
about showing their evidence.
And as I said last week, both legally and morally the onus is on
SCO to provide proof of their claims: the infringement, that it
was done maliciously, that it has caused them harm. The `evidence'
they have shown so far makes me doubt very much that they can
prove all three of those things, or possibly any but the least-
significant case of the first.
As I also said last week, I don't mean to discourage anyone from
doing code comparisons. Intellectually it's an interesting exercise.
Ethically it's the right thing to do if the Linux community thinks it's
possible that licensed code got into the system. Even legally it
might make some difference to have shown due diligence, though not
in the matter presently before the courts. If it makes someone feel
less frustrated, that's fine too.
But scanning the Linux code won't provide hard proof of anything,
any more than you can claim to prove there are no leaks in your roof
solely by inspection. If proof is possible, it will work the other way.
Norman Wilson
Toronto ON
From rweather at zip.com.au Tue Sep 16 10:46:49 2003
From: rweather at zip.com.au (Rhys Weatherley)
Date: Tue, 16 Sep 2003 10:46:49 +1000
Subject: [TUHS] Lexical comparator, was Re: the battle against SCO
In-Reply-To: <20030915224853.GA27957@minnie.tuhs.org>
References: <20030915204355.EB9311E5D@minnie.tuhs.org>
<20030915224853.GA27957@minnie.tuhs.org>
Message-ID: <200309161046.49958.rweather@zip.com.au>
On Tuesday 16 September 2003 08:48 am, Warren Toomey wrote:
> While we're on the topic, I saw esr's code shredder/comparator that works
> on lines of code. This isn't going to work if variables get renamed etc.
I'd like to point out that the more steps that are taken to factor out
identifier names, whitespace conventions, etc, the closer you approach a
situation where the tool says "both programs are written in the same
programming language" or "both programs use binary searching somewhere in
their code". Which, while true, isn't terribly useful to know. A human
being still needs to wade through the results and inspect them manually.
Cheers,
Rhys Weatherley.
From robert at timetraveller.org Tue Sep 16 11:35:12 2003
From: robert at timetraveller.org (Robert Brockway)
Date: Mon, 15 Sep 2003 21:35:12 -0400 (EDT)
Subject: [TUHS] Lexical comparator, was Re: the battle against SCO
In-Reply-To: <20030916000703.635F31E5D@minnie.tuhs.org>
References: <20030916000703.635F31E5D@minnie.tuhs.org>
Message-ID: <Pine.LNX.4.56.0309152131290.24213@zen.canint.timetraveller.org>
On Mon, 15 Sep 2003, Norman Wilson wrote:
> possible that licensed code got into the system. Even legally it
Hi. Don't want to nitpick here but many of us think it is important to
get this point straight whenever we are talking about GPLed code. The
kernel is licenced (as I'm sure you know). What we are of course
concerned about is:
a) Code which is licenced in a manner incompatible with the GPL
b) Code that the copyright holder did not authorise going into the kernel.
I'm sure you were just speaking in shorthand but it is subtle point that
many misinterpret. Many people outside the OSS community think that "all
that free code" is in the public domain, which it is most definately not.
> Norman Wilson
> Toronto ON
A fellow Torontonian, perhaps we may meet at TLUG sometime. I'm giving
the next talk.
Cheers,
Rob
--
Robert Brockway B.Sc. email: robert at timetraveller.org, zzbrock at uqconnect.net
Linux counter project ID #16440 (http://counter.li.org)
"The earth is but one country and mankind its citizens" -Baha'u'llah
From norman at nose.cs.utoronto.ca Tue Sep 16 12:11:41 2003
From: norman at nose.cs.utoronto.ca (Norman Wilson)
Date: Mon, 15 Sep 2003 22:11:41 -0400
Subject: [TUHS] Lexical comparator, was Re: the battle against SCO
Message-ID: <20030916021555.EFF121EB2@minnie.tuhs.org>
Robert Brockway:
Hi. Don't want to nitpick here but many of us think it is important to
get this point straight whenever we are talking about GPLed code. The
kernel is licenced (as I'm sure you know). What we are of course
concerned about is:
a) Code which is licenced in a manner incompatible with the GPL
b) Code that the copyright holder did not authorise going into the kernel.
I'm sure you were just speaking in shorthand but it is subtle point that
many misinterpret. Many people outside the OSS community think that "all
that free code" is in the public domain, which it is most definately not.
====
Quite right. I wasn't speaking in shorthand, I was speaking in
clumsy; what I should have written is `possible that code restricted
by the System V license got into the system.'
Licenses come in all flavours, and whether there is any license
at all is not the issue here. I certainly didn't mean, for
example, to imply that all licenses are evil, reptilian kitten-
eaters from another planet.
Norman Wilson
Toronto ON
From imp at bsdimp.com Tue Sep 16 13:01:26 2003
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 15 Sep 2003 21:01:26 -0600 (MDT)
Subject: [TUHS] Fwd: Helping in the battle against SCO
In-Reply-To: <20030915204355.EB9311E5D@minnie.tuhs.org>
References: <20030915204355.EB9311E5D@minnie.tuhs.org>
Message-ID: <20030915.210126.54187719.imp@bsdimp.com>
In message: <20030915204355.EB9311E5D at minnie.tuhs.org>
norman at nose.cs.utoronto.ca (Norman Wilson) writes:
: tracking it all down and trying to declare where each line came from,
In BSD land, we can do that. We have cvs annotate. Looks like the
stubborn refusal to use source code control, and to have only a few
people putting things together makes it a lot harder to track things
down after the fact. Good call that.
Warner
From imp at bsdimp.com Tue Sep 16 13:10:11 2003
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 15 Sep 2003 21:10:11 -0600 (MDT)
Subject: [TUHS] Lexical comparator, was Re: the battle against SCO
In-Reply-To: <Pine.LNX.4.56.0309152131290.24213@zen.canint.timetraveller.org>
References: <20030916000703.635F31E5D@minnie.tuhs.org>
<Pine.LNX.4.56.0309152131290.24213@zen.canint.timetraveller.org>
Message-ID: <20030915.211011.51703000.imp@bsdimp.com>
In message: <Pine.LNX.4.56.0309152131290.24213 at zen.canint.timetraveller.org>
Robert Brockway <robert at timetraveller.org> writes:
: a) Code which is licenced in a manner incompatible with the GPL
: b) Code that the copyright holder did not authorise going into the kernel.
There's a lot of code that originated in the BSD world that had its
copyrights shorn off, a GPL splatted on and the mass hacking began.
Many of these are no longer recognizable from there original form, and
aren't a problem. Some have much more in common with the original.
Linux is vulnerable to the original author having a shit fit if they
ever find out. Most of the open source authors are amused when this
happens, so the odds are low a big deal would be made of it. This
practice was wide-spread in the early 1990s, although things have
improved a lot.
However, without something like CVS and the legal assignment of
copyright (or formal acknowledgement of licensing under the GPL, which
is harder to defend), this will always be a problem with Linux.
The BSD projects are a little tigher about this, but still would be
vulnerable.
Warner
From iosglpgc at teleline.es Thu Sep 18 06:26:23 2003
From: iosglpgc at teleline.es (Natalia Portillo)
Date: Wed, 17 Sep 2003 21:26:23 +0100
Subject: [TUHS] VMS for MicroVAX 2000
Message-ID: <00ec01c37d59$f7242b90$0100a8c0@cicm.iosg.com>
Hello
I know this can be some offtopic as VMS is not a UNIX system, but, I
recently adquired a MicroVAX 2000 for a museum and I'm guessing if I can get
a tarball of the original VMS installation tape or someone could send me a
tape.
Thanks in advance.
Natalia Portillo
Canary Islands Computer Museum
From kevin at mpcf.com Thu Sep 18 06:37:42 2003
From: kevin at mpcf.com (Kevin)
Date: Wed, 17 Sep 2003 16:37:42 -0400
Subject: [TUHS] VMS for MicroVAX 2000
In-Reply-To: <00ec01c37d59$f7242b90$0100a8c0@cicm.iosg.com>
References: <00ec01c37d59$f7242b90$0100a8c0@cicm.iosg.com>
Message-ID: <20030917163742.0009282c.kevin@mpcf.com>
If no one can get it for you, can get an official copy
form here.
http://www.montagar.com/hobbyist/mount.html
/KRM
On Wed, 17 Sep 2003 21:26:23 +0100
"Natalia Portillo" <iosglpgc at teleline.es> wrote:
> Hello
>
> I know this can be some offtopic as VMS is not a UNIX
> system, but, I recently adquired a MicroVAX 2000 for
> a museum and I'm guessing if I can get a tarball of
> the original VMS installation tape or someone could
> send me a tape.
>
> Thanks in advance.
> Natalia Portillo
> Canary Islands Computer Museum
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/tuhs
--
keyserver: http://pgp.mit.edu/
From wkt at tuhs.org Thu Sep 18 12:56:32 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 18 Sep 2003 12:56:32 +1000
Subject: [TUHS] Lexical comparator
In-Reply-To: <20030915224853.GA27957@minnie.tuhs.org>
References: <20030915204355.EB9311E5D@minnie.tuhs.org>
<20030915224853.GA27957@minnie.tuhs.org>
Message-ID: <20030918025632.GA50614@minnie.tuhs.org>
On Tue, Sep 16, 2003 at 08:48:53AM +1000, Warren Toomey wrote:
> While we're on the topic, I saw esr's code shredder/comparator that works
> on lines of code. This isn't going to work if variables get renamed etc.
> I'm writing a code comparator that works on a lexical basis, comparing
> C tokens. It's only going to be proof of concept (i.e. slow), but I
> should have it done by week's end and I'll pop a notice in here when it's
> ready.
Well, it's done. The software is now available at
http://minnie.tuhs.org/Programs/Ctcompare. I have also made available
some tokenised source trees so you can do some comparisons straight away.
If anybody has Unix kernel trees which they cannot divulge due to licensing
restrictions, I'd appreciate you creating tokenised files of the kernel
source and e-mailing them to me.
Thanks!
Warren
From wkt at tuhs.org Thu Sep 18 21:45:26 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 18 Sep 2003 21:45:26 +1000
Subject: [TUHS] Lexical comparator
In-Reply-To: <200309181041.h8IAfAWe000686@skeeve.com>
References: <200309181041.h8IAfAWe000686@skeeve.com>
Message-ID: <20030918114526.GA54312@minnie.tuhs.org>
On Thu, Sep 18, 2003 at 01:41:10PM +0300, Aharon Robbins wrote:
> > If anybody has Unix kernel trees which they cannot divulge due to licensing
> > restrictions, I'd appreciate you creating tokenised files of the kernel
> > source and e-mailing them to me.
>
> Hmmm. Just between us chickens, given tokenized versions of an entire tree,
> how hard would it be to recreate a functional kernel?
Pretty damn hard. All identifiers, (variable names) are reduced to
a single token. Actually, that's not true. The meaning of the names
is removed an replaced with numeric identifiers that are unique to
each file. Here's a tokenised portion of 32V (bio.c):
56: struct id10 *
57: id13 ( id14 , id15 )
58: id16 id14 ;
59: id17 id15 ;
60: {
61: register struct id10 * id18 ;
62:
63: id18 = id19 ( id14 , id15 ) ;
64: if ( id18 ->id20 & id21 ) {
65: #ifdef id1
66: id9 . id5 ++ ;
67: #endif
68: return( id18 ) ;
69: }
70: id18 ->id20 |= id22 ;
71: id18 ->id23 = id24 ;
72: ( * id25 [ id26 ( id14 ) ] . id27 ) ( id18 ) ;
73: #ifdef id1
74: id9 . id3 ++ ;
75: #endif
76: id28 ( id18 ) ;
77: return( id18 ) ;
78: }
Now go and check the actual source and work out which function it is!
[ see http://minnie.tuhs.org/UnixTree/32VKern/usr/src/sys/sys/bio.c.html ]
Warren
From tom at insolvencyhelp.org Fri Sep 19 09:52:31 2003
From: tom at insolvencyhelp.org (tom at insolvencyhelp.org)
Date: Thu, 18 Sep 2003 19:52:31 -0400
Subject: [TUHS] Comparing UNIX/Linux Code
In-Reply-To: <000001c33cbf$b07b3330$06fea8c0@maciek>
References: <000001c33cbf$b07b3330$06fea8c0@maciek>
Message-ID: <3F6A453F.nail7JK11UM94@insolvencyhelp.org>
:help
q
From tom at insolvencyhelp.org Fri Sep 19 09:54:30 2003
From: tom at insolvencyhelp.org (tom at insolvencyhelp.org)
Date: Thu, 18 Sep 2003 19:54:30 -0400
Subject: [TUHS] Comparing UNIX/Linux Code
In-Reply-To: <000001c33cbf$b07b3330$06fea8c0@maciek>
References: <000001c33cbf$b07b3330$06fea8c0@maciek>
Message-ID: <3F6A45B6.nailGLZ1GJNLC@insolvencyhelp.org>
:help
:set
q
q
From wkt at tuhs.org Wed Sep 24 12:40:02 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 24 Sep 2003 12:40:02 +1000
Subject: [TUHS] ctcompare 1.2 is up
Message-ID: <20030924024002.GA42436@minnie.tuhs.org>
Hi all,
It's probably bad form to release a new version of a program
24 hours after the last version, but version 1.2 of my C comparison
tool is now available at http://minnie.tuhs.org/Programs/Ctcompare.
The speed has been vastly improved by using the Rabin-Karp string
comparison algorithm, and thanks go to Roger Willcocks who pointed
me at the algorithm. There are no other bug fixes, and I shouldn't
bring out a new version for quite a while now.
So if you have access to any restricted C source trees, maybe you can
send me the ctf file of the tree so I can do some comparisons!
Cheers,
Warren
From wkt at tuhs.org Fri Sep 26 13:03:00 2003
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 26 Sep 2003 13:03:00 +1000
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
In-Reply-To: <PMEAIMBALAHKECEIMJFGMELBMCAA.jmbw@nather.com>
References: <20030924024002.GA42436@minnie.tuhs.org>
<PMEAIMBALAHKECEIMJFGMELBMCAA.jmbw@nather.com>
Message-ID: <20030926030300.GF63735@minnie.tuhs.org>
On Wed, Sep 24, 2003 at 11:12:54AM -0500, Markus Weber wrote:
> Can you decompress the files in either of the two 4.3BSD-Quasijarus dists
> (in /4BSD/Distributions)? If so, how? The oldest versions that I have date
> back to a CD somebody cut me in mid-2000, and I can't decompress these files
> no matter what.
The 4.3BSD-Quasijarus dists were compressed with a compression format
that's not compatible with either gzip nor old compress(1). Michael
Sokolov should be able to send in some notes on the tools required.
> Is there a set of 4.3BSD-Tahoe Vax distribution files that's complete?
Not that I know of.
> Finally, do you know of any 4.3BSD version that will install and run on
> simh? Quasijarus and Tahoe of the Unix Archive are broken for me and Reno
> doesn't boot stand. Admittedly, I haven't tried the vanilla version yet.
Not that I know of. I'll cc this to the TUHS list and see if any other
people know the answer.
> If I manage to get a version of 4.3 working on simh, I'll offer a turnkey
> system for download on my site.
Yes, I'd appreciate that :-)
Thanks,
Warren
From msokolov at ivan.Harhan.ORG Fri Sep 26 21:47:28 2003
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Fri, 26 Sep 03 04:47:28 PDT
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
Message-ID: <0309261147.AA07050@ivan.Harhan.ORG>
Warren Toomey <wkt at tuhs.org> wrote:
> The 4.3BSD-Quasijarus dists were compressed with a compression format
> that's not compatible with either gzip nor old compress(1). Michael
> Sokolov should be able to send in some notes on the tools required.
Yes, for political reasons I needed to make the 4.3BSD-Quasijarus compressor a
version of compress, not gzip (can't have any GNU), but I wanted to have the
higher compression ratio of deflation, so I created a new version of compress
that supports deflation in addition to the original LZW algorith. You can find
the new compress in components/compress.tar either on my FTP site or in Warren's
archive in the 4BSD area.
> > Is there a set of 4.3BSD-Tahoe Vax distribution files that's complete?
>
> Not that I know of.
"4.3BSD-Tahoe Vax distribution" is an oxymoron. Berkeley released the Tahoe
tape with Tahoe binaries, no VAX binaries. I was the one who compiled the Tahoe
source for the VAX, and the result was 4.3BSD-Quasijarus0.
OTOH, you may be referring to the fact that the Tahoe distribution in the
archive is broken. Yes, it is. Unfortunately there was an unrecoverable tape
read error.
> > Finally, do you know of any 4.3BSD version that will install and run on
> > simh? Quasijarus and Tahoe of the Unix Archive are broken for me and Reno
> > doesn't boot stand. Admittedly, I haven't tried the vanilla version yet.
>
> Not that I know of. I'll cc this to the TUHS list and see if any other
> people know the answer.
This has come up time and again. SIMH's emulation of VAX is too poor. VAX is
not an easy architecture to emulate.
MS
From matt at njit.edu Sat Sep 27 00:03:39 2003
From: matt at njit.edu (Matthew E Hoskins)
Date: Fri, 26 Sep 2003 10:03:39 -0400
Subject: [TUHS] Any unix for MicroPDP-11?
Message-ID: <3F74473B.21D8226@njit.edu>
Greetings all, and forgive me if this was answered prevously, but i
didnt see it when i grepped the archive..
Are there any *nix versions in the archive that will run on a MicroPDP11
model 630QZ-AX? Currently it is running RSX-11 /w what looks like a
seagate MFM/RLL type HDD. It has only dual floppy for removeable. But
i might be able to get my hands on a TK50/70 and qbus adapter for it.
Thanks.
-Matt
--
# Matthew E. Hoskins #############################################
# Information Systems Analyst /| / / / ~~/~~ #
# University Information Systems / | / / / / #
# New Jersey Institute of Technology / | / / / / / #
# University Heights, Newark, NJ 07102 / |/ /___/ / / #
# Ph: 973-596-5202 # Beep: pagematt at cobol.njit.edu #
# Rm: 5400 GITC Building # Email: matt at njit.edu #
###################################################################
"Any technology sufficiently advanced is indistinguishable
from a perl script"
"Anyone who considers arithmetical methods of producing
random digits is, of course, in a state of sin
-- John von Neumann"
From jmbw at nather.com Sat Sep 27 03:48:31 2003
From: jmbw at nather.com (Markus Weber)
Date: Fri, 26 Sep 2003 12:48:31 -0500
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
In-Reply-To: <0309261147.AA07050@ivan.Harhan.ORG>
Message-ID: <PMEAIMBALAHKECEIMJFGEEMAMCAA.jmbw@nather.com>
Thanks for the help.
So far I managed to uncompress the files with the custom version of compress
on NetBSD/simh. I then created a .tap file according to the reference in
FORMAT.
I'm using the following config file for simh 3.0.1:
load -r ka655.bin
set rq0 ra82
at rq0 ra82.dsk
set tq tk50
at tq0 quasijarus0a-dist.tap
boot cpu
Here's a transcript of the very first attempt of booting off the tape:
$ ./vax 43cfg
VAX simulator V3.0-1
KA655-B V5.3, VMB 2.7
Performing normal system tests.
40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25..
24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09..
08..07..06..05..04..03..
Tests completed.
>>>boot mua0:
(BOOT/R5:0 MUA0
2..
-MUA0
1..0..
=
Clearly, stand boots. I'm hopeful that 4.3-Quasijarus0a will indeed run on
simh.
For some follow-up questions... Standalone format supports hp and up disks,
but simh only emulates RL and RQ controllers - which means that the Ultrix
utilities to label a cold disk must be ported or recreated to the simh host
platform. Of course, it may well be that applying a hex editor to the disk
image will suffice.
Am I correct that Quasijarus supports RA82 disks (using the ra type) and the
TK50 tape (as a tms)?
Markus
-----Original Message-----
From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG]
Sent: Friday, September 26, 2003 6:47 AM
To: jmbw at nather.com; tuhs at tuhs.org
Subject: Re: [TUHS] Re: 4.3 BSD version in the Unix Archive
Warren Toomey <wkt at tuhs.org> wrote:
> The 4.3BSD-Quasijarus dists were compressed with a compression format
> that's not compatible with either gzip nor old compress(1). Michael
> Sokolov should be able to send in some notes on the tools required.
Yes, for political reasons I needed to make the 4.3BSD-Quasijarus compressor
a
version of compress, not gzip (can't have any GNU), but I wanted to have the
higher compression ratio of deflation, so I created a new version of
compress
that supports deflation in addition to the original LZW algorith. You can
find
the new compress in components/compress.tar either on my FTP site or in
Warren's
archive in the 4BSD area.
> > Is there a set of 4.3BSD-Tahoe Vax distribution files that's complete?
>
> Not that I know of.
"4.3BSD-Tahoe Vax distribution" is an oxymoron. Berkeley released the Tahoe
tape with Tahoe binaries, no VAX binaries. I was the one who compiled the
Tahoe
source for the VAX, and the result was 4.3BSD-Quasijarus0.
OTOH, you may be referring to the fact that the Tahoe distribution in the
archive is broken. Yes, it is. Unfortunately there was an unrecoverable
tape
read error.
> > Finally, do you know of any 4.3BSD version that will install and run on
> > simh? Quasijarus and Tahoe of the Unix Archive are broken for me and
Reno
> > doesn't boot stand. Admittedly, I haven't tried the vanilla version yet.
>
> Not that I know of. I'll cc this to the TUHS list and see if any other
> people know the answer.
This has come up time and again. SIMH's emulation of VAX is too poor. VAX
is
not an easy architecture to emulate.
MS
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
From jkunz at unixag-kl.fh-kl.de Sat Sep 27 03:58:06 2003
From: jkunz at unixag-kl.fh-kl.de (Jochen Kunz)
Date: Fri, 26 Sep 2003 19:58:06 +0200
Subject: [TUHS] Any unix for MicroPDP-11?
In-Reply-To: <3F74473B.21D8226@njit.edu>;
from matt@njit.edu on Fri, Sep 26, 2003 at 16:03:39 CEST
References: <3F74473B.21D8226@njit.edu>
Message-ID: <20030926195806.E69224@MissSophie.unixag-kl.fh-kl.de>
On 2003.09.26 16:03 Matthew E Hoskins wrote:
> Are there any *nix versions in the archive that will run on a
> MicroPDP11 model 630QZ-AX?
This doesn't look like a PDP-11 model, more like MicroVAX II (enclosure)
model designator. Open the machine and make a list of the cards that are
inside. Look for the Mxxxx numbers and have a look at
pdp11-field-guide.txt (easy to find with your prefered web search
engine). Once you have determind the CPU type look around
http://www.tuhs.org/ I think there was a FAQ somewhere that listed what
versions of UNIX run on what models.
--
tschüß,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
From jmbw at nather.com Sat Sep 27 06:24:27 2003
From: jmbw at nather.com (Markus Weber)
Date: Fri, 26 Sep 2003 15:24:27 -0500
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
In-Reply-To: <0309261835.AA07237@ivan.Harhan.ORG>
Message-ID: <PMEAIMBALAHKECEIMJFGAEMCMCAA.jmbw@nather.com>
Stand/copy from tms(0,1) to ra(0,1) fails with a 'disk unlabeled' diagnostic
on a cold disk image. It turns out that NetBSD's disklabel(8) will create a
template disk image file that makes stand/copy happy, although I haven't
verified that the label is all that it should be.
The boot of the miniroot's GENERIC kernel does indeed fail. If only ra0 is
configured for simh, it takes the kernel a long time to decide that ra1,
ra2, and ra3 are offline. Having said that, I do not know how long this
takes on actual hardware. This part can be speeded up by supplying empty
image files for the remaing three disks, but in either case the kernel (and
not simh) subsequently segfaults (trap type 8, code = c0000200, pc =
8003fe16).
I haven't yet investigated what this diagnostic signifies. There are two
likely scenarios, the kernel either crashes late in the ra driver
initialization or while probing for the next device in line. At this point
I'm not prepared to argue whether this is primarily an emulation error or a
kernel bug.
Owing to the lack of Vax hardware or at least a compatible environment, you
have me at a disadvantage. Which function does pc = 8003fe16 correspond to?
Markus
-----Original Message-----
From: Michael Sokolov [mailto:msokolov at ivan.Harhan.ORG]
Sent: Friday, September 26, 2003 1:36 PM
To: jmbw at nather.com; tuhs at tuhs.org
Subject: RE: [TUHS] Re: 4.3 BSD version in the Unix Archive
Markus Weber <jmbw at nather.com> wrote:
> Clearly, stand boots. I'm hopeful that 4.3-Quasijarus0a will indeed run on
> simh.
Just be warned that I have heard from others that the kernel won't boot on
SIMH
due to sucky emulation.
> For some follow-up questions... Standalone format supports hp and up
disks,
> but simh only emulates RL and RQ controllers - which means that the Ultrix
> utilities to label a cold disk must be ported or recreated to the simh
host
> platform. Of course, it may well be that applying a hex editor to the disk
> image will suffice.
Arghh, why don't people just f-ing get it! Standalone format is what is
known
as low-level format in the PeeCee world (magnetic level stuff, certainly not
needed on an emulator), and it has absolutely nothing to do with disk
labeling.
4.3BSD-Quasijarus0[a] does not have standalone disklabel, but RA82 is known
to
the compiled-in tables and thus will work unlabeled. Also Ultrix' disk
labels
are not useful for 4.3BSD-Tahoe/Quasijarus, since the labels are stored in a
different place in a different format. (Berkeley and DEC developed pack
labels
independently. BSD stores them in the boot block, Ultrix stores them in the
root fs superblock, which has the disadvantage of requiring you to create
some
dummy root fs before you can write a label, even if you want a root fs of
different size.)
> Am I correct that Quasijarus supports RA82 disks (using the ra type) and
the
> TK50 tape (as a tms)?
Yes.
MS
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003
From msokolov at ivan.Harhan.ORG Sat Sep 27 04:35:37 2003
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Fri, 26 Sep 03 11:35:37 PDT
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
Message-ID: <0309261835.AA07237@ivan.Harhan.ORG>
Markus Weber <jmbw at nather.com> wrote:
> Clearly, stand boots. I'm hopeful that 4.3-Quasijarus0a will indeed run on
> simh.
Just be warned that I have heard from others that the kernel won't boot on SIMH
due to sucky emulation.
> For some follow-up questions... Standalone format supports hp and up disks,
> but simh only emulates RL and RQ controllers - which means that the Ultrix
> utilities to label a cold disk must be ported or recreated to the simh host
> platform. Of course, it may well be that applying a hex editor to the disk
> image will suffice.
Arghh, why don't people just f-ing get it! Standalone format is what is known
as low-level format in the PeeCee world (magnetic level stuff, certainly not
needed on an emulator), and it has absolutely nothing to do with disk labeling.
4.3BSD-Quasijarus0[a] does not have standalone disklabel, but RA82 is known to
the compiled-in tables and thus will work unlabeled. Also Ultrix' disk labels
are not useful for 4.3BSD-Tahoe/Quasijarus, since the labels are stored in a
different place in a different format. (Berkeley and DEC developed pack labels
independently. BSD stores them in the boot block, Ultrix stores them in the
root fs superblock, which has the disadvantage of requiring you to create some
dummy root fs before you can write a label, even if you want a root fs of
different size.)
> Am I correct that Quasijarus supports RA82 disks (using the ra type) and the
> TK50 tape (as a tms)?
Yes.
MS
From msokolov at ivan.Harhan.ORG Sat Sep 27 06:47:59 2003
From: msokolov at ivan.Harhan.ORG (Michael Sokolov)
Date: Fri, 26 Sep 03 13:47:59 PDT
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
Message-ID: <0309262047.AA07364@ivan.Harhan.ORG>
Markus Weber <jmbw at nather.com> wrote:
> Stand/copy from tms(0,1) to ra(0,1) fails with a 'disk unlabeled' diagnostic
> on a cold disk image.
It should print the unlabeled diagnostic, but then proceed rather than fail. I
just double-checked the standalone driver source, and it does provide a default
label for RA82, as long as the MSCP controller actually returns RA82 as the MSCP
disk ID. Does it give you an error message about disk type (some hex humber)
not supported? If so, SIMH's MSCP emulation must be lacking in quality.
> If only ra0 is
> configured for simh, it takes the kernel a long time to decide that ra1,
> ra2, and ra3 are offline. Having said that, I do not know how long this
> takes on actual hardware.
On real HW it takes no noticeable time.
> the kernel (and
> not simh) subsequently segfaults (trap type 8, code = c0000200, pc =
> 8003fe16).
Well, obviously this doesn't happen on real HW, since on real HW it works (I'm
typing this message on a MicroVAX 3+ running 4.3BSD-Quasijarus).
But I will grant the possibility that the kernel is not w/o fault either in that
perhaps it's going south (dereferencing a garbage pointer and crashing) when the
MSCP controller (in this case SIMH's poor emulation) is doing something it
doesn't expect. If this is so, it should be fixed, since even w/o emulators
(which I refuse to support on principle) real HW can be broken and return
garbage on reg reads, and the kernel must handle it gracefully. I'll look into
it.
MS
From jy99 at swbell.net Tue Sep 30 04:50:12 2003
From: jy99 at swbell.net (Joseph F. Young)
Date: Mon, 29 Sep 2003 13:50:12 -0500
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
Message-ID: <6.0.0.22.2.20030929131607.02ecef00@192.168.1.1>
From my experience, you need to have a recent release of SIMH in order to
run 4.3BSD. A few months ago, I managed to build "working" Quasijarus and
Reno disk images (Quasijarus appears to work fine for me, but Reno is as
buggy as I remember it being on real hardware). I had to use Ultrix and
Netbsd to do the bootstrap/install; I could not get the tape boot to work
at all.
Here's my SIMH ini file for Quasijarus:
---------------------------------------------------------------------------------------------------------------
set cpu 32m
set cpu conhalt
set tto 7b
set tti 7b
at rom ka655.bin
at nvr nvr.bin
set rq0 ra82
at rq0 bsd43q_ra0.dsk
set rq1 ra82
at rq1 /dev/null
set rq2 ra82
at rq2 /dev/null
set rq3 ra82
at rq3 /dev/null
set tq0 locked
at tq0 BSD43Q_TAPE.tap
set dz 7b
at -m dz0 4501
at xq eth0
set lpt dis
set ts dis
set rl dis
boot cpu
--------------------------------------------------------------------------------------------------------------
Here's an example boot log for Quasijarus under SIMH:
>>>boot dua0
(BOOT/R5:0 DUA0
2..
-DUA0
1..0..
loading boot
Boot
: /vmunix
327204+103384+130352 start 0x23a8
4.3 BSD Quasijarus UNIX #0: Sat Oct 2 22:15:38 CDT 1999
msokolov at luthien:/usr/src/sys/GENERIC
real mem = 33521664
SYSPTSIZE limits number of buffers to 80
avail mem = 31697920
using 80 buffers containing 655360 bytes of memory
MicroVAX 3000, ucode rev 6
tmscp0 at uba0 csr 174500 vec 774, ipl 15
tms0 at tmscp0 slave 0
tms1 at tmscp0 slave 1
uda0 at uba0 csr 172150 vec 770, ipl 15
uda0: version 3 model 3
uda0: DMA burst size set to 4
ra0 at uda0 slave 0: RA82, size = 1216665 sectors
ra1 at uda0 slave 1: no disk label: ra82, size = 1216665 sectors
ra2 at uda0 slave 2: no disk label: ra82, size = 1216665 sectors
ra3 at uda0 slave 3: no disk label: ra82, size = 1216665 sectors
dz0 at uba0 csr 160100 vec 300, ipl 15
dz1 at uba0 csr 160110 vec 310, ipl 15
dz2 at uba0 csr 160120 vec 320, ipl 15
dz3 at uba0 csr 160130 vec 330, ipl 15
qe0 at uba0 csr 174440 vec 764, ipl 15
qe0: delqa, hardware address 08:00:2b:aa:bb:cc
Changing root device to ra0a
WARNING: clock gained 91 days -- CHECK AND RESET THE DATE!
Automatic reboot in progress...
Mon Sep 29 08:38:03 CDT 2003
/dev/ra0a: 669 files, 5242 used, 25429 free (37 frags, 3174 blocks, 0.1%
fragmentation)
/dev/rra0g: 12267 files, 71408 used, 376714 free (1634 frags, 46885 blocks,
0.4% fragmentation)
Mon Sep 29 08:43:51 CDT 2003
checking quotas: done.
starting system logger
preserving editor files
clearing /tmp
standard daemons: update cron accounting.
starting network daemons: routed named inetd printer.
Sep 29 08:44:28 simh named[66]: /etc/named.boot: No such file or directory
starting local daemons: sendmail.
Mon Sep 29 08:44:52 CDT 2003
4.3 BSD UNIX (simh.localdomain) (console)
login:
-----------------------------------------------------------------------------------------------------------
Cheers,
----
Joseph Young
jy99 at swbell.net
From jmbw at nather.com Tue Sep 30 23:04:52 2003
From: jmbw at nather.com (Markus Weber)
Date: Tue, 30 Sep 2003 08:04:52 -0500
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
In-Reply-To: <6.0.0.22.2.20030929131607.02ecef00@192.168.1.1>
Message-ID: <PMEAIMBALAHKECEIMJFGEENIMCAA.jmbw@nather.com>
Thanks to your help it works. Please see
http://www.itsecuritygeek.com/modules.php?op=modload&name=News&file=article&
sid=22
for an annotated installation transcript. You'll find a pre-installed disk
image in the site's Download section.
-----Original Message-----
From: Joseph F. Young [mailto:jy99 at swbell.net]
Sent: Monday, September 29, 2003 1:50 PM
To: tuhs at minnie.tuhs.org
Cc: jy99 at swbell.net
Subject: [TUHS] Re: 4.3 BSD version in the Unix Archive
From my experience, you need to have a recent release of SIMH in order to
run 4.3BSD. A few months ago, I managed to build "working" Quasijarus and
Reno disk images (Quasijarus appears to work fine for me, but Reno is as
buggy as I remember it being on real hardware). I had to use Ultrix and
Netbsd to do the bootstrap/install; I could not get the tape boot to work
at all.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 9/18/2003