TUHS December 2017

tuhs@tuhs.org

82 participants
93 discussions

by jnc＠mercury.lcs.mit.edu

Heh, my V6 machine thinks (via 'date') that today is _Monday_, December 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the date code is probably missing the '400 year' exception. Noel

6 years, 4 months

shell PS1/PS2 which survive cut-paste

by George Michaelson

I tried a long time ago to set PS1 and PS2 to character sequences which would permit cut-paste to work. I failed, but I didn't try very hard. The choice of "# " and "> " interests me. Because roots prompt of "hash" has a side effect of making a cut-paste over it a comment in most shells. But.. it predates being *able* to cut-paste so it has to be a side-effect, not a design choice. "> " is more dangerous in cut-paste. Which again feels like a side-effect both by anachronistic time effects, and intent: nobody would be that suicidally mad to make cut-paste invoke shell pre-forming the command sequence which neccessarily zeros out the > targets before executing the cmd... -G

6 years, 4 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Arnold > One would think that SIMH I'm using Ersatz-11... > into the simulated computer's time of day clock. What Time of Day clock? We're talking PDP-11's here! :-) The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure none of their others did. And of course V6 long pre-dated the /93-94. Noel

6 years, 4 months

Re: [TUHS] Date madness

by Doug McIlroy

>>> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. >> >> Easy, but perhaps unwise. The sign bit is a potential escape hatch for >> times, just as it is for characters in UTF-8. > > I'm not sure what you're suggesting - UTF-8 works because it's a variable length encoding - a variable length timestamp might be interesting as an academic exercise, but there's no way for time() to specify how much space is needed, or be informed of how much space is allocated Like UTF-8, a variable-length time would be something normal programs aren't supposed to see--it would be a format for external media (i.e. file systems). Times in inodes would be variable-length. Times returned by stat() and time() would be full length. Only the kernel needs to know the encoding. One may note that inodes already use a variable-length encoding for the list of physical block addresses, so there is nothing radical here. I admit, though, that if the kernel can tell "old" from "new" inodes, then they could have different time encodings rather than one variable-length encoding. Doug

6 years, 4 months

Re: [TUHS] Early Clones / Rewrites for TUHS archives

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > It would be nice to have section in TUHS of any early clones that could > be collected. The Unix Tree does have a section for "Unix Clones", and it has Coherent, Xinu, Minix and some early Linuxes. Another one that's missing (although in a different category) is Ultrix-32.> Noel

6 years, 4 months

Partition table rationales?

by Random832

Is there any information on the rationales behind the sizes and positions of the hardcoded partitions in the rp/hp drivers in V6? There are odd gaps of unused space between ones that appear to be intended to be used together (I think I have some pieces of the puzzle worked out below, but not all). For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are 9200 blocks. The hp partitions looked more complicated, but it looks like the manpage is wrong about where partition 2 starts - 84018 vs 48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567 start on 100-cylinder boundaries, but are only a bit over 97 cylinders long - in fact, they are the same length as rp[01]: 203 RP03 cylinders. rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks, making rp[65] and 47 reasonably non-wasteful configurations. Is there something special about 9200 blocks? rp2 and rp3 are that size, and hp1 is that size rounded to the next cylinder. V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set with no wasted space. hp[0145], 016, and 017 are non-overlapping sets.

6 years, 4 months

Re: [TUHS] Date madness

by Doug McIlroy

> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. Easy, but perhaps unwise. The sign bit is a potential escape hatch for times, just as it is for characters in UTF-8. Doug

6 years, 4 months

Difference in purpose of /var/spool vs /var/lib

by Grant Taylor

Can anyone enlighten me on the effective difference in the use of /var/spool vs /var/lib? It's my understanding that spools are for files that are in transit. Effectively like packages moving through a shipping depo or people waiting in line. I.e. they come in, they hang around for a while, and then they leave. I'm of the opinion that files in /var/lib should stick around longer and are not nearly as dynamic (if at all, save for code updates). As sure as I type this, I can't think of a reason library files would go under /var vs a different */lib directory. Does it make any difference if the files are actually executed and / or consumed on the system? I don't consider the POP3 / IMAP / NNTP server to be processing files when people access messages / articles (read: files) via the respective protocols. Back story: I'm considering writing something that will download a file every day and process the last day's / week's / month's file(s) to generate output which is itself stored elsewhere. - I feel like these files should live in the /var/spool/<bla> subdirectory. -- Grant. . . . unix || die

6 years, 4 months

Re: [TUHS] Date madness

by jnc＠mercury.lcs.mit.edu

> From: Tom Ivar Helbekkmo > My /83s have them, but I'm not so sure it's a feature of the CPU board: > there's this thought nagging in the back of my head that the ToY thing > actually sits in the front panel module with the various buttons on it. /83 documentation seems to be very thin on the ground, alas. It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual (EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84 Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a different backplane, with QBUS/UNIBUS converter, so this could equally well be titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock", indicating the 83/84 don't have one. Several companies made after-market ToD clocks to plug into the QBUS, e.g. here: https://www.ebay.com/itm/371284594072 Is something like that what your /83 has? Noel

6 years, 4 months

Other history lists...

by Grant Taylor

Does anyone know of any other similar history discussion mailing lists / newsgroups to discuss things like Mainframes or (Open)VMS? I have some questions as I try to broaden my horizons, but I don't think they fit in the TUHS context. -- Grant. . . . unix || die

6 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 December 2017