TUHS

tuhs@tuhs.org

6 participants
6532 discussions

Re: [TUHS] SCO vs. IBM: Eric Raymond striking a blow for ... something

by Aharon Robbins

> I find it hard to take a secret No Secrets campaign seriously. That says it well. > That such a campaign exists in the current context also sounds to > me like an admission that substantial parts of Linux were in fact > lifted directly from a licensed UNIX. That that might be so seems > surprising; that someone would want to prove it was OK even more so. I think it's more of a "How dare anyone even think licensed code was lifted? We all know better than that. I'm gonna show you that you don't even have a leg to stand on." Whatever. Anyone with any sense knows that SCO hasn't got much ground to stand on. Sadly, "anyone with any sense" likely doesn't cover the judge and the jury. Sigh. (Fade to black, as Dionne Warwick sings "Deja Vu" in the background...) Arnold

22 years, 1 month

SCO vs. IBM: Eric Raymond striking a blow for ... something

by Aharon Robbins

I just saw this: http://www.catb.org/~esr/nosecrets/ This either Very Smart or Very Dumb, I'm not sure which. I don't know that it need be discussed to death on this list, either, but I do figure that the list members will at least be interested in it. Arnold

22 years, 1 month

Re: [TUHS] V7 ls -s option

by Aharon Robbins

The V7 ls.c code: > >>> long > >>> nblock(size) > >>> long size; > >>> { > >>> return((size+511)>>9); > >>> } > >> I wrote: > > In fact, the V7 calculation is only > > an approximation in another sense; a file with large holes could > > generate too large a result. Greg wrote: > A block is a block. If it's allocated, it's all there (at least in > the Seventh Edition). It doesn't make any difference that some of the > space in the block may not represent valid data. You're missing my point. Consider a C program along these lines: int main(void) { int fd = creat("/some/file", 0600); lseek(fd, 123456789L, 0); /* absolute seek */ write(fd, "x", 1); close(fd); } After running this program, the `/some/file' file now looks rather large. But it only has one block allocated to it. However, the V7 nblock() function computes a number somewhat larger than one. Thanks, Arnold

22 years, 1 month

Re: [TUHS] sco v. ibm

by norman＠nose.cs.utoronto.ca

I haven't come up to speed yet on SCOIBM Wars (pronounce it as you like, but perhaps not in polite company), but even so I know enough to ask a question: is anyone in possession of a signed, original, genuine, non-electronic copy of the Bill Broderick letter of 23 Jan 2002 that granted a mostly free license (as long as credit given and Caldera's name not used in vain) for 32V, V7, and predecessors? Certainly there are electronic copies around; it existed (perhaps still exists) as a PDF file on Caldera's web site. I have a hardcopy in my own files, next to the old SCO Ancient UNIX Source Code agreement for which I paid hard cash (as we used to call the US dollar). But if there is an original somewhere, that might carry more weight. Is Bill Broderick still in an appropriately high position at Caldera or SCO? Norman Wilson Toronto ON

22 years, 1 month

[pups] Temporary loss of minnie.tuhs.org

by Warren Toomey

All, At 7am on Saturday 31st May (local time), the machine which runs this mailing list will be temporarily shut down as major power and UPS alterations are done in the machine room. I am informed that this should only take 12 hours, but you know what computers and such are like. Therefore, you should expect that this mailing list will be unavailable over the weekend of the 31st May / 1st June. Normal services will be resumed shortly :-) Cheers, Warren

22 years, 1 month

Temporary loss of minnie.tuhs.org

by Warren Toomey

22 years, 1 month

Re: [TUHS] V7 ls -s option

by Aharon Robbins

> From: Dennis Ritchie <dmr(a)plan9.bell-labs.com> > To: tuhs(a)minnie.tuhs.org > Subject: [TUHS] (no subject) > Date: Fri, 23 May 2003 00:10:30 -0400 > > > The V7 ls(1) man page says that the -s option, which prints total > >blocks, includes any indirect blocks. > > >However, the V7 struct stat didn't have the st_blocks member in the > > struct stat, and the code in ls.c uses > > > long > > nblock(size) > > long size; > > { > > return((size+511)>>9); > > } > > >So, is this just a case of the man page being mistaken? > > Yes, it looks like a manual bug. Retrieving > the true number of indirect blocks isn't possible > from the 7th edition stat. I'm not sure when (or by > whom) the st_blocks member was added. Thanks for confirming this. In fact, the V7 calculation is only an approximation in another sense; a file with large holes could generate too large a result. System III doesn't have st_nblocks either. > > While I'm at it, the V7 ls -a option only adds . and .. to the > > list; apparently all other dot files were printed by default. > > When did ls change such that -a applied to all dot files? > > UCB or USL did this (I'm sure which first). > Both tended to use more . files. > > Dennis As already pointed out, earlier Research code only checked the first character for being '.'; I later looked at the V6 ls.c. The System III ls.c is essentially the V7 one, but with comments added, and -l printing both owner and group, with -g and -o to turn off group or owner from -l. Also, support for FIFOs. The nblock() calculation is considerably more complicated, and would seem to actually get the number of indirect blocks. At first glance, it looks though like a file with holes would still confuse it. Nothing like engaging in Software Archeology... :-) Thanks, Arnold

22 years, 1 month

question about V7 ls(1) vs. sys/stat.h and ls.c

by Kirk McKusick

The st_blocks field was first added to the stat structure in 4.2BSD (4.1b really) as part of the overhaul to add the new filesystem. I added it because the variable filesystem blocksize made it difficult to compute the amount of storage dedicated to a file. Kirk McKusick

22 years, 1 month

Re: [TUHS] sco v. ibm

by norman＠nose.cs.utoronto.ca

T. M. Sommers: If [Broderick] was [SCO's or Caldera's] agent, then it doesn't matter what they claim to recognize now; they are bound by his statement. Assuming it can be proven that the statement was officially made, which is why I ask after properly signed hardcopy rather than the PDF file we have all seen. Probably there are documents hidden away in SCO's files--there must have been some paper trail leading to Broderick's letter--but that is likely to be harder to track down from outside. I don't doubt Broderick really wrote that letter, nor that he was authorized to make the statement. But the problem before us isn't truth, it's proof. Norman Wilson Toronto ON

22 years, 1 month

The nameless horror of dotfiles [was (no subject)]

by Dennis Ritchie

The omniscient Norman seems to have nailed me: > Judging by the manuals, Research did it first. In every manual from > 1/e to 6/e, the entry for ls(I) has this description for the -a option: > list all entries; usually those beginning with "." are suppressed I suspect that in v7 (where .thing was indeed listed by default) we decided that since .thing was a real file in the directory it was better to list it instead of hiding it by default. (Seeing . and .. seemed seldom interesting, however). I was solely (and much more recently) responsible for the lack of subject header in my earlier reply. Dennis

22 years, 1 month

(no subject)

by Dennis Ritchie

> The V7 ls(1) man page says that the -s option, which prints total >blocks, includes any indirect blocks. >However, the V7 struct stat didn't have the st_blocks member in the > struct stat, and the code in ls.c uses > long > nblock(size) > long size; > { > return((size+511)>>9); > } >So, is this just a case of the man page being mistaken? Yes, it looks like a manual bug. Retrieving the true number of indirect blocks isn't possible from the 7th edition stat. I'm not sure when (or by whom) the st_blocks member was added. > While I'm at it, the V7 ls -a option only adds . and .. to the > list; apparently all other dot files were printed by default. > When did ls change such that -a applied to all dot files? UCB or USL did this (I'm sure which first). Both tended to use more . files. Dennis

22 years, 1 month

The nameless horror of dotfiles [was (no subject)]

by norman＠nose.cs.utoronto.ca

Dennis Ritchie, on ls discarding all names beginning with .: UCB or USL did this (I'm sure which first). Both tended to use more . files. Judging by the manuals, Research did it first. In every manual from 1/e to 6/e, the entry for ls(I) has this description for the -a option: list all entries; usually those beginning with "." are suppressed I always thought this was just a quick-and-dirty way to skip the . and .. entries; the sort of shortcut that was common in the good old days when everything was written in assembly language. That the USL system kept the old convention probably reflects its PWB heritage; both the latter system and that of Berkeley had already invented lots of configuration files clumsily hidden by putting . at the beginning-- more than ls had options at the time--and I guess they felt it was better to let sleeping dots lie. Incidentally, in 1/e ls(I) had a whopping five options: l, t, a, s, and d, each with the same meaning as now (except that -s is described simply as `give size in blocks for each entry' with nothing about accounting for indirect blocks or other overhead). Who says we haven't made decadence, er, progress over the years? Norman Wilson Toronto ON PS: I've lost track. Did the original Subject: line of this thread of conversation get lost because it began with a dot?

22 years, 1 month

question about V7 ls(1) vs. sys/stat.h and ls.c

