TUHS

tuhs@tuhs.org

29 participants
6496 discussions

by Matthew E Hoskins

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(a)cobol.njit.edu # # Rm: 5400 GITC Building # Email: matt(a)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"

21 years, 7 months

Re: [TUHS] Re: 4.3 BSD version in the Unix Archive

by msokolov＠ivan.Harhan.ORG

Warren Toomey <wkt(a)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

21 years, 7 months

Re: 4.3 BSD version in the Unix Archive

by Warren Toomey

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

21 years, 7 months

ctcompare 1.2 is up

by Warren Toomey

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

21 years, 7 months

Comparing UNIX/Linux Code

by Maciek Bieszczad

An interesting attempt at finding shared code: http://www.rickbradley.com/chron/20030619/ -- Maciek (macbiesz(a)optonline.net)

21 years, 7 months

Re: [TUHS] Lexical comparator

by Warren Toomey

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

21 years, 7 months

Re: [TUHS] Fwd: Helping in the battle against SCO

by norman＠nose.cs.utoronto.ca

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

21 years, 7 months

VMS for MicroVAX 2000

by Natalia Portillo

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

21 years, 7 months

Lexical comparator, was Re: the battle against SCO

by norman＠nose.cs.utoronto.ca

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

21 years, 8 months

Re: [TUHS] Lexical comparator, was Re: the battle against SCO

by norman＠nose.cs.utoronto.ca

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

21 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS