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
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
> 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
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
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
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
> 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
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?
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
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
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."
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 :)
>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
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/
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 )
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
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)
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 )
Sign on the side of a transport belonging to the Rebel Alliance,
"Force happens".
Hi -
> From: Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de>
> As already mentioned: If I add comments at the end of the lines it
> cn 1 176540 344 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)
> cn 2 176550 354 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)
> cn 3 176560 364 5 cnrint cnxint # kl/dl-11 (on mvx11-aa)
> cn 1 csr 176540 vector 344 attached
> cn 2 csr 176550 vector 354 attached
> cn 3 csr 176560 vector 364 attached
> Sounds like a funny bug?
Yes, it does. A bug in the parsing. Why it does not affect all
the lines is unknown. Perhaps some trailing whitespace caused the
parser to exhibit the bug.
> But if I try to use /dev/ttyl1 I get a message about a unknown interrupt
> and the output of /dev/ttyl1 hangs after the first character.
What is the exact message? I did a "strings /unix" and could not
not find a string that looked mentioned unknown or interrupt.
That would seem to indicate that the device is interrupting but not
at the expected vector.
It is possible to use 'adb' to look at the contents of the vectors.
adb -k /unix /dev/kmem
0344/o
will show the contents of the 0344 vector. The value there should
be equal to 'cnrint' (or cnxint - I forget which comes first).
> I have a M3106 DZQ11 that I can use instead.
Definitely worth trying.
> The DHV is a DEC M3104:
> dhv ? csr 160440 vector 310 didn't interrupt.
> The DL11 card is a clone made by Sigma.
Ah, ok. Thanks for the correction. I misread the initial mail item.
> > 'halt' button?
> [...]
> Noticed that already. I am really not used to Unix stuff of that age.
:)
I did the the same thing - wondered why I could never get a clean
file system. Then I realized what was going on.
Cheers,
Steven Schultz
Hi -
> From: Carl Lowenstein <cdl(a)mpl.ucsd.edu>
> > > > 'halt' button?
> > > [...]
> >
> > I did the the same thing - wondered why I could never get a clean
> > file system. Then I realized what was going on.
>
> Isn't this really true of Unix systems of any age, when doing fsck
> on a mounted root file system?
Not really. Newer systems mount the root filesystem read-only
while running fsck. After the filesystem is verified as clean
then it is upgraded to read-write.
Older systems such as 2BSD can't run with a read-only root
filesystem that I know of. At least not easily/happily. Might be
possible (the ability to upgrade a ro mount to rw is present) but
it's never been a priority to look into it ;)
Cheers,
Steven Schultz
> From: "Steven M. Schultz" <sms(a)2BSD.COM>
> To: pups(a)minnie.tuhs.org
> Subject: Re: [pups] 2.11BSD device config trouble
> Date: Wed, 30 Apr 2003 11:43:11 -0700 (PDT)
>
> Hi -
>
> > From: Jochen Kunz <jkunz(a)unixag-kl.fh-kl.de>
>
> > > 'halt' button?
> > [...]
> > Noticed that already. I am really not used to Unix stuff of that age.
>
> :)
>
> I did the the same thing - wondered why I could never get a clean
> file system. Then I realized what was going on.
Isn't this really true of Unix systems of any age, when doing fsck
on a mounted root file system?
carl