by Aharon Robbins

Greetings all. The V7 ls(1) man page says that the -s option, which prints total blocks, includes any indirect blocks. However, the V7 struct stat didn't have the st_blocks member in the struct stat, and the code in ls.c uses long nblock(size) long size; { return((size+511)>>9); } So, is this just a case of the man page being mistaken? When did the struct stat acquire the st_blocks member? While I'm at it, the V7 ls -a option only adds . and .. to the list; apparently all other dot files were printed by default. When did ls change such that -a applied to all dot files? Thanks, Arnold Robbins

22 years, 1 month

Re: [TUHS] question about V7 ls(1) vs. sys/stat.h and ls.c

by msokolov＠ivan.Harhan.ORG

Chris Palmer <chris(a)nodewarrior.org> wrote: > What's with that "511" in there? To divide by N rounding up you first add N-1, then divide by N. MS

22 years, 1 month

Open Source Initiative response to SCO vs. IBM

by Aharon Robbins

A friend passed this URL on to me. I have not read it yet. Principal author is Eric Raymond. http://www.opensource.org/sco-vs-ibm.html Arnold

22 years, 1 month

sco v. ibm

by Phil Garcia

Hi, What do you make of the SCO (Caldera) lawsuit? Does it affect the archive in any way?

22 years, 1 month

RE: [TUHS] sco v. ibm

by Ian King

Reminds me of the old joke about the gnat buzzing around the elephant's nether end, with rape on its mind.... :-) ________________________________ From: tuhs-admin(a)minnie.tuhs.org on behalf of Phil Garcia Sent: Wed 5/21/2003 12:53 PM To: tuhs(a)tuhs.org Subject: [TUHS] sco v. ibm Hi, What do you make of the SCO (Caldera) lawsuit? Does it affect the archive in any way? _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 1 month

[pups] Re: Concurrent Pascal, Solo OS, et al

by Al Kossow

I was given a disc image of the system for the PDP11 I'll try to dig it up for you.

22 years, 1 month

[pups] Fwd: Re: Concurrent Pascal, Solo OS, et al

by Wesley Parish

I asked Per Brinch Hansen recently about Solo and Concurrent Pascal, for use on the PDP 11 simulators, et al, and I received a reply today. This is it. I am wondering, does anyone have any clue as to where these copies of the system might be squirrelled away? How many might've seen it at their Universities? Wesley Parish ---------- Forwarded Message ---------- Subject: Re: Concurrent Pascal, Solo OS, et al Date: Sun, 18 May 2003 00:17:33 -0400 From: Per Brinch Hansen <pbh(a)pothos.syr.edu> To: Wesley Parish <wes.parish(a)paradise.net.nz> Cc: Per Brinch Hansen <pbh(a)pothos.syr.edu> Date: 18 May 2003 To: Wesley Parish <wes.parish(a)paradise.net.nz> From: Per Brinch Hansen <pbh(a)pothos.syr.edu> Subject: Re: Concurrent Pascal, Solo OS, et al On May 4, you wrote: What I was wondering is, would it be worth asking you about the possibility of your releasing the Concurrent Pascal, Solo OS and several other such computer tools and programs, to PUPS (the PDP Unix Preservation Society)? At Caltech we prepared a distribution tape for the PDP 11/45 with the source text and portable code of the Solo system, including the Concurrent and Sequential Pascal compiler. The system reports were supplemented by implementation notes. By the spring of 1976 we had distributed the system to 75 companies and 100 universities in 21 countries. Later, other people moved the system to the Interdata 8/32, NCR 8250, Modular 1, LSI 11, IBM 370/145 and many other computers. Sad to say, I no longer have a copy of the system (and I don't know who does). Per Brinch Hansen ------------------------------------------------------- -- Mau e ki, "He aha te mea nui?" You ask, "What is the most important thing?" Maku e ki, "He tangata, he tangata, he tangata." I reply, "It is people, it is people, it is people."

22 years, 1 month

Looking for obscure unix information

by Apostolos Koutropoulos

Hi to all, I stumbled on your mailing list and I thought this would be a good place to pose my question. I was looking around for information about several little known (to me) unix derived Oses. AMIX (Amiga Unix) RISCiX ArchBSD Lynx Inferno Helios What I am looking for is basically what versions existed and when they were released, and also from where did they originate. For instance I know that RISCiX originated from BSD 4.4 but that is all I know. I also know that inferno grew out of the research for plan 9, but what version of plan 9 it evolved from I don¹t know. Anyone know the above info? If not any idea where I can look for further info? Thanks :)

