TUHS

tuhs@tuhs.org

2 participants
6532 discussions

by jnc＠mercury.lcs.mit.edu

> From: Michael Kjorling > That wouldn't have anything to do with how ^@ is a somewhat common > representation of 000, would it? .. I've always kind of wondered where > that notation came from. Well, CTRL-<*> is usually just the <*> character with the high bits cleared. So, to have a printing representation of NULL, you have two character choices - SPACE, and '@'. Printing "^ " is not so hot, so "^@" is better. Also, if you look at an ASCII table, usually people just take the @-_ column, and use that, since every character in that column has a printing representation. The ' '-? column is missing the ' ', and `-<DEL> is missing the DEL. So if you just take a CTRL character and set the 0100 bit, and print it as "^<char>", you get something readable. (Note that CTRL-' ' _is_ usually used when one needs to _input_ a NUL character.) Noel

8 years, 4 months

Unix stories

by Larry McVoy

Inspired by: > Stephen Bourne after some time wrote a cron job that checked whether an > update in a binary also resulted in an updated man page and otherwise > removed the binary. This is why these programs have man pages. I want to tell a story about working at Sun. I feel like I've sent this but I can't find it in my outbox. If it's a repeat chalk it up to old age. I wanted to work there, they were the Bell Labs of the day, or as close as you could get. I got hired as a contractor through Lachman (anyone remember them?) to do POSIX conformance in SunOS (the 4.x stuff, not that Solaris crap that I hate). As such, I was frequently the last guy to touch any file in the kernel, my fingerprints were everywhere. So when there was a panic, it was frequently laid at my doorstep. So here is how I got a pager and learned about source management. Sun had two guys, who will remain nameless, but they were known as "the SCSI twins". These guys decided, based on feedback that "people can interrupt sun install", to go into the SCSI tape driver and disable SIGINT, in the driver. The kernel model doesn't allow for drivers messing with your signal mask so on exit, sometimes, we would get a "panic: psig". Somehow, I sure was because of the POSIX stuff, I ended up debugging this panic. It had nothing to with me, I'm not a driver person (I've written a few but I pretty much suck at them), but it landed in my lap. Once I figured it out (which was not easy, you had to hit ^C to trigger it so unless you did that, and who does that during an install) I tracked down the code to SCSI twins. No problem, everyone makes mistakes. Oh, wait. Over the next few months I'm tracking down more problems, that were blamed on me since I'm all over the kernel, but came from the twins. Suns integration machines were argon, radon, and krypton. I wrote scripts, awk I think, that watched every update to the tree on all of those machines and if anything came from the SCSI twins the script paged me. That way I could go build and test that kernel and get ahead of the bugs. If I could fix up their bugs before the rest of the team saw it then I wouldn't get blamed for them. I wish I could have figured out something like Steve did that would have made them not screw up so much but this was the next best thing. I actually got bad reviews because of their crap. My boss at the time, Eli Lamb, just said "you are in kadb too much". --lm

8 years, 4 months

Re: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...)

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > The best one seems to have been the 3Com stack, which puts IP in the > kernel and TCP in a daemon. I've gotta get the MIT V6 one online. Incoming demux is in the kernel; all of the TCP, and everything else, is in processes along with the application - one process per application instance. It sounds like it might be clunky, but it's not: there are a couple of different TCP's (a small, low performance one for things like User TELNET, timer servers, yadda-yadda; a bigger, higher-performance one for things like FTP), and the application just calls them as subroutine libraries (effectively). Since there's no IPC overhead, the performance is pretty good. Unfortumately, a lot of the stuff never migrated from personal directories to the system folder, so I have to go curate out the personal files (or, more likely, move them all to a system folder) before I can release it all. > Perhaps economizing on fragmentation and and window management is > better. Fragmentation, perhaps - but good window management is a must. > I wonder if just putting the code for this state in the kernel and > handling only the state changes and other states in a daemon is perhaps > the best split on constrained hardware. I don't think that's a good idea; cutting the TCP in two parts, which have to communicate over an interface is going to be _really_ ugly: do you have one copy of the connection state data (in which case one them has to go through an interface to get to it), or two (synchronization issues). If you want a small kernel footprint, take the MIT approach. Noel

8 years, 4 months

Re: [TUHS] // comment in C++

by Paul McJones

> I'm fairly certain it was originally in BCPL. > > You could just drop a note to Bjarne Stroustrup and ask. :-) On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994), Stroustrup says: “However, only C, Simula, Algol68, an in one case BCPL left noticeable traces in C++ as released in 1985. Simula gave classes, Algol68 operating overloading, references, and the ability to declare variables anywhere in a block, and BCPL gave // comments.” He says a bit more about // comments on page 93, including an example of how they introduced an incompatibility with C.

8 years, 4 months

Re: [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...)

by jnc＠mercury.lcs.mit.edu

> From: Nick Downing > I'm much more of a V7 guy and I think I would find V6 strange and > compromised De gustibus. I used it for many years, and am quite at home in it. I think it's a marvel of functionality/size - at the time it came out, not much bigger than DEC PDP-11 OS's, but with a 'big system' feel to it (which they _definitely_ did not) - in fact, _better_ than most big systems of the day. But I can see it would be rather too simple (and in the kernel inelegant, code-wise, by today's standards - see below) for many. V7 is not that different, in terms of user experience, from V6, though. > I am thinking I will definitely have to apply some of these patches, or > at least check how much they increase the code size by. Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about there is for user commands, not the kernel. There are only a few kernel changes (lseek() and mdate(), and param.c so that the new 'si' command can get thing from param.h without having to have it compiled in), and they are all small. > But probably my preferred approach is to calculate a patch V6 -> Mini > Unix or V6 -> LSX and then try to apply that on top of V7. I'm a little confused as to what your goal is here. Get V6 running on some other architecture? Upgrade V6 for some goal which I am not aware of? I know you probably said something in an earlier email, sorry, I don't recall. Anyway, if you're going to do anything with V6 kernel code, you need to be aware that it's really idiosyncratic - a lot of its written in a very early dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int a = 1' are pretty easy to fix, there are lots of intances of int's being used as pointers to several different kinds of structures, etc, etc. If you want to move an early, small Unix to something other than a PDP-11, V7 is probably a much better bet. > As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this > is adviseable, as I was saying earlier I think it might be best to keep > that functionality outboard from the kernel. There are a couple of early TCP/IP's which ran outside the kernel, but I think the standard Berkeley one might be a handful to move out. Noel

8 years, 4 months

Re: [TUHS] Early Internet work

by jnc＠mercury.lcs.mit.edu

> From: Charles Anthony > Sigh. That tops my Multics bug report. No way! You actually got the fix approved by an MCB! Much cooler! :-) > BSD4.1 is circa 1890? Well, it's old, but not _that_ old!! :-) Noel

8 years, 4 months

Re: [TUHS] Early Internet work

by jnc＠mercury.lcs.mit.edu

> Hi, we just read the second tape, which read without error. > ... > So at this point we have access to everything that was on that machine. So, in the process of transferring this all to a TAR file, we found a bug in BSD 4.1b. (The length of some directories whose last sector held only one entry was being incorrectly set to the actual length of the directory, not a multiple of the sector size.) Anyone know where I can report a BSD 4.1b bug? :-) Noel PS: Although the Algol-60 isn't there, there is a nice LISP (good enough to run The Doctor ... :-)

8 years, 4 months

Re: [TUHS] Early Internet work

by jnc＠mercury.lcs.mit.edu

> From: Nick Downing > is it possible for you to read the other tapes also? Hi, we just read the second tape, which read without error. It appears to be mostly the same stuff as the first, except that for some not-now-understood reason, a lot of the sub-directories in /src/src (the directory that held most of the sources) weren't there on the _first_ tape, but _are_ there on the _second_. So at this point we have access to everything that was on that machine. It's too long a list to go through, but here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/csr2_edfiles.txt is an edited list of the files on the machine. Most of /usr/ has been deleted, since it contains a lot of personal files, the names of which I don't wish to make public. Alas, some of the code (e.g. the much of the MIT TCP/IP) was in some personal directories; it will take me a while to curate all that. Also, this machine did not contain everything that was done at MIT: one particularly saddening lacuna is that the Algol-60 (written for the 'Intro to programming for CS majors' course, 6.031 to those for whom that means anything) isn't there, along with its documentation. With that being _such_ an incredibly influential language, I'd really wanted to see a PDP-11 version made available. There's also an APL, and some missing subdirectories in the BCPL source directory ('henke', 'richards' and 'tenex'). Etc, etc. I have reached out to people at MIT, to see if a tape backup from the machine where all that was can be found; I will keep you all posted if anything shows up. > I would be particularly interested in the early 8080 compiler Yes, that's there ('c8080'), but object-only - it may have been something that was purchased from an outside vendor. There does seem like there might be an 8080-back end for the BCPL compiler. Noel

8 years, 4 months

Re: [TUHS] Early Internet work (Was: History of select(2))

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > Great! I'd love to take a look at all that. OK, it'll all be appearing once we have a chance to get organized (it's all mixed in with personal files). > That is very interesting. It may be related to the V6 with NCP from > UoI/DTI. I think it _is_ the V6 from UoI/DTI. The source has Gary (?) Grossman's and Steve Holmgren's name on it, and the headers say they date from 1074-75. > The printout does not have the kernel modifications with it, so it would > be great if your archive does include that. The archive does include the complete kernel, but i) the changes aren't listed in any way (I forsee a lot of 'diffs', unless you just take the entire kernel), ii) there's a file called 'history' which contains a long list of general changes/improvements of the kernel not really related to TCP/IP, by a long list of people, dated from the middle of '78 to the middle of '79. So it looks like he started with a considerably modified system. The only client code I see is User Telnet. (The MIT code has User and Server Telnet and FTP, as well as SMTP, but it uses a wholly different TCP interface.) Noel

8 years, 4 months

How Unix brings people together, or it's a small world

by David

Side story on Unix related to Xview. I go to a conference in San Jose for Sun users in the mid 80’s and am discussing Xview with a few folks (names lost to memory). A very nice person named Nancy Blackman walks up and joins the discussion. We get to talking and she has a weird memory bug and I’m willing to help her look at it. So we go to ‘her place’ which is her lab at Moffet field. We discuss her bug, find a fix and I go back home to San Diego. I mention that I met this very nice lady named Nancy Blackman at the conference to my wife. Turns out my wife went to school with Nancy before she moved to San Diego. So, who else has weird stories of how Unix development or Unix conferences had the side effect of making the world a smaller place. If this is too off topic, drop the conversation here. David > On Feb 1, 2017, at 1:52 PM, tuhs-request(a)minnie.tuhs.org wrote: > > Date: Wed, 1 Feb 2017 13:40:11 -0800 > From: Larry McVoy <lm(a)mcvoy.com> > To: Noel Chiappa <jnc(a)mercury.lcs.mit.edu> > Cc: tuhs(a)minnie.tuhs.org > Subject: Re: [TUHS] shared memory on Unix > Message-ID: <20170201214011.GG880(a)mcvoy.com> > Content-Type: text/plain; charset=us-ascii > > On Wed, Feb 01, 2017 at 02:44:34PM -0500, Noel Chiappa wrote: >>> From: "Steve Johnson" >> >>> The meetings went on for over a year, but _I NEVER MET WITH THE SAME >>> PERSON TWICE!_ It seemed that the only thing the marketing group knew >>> how to do was reorganize the marketing group... >> >> Shades of SI:Electric-Marketing (I _think_ that was its name) on the Symbolics >> LISP Machine... >> >> (For those who never had the joy of seeing this, it randomly drew a bunch of >> boxes with people in them on the screen in a hierarchy, connected them, and >> then started randomly moving the boxes around... I wonder if the source >> still exists - or, better yet, a video of it running? Probably not, alas.) > > Sun had reorgtool (orgtool) that had all the high up people down to > directors I think and you pushed a button and it reshuffled them. > It was a Xview app, anyone remember that toolkit (I sorta miss it). > > --lm

8 years, 4 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