22 years, 1 month

Re: [pups] Tektronix 8560 with PDP-11/23 CPU running TNIX (UINX)

by David W. Talmage

>I got a "Tektronix 8560 Multi-User Software Development Unit" together >with a Tektronix 8540 in system 68k CPU emulator. The 8560 is based on I found this by Googling for "tnix single-user": http://minnie.tuhs.org/pipermail/pups/1998-March/000027.html

22 years, 2 months

[pups] Tektronix 8560 with PDP-11/23 CPU running TNIX (UINX)

by Jochen Kunz

Hi. I got a "Tektronix 8560 Multi-User Software Development Unit" together with a Tektronix 8540 in system 68k CPU emulator. The 8560 is based on the DEC M8186 PDP-11/23 CPU module but that card is the one and only DEC part in the machine. Everything else is from Tektronix. There is a 35 MB 8" disk and a 8" floppy in the 8560 and it runs some flavor of UNIX called TNIX. I am trying to break into it currently, as I have no passwords. I can't get it to single user mode and I have no distribution media nor no stand alone tools. Has someone heared from this machine bevore? Has someone distribution media or stand alone tools? -- tschüß, Jochen Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/

22 years, 2 months

RE: [pups] Restoring volumes

by Gregg C Levine

Hello again from Gregg C Levine Yes, Ian. That's exactly what I mean. Of course I was thinking of RL02 images, rather then a RK05 image. Which one did you choose? And can you post something explaining the steps? And your response was the simpler form, which is what I wanted. David's comment was a bit obtuse, but I got it. By the way? Are you a WB fan? As in Warner Bros. Animation. I'm partial to the wisdom of B. Bunny. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) Sign on the side of a transport belonging to the Rebel Alliance, "Force happens". > -----Original Message----- > From: Ian King [mailto:iking@killthewabbit.org] > Sent: Thursday, May 01, 2003 1:34 AM > To: Gregg C Levine > Subject: Re: [pups] Restoring volumes > > That's where I got my RK05 image for UNIX v6, which I run on my 11/34. Is > that what you're asking, or am I being simple? -- Ian > > ----- Original Message ----- > From: "Gregg C Levine" <hansolofalcon(a)worldnet.att.net> > To: <pups(a)minnie.tuhs.org> > Sent: Wednesday, April 30, 2003 8:35 PM > Subject: [pups] Restoring volumes > > > Hello again from Gregg C Levine > Just for the sake of an argument, has anyone actually managed to > restore a volume from the collection on the ftp server, back to an > originally sized disk pack? Or for that matter restored a system so > that it behaves as advertised under E-11? > > No, folks that machine I "have on order", has not arrived. Once again > I am searching for information for a future project. One that might be > happening sometime this week, or even later this month. > ------------------- > Gregg C Levine hansolofalcon(a)worldnet.att.net > ------------------------------------------------------------ > "The Force will be with you...Always." Obi-Wan Kenobi > "Use the Force, Luke." Obi-Wan Kenobi > (This company dedicates this E-Mail to General Obi-Wan Kenobi ) > (This company dedicates this E-Mail to Master Yoda )

22 years, 2 months

Re: Re: [pups] 2.11BSD device config trouble

by msokolov＠ivan.Harhan.ORG

Norman Wilson <norman(a)nose.cs.utoronto.ca> wrote: > This convenience was abolished in either 4.2 or 4.3 (I am > travelling right now and cannot check manuals and > sources). I don't remember the details in my head and I'm also typing this on the go, but in 4.3BSD fsck does work on the block device and then you reboot with, well, reboot, and it works. MS

22 years, 2 months

Re: Re: [pups] 2.11BSD device config trouble

by Norman Wilson

Carl Lowenstein: Isn't this really true of Unix systems of any age, when doing fsck on a mounted root file system? Some middle-elderly BSD systems--4.1 and possibly 4.0-- managed the buffer pool in such a way that the super-block of a mounted file system was kept in the original buffer, with device and block number correctly stored in the struct buf header. Hence if fsck wrote to the block device rather than the raw one, the super-block came out right even when checking a mounted file system; in particular there was no need to reboot. This convenience was abolished in either 4.2 or 4.3 (I am travelling right now and cannot check manuals and sources). I never quite understood why, though I never looked at the source code in the later systems. The scheme found in most current systems, in which the root starts out read-only, is a better idea anyway. Norman Wilson Toronto ON (normally)

22 years, 2 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