- TUHS - www.tuhs.org

by jnc＠mercury.lcs.mit.edu

> From: Jacob Ritorto <jacob.ritorto(a)gmail.com> > System III only supports rl01, not rl02 Really? That seems odd; SysII long post-dates (I think) the RL0x, if so it's odd they only supported the RL01. Looking at: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SysIII/usr/src/uts/pdp11/io/… it seems to support RL02's: #define RL02 0200 /* bit 7 indicates an rl02 present if set */ > Would anyone know if it's trivial to modify the source for the rl01 > driver to just add double the blocks The only difference between the two is that the RL02 has twice as many cylinders, so there's an extra bit in use on the high end of the 'disk address' register. > From: Clem cole <clemc(a)ccc.com> > Also if you have a 40 class system like the 34 of 34A see if you can > find an Able Enable board. I'm sure there are a stack of them stored away with Jimmy Hoffa's body and the Ark of the Covenant in King Solomon's Mine! :-) Seriously, if anyone has one, I'd pay a very substantial sum for it. Noel

6 years, 7 months

1
0
0 0

IBM Mach 3.0 Ports

by Kevin Bowling

Does anyone have these documents or the ports themselves? Or know who to talk to so they can be preserved? https://www.cs.cmu.edu/afs/cs/project/mach/public/FAQ/rs6k_announce Regards, Kevin

6 years, 7 months

2
2
0 0

Anyone have any luck trying to contact Micro Focus regarding Unix licensing?

by jsteve＠superglobalmegacorp.com

I've tried calling, emails to sales, using their website and I'm getting nowhere. I know this is more complicated than v6’s context switching …. I've also read that apparently Microsoft swooped in 2010 acting as CPTN Holdings and bought all the Novell patents and turned them over to GPL v2? I know after the whole SCO personal licenses and then Ransom Loves’s making 32v and all prior open was great but apparently it wasn’t his to give away. Or am I wrong? Are Unix licenses transferrable? Anyone know someone wanting to lease/loan/sell? I don't want to kick up too much of the hornets nest. I'd just hate to think that the original Unix is going to languish. I know many people worked so hard to keep the “Unix lights on”, just want to see that it doesn't die clouded in secrecy like VMS.

6 years, 7 months

2
1
0 0

Ultrix Tape: Block Size?

by Warren Toomey

All, I received this request from Matthew who isn't subscribed to either the TUHS or cctalk lists. He knows how to read the lists archives. Many thanks for any help you can provide. Cheers, Warren ----- Forwarded message from Matthew Whitehead ----- Date: Mon, 15 Oct 2018 08:25:39 -0400 From: Matthew Whitehead Subject: Ultrix Tape Blocks Warren, I wonder if you can give me a referral. I want to install Ultrix-32 on my MicroVAX II using the ancient TK-50 tape drive. I know the tape files are on your archive, but I need to know the block size for each of the many files; it can vary a lot. Who might be able to help me with this? Matthew Whitehead ----- End forwarded message -----

6 years, 7 months

7
10
0 0

Re: [TUHS] Alan Snyder's portable C compiler

by jnc＠mercury.lcs.mit.edu

> From: Lars Brinkhoff > I have Alan Snyder's C compiler running Way cool! Congrats! Where did you find it? Do you have source too? > there may also be machine descriptions for Honeywell 6000 series and > PDP-11 There _was_ one for the H6000, not sure about the -11. > At some point it seems like this compiler was tangled with Stephen > Johnson's PCC. It would be good to find out what, if any, the connection is. Noel

6 years, 7 months

1
0
0 0

Alan Snyder's portable C compiler

by Lars Brinkhoff

Hello, I have Alan Snyder's C compiler running in case anyone would like to play with it. It's from around 1975, so the syntax is yummily archaic. The primary host is a PDP-10 running ITS, but there may also be machine descriptions for Honeywell 6000 series and PDP-11. At some point it seems like this compiler was tangled with Stephen Johnson's PCC.

6 years, 7 months

1
0
0 0

In memoriam: Ken Iverson

by Dave Horsfall

We lost Ken Iverson on this day in 2004; a Canadian mathematician and computer scientist, he gave us APL (and its obscure one-liners). -- Dave

6 years, 7 months

1
0
0 0

Vaxen, my children...

by Dave Horsfall

Time to post this classic; I don't recall who wrote it. Note that the references are pretty obscure now... ----- VAXen, my children, just don't belong some places. In my business, I am frequently called by small sites and startups having VAX problems. So when a friend of mine in an Extremely Large Financial Institution (ELFI) called me one day to ask for help, I was intrigued because this outfit is a really major VAX user - they have several large herds of VAXen - and plenty of sharp VAXherds to take care of them. So I went to see what sort of an ELFI mess they had gotten into. It seems they had shoved a small 750 with two RA60s running a single application, PC style, into a data center with two IBM 3090s and just about all the rest of the disk drives in the world. The computer room was so big it had three street addresses. The operators had only IBM experience and, to quote my friend, they were having "a little trouble adjusting to the VAX", were a bit hostile towards it and probably needed some help with system management. Hmmm, hostility... Sigh. Well, I thought it was pretty ridiculous for an outfit with all that VAX muscle elsewhere to isolate a dinky old 750 in their Big Blue Country, and said so bluntly. But my friend patiently explained that although small, it was an "extremely sensitive and confidential application." It seems that the 750 had originally been properly clustered with the rest of a herd and in the care of one of their best VAXherds. But the trouble started when the Chief User went to visit his computer and its VAXherd. He came away visibly disturbed and immediately complained to the ELFI's Director of Data Processing that, "There are some very strange people in there with the computers." Now since this user person was the Comptroller of this Extremely Large Financial Institution, the 750 had been promptly hustled over to the IBM data center which the Comptroller said, "was a more suitable place." The people there wore shirts and ties and didn't wear head bands or cowboy hats. So my friend introduced me to the Comptroller, who turned out to be five feet tall, 85 and a former gnome of Zurich. He had a young apprentice gnome who was about 65. The two gnomes interviewed me in whispers for about an hour before they decided my modes of dress and speech were suitable for managing their system and I got the assignment. There was some confusion, understandably, when I explained that I would immediately establish a procedure for nightly backups. The senior gnome seemed to think I was going to put the computer in reverse, but the apprentice's son had an IBM PC and he quickly whispered that "backup" meant making a copy of a program borrowed from a friend and why was I doing that? Sigh. I was shortly introduced to the manager of the IBM data center, who greeted me with joy and anything but hostility. And the operators really weren't hostile - it just seemed that way. It's like the driver of a Mack 18 wheeler, with a condo behind the cab, who was doing 75 when he ran over a moped doing its best to get away at 45. He explained sadly, "I really warn't mad at mopeds but to keep from runnin' over that'n, I'da had to slow down or change lanes!" Now the only operation they had figured out how to do on the 750 was reboot it. This was their universal cure for any and all problems. After all it works on a PC, why not a VAX? Was there a difference? Sigh. But I smiled and said, "No sweat, I'll train you. The first command you learn is HELP" and proceeded to type it in on the console terminal. So the data center manager, the shift supervisor and the eight day-operators watched the LA100 buzz out the usual introductory text. When it finished they turned to me with expectant faces and I said in an avuncular manner, "This is your most important command!" The shift supervisor stepped forward and studied the text for about a minute. He then turned with a very puzzled expression on his face and asked, "What do you use it for?" Sigh. Well, I tried everything. I trained and I put the doc set on shelves by the 750 and I wrote a special 40 page doc set and then a four page doc set. I designed all kinds of command files to make complex operations into simple foreign commands and I taped a list of these simplified commands to the top of the VAX. The most successful move was adding my home phone number. The cheat sheets taped on the top of the CPU cabinet needed continual maintenance, however. It seems the VAX was in the quietest part of the data center, over behind the scratch tape racks. The operators ate lunch on the CPU cabinet and the sheets quickly became coated with pizza drippings, etc. But still the most used solution to hangups was a reboot and I gradually got things organized so that during the day when the gnomes were using the system, the operators didn't have to touch it. This smoothed things out a lot. Meanwhile, the data center was getting new TV security cameras, a halon gas fire extinguisher system and an immortal power source. The data center manager apologized because the VAX had not been foreseen in the plan and so could not be connected to immortal power. The VAX and I felt a little rejected but I made sure that booting on power recovery was working right. At least it would get going again quickly when power came back. Anyway, as a consolation prize, the data center manager said he would have one of the security cameras adjusted to cover the VAX. I thought to myself, "Great, now we can have 24 hour video tapes of the operators eating Chinese takeout on the CPU." I resolved to get a piece of plastic to cover the cheat sheets. One day, the apprentice gnome called to whisper that the senior was going to give an extremely important demonstration. Now I must explain that what the 750 was really doing was holding our National Debt. The Reagan administration had decided to privatize it and had quietly put it out for bid. My Extreme Large Financial Institution had won the bid for it and was, as ELFIs are wont to do, making an absolute bundle on the float. On Monday the Comptroller was going to demonstrate to the board of directors how he could move a trillion dollars from Switzerland to the Bahamas. The apprentice whispered, "Would you please look in on our computer? I'm sure everything will be fine, sir, but we will feel better if you are present. I'm sure you understand?" I did. Monday morning, I got there about five hours before the scheduled demo to check things over. Everything was cool. I was chatting with the shift supervisor and about to go upstairs to the Comptroller's office. Suddenly there was a power failure. The emergency lighting came on and the immortal power system took over the load of the IBM 3090s. They continued smoothly, but of course the VAX, still on city power, died. Everyone smiled and the dead 750 was no big deal because it was 7 AM and gnomes don't work before 10 AM. I began worrying about whether I could beg some immortal power from the data center manager in case this was a long outage. Immortal power in this system comes from storage batteries for the first five minutes of an outage. Promptly at one minute into the outage we hear the gas turbine powered generator in the sub-basement under us automatically start up getting ready to take the load on the fifth minute. We all beam at each other. At two minutes into the outage we hear the whine of the backup gas turbine generator starting. The 3090s and all those disk drives are doing just fine. Business as usual. The VAX is dead as a door nail but what the hell. At precisely five minutes into the outage, just as the gas turbine is taking the load, city power comes back on and the immortal power source commits suicide. Actually it was a double murder and suicide because it took both 3090s with it. So now the whole data center was dead, sort of. The fire alarm system had its own battery backup and was still alive. The lead acid storage batteries of the immortal power system had been discharging at a furious rate keeping all those big blue boxes running and there was a significant amount of sulfuric acid vapor. Nothing actually caught fire but the smoke detectors were convinced it had. The fire alarm klaxon went off and the siren warning of imminent halon gas release was screaming. We started to panic but the data center manager shouted over the din, "Don't worry, the halon system failed its acceptance test last week. It's disabled and nothing will happen." He was half right, the primary halon system indeed failed to discharge. But the secondary halon system observed that the primary had conked and instantly did its duty, which was to deal with Dire Disasters. It had twice the capacity and six times the discharge rate. Now the ear splitting gas discharge under the raised floor was so massive and fast, it blew about half of the floor tiles up out of their framework. It came up through the floor into a communications rack and blew the cover panels off, decking an operator. Looking out across that vast computer room, we could see the air shimmering as the halon mixed with it. We stampeded for exits to the dying whine of 175 IBM disks. As I was escaping I glanced back at the VAX, on city power, and noticed the usual flickering of the unit select light on its system disk indicating it was happily rebooting. Twelve firemen with air tanks and axes invaded. There were frantic phone calls to the local IBM Field Service office because both the live and backup 3090s were down. About twenty minutes later, seventeen IBM CEs arrived with dozens of boxes and, so help me, a barrel. It seems they knew what to expect when an immortal power source commits murder. In the midst of absolute pandemonium, I crept off to the gnome office and logged on. After extensive checking it was clear that everything was just fine with the VAX and I began to calm down. I called the data center manager's office to tell him the good news. His secretary answered with, "He isn't expected to be available for some time. May I take a message?" I left a slightly smug note to the effect that, unlike some other computers, the VAX was intact and functioning normally. Several hours later, the gnome was whispering his way into a demonstration of how to flick a trillion dollars from country 2 to country 5. He was just coming to the tricky part, where the money had been withdrawn from Switzerland but not yet deposited in the Bahamas. He was proceeding very slowly and the directors were spellbound. I decided I had better check up on the data center. Most of the floor tiles were back in place. IBM had resurrected one of the 3090s and was running tests. What looked like a bucket brigade was working on the other one. The communication rack was still naked and a fireman was standing guard over the immortal power corpse. Life was returning to normal, but the Big Blue Country crew was still pretty shaky. Smiling proudly, I headed back toward the triumphant VAX behind the tape racks where one of the operators was eating a plump jelly bun on the 750 CPU. He saw me coming, turned pale and screamed to the shift supervisor, "Oh my God, we forgot about the VAX!" Then, before I could open my mouth, he rebooted it. It was Monday, 19-Oct-1987. VAXen, my children, just don't belong some places. -- Dave

6 years, 7 months

1
0
0 0

TK50, was: Re: Ultrix Tape: Block Size?

by emanuel stiebler

On 2018-10-16 20:37, Paul Koning via cctalk wrote: > > >> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk <cctalk(a)classiccmp.org> wrote: >> >> DEC Tape II was the serial driven TU58. >> The TK50 was CompacTape or something like that. It was the predecessor of a number of square tapes... >> >> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape >> >> Bill > I used DLT on RSTS systems, with a Qbus interface. Those were modest speed hosts and buses, but I never remember data late or overrun issues, and we drove those tapes quite hard in full time streaming mode for backup and software distribution. Longer blocks, too (2k or so) which would make any buffering issues more severe. Just few words here, as I'm not sure anymore we are talking about the same thing ... there were TK50Z as an external drive, on "SCSI" TZ30 internal drive, on "SCSI", using TK50 tapes TK50 on QBUS with an TQK50 controller which really didn't stream to often TK50 on QBUS with an TQK70 controller, which doubled the memory of the TQK50, which was capable of streaming ...

6 years, 7 months

3
3
0 0

Re: [TUHS] Another one (Was: In memoriam: Jon Postel)

by Nelson H. F. Beebe

For more information on J. C. R. Licklider, see these books Cyber reader ISBN 0-7148-4071-8 The Innovators: How a Group of Hackers, Geniuses and Geeks Created the Digital Revolution ISBN 1-4711-3879-8 The Dream Machine: J. C. R. Licklider and the Revolution That Made Computing Personal ISBN 0-670-89976-3 The computing universe: a journey through a revolution ISBN 0-521-76645-1 Detailed BibTeX entries, with table of contents information, can be found at http://www.math.utah.edu/pub/tex/bib/master.html http://www.math.utah.edu/pub/bibnet/authors/t/turing-alan-mathison.html http://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.html (change .html to .bib for a BibTeX file). A Library of Congress search found another book, by Licklider himself: Libraries of the future xvii + 219 pp Bolt, Beranek, and Newman, Inc., Cambridge, MA (1965) LCCN: Z699 .L5 Given its age and small publisher, I suspect that it may be hard to find; I have not seen it myself. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 7 months

1
0
0 0

In memoriam: Jon Postel

by Dave Horsfall

We lost Jon Postel, regarded as the Father of the Internet (due to his many RFCs) on this day in 1998. -- Dave

6 years, 7 months

2
1
0 0

Paul Allen dead at 65.

by Dan Cross

I just saw this headline. Microsoft co-founder Paul Allen dead of cancer, aged 65. Relevancy to TUHS as Microsoft has been both a competitor to and supporter of both Unix and (much more recently) Linux. Allen also funded the Living Computer Museum in Seattle, where one can log into a real PDP-11/70 running 7th Edition Unix. - Dan C.

6 years, 7 months

3
2
0 0

Paul Allen dead at 65.

by norman＠oclsc.org

Dan Cross: Allen also funded the Living Computer Museum in Seattle, where one can log into a real PDP-11/70 running 7th Edition Unix. And see a real live PDP-7, and many other marvellous artifacts. Their basic idea is to be a museum of history that runs. Well worth a visit when in Seattle. Norman Wilson Toronto ON

6 years, 7 months

1
0
0 0

Re: [TUHS] The origin of /home

by jnc＠mercury.lcs.mit.edu

> From: Norman Wilson > Unfortunately all the quick hacks and poorly-considered tweaks of the > past have long since been cast in stone by widespread convention There seem to be two kind of people in the world; i) those who cannot bring themselves to change anything, and ii) those who change all sort of things, usually with no good reason (perhaps just to be different). The world of Unix seems to be thickly stocked with both. Noel

6 years, 7 months

5
4
0 0

In memoriam: Dennis Ritchie

by Dave Horsfall

Co-inventor of Unix, we lost him in 2011. -- Dave

6 years, 7 months

1
0
0 0

Re: [TUHS] The origin of /home

by Norman Wilson

Dave Horsfall: Before I started using /home (Slowaris had yet to appear), I used /u/* instead (I didn't want to pollute /usr with home directories). === I'm late to the party, but I'll chime in too: The first UNIX system I ever used, ca. 1980, had users' home directories in /u. I suspect it was that way (as suggested in some earlier messages) just for storage management: separate file system from /usr. I've carried /u around with me ever since to other systems I've set up from scratch, except in my home environment where I've made a radical departure: everything that isn't part of the base OS is in a tree rooted at /con, so home directories are /con/u. /con was `constant,' inspired by /var, meaning stuff that should be preserved when the OS is reinstalled--everything else should come from installation media or configuration management. But in any case there's nothing especially novel about moving users' home directories out of /usr, and since it's UNIX, nothing that says there has to be any standard at all. On the systems I am currently paid to help run, most users have home-directory names like /h/u12/c4/00/c4ntest. There is no attempt to glue together a single name hierarchy; we have in excess of 17000 users so that would be something of a mess. (I guess enormous directories aren't the resource pigs they used to be, though symlinks are just as bad as they have ever been.) There's the ~user shell syntax for those who like that; I don't, but I have a little shell script in my personal bin directory so I can do things like ls `home c4ntest`; it all just works. I once thought of writing a paper entitled `/usr and /etc considered harmful,' in which I would have proposed: a. It no longer matters a whit whether the (real) root file system can fit into a 5MB slice of the disk or the like, so just merge everything that spilled into /usr in the tiny-disk days back into the root where it belongs. b. /etc is largely junk. Executables have long since moved into /sbin. Pretty much everything else that's there belongs (according to the original scheme, not the latter-day complications inflicted by those who didn't understand) in /lib. Unfortunately all the quick hacks and poorly-considered tweaks of the past have long since been cast in stone by widespread convention, so it's fruitless to try to clean any of this up. Norman Wilson Toronto ON

6 years, 7 months

6
5
0 0

Re: [TUHS] Software Archeology: QED

by Norman Wilson

Leah Neukirchen: I tried contacting David Tilbrook several times and got no replies. I think some people around Toronto still use qed, but they seem to be very secretive about it. ==== David is likely well-retired by now, but I don't really know. Even though I walk within a block of his house fairly often, we've never really been consistently in touch. But he was responsible for a distinct branch of the qed that originated at the University of Toronto in the late 1970s (same one Rob supplied). Certainly worth tracking down. I don't know your definitions of `people around Toronto' or `secretive.' I still use qed daily; my copy is one I've been carrying around, and occasionally tweaking, since my time at Caltech (where I got it from Rob). I'll send Arnold a copy. I'm really tired both of having to recompile it (and deal with yet another bit of obsolete-C assumption that no previous compiler or C library has shown up) now and then, and with its private variant of regular expressions, so I keep threatening (mainly to myself) to rewrite it in Python, but I have no idea whether I'll ever get around to that. If I do I suspect I'll throw away some of the programmability hooks, which I never use, and perhaps extend it here and there (I really want nesting globals, and they're not that hard to do--I did them in my half-baked personal mail reader, which has an ed-like interface). I don't know offhand of anyone else around Toronto using my branch of qed. I do know of a couple of friends in California, one who left Caltech before I did but is now back there, another elsewhere in Los Angeles, who still use my version at least occasionally. It wouldn't surprise me if there were people around Toronto who use Tilbrook's branch, since it was part of his qef toolkit and he introduced several companies to it when consulting for them; but I don't know of any specifics. None of which is as archaeologically interesting as the non-UNIX qeds, of course. Norman Wilson Toronto ON

6 years, 7 months

1
0
0 0

Cellular Irix

by Kevin Bowling

https://cug.org/5-publications/proceedings_attendee_lists/1998CD/S98PROC/AU… anyone know more about this? Seems like they were thinking about the interesting problems at the time Regards, Kevin

6 years, 7 months

1
0
0 0

The origin of /home

by Cág

Hi, The earliest I've found to be in the FHS from '94. Are there any earlier examples of a home directory being at /home instead of /usr/$(user)? Are there any current Unix systems that don't use /home by default (except OSX)? Does anybody here do it intentionally? Also, what was the rationale of moving the directory to /home? Thanks! -- caóc

6 years, 7 months

19
30
0 0

Unix source code archive in the news

by Nelson H. F. Beebe

I've just finished reading another article in the latest print issue of Communications of the ACM that arrived in my mailbox earlier this week: Jean-Fran{\c{c}}ois Abramatic, Roberto Di Cosmo, and Stefano Zacchiroli Viewpoint: Building the universal archive of source code Comm. ACM 61(20) 29--31 October 2018 https://doi.org/10.1145/3183558 https://dl.acm.org/citation.cfm?doid=3281635.3183558 I draw it to your attention to it because it has favorable mention of the Computer History Museum, and of Diomidis Spinellis's work on the Unix source code archive, described in his article A repository of Unix history and evolution Empirical Software Engineering 22(3) 1372--1404 June 2017 https://doi.org/10.1007/s10664-016-9445-5 https://link.springer.com/article/10.1007/s10664-016-9445-5 The project that Abramatic describe is impressive: a goal of a triplicated complete archive of the world's software history, including both open source and proprietary code. They report holding 200TB of data already, covering 80 million code projects. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 7 months

7
7
0 0

QED editor - thanks!

by arnold＠skeeve.com

Thanks to everyone who replied with tarballs, zip files, pointers to stuff in the archive, web links ... I will try (eventually) to thank everyone individually as well, but in the meantime please accept this broadcast. :-) This has now become Yet Another Back Burner Project; I hope putting things together into a reasonable github repo (or two) will happen without too much of a delay. This is a great group of people! Thanks, Arnold

6 years, 7 months

2
2
0 0

Re: [TUHS] Unix source code archive in the news

by jnc＠mercury.lcs.mit.edu

> From: jsteve > I'd say TripOS. There is some surce fragments but I never could get any > BCPL to cross build anything. I'm somewhat stunned to hear that, given that Martin Richards did both! What kind of things are the compilers complaining about? (And I'm also kind of amazed that Cambridge didn't make an effort to save Tripos.) Noel

6 years, 7 months

3
2
0 0

Re: [TUHS] Software Archeology: QED

by Jeffrey H. Johnson

Might as well send this to the list: There are Multics QEDX sources, but I haven't run across QED - however, there is an overview of it's use and commands in the General Electric June 1969 Multics Condensed Guide (http://bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-g…) I pulled the QEDX source at put it at https://ban.ai/~jhj/misc/qedx/ for easy access - this is the MR12.5 version and last modified in 1989, sadly, I don't ever recall seeing the BCPL QED. [ I'll be sure to remember now if I see it. ] [ Somewhat off-topic ] How about Yale 'Z' as long as we're talking editors? Or another editor (that I very much like) is the 'G' editor, which has a long history, originating on Honeywell 6000 GCOS/TSS, originally written in B: https://github.com/ascheepe/g-editor - works nicely today. There is also the Ecce editor, which includes versions in IMP, BASIC, C, BCPL, and FORTRAN at http://history.dcs.ed.ac.uk/archive/apps/ecce/ - bringing Ecce up on Multics is an item on my todo list. -- Jeff - https://ban.ai/multics/

6 years, 7 months

1
0
0 0

Re: [TUHS] Unix source code archive in the news

by jnc＠mercury.lcs.mit.edu

> From: "Nelson H. F. Beebe" > a goal of a triplicated complete archive of the world's software > history, including both open source and proprietary code. They report > holding 200TB of data already, covering 80 million code projects. I should ask them if they have a copy of MERT! Now that we have Multics, ITS, PDP-7 UNIX and UNIX V0, etc MERT (which may have been the first micro-kernel - although perhaps THE gets that palm) is perhaps the most significant 'missing' OS. If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's been saved.) The THE system? (Ditto - although I know someone has saved the last X8.) The Atlas OS? Noel

6 years, 7 months

3
2
0 0

Re: [TUHS] Unix source code archive in the news

by Paul McJones

> On Oct 6, 2018 ,jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > Date: Sat, 6 Oct 2018 21:04:59 -0400 (EDT) > From: jnc(a)mercury.lcs.mit.edu <mailto:jnc@mercury.lcs.mit.edu> (Noel Chiappa) > Subject: Re: [TUHS] Unix source code archive in the news > Message-ID: <20181007010459.9098E18C096(a)mercury.lcs.mit.edu <mailto:20181007010459.9098E18C096@mercury.lcs.mit.edu>> > > If not, what am I missing? The Berkeley Genie OS for the SDS? (Dunno if that's > been saved.) The THE system? (Ditto - although I know someone has saved the > last X8.) The Atlas OS? The Computer History Museum’s Donald Knuth digital archive project (http://www.computerhistory.org/collections/catalog/102726297 <http://www.computerhistory.org/collections/catalog/102726297>) contains a scan of a listing of the source code of the THE Operating System by Bron, Dijkstra, et al. The finding aid for the collection is here: http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index… <http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index…> — scan down for “Source code of the THE Operating System”.

6 years, 7 months

1
0
0 0

Re: [TUHS] plan9 first edition

by Steve Simon

I can only speak from my experience, but I think there was a more or less official 1st Ed release. in 1993 I was working as a system manager at UNSW I requested and receicved a Plan9 CDROM with about 5 inches of printed manual (but unbound) manual from the labs. Here is some bits and pieces about the Ed1 I scraped together some years ago, including the artwork for the CD :-) https://plan9.io/sources/contrib/steve/historic/1st-edition/ I also believe that the CD contained some music in RedBook form (sadly I never got around to putting the disk in an audio cd drive). If I am right, then this has been reissued. https://bauhaus.bandcamp.com/ Everyone sing along now, Undead undead, undead... -Steve

6 years, 7 months

2
1
0 0

Re: [TUHS] cat -v and other complaints

by Clem Cole

On Wed, Aug 29, 2018 at 1:07 AM Greg 'groggy' Lehey <grog(a)lemis.com> wrote: > On Tuesday, 28 August 2018 at 23:23:10 -0400, Theodore Y. Ts'o wrote: > > On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote: > .... > > > Creeping featurism! > No, I think its really is that many programmers that touch different applications felt the need to pee on the code to feel that they left their scent. 😘 Seriously, IMO the problem is you can never know what someone else really values, so be careful at what you change. Pike's 'cat -v' dissertation b*tched at UCB for the some of the same issues. Somewhere there is a proper middle ground ( I think of as having good taste elegance). BSD nor Linux was no more 'perfect' that 6th or 7th edition. Truth is a much as I pine for the elegance, I don't want to run either of the later as my day-2-day system in today's world and I >>loved<< running them when they were what I had. Rob has a real point and many of the changes really *are gratuitous* and there *are better ways of doing* many things than adding a switch to old command and reusing it because you can. I also think the complaint of just adding 'crap' because you could started with BSD but the cause wasn't that people were bad -- there was address space relief over the PDP-11 and often added a new switch/new functionality was easy to do, instead of creating a whole new solution just deidcated to that problen only. FWIW: sendmail is my best example (useful tool that it was - there were/are much more elegant solutions - sendmail should have been 'headerwriter' and smtpd should have been a seperate program). Dueling switches and functionality (dec vs -f bs -F) I fear is sometimes ignorance of the past. I fear there is some sort of belief we need to shed the past because someone feeld the it gets in the way of the future (I'll pick on my on son here - who things 2-3 years is 'old' and its time to throw things away). Truth is sometimes it might. But I would rather inject a stronger strain into the mix and let the users decide and for good or bad, BSD did that to the original (v6/v7) and now Linux is doing/has done it to much of BSD. The compaint is the 'throwing the baby out with the bath water' behavior that seems to often follow (see systemd issues on other mailing lists); *i.e*. did you really gain something for this huge disruption. To me when something really new/a great innovation comes that should be celebrated. BSD gave us VM and a number of 'useful' new utilities, and eventually an networking API (al biet not everyone liked it, sockets was good enough, solved the problems and became a standard that allowed us to move on). Mach (while Larry may not like the VM implementation), moved the bar for the kernel's handling of memory a huge amount and almost won the uK war (which IMO was a too bad). BTW: other kernels would do nice VM's too, but Mach was generally available (open source if you will and really was the system the moived it forward). That said, I give the Linux folks great credit for the addition of modules was huge and it took BSD and the other UNIX systems a few years really pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX etc.. had something too but again - my comment about being generally available applies). So here is the issue, how to do move the ball forward? BSD, then Linux, became the 'stronger strain' and pushed out the old version. The problem is the ROMs in my fingers (like Dave) never got reprogrammed so some of the 'new' becomes annoying. Will I learned to like systemd? We shall see... Clem

6 years, 7 months

21
44
0 0

plan9 first edition

by Paul Ruizendaal

Somewhat off topic, for which apologies beforehand. I’m looking for source code of Plan9’s first edition. A quick search on Google came up dry. Would that source be publicly available? Or were the licensing restrictions such that it only exists in non-public archives?

6 years, 7 months

2
1
0 0

Re: [TUHS] Original Unix SOSP paper?

by Doug McIlroy

Warren wrote: > I would like to do some work on how the content changed over time. > The result would be, for me, an interesting paper to read but somehow > I think the readership base would be limited :-) "Critical editions", as they are known in literary circles, garner wide respect if not wide readership. Go for it. Incidentally the earliest diff programs I know about date from about 1969. One was by Steve Johnson, specifically for comparing comdecks--compressed assembler source. The other arose in service of critical editions. Doug

6 years, 7 months

1
0
0 0

Original Unix SOSP paper?

by Warren Toomey

All, I just got an e-mail from a TUHS member who would like to lay their hands on a copy of the original Unix SOSP paper: Anyway, I am trying to get my hands on the original 1972/73 paper on The UNIX TIME-SHARING SYSTEM that was published at the SOSP ‘73 Proceedings of the fourth ACM symposium on operating system principles. I do have the 1974 and 1978 reprint papers. But, I really want the 1972/73 original. I see it in the ACM digital library, but the full text PDF prints only the abstract. Does anybody have a scan of the original SOSP paper? I'd also like a copy of the 1974 reprint in CACM. Thanks, Warren

6 years, 7 months

6
9
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by Nelson H. F. Beebe

Noel Chiappa <jnc(a)mercury.lcs.mit.edu> comments on the use of "home directory" on Thu, 27 Sep 2018 19:14:19 -0400 (EDT): >> I _did_ find "home directory" in the ITS documentation; the oldest doc file I >> found it in was dated 5/25/79. If ITS was the source, not sure how it spread - >> maybe via EMACS? I looked in my own TECO code (> 12K lines), and found "home directory" in two files with internal date headers from 1983. I scanned my archive of TOPS-20 emacs source code and found these uses: % grep -i 'home dire' * babyl.info:operating system; this file resides in the user's "home directory" and conv.info:stands for the user's home directory. If neither file exists, the emacs.info:Home Directory Your home directory is the one on which your mail and emacs.info: may be the same as your home directory's name. emacs.mss:@Index{Home Directory}@Index{User Name} emacs.mss:it should be called @ITS{<home directory>;<user name> EVARS instead of EMACS.} emacs.mss:@Index{Home Directory} emacs.mss:EMACS into the file @ITS[<home directory>;TS ESAVE](a)Twenex[ESAVE.EXE] Binary file mkdump.info matches teco.archiv:*) FS U HSNAMEnd FS U MAILllow you to get a user's home directory teco.archiv:* FS HSNAME$ is the user's home directory, as a numeric sixbit word. teco.archiv:On old versions of ITS that don't have home directories, it is the teco.archiv:same as FS MSNAME$. The home directory is (presumably) where such things teco.archiv: B) People whose home directory is a shared directory tecord.info: If you @EJ a file TS FOO on your home directory, then FOO^K tecord.info:FS HSNAME s the user's home directory. The home directory tecord.ref:FS HSNAME user's home directory tecord.ref:FS U HSNAME used to determine a user's home directory Here are the file dates: % grep -l -i 'home dire' * | xargs ls -log -rw-r--r-- 1 51376 Jun 5 1981 babyl.info -rw-r--r-- 1 81689 Oct 16 1981 conv.info -rw-r--r-- 1 466772 Dec 28 1981 emacs.info -rw-r--r-- 1 412673 Oct 16 1981 emacs.mss -rw-r--r-- 1 12570 May 24 1982 mkdump.info -rw-r--r-- 1 121865 Oct 16 1981 teco.archiv -rw-r--r-- 1 225207 Oct 16 1981 tecord.info -rw-r--r-- 1 16407 Dec 28 1981 tecord.ref In another directory named emacs-162, there were 18 files containing "home directory"; the oldest is dated 6-Mar-1980. However, when I dug into teco.archiv, I found that the match occurred in a change log block that begins TECO 699: RMS 10/14/77 Many changes ... ITS only: Thus, 14-Oct-1977 is the earliest date that I can find for "home directory", credited to Richard Stallman. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 7 months

1
0
0 0

Re: [TUHS] The origin of /home

by jnc＠mercury.lcs.mit.edu

> My memory is that the term "home directory" predates /home - perhaps on > other OS's such as TOPS-20, but I don't have time to research that. Well, I looked at the "Introduction to MIT-XX" (a TOPS-20 machine), and it also used the terms "logged-in directory" (home dir) and "connected directory" (current dir). I couldn't find any use of 'home' in the V6 documentation. I _did_ find "home directory" in the ITS documentation; the oldest doc file I found it in was dated 5/25/79. If ITS was the source, not sure how it spread - maybe via EMACS? Noel

6 years, 7 months

2
1
0 0

Re: [TUHS] The origin of /home

by Doug McIlroy

> I couldn't find any use of 'home' in the V6 documentation. $HOME was set by default in v7. It probably dates from the advent of enviroment variables. Doug

6 years, 7 months

1
0
0 0

/home

by Steve Simon

At college we had /h but that may be an interdata/edition7 thing. mine was /h/beng4/ssimon. each course/year was in a separate disk partition - if group filled their partition other groups could still work. -Steve

6 years, 7 months

4
3
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by Norman Wilson

NUXIi s artdamera kfoB le laLobarotirse (A few of you are expected to understand this.) Norman Wilson Toronto ON

6 years, 7 months

1
0
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by Nelson H. F. Beebe

As a followup to discussions on this thread about hardware architectures, some of you may be interested in this new letter published today: Letters to the editor: Hennessy and Patterson on the roots of RISC Comm. ACM 61(10) 6 (2018) https://doi.org/10.1145/3273019 http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf The short two-paragraph letter is from Fred Brooks, noted computer architect, author, and computer scientist. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 7 months

5
5
0 0

Re: [TUHS] The origin of /home

by jnc＠mercury.lcs.mit.edu

> From: Dan Cross > particular in sites with lots of users like universities and > production-focused corporate groups The existence of /usr, /usr/bin, /etc, /lib, etc dates back to the Research group at Bell, so I don't think we can look to these other environments for an explanation. > "Hmm. Well, we've got space in /usr: create /usr/bin I seem to recall reading (don't recall where, OTTOMY) an explanation for the creation of /usr/bin, and I think it was performance related; IIRC the issue was that they wanted to keep the directory size down (both for disk block caching, and search time, reasons). Or maybe that was later on, and it was originally created for 'user-maintained' ancillary programs (another vague memory)? > The more intriguing possibility from the antiquarian point of view is > whether someone coined "/home" and then THAT led to the rise of the "home > directory" nomenclature. My memory is that the term "home directory" predates /home - perhaps on other OS's such as TOPS-20, but I don't have time to research that. (I did look quickly in the Multics docs, and it has 'working directory', i.e. current dir - but it refers to the home dir as 'original WD', i.e. the WD at the time of login.) Noel

6 years, 7 months

2
1
0 0

Re: [TUHS] The origin of /home

by jnc＠mercury.lcs.mit.edu

> From: Jon Forrest > Another reason why the home directory part of /usr was made into /home > is because after doing so, it was possible to mount /usr read-only, and > supply it from a server. The real issue is that /usr contained stuff which wasn't true 'user data' - e.g. /usr/bin. The reasons for that must have seemed good at the time it started, but it was IMO a mistake. (Disgression about partitions, physical packs, etc elided for now.) Noel

6 years, 7 months

1
0
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by Paul Ruizendaal

> Did the 5150 have a UNIX available anywhere near its launch date? I know > that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's > not clear to me whether Xenix ever supported the original PC; were there > other early porting efforts? The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC. Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based on Sys III. This was marketed by IBM. Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0. These versions are a hole in the TUHS archive (unless they are in the confidential archive). It would be wonderful if MS would open up pre-1984 Xenix on the occasion of Unix 50th. These builds would well illustrate the broad Unix portability, which was unique at the time. Paul

6 years, 7 months

2
1
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by jnc＠mercury.lcs.mit.edu

> From: Arthur Krewat > Also, granted, to this day you can still use only 8-bits of a register: Yeah, but that's not totally useless; lots of byte-organized data out there in the world, e.g. ASCII strings. 16-bit data, less so, although there is some in networking protocols (checksums, ports, etc - although the checksums you _compute_ using bigger chunks). (Not a defense of the x86 instruction set, mind!) Noel

6 years, 7 months

4
3
0 0

SPARC is CRAPS spelled backwards.

by Don Hopkins

Its register windows have spilled out into the SCRAP heap of history. But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST PAST. It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST. It can create a CAT SOPRANIST with a CASTRATO SNIP. -Don

6 years, 7 months

11
16
0 0

Fwd: Re: SPARC is CRAPS spelled backwards.

by William Pechter

Should have copied the list... -----Original Message----- From: William Pechter <pechter(a)gmail.com> To: Henry Bent <henry.r.bent(a)gmail.com> Sent: Wed, 26 Sep 2018 11:59 Subject: Re: [TUHS] SPARC is CRAPS spelled backwards. There was Xenix-86 which ran on the AT&T 6300, and IBM PC/XT. I ran it on an 8MHz NEC V30 cpu on the 6300. I would love to install it on my Panasonic Sr. Partner but lost the install key. -----Original Message----- From: Henry Bent <henry.r.bent(a)gmail.com> To: TUHS main list <tuhs(a)minnie.tuhs.org> Sent: Wed, 26 Sep 2018 11:45 Subject: Re: [TUHS] SPARC is CRAPS spelled backwards. On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter(a)rulingia.com> wrote: > > An 8-bit memory bus means half as many RAM chips and buffers. Keep in mind > that the IBM 5150 was intentionally crippled to ensure it didn't compete > with > IBM's low-end minis. > Did the 5150 have a UNIX available anywhere near its launch date? I know that it had DOS, CP/M-86, and the UCSD p-System relatively early on. It's not clear to me whether Xenix ever supported the original PC; were there other early porting efforts? -Henry

6 years, 7 months

1
0
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch > This paper has a nice survey of instruction set densities And the winner is.... the PDP-11! I'm not too surprised by this; back in the days of core memory (and limited, at that - the first PDP-11's came standard with ... 8KB of memory :-), having the denset possible code had real savings. Noel

6 years, 8 months

1
0
0 0

Re: [TUHS] SPARC is CRAPS spelled backwards.

by jnc＠mercury.lcs.mit.edu

> From: Paul Winalski > In general, a CISC instruction set encoding can express the same > algorithm more compactly than a RISC instruction set. I have often pointed to memory bandwidth as one of the key factors in the evolution of CISC and RISC. When it was low, compared to CPU speeds (most of the core era), CISC made sense. When it increased (with DRAM), RISC made more sense, because it allowed CPUs to run faster (via simpler instructions). Caching made the picture a little more complex; and today, with the incredible mismatch between memory speeds and CPU speeds, caching dominates, whether you have RISC or CISC. Noel

6 years, 8 months

1
0
0 0

unix svr1 install docs

by Jacob Ritorto

Hi, I'm hoping to run System V Release 1 on my pdp11/45, provided I can find a controller that'll emulate one of the few disks it supports. I've been looking around trying to find the installation manual to no avail. The programmers manual, user's manual and error manual are all readily available, but nothing about install aside from some anecdotal lines from a simh install. Would anyone have a hint on where to find it or perhaps a real copy to lend? Happy to scan and mail back if so. thx jake

6 years, 8 months

3
5
0 0

Re: [TUHS] [COFF] RetroNet… Virtual is cheap.

by Dave Horsfall

On Sun, 2 Sep 2018, Peter Jeremy wrote: > [2] This is good enough because Australian ISPs don't believe in IPv6 If I go to a site that reports my IP address, I get IPv6 (I have a static IPv4 address), which appears to be the default used by my router (a Fastnet 5355 or something, which T$ appear to be unloading on us). I tried asking T$ for a static IPv6 range, but was unable to find anyone who even knew what I was talking about. -- Dave

6 years, 8 months

1
0
0 0

Happy birthday Dennis Ritchie

by Caipenghui

Today, a great scientist Dennis Ritchie was born, he did too much for humanity! I can't describe him in words, Dennis wishes you a happy birthday! Caipenghui

6 years, 8 months

1
0
0 0

Happy birthday, Dennis Ritchie

by Dave Horsfall

Co-inventor of Unix, and sadly lost to us in 2011, he was born on this day in 1941. Thank you Dennis (and of course Ken), for that wonderful OS that we still use to this day, and imitated by others. -- Dave

6 years, 8 months

1
0
0 0

Re: [TUHS] [TUHS} cat -v and other complaints

by Doug McIlroy

> you can't tell me > this system was designed with the idea of running it using text terminal > and no mouse. There is also no cursor addressing, no curses. The well named Curses and the associated vi were an ugly outgrowth of glass screens--an outgrowth many of us in the Unix lab never adopted. That branch of evolution was unrelated to the Blit branch that essentially preserved the old TTY interface, except that one could have multiple terminals on screen and a mouse was available to give mechanical help for manual cut/paste/edit activities. Plan 9 terminal-handling smoothly continued that evolutionary branch. Mouse support could have been used to take off in a radical direction, but it wasn't. To my mind, the primary innovation in Plan 9 was not terminal support, nor everything-is-a-file. Rather it was an advance in what Vyssotsky called "distributable computing", where components can collaborate in a uniform way, no matter where they are. The key was the 9P protocol that unpacked the notion of file type--a unifying principle that brought simplicity and generality to a diversity of particulars.

6 years, 8 months

4
3
0 0

Public System V UNIX Release 3 (3B2/400) Access

by Seth Morabito

Hello all, I'm beta-testing a service I've set up to allow public access to a network of computers running System V UNIX Release 3.2. This is only tangentially related to RetroNet, and we hope to peer with them once RetroNet has UUCP peering going! The network consists of three emulated 3B2/400s linked by UUCP, and connected to the Internet through a gateway system. E-mail (UUCP, UUCP-to-SMTP, and SMTP-to-UUCP) works in and out of the network. There is a small private Net News setup running BNews for that true historic flair. All machines have access to the "retronet.*" news hierarchy. (There is no public Usenet access, sorry!) If you're interested in reliving some UNIX history, consider signing up for an account. You'll be randomly assigned a home host in the network. Account signup form is here: https://loomcom.net/ Access is via SSH-to-Telnet gateway, by connecting to: $ ssh access(a)loomcom.net (No password is needed for the SSH gateway, it is a captive portal) -Seth -- Seth Morabito Poulsbo, WA web(a)loomcom.com

6 years, 8 months

1
0
0 0

Re: [TUHS] cat -v and other complaints

by Norman Wilson

Andy Kosela: One still cannot ignore the fact that Unix and Plan 9 offer two completely different approaches to displaying text. I admit I've never actually used Plan 9. Can you elaborate on the different approaches? One difference from most of what passes for UNIX these days is probably that the basic terminal model allows one to edit anything on the screen, using the mouse and keyboard and a simple button-2 menu similar to that of sam. You can edit what some program has already printed, then pick it up and send it back as input. You can even edit text in the current line that hasn't been sent yet (because you haven't hit a return yet); in effect the canonical-line part of the tty driver is in the terminal. But you probably don't mean that, both because it's not really such a radical difference, and because it doesn't conflict at all with UNIX. In fact it originated on UNIX, five or six years before Plan 9 was thought of: it's the model from the terminal program in mux, the more-advanced version of the Blit/Jerq window manager that nearly everybody used in 1127 by the time I arrived in 1984. And I still use it every day, even on Linux (and in years past on Solaris and IRIX and Digital UNIX and Ultrix). The modern version of the program to do that is called 9term. It doesn't work quite as well as I'd like on Linux due to changes in the tty driver that make it hard for a program to learn right away when tty modes are changed (in particular when echo is turned off or on), and it does conflict with the GNU readline junk because that turns off canonical processing, but to those of us who have a taste for it it's still just fine. As I say, I don't think that's the difference you mean, so please step in and supersede me. (And feel free to use my referring to something that is part of the latter-day Research editions as an excuse to continue discussing it. I think of Plan 9 as a successor to those systems anyway, and therefore related to UNIX heritage, at least as long as we're comparing and contrasting the systems.) Norman Wilson Toronto ON

6 years, 8 months

2
1
0 0

RetroNet…

by Grant Taylor

On 08/29/2018 07:46 AM, William Pechter wrote: > Also... If you run on the internet remember documented security exploits > are decades old. I recommend no open ports except for ssh if it will > build and maybe UUCP. I'm working on a Retro Computing Networking project with a few other people and I think it would be a benefit for things like running 4.3 BSD and other old OSs in a relatively safe environment. I'm bringing this up on TUSH for two reasons: 1) I think THUS members could benefit from RetroNet 2) I (we) would very much appreciate any suggestions or desires that the THUS community would like to see in such a network. The idea behind RetroNet is two fold: 1) Create a network of interconnected VPNs between interested parties. 2) Provide ISP like services over said interconnections. Our hopes are for RetroNet to be able to provide a sandbox / small pool / isolated network where members can interconnect with each other (if they want to) similar to the Internet, but with much less exposure. (We are planing on RetroNet not having direct Internet connectivity.) We are also hoping and planing to be able to carry any Ethernet based traffic between sites, routed or not. I (we) would be very interested in any input that THUS members might be able to provide. Particularly what you might like to see in such a network. -- Grant. . . . unix || die

6 years, 8 months

20
68
0 0

Re: [TUHS] SunOS code?

by jnc＠mercury.lcs.mit.edu

> From: Warner Losh > The trouble, as I was given to understand when I worked at Solbourne, > was that ... There were a number of third party bits and pieces in there > that could not be relicensed ... if there are other IP issues, not > limited ... It's that quagmire that efforts like this will run up > against. Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they have the ability to grant a licence'. There's no way I'd want them to have to chase down all the corner cases, that's just a way to guarantee it will never happen. I'd want to ask for the bare minimum of time/effort on their part. Anything above that, probably the SCCS stuff would be next on the priority list, sounds like. Noel

6 years, 8 months

16
35
0 0

Re: [TUHS] SunOS code?

by jnc＠mercury.lcs.mit.edu

> From: Henry Bent > just because you can find source (or binaries, or CD images, etc.) on > the internet, that doesn't make it the least bit legal. ... The concept > of "abandonware" has no legal footing whatsoever. True; but if all the copies of a particular item are discarded, one can make all the lawyers on the planet as happy as clams, and it won't do a bit of good. Save the bits, _then_ work out the legal issues, is my thinking on priorities. Noel (PS: 'Internet' is spelled with a capital; there are many internets, but only one Internet, just as there are many white houses, but only one White House. If the technical community, which _does_ understand the difference, can't get it's act together, how can we expect the media, etc, to do the right thing?)

6 years, 8 months

5
5
0 0

Speaking of legality...

by Warner Losh

I have a question... I'm trying to recreate "a" source representation of the Venix for Rainbow that I have. It's a v7 port, and I have all the .o's for it. Most of the .o's compile, with the proper compiler, to the same code that are in the .o's, at least judging from the .c file of the same name in the TUHS archive. The question is, what are the legal ramifications of publishing my reconstruction? Warner

6 years, 8 months

3
3
0 0

Re: [TUHS] Cryptic Unix Commands

by jnc＠mercury.lcs.mit.edu

> From: Norman Wilson > It is just plain wrong to code > kill(9, pid) _All_ uses of magic numbers in numeric form are wrong! Noel

6 years, 8 months

3
2
0 0

Re: [TUHS] Cryptic Unix Commands

by Norman Wilson

Ron Natalie: I use the numbers but I think it stems from the days when kill didn't take the names. It's easier for me to remember -1 and -9 than to remember what the mnemonics are. ==== Me too. And not just the kill command; the (real) shell's trap command too. It's all just muscle memory, not a desire to save keystrokes. On the rare occasions when I need to send a post-modern signal like SIGSTOP or SIGCONT, I use the name. As an aside, why do modern kill and sh accept only the abbreviated form of the signal name, not the full name; e.g. kill -STOP is OK, kill -SIGSTOP an error? When we taught kill about that sometime in (I think) the 9th Edition era at Research, we allowed either form. I think it was Doug who insisted on it, and he was right. All this applies to shell commands, not to programs. It is just plain wrong to code kill(9, pid) in C. Norman Wilson Toronto ON

6 years, 8 months

2
1
0 0

Research UNIX on the AT&T 3B2?

by Seth Morabito

After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong. -Seth -- Seth Morabito Poulsbo, WA web(a)loomcom.com

6 years, 8 months

32
76
0 0

Re: [TUHS] Public access multics

by Doug McIlroy

> Was Algol 60 any kind of viable alternative at the time? The operating system for the Burroughs B5000 had been written in Burroughs Algol. That punctured the widespread belief that OS's were so particular to the hardware that they had to be written in machine language. I don't recall how far Burroughs Algol went beyond Algol 60, nor why Multics did not want to follow that lead. ("Viable" is a slippery concept when choosing among Turing-complete alternatives.) Doug

6 years, 8 months

3
2
0 0

Re: [TUHS] Public access multics

by Doug McIlroy

Caveat: As a member of the PL/I committee, and the person who brought the new and unimplemented language to the attention of Multics, let a disastrous contract for a compiler, and finally helped cobble together a rudimentary compiler that got the project off the ground, I am not exactly an unbiased observer. A ground tenet of Multics was that it would be programmed in a higher level language. A subsidiary requirement, which was generally agreed upon, was language-level access to the logical operators and address manipulation inherent in the hardware. No widely used language of the time met this requirement. And they didn't want to get sidetracked into language design. Discussions finally boiled down to AED, developed at MIT by Doug Ross, and PL/I. Ross was a brilliant software innovator with a mystical outlook that made it difficult to distinguish his vision of what could be done from what actually existed. AED was definitely a moving target. By contrast PL/I had a written spec, so you knew exactly what could be done in it, though not how well the compiler would do it. PL/I was very big; we deliberately (and explicitly) omitted about half the spec. The remainder was definitely seen as a "plausible systems programming language". >From the perspective of the time, why do you think the contrary? Doug

6 years, 8 months

2
1
0 0

Re: [TUHS] Fwd: Public access multics

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > I was thinking that Multics was a failed predecessor of unix > ... straighten me out :) I'd start with: https://multicians.org/myths.html > From: Clem Cole <clemc(a)ccc.com> > https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole Clem, I think that's too limited in scope. Like a lot of 'big' 'failures' (defined in Multics' case as 'failure to grow to significant market share, and continue in the long term'), I don't think Multics 'failed' for a single reason. In general, in large failures, there are a number of causes, all doing their bit. Now, if there are M causes, ranked in priority, maybe the first N1 are _each_ big enough that _any one_ of them could have led to that outcome. Or maybe not; maybe it needed the first N2, all acting in concert. My crystal ball isn't that accurate. But here's my take on _some_ of Multics' main issues. - Management: if you look at: https://multicians.org/hill-mgt.html it's clear that Honeywell top management didn't understand Multics, and didn't understand that it had a long-term potential. They terminated investment in new hardware, and that was what finally killed Multics. - Non-portability: the system was too tied to a specific platform; it couldn't really be moved elsewhere. (E.g. the code is riddled with 'fixed bin 18'; yes, that could be changed with a program to edit the source, but there are lots of dependencies on the specifics of the machine's architecture.) It would be possible to re-write it to run on, say, a 386, but you'd pretty much have to start from scratch. - Built for the wrong future: a key assumption was that people would continue to get their computes from large centralized machines. Clearly, that was wrong (and it played into the issues with Honeywell management)>. Multics _could_ have made the transition to today's 'small' (physically) machines, in which case it would have been really good to have - e.g. if we could run browsers in AIM boxes a lot of malware simply would not be an issue. But the point above prevented that. Those are some of the big ones; I may come up with more. I've CC'd a couple of Multicians - perhaps they can add additional insight. Noel

6 years, 8 months

3
3
0 0

Public access multics

by Will Senn

So, it looks like someone has gone and started running a multics instance: http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html That’s interesting, and y’all may even have been aware of it. But, I was thinking that Multics was a failed predecessor of unix and it’s craziness an inspiration for how unix isn’t multics... straighten me out :) Will Sent from my iPhone

6 years, 8 months

9
10
0 0

UVM VM system

by Larry McVoy

So I just read this https://www.usenix.org/legacy/event/usenix99/full_papers/cranor/cranor.pdf and it looks encouraging. Apparently NetBSD is using it. Does anyone know if they are happy with it? Has FreeBSD considered this? Has anyone benchmarked FreeBSD against NetBSD to see which is faster for VM stuff?

6 years, 8 months

9
12
0 0

Re: [TUHS] Public access multics

by Jeffrey H. Johnson

Greetings, Multics, while not a 'massive' sales success in retrospect, was certainly not the failure commonly believed and wasn't treated as one in the press of the time - at least not until after the decision was made by Honeywell-Bull to phase out the the Multics (and CP-6) products to focus on GCOS - GCOS7/GCOS8 is still a major player today. "Honeywell is having considerable — and surprising — success with the ultra-secure Multics operating system … Besides 3-5 systems within Honeywell, Multics has been installed or committed within Nippon Electric, Rome Air Development Center, USAF Data Services Center, and Ford." from mid-1970's industry press. See also https://multicians.org/myths.html We have about 120 members on BAN - including many original and new Multicians who make the project possible. We're always working on new things and projects - see "pmotd -a" when logged in for some of the most recent activity. I'd be happy to answer any questions on BAN.AI if anyone has particular questions - or just ssh to dps8(a)m.trnsz.com - feel free to use the guest account. I don't want to take the list too off-topic. We have many exclusive features that I hope makes BAN.AI a 'special' (and loved) system, a lot more coming. -- https://ban.ai/multics

6 years, 8 months

1
0
0 0

Re: [TUHS] Public access multics

by jnc＠mercury.lcs.mit.edu

> From: jcs > The real mystery is what it's running on. ... It's=20 probably a > simulator but I've never heard of one for the H6000. Per: https://multicians.org/multics.htmlhttps://multicians.org/multics.html "Harry Reed and Charles Anthony reached a major milestone on the Multics simulator on Saturday 08 November, 2014. Their SIMH-based simulator booted Multics MR 12.5, came to operator command level, entered admin mode, created a small PL/I program, compiled and executed it, and shut down. Release 1.0 of the simulator is now available." Noel

6 years, 8 months

2
1
0 0

Re: [TUHS] TUHS Digest, Vol 34, Issue 4

by Don Hopkins

> On 1 Sep 2018, at 19:18,Warner Losh <imp(a)bsdimp.com <mailto:imp@bsdimp.com>> wrote: > > I recall a more knowledgeable friend complaining about FreeBSD VM in 1994 or so. > > It used to be downright aweful. > That sounds like a GOOD thing: full of awe! At least it wasn’t offal: decomposing animal flesh. -Don

6 years, 8 months

1
0
0 0

Fwd: Public access multics

by Clem Cole

below... On Sat, Sep 1, 2018 at 4:37 PM Will Senn <will.senn(a)gmail.com> wrote: > So, it looks like someone has gone and started running a multics instance: > > http://lists.nycbug.org/pipermail/semibug/2018-August/000288.html > > That’s interesting, and y’all may even have been aware of it. But, I was > thinking that Multics was a failed predecessor of unix and it’s craziness > an inspiration for how unix isn’t multics... straighten me out :) > > https://www.quora.com/Why-did-Unix-succeed-and-not-Multics/answer/Clem-Cole ᐧ ᐧ

6 years, 8 months

1
0
0 0

gopher://ftp.icm.edu.pl/1/vol/rzm2/

by Marcus Merighi

Hello, against my plan to stay under my rock and learn from your messages I now have to speak up, because I stumbled over this: https://bsd.network/@sehnsucht/100635118831337239 which speaks of gopher://ftp.icm.edu.pl/1/vol/rzm2/ (after some puzzled searching for a client I found out that lynx still supports gopher) This site has the following list in its root directory: 4.4BSD-Lite FreeBSD LSI NetBSD OpenBSD UnixArchive ancient-unix desktopbsd dragonflybsd ghostbsd kde kde-applicationdata kś linux-alsa linux-archlinux linux-atm linux-bipv6 linux-blackarch linux-bluehawk linux-cbq.init linux-cryptoapi linux-documentation linux-dret linux-e2compr linux-fido linux-gentoo linux-gentoo-portage linux-inner linux-iproute linux-linos linux-net-tools linux-norlug linux-nvidia linux-nvidia.old linux-nvidia.old2 linux-openvz linux-packware linux-pcmcia linux-radvd linux-raspbian linux-reiserfs linux-rtlinux linux-sgi linux-silo linux-slackware linux-sparc linux-superrescue linux-tsx-11 linux-uk linux-usagi linux-uw-linux linux-vectorlinux linuxberg nexenta openindiana opensolaris pcbsd solaris-10 solaris-cd-fsn solaris-cd-pm solaris_i86pc solaris_sparc sun-fixes sun-patches www.tazenda.demon.co.uk I descended into the OpenBSD directory, where things look quite authentic, at a first glance. Please keep the stories coming, Marcus

6 years, 8 months

1
0
0 0

Re: [TUHS] SunOS code?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The problem is finding some at Oracle that would care Well, I've got a nephew who's been at Oracle for like 20+ years; he can probably point us at the right person. > and finding a proper distribution tape to officially release. Why do we need that? Can't they say 'any and all versions of SunOS', and that term ('SunOS') is sufficiently well defined in real-world documents (e.g. Sun licenses) that that should be 'good enough'. It sounds like the _actual code_ is reasonably available, we wouldn't need Oracle to go looking around for it, would we? Noel

6 years, 8 months

7
15
0 0

Running 4.3 BSD on x86 hardware? Suggestions?

by Gilles Gravier

Hi! If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)... anybody has suggestions? Where can I find media for 4.3BSD (if any are legitimately accessible)? Or on a Raspberry Pi? :) Thanks! Gilles -- *Gilles Gravier* - Gilles(a)Gravier.org GSM : +33618347147 and +41794728437 Skype : ggravier | PGP Key : 0x8DE6D026 <http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index>

6 years, 8 months

5
6
0 0

hal.gnu.ai.mit.edu

by Steve Mynott

Back in the early 90s before the FSF withdrew the service due to misuse it was possible to write off to them to get a free shell account on "hal" as I did. I recall having to telnet through one of three gateway systems so assume it was on its own little subnet. But I can't remember what sort of system (hardware or OS) it was now however and wondered if anyone else did? -- Steve Mynott <steve.mynott(a)gmail.com> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5

6 years, 8 months

3
3
0 0

Re: [TUHS] changes in C compilers

by Norman Wilson

Clem Cole: Clearly from the time, ditroff did not yet exist. The more I think about it, Brian K actually might know some of the story. === I'm quite sure Brian Kernighan knows the full story of the origins of typesetter-independent troff (as it was originally called, in CSTR 97, published in 1981; the binary was just /usr/bin/troff). The reason I'm so sure of that is that it was Brian who rewrote troff to bring it into the modern era and to make it supportable. He's also the author of the CSTR. Norman Wilson Toronto ON

6 years, 8 months

2
1
0 0

Re: [TUHS] SunOS code?

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > I'd really like the SCCS history. Any idea if that even still exists, or did it get shredded somewhere along the way? Anyway, should I spin up my nephew on trying to find the right person to put out a historic, personal-use license? Noel

6 years, 8 months

2
1
0 0

Fwd: Re: RetroNet…

by William Pechter

Missed the cc line. Also I have mailman up @ lakewoodmicro.com at Digital Ocean. If we need mailing lists. -----Original Message----- From: William Pechter <pechter(a)gmail.com> To: Grant Taylor <gtaylor(a)tnetconsulting.net> Sent: Wed, 29 Aug 2018 14:46 Subject: Re: [TUHS] RetroNet… Damn. Television was autocorrect but I wrote "Telebit" at the time. Perhaps setting up a mumble server for voice chat makes sense. Bill -----Original Message----- From: Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org> To: tuhs(a)minnie.tuhs.org Sent: Wed, 29 Aug 2018 14:42 Subject: Re: [TUHS] RetroNet… On 08/29/2018 12:26 PM, William Pechter wrote: > Count me in. Cool! Welcome! We're currently hanging out in the #retronet group on the Synchronet network (I'm accessing through irc.chivanet.org) > I think a UUCP over ssh would be nice as would an SSL version. I've personally done UUCP over SSH multiple times. It looks like TCP port 540 is reserved for UUCP over TCP and TCP port 4031 is reserved for UUCP over SSL. So, we'll definitely be offering those services inside of RetroNet. Currently the idea is to make services available inside of RetroNet. I don't know how many services will be openly available across the Internet. Primarily for security / safety reasons. That being said, I think we are planing on a gateway for things. We're certainly willing to talk about other options too. > I would like to see UUCP over ether as serial for backwards compatibility > to talk to old machines and emulation. I / we would like to know more about the "over ether as serial" part. I'd think the goal would be to have RS-232 (et al) serial ports that can connect to retro computers and make things look like what they would expect to see. That being said, we will either need an RS-232 (et al) serial port on a gateway, or something else to translate from serial to likely an IP~>telnet connection. If you have ideas, please bring them and share them. > Some of the kid's I know would be blown away by Cnews and television or > transported over Internet or PPP links. Yep. :-) -- Grant. . . . unix || die

6 years, 8 months

2
1
0 0

Re: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions?

by jnc＠mercury.lcs.mit.edu

> From: Noel Chiappa > I'll update the page as well. I have to do it since, after severe issues with spam, a login is required to make changes. If anyone is interested in adding content (please, we need more in just about every area - I've done a lot of PDP-11's, but that's a fairly small corner overall :-), please drop me a short line, and I'll set you up (just let me know the account name you want, and what email address to associate with it). > From: William Pechter > Just a plug for the 4.3+University of Wisconsin version on Simh. I don't think I see that in the TUHS repository that Clem just pointed to? Got a URL? Any chance I can convince you to add a bit of content about it? :-) Noel

6 years, 8 months

1
0
0 0

Re: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions?

by jnc＠mercury.lcs.mit.edu

> From: Rares Aioanei > gunkies.org works. The URL for getting the sets doesn't Ah, OK. Link-rot; sigh. The bane of the Web! If someone can provide a working alternative for you to use, I'll update the page as well. Noel

6 years, 8 months

3
2
0 0

Re: [TUHS] Running 4.3 BSD on x86 hardware? Suggestions?

by jnc＠mercury.lcs.mit.edu

> From: Rares Aioanei > Link doesn't seem to work, I get "Connection reset". Which link - the gunkies.org (Computer History Wiki) one? It's working for me at the moment. Does your browser accepts non-HTTPS URLs? (There's apparently a craze on to denigrate them at the moment.) Noel

6 years, 8 months

2
1
0 0

C++ / Kernel

by ron＠ronnatalie.com

> Has anyone experimented with building Unix using C++, to take > advantage of strong typing? My guess is no--it would be a Herculean task likely to introduce more bugs than it would fix. I'm not sure what "strong typing" gain you expect to find. With the exception of the void* difference, C++ isn't much more "type strong" than C. A lot of the type issues you can find on the Kernel just by turning up the compiler warnings (or use lint). The biggest issue we had was BSD didn't use void* at all. Had they converted pointers to void*, which is in implementation necessarily the same as char*, C would have done the right thing. The problem is they did what I call "Conversion by union." They would store a char* into one element of a union and read it out of another typed pointer. This works fine for a VAX where all pointers are the same format, but fails on word address machines (notably in our case the HEP where the target size is encoded in the low order bits of the pointer). Still, running around and fixing those was only a few hours work. The DevSwitch is the beginnings of an object oriented philosophy. Alas, the original UNIX used it only for mapping major dev numbers to functions. It got some later use for other things like multi filesystemsupport. The scary supportability thing in the kernel, isn't so much typing, but the failuer to "hide" implementation details of one part of the kernel from the other.

6 years, 8 months

10
21
0 0

Research UNIX on the AT&T 3B2?

by Norman Wilson

Seth Morabito: After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong. ===== I never heard of anyone doing such a thing. Had they ported the kernel I would almost certainly have heard about it, because they'd have asked me a question or two. Much VAX-specific structure inside there that I'd love to have had the time and energy to clean up. It's possible that someone did a semi-port, moving a lot of the user-mode tools like the shell and the Jerq software. Dave Kapilow did something like that for early SunOS, including a mux-like X11 terminal program called sux, built atop a library that did a simple mapping from Jerq graphics-library calls to X11. Certainly nobody inside 1127 ever did either of those things. A few of us played with 3B1 or 3B2 systems (I remember Tom Duff had a 3B1 at home at one point), but never very seriously. Norman Wilson Toronto ON

6 years, 9 months

1
0
0 0

Re: [TUHS] changes in C compilers

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Looking at the v6 distribution tape I have, the assembler versions of > roff and nroff was there Whoa! The standard V6 distribution tape, as in the one there are a couple of copies of in the repository, does not have that. Do you have that in machine-readable form? If so, can you get it to Mr. Toomey ASAP? > The order I remember is this ... V5, V6, Patches, Typesetter C, TS, V7 Where do USG and PWB fit into that? The repository has PWB (or, what is _claimed_ to be PWB), which is how I know the MIT system is PWB. But there is nothing of the others (except the kernel manual for USG, which shows that the version described in it is basically V6). If anyone has TS in _any_ form (including hardcopy listings, please speak up! Those 'early' PDP-11 versions are very poorly documented now, and I'd love to get more on them. Noel

6 years, 9 months

2
1
0 0

changes in C compilers

by arnold＠skeeve.com

My two cents, ... > From: Clem Cole <clemc(a)ccc.com> > Date: Thu, 23 Aug 2018 20:30:19 -0400 > To: ron(a)ronnatalie.com > Subject: Re: [TUHS] C++ / Kernel > > Yep. Im pretty sure I remember void being in typesetter C also. IIRC the > differences between that version of Dennis???s compiler and what was included > in 7th Edition was mostly in the libraries ie stdio was first released as > part of the typesetter compiler but it was still a work in progress. K&R 1 did not have void or structure assignment. Those came later, although I'm not sure when. They may have been mentioned in an appendix; my copy isn't handy to check. At what point did each struct become its own namespace? I think around the time of K&R1. > From: Clem cole <clemc(a)ccc.com> > Date: Thu, 23 Aug 2018 22:52:24 -0400 > To: Noel Chiappa <jnc(a)mercury.lcs.mit.edu> > Subject: Re: [TUHS] C++ / Kernel > > ... > > The big changes to the language were between 6th Edition and Typesetter > which were done in concert if not to support Brian???s work on the troff > rewrite. Plus the first draft of book was being written around then also. The troff rewrite was later, circa '81 or so. Definitely NOT in the V6/V7 timeframe. Arnold

6 years, 9 months

5
6
0 0

Re: [TUHS] changes in C compilers (Typesetter C)

by jnc＠mercury.lcs.mit.edu

> From: Jaap Akkerhuis > I've been told that when troff was rewritten from assembler to C Was TROFF ever in assembler? I'm pretty sure NROFF was, as of V6; the source is not in the V6 distro, and the binary is stripped, but looking at the object code, it doesn't look like C compiler output. As of the PWB system that MIT had (or maybe it was TS - how can one tell the difference, does anyone know?), NROFF and TROFF were generated from the same C source (which I have, if anyone wants to look at it). > the compiler needed some rework and thus typesetter C was born. I heard he needed features (e.g. longs and unsigned), but... looking at the N/TROFF source, there are _no_ 'unsigned's, and only a handful of 'long' variables! There also don't seem to be any bit fields, typedefs, etc. There is _one_ initialized structure (array of structures, to be precise). (Although there are a lot of places were an int is initialized with a double-character constant!) About the only features in "C Changes" that it uses are i) register types on arguments, and the 'static' storage class. So now I'm wondering about that meme... Noel

6 years, 9 months

1
0
0 0

Re: [TUHS] Details and Dates (was C++ / Kernel)

by Clem Cole

On Fri, Aug 24, 2018 at 10:02 AM Dan Cross <crossd(a)gmail.com> wrote: > It's my subjective impression, based largely on what I read here on TUHS, > that there was quite a lot of activity and cross-pollination in and out of > Bell Labs at the time, so I'm not surprised that the details here are fuzzy. > Amen - The Ritchie compiler in particular, as well as the Research Kernel and BSD releases are examples a continuous development and express specific points in time. The *people and thus knowledge were fluid* (*a.k.a.* 'open source ;-) and features within the system followed the people. The reasons, order and local politics for many things are sometimes forgotten. Different actions feed back and forth and things get cloudy in the history. For instance, while people give BSD credit for the Unix networking because it was widely released with BSD 4.2 and 4.3 as the vehicle, it was actually BBN did the original IP and TCP stack that Eric Cooper added to 4.1 and Joy would eventually create sockets in 4.1A. All of MIT with ChaosNet, UofI and Rand's work on the ArpaNet NCP predates that work and was used by BBN -- as did the 3Com UNET code for V7, much less things like Rashid's Accent work, Mike Malcom and Cheridon's Thoth and later V Kernel. This is why I try to use other information that we can precisely date, as well as constants like trying code on old V7 releases like Dan just did. To me 'other information' is like when some of us matriculated at which schools or moved jobs, *i.e.* when Ted show up at CMU for his original OYOC year, Noel's time in Tech Sq, me at CMU or UCB, the summer the V6 patch tape 'accidentally' found its way to the Arpanet community can be dated by Ken's trip to California/visit to see Chesson who was finishing up at UofI ; or big outside actions like the need to support to big unmovable (and thus otherwise datable) items such as the APS5 or addition of the Vax VM support at UCB , dvk and my going on strike to force CMU to get a commercial Unix license summer of '78, when UCB got its own C70 IMP instead of the VDHI to LBL for Ing70; *etc* . Dates of different USENIX conferences, which were were a lot of ideas (and code) moved back and forth. Clem

6 years, 9 months

1
0
0 0

Re: [TUHS] C++ / Kernel

by jnc＠mercury.lcs.mit.edu

> From: Ron Natalie > The BSD kernel looks as if it requires such a later compiler (it uses > bit fields which the earlier compilers didn't support). Umm, minor nit: bit fields were added to/as of 'Typesetter C', which I gather was intermediate between V6 and V7. Noel

6 years, 9 months

4
4
0 0

Re: [TUHS] compiler checking types

by Steve Simon

At the risk of being boring, Ken thompson’s portable c compiler on plan9 checks types. -Steve

6 years, 9 months

1
0
0 0

C++ / Kernel

by Paul Ruizendaal

> Perhaps Steve Johnson can chime in on this? I suspect he'd know the history > here well. The origins of void were discussed 4-7 nov 2017 on this list.

6 years, 9 months

1
0
0 0

Re: [TUHS] C++ / Kernel

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > Im pretty sure I remember void being in typesetter C also. Hmm. In the two original 'help' files I have about the changes to C (the term 'typesetter C' doesn't appear, but it's pretty clear that's what the subject is), available through here: http://gunkies.org/wiki/Typesetter_C the term 'void' does not appear (although most other stuff - e.g. unions, bit fields, typedef, yadda yadda - does). Noel

6 years, 9 months

2
1
0 0

About Unix header files

by Caipenghui

Hello everyone Hello everyone, I have a question, I looked at the source code of early Unix, found that a lot of.c files did not contain header files, so compiler compiler will not error? Caipenghui

6 years, 9 months

8
11
0 0

Re: [TUHS] About Unix header files

by Doug McIlroy

> Has anyone experimented with building Unix using C++, to take advantage of strong typing? My guess is no--it would be a Herculean task likely to introduce more bugs than it would fix. How Unix didn't get written in C++: When Bjarne Stroustrup joined Bell Labs, he hoped to write an operating system, but he wanted to do it in an object oriented language, so he took a small detour to make an object-oriented sibling of C. That turned out to be a maelstrom from which he never escaped. Doug

6 years, 9 months

2
1
0 0

A c program problem

by cc

Hello everyone I had a problem compiling a piece of c code from the book. The result of running the book is 5050, but the compiler is 100. I don't know which is right, please help me to see which is wrong. Thank you very much! #include <stdio.h> int main(void) { int i, sum = 0; i = 1; while ( i <= 100) { sum = sum + 1; i++; } printf("%d\n", sum) return 0; } | | cc | | 邮箱：caipenghui_c(a)163.com | 签名由网易邮箱大师定制

6 years, 9 months

7
9
0 0

.

by Caipenghui

.

6 years, 9 months

1
0
0 0

Re: [TUHS] TUHS Digest, Vol 33, Issue 5

by jnc＠mercury.lcs.mit.edu

> From: Steve Simon > well spec'ed machines where more common in the past. Err, engineering data is not the same thing as a formal specification. If not, almost every computer built could be said to have a 'formal spec' - there usually are engineering documents for anything that was produced in any sort of quantity. Also, whether said engineering info is publicly available or not (which seems to be another of your observations) is an orthogonal axis. Noel

6 years, 9 months

8
8
0 0

Formal Specification and Verification

by Paul Ruizendaal

> I also note that the general response here was the one I almost always > get when I mention this stuff to people, which is near silence. Don’t take that as disinterest. For me at least it simply reflects that I need to find some time to read up on and digest the points you were making. Paul

6 years, 9 months

1
0
0 0

Re: [TUHS] [groff] Creating a numbered list without macros

by Doug McIlroy

An arguable distinction: I thought hard about claiming priority for -ms. Joe Ossanna intended option -m to foster macro packages from the outset. -man was an early use, hidden in the man command. But -man was not packaged (in the sense of being an announced feature that can be used from its external description) until v7. -ms appeared in v6. Doug Arnold Robbins <arnold(a)skeeve.com> wrote: > Doug McIlroy <doug at cs.dartmouth.edu> wrote: > >>> Why create ms when you have mm? >> >> Well, the real reason is that ms was the very first macro package. >> It has held up spectactularly well, evolving much less than the >> underlying [ntg]roff. >> >> Doug > > Or say, rather, the first *general purpose* macro package. The man > macros predate it. :-)

6 years, 9 months

3
2
0 0

Can anyone point me to source for a lex that works on Linux?

by Arnold Robbins

Hi. Can anyone point me to source for Unix lex that can be compiled and works on Linux? I've tried in the past to make V7 lex work and failed. Thanks, Arnold

6 years, 9 months

6
5
0 0

Re: [TUHS] [groff] Creating a numbered list without macros

by Doug McIlroy

> Why create ms when you have mm? Well, the real reason is that ms was the very first macro package. It has held up spectactularly well, evolving much less than the underlying [ntg]roff. Doug

6 years, 9 months

2
1
0 0

Sort of off-topic: usefulness of TUHS list and archive?

by Warren Toomey

All, sorry that this is tangential to TUHS. I work at TAFE Queensland, which is a bit like a polytechnic or a U.S college. As a teacher, I have to demonstrate industry skills. I've listed my administration of the TUHS server over 25+ years. However, TAFE wants this to be verified by third parties: "Where possible the teacher could show that industry endorses his website and any if there are any testimonials/comments/reviews available on the site, these could also be provided." So, if you could pop a sentence or two in reply to this e-mail about the usefulness of the TUHS archive and the mailing list, that would be really helpful! Cheers & thanks in advance, Warren

6 years, 9 months

6
6
0 0

Re: [TUHS] TUHS Digest, Vol 33, Issue 7

by Don Hopkins

Decades ago I made my prompt simply end with a newline, which perfectly and cleanly solves the problem of making it easy to copy and paste a whole line by multiple clicking in a terminal emulator to select the line, or by using line oriented commands in an emacs shell (or moving to the line and hitting return, which Emacs often regularly fucks up with its idiotic kludges to identify the prompt with invisible marks and regular expressions), without injecting any garbage characters into the beginning of the command line or requiring any extra mouse clicks, precision cursor targeting, or extra keystrokes. Using “;” or any other character as a prompt is an ugly hack, and doesn’t solve the problem thoroughly or cleanly. No matter what character you use as a prompt at the beginning of the line, it’s going to cause some problems, like semicolons building up each time you re-enter the line, or conflicts with built-in shell syntax (retch!), so the only logical (and most obvious) solution is not to use any characters at the beginning of the line at all, and just put the prompt on a line above on its own. There is no downside to that, unless it somehow offends your sense of aesthetics. (In which case you should get over it.) That’s the cleanest solution without any unpleasant side effects. I don’t understand why that solution isn’t the first thing shell users think of, and the default used by the shell — it’s so obvious. Maybe because people used to the shell are just so accustomed to having to deal with mashing together unpleasant hackey kludgy incompatible competing ad-hoc syntax that it would never occur to them that it’s possible to solve a problem by REMOVING punctuation and noise characters instead of ADDING more of them. -Don > On 8 Aug 2018, at 04:00, tuhs-request(a)minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs(a)minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request(a)minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner(a)minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > Today's Topics: > > 1. Re: Origins of shell prompt suffixes % $ > # (Michael Kjörling) > 2. Re: Origins of shell prompt suffixes % $ > # (Kurt H Maier) > 3. Re: Origins of shell prompt suffixes % $ > # (arnold(a)skeeve.com) > 4. Re: Origins of shell prompt suffixes % $ > # (Bakul Shah) > 5. Re: Origins of shell prompt suffixes % $ > # (Michael Kjörling) > 6. Re: Origins of shell prompt suffixes % $ > # (Dave Horsfall) > 7. Re: Origins of shell prompt suffixes % $ > # (KatolaZ) > 8. Re: TUHS Digest, Vol 33, Issue 5 (Steve Johnson) > 9. Re: Origins of shell prompt suffixes % $ > # (Tony Finch) > 10. Re: Origins of shell prompt suffixes % $ > # (Pete Turnbull) > 11. Re: Origins of shell prompt suffixes % $ > # (Doug McIlroy) > 12. Re: Origins of shell prompt suffixes % $ > # (Brian Zick) > 13. Re: Origins of shell prompt suffixes % $ > # (John P. Linderman) > 14. Re: Origins of shell prompt suffixes % $ > # (Lyndon Nerenberg) > 15. Re: Origins of shell prompt suffixes % $ > # (Cág) > 16. Re: Origins of shell prompt suffixes % $ > # (arnold(a)skeeve.com) > 17. Re: Origins of shell prompt suffixes % $ > # (Cág) > 18. Re: Origins of shell prompt suffixes % $ > # (Brian Zick) > > From: Michael Kjörling <michael(a)kjorling.se> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 08:54:54 CEST > To: tuhs(a)minnie.tuhs.org > > > On 6 Aug 2018 21:53 +0100, from brian(a)zick.io (Brian Zick): >> rc uses ; > > Not sure what came first, and not up to digging out the history books, > but these days, a plain `;` for a prompt has a distinct advantage in > that you can copy the whole line and paste it into another shell, and > the shell will do The Right Thing (tm) as long as (as is, I believe, > done by all of the major shells at least) it uses `;` for command > separation. > > -- > Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se > “The most dangerous thought that you can have as a creative person > is to think you know what you’re doing.” (Bret Victor) > > > > > From: Kurt H Maier <khm(a)sciops.net> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 09:31:36 CEST > To: Brian Zick <brian(a)zick.io> > Cc: tuhs(a)minnie.tuhs.org > > > On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: >> >> rc uses ; > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > default value of $prompt. At least that's how it's described in the > manual. None of the v8/9/10 tarballs in the archive contain rc code, > but some contain manual source, and those describe % prompts. > > I've seen other references to ; (presumably ('; ' ' ')) as the rc > prompt but I've never seen it in the wild. Does anyone here know what > the story is? > > khm > > > > > From: arnold(a)skeeve.com > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 09:50:21 CEST > To: khm(a)sciops.net, brian(a)zick.io > Cc: tuhs(a)minnie.tuhs.org > > > Kurt H Maier <khm(a)sciops.net> wrote: > >> On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: >>> >>> rc uses ; >> >> Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the >> default value of $prompt. At least that's how it's described in the >> manual. None of the v8/9/10 tarballs in the archive contain rc code, >> but some contain manual source, and those describe % prompts. >> >> I've seen other references to ; (presumably ('; ' ' ')) as the rc >> prompt but I've never seen it in the wild. Does anyone here know what >> the story is? >> >> khm > > I believe that Tom Duff's rc does indeed use ('% ' ' '). But I think that > Byron Rakitsis's version changed the default to ('; ' ' ') exactly for > the reason that it's copyable/pastable. > > HTH, > > Arnold > > > > > From: Bakul Shah <bakul(a)bitblocks.com> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 09:57:11 CEST > To: Kurt H Maier <khm(a)sciops.net> > Cc: Brian Zick <brian(a)zick.io>, tuhs(a)minnie.tuhs.org > > > On Tue, 07 Aug 2018 00:31:36 -0700 Kurt H Maier <khm(a)sciops.net> wrote: >> On Mon, Aug 06, 2018 at 09:53:33PM +0100, Brian Zick wrote: >>> >>> rc uses ; >> >> Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the >> default value of $prompt. At least that's how it's described in the >> manual. None of the v8/9/10 tarballs in the archive contain rc code, >> but some contain manual source, and those describe % prompts. >> >> I've seen other references to ; (presumably ('; ' ' ')) as the rc >> prompt but I've never seen it in the wild. Does anyone here know what >> the story is? > > The es shell (by Haar and Rakitzis) used ; - the reason (as > per the man page)is that a user can cut-n-paste a previous > line to rexecute it (for the same reason people use term% and > cpu% functions to execute their args). Es syntax was derived > from rc, which may be why the confusion. > > > > > From: Michael Kjörling <michael(a)kjorling.se> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 10:02:56 CEST > To: tuhs(a)minnie.tuhs.org > > > On 7 Aug 2018 06:54 +0000, from michael(a)kjorling.se (Michael Kjörling): >> the shell will do The Right Thing (tm) > > I suspect I must stand corrected on this. Turns out that at least GNU > bash 4.4.12(1) seems to not like a `;` at the beginning of the command > line. > > $ /bin/bash --version | head -n1 > GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) > $ /bin/bash > $ ; true > bash: syntax error near unexpected token `;' > $ echo $? > 2 > $ > > Hopefully other shells are more sane. > > -- > Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se > “The most dangerous thought that you can have as a creative person > is to think you know what you’re doing.” (Bret Victor) > > > > > From: Dave Horsfall <dave(a)horsfall.org> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 10:23:37 CEST > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > > > On Tue, 7 Aug 2018, Michael Kjörling wrote: > >> Hopefully other shells are more sane. > > The MacBook here runs GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin16) and is equally busted, as is plain "sh" on both the Mac and FreeBSD (I can't be bothered checking the Penguin); I use ZSH on FreeBSD and it does The Right Thing (tm), as does ZSH on the Mac. > > -- Dave > > > From: KatolaZ <katolaz(a)freaknet.org> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 10:37:23 CEST > To: tuhs(a)minnie.tuhs.org > > > On Tue, Aug 07, 2018 at 06:23:37PM +1000, Dave Horsfall wrote: >> On Tue, 7 Aug 2018, Michael Kjörling wrote: >> >>> Hopefully other shells are more sane. >> >> The MacBook here runs GNU bash, version 3.2.57(1)-release >> (x86_64-apple-darwin16) and is equally busted, as is plain "sh" on both the >> Mac and FreeBSD (I can't be bothered checking the Penguin); I use ZSH on >> FreeBSD and it does The Right Thing (tm), as does ZSH on the Mac. >> >> -- Dave > > I have tried all the shells I have on my linux box. It turns out that > only ksh and zsh like a ";" at the beginning of the line. Otherwise, > bash, busybox, ash/dash, mksk, posh, and yash can't bear it. > > I really don't see the point of using ";", especially if you need to > make it clear if a command needs to be run by root. > > $ ;-P > sh: 1: Syntax error: ";" unexpected > > > -- > [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] > [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] > [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] > [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] > [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] > > > > From: "Steve Johnson" <scj(a)yaccman.com> > Subject: Re: [TUHS] TUHS Digest, Vol 33, Issue 5 > Date: 6 August 2018 at 23:19:31 CEST > To: "Hellwig Geisse" <hellwig.geisse(a)mni.thm.de>, tuhs(a)minnie.tuhs.org > > > I take a somewhat more relaxed view of what a spec should be: > It should describe a program with enough completeness that a competent > programmer could write it from the spec alone. > Each section of the spec should be capable of being tested. > If all the tests for all the sections pass, then the program is ready > for general use. > > The formal systems I have seen would roll over and die when presented with > even a simple compiler. Additionally, being able to specify that a particular > function be carried out by a heapsort, for example, would require that the > formalism could describe the heapsort and prove it correct. These don't > grow on trees... > > Steve > > > > ----- Original Message ----- > From: "Hellwig Geisse" <hellwig.geisse(a)mni.thm.de> > To:<tuhs(a)minnie.tuhs.org> > Cc: > Sent:Mon, 06 Aug 2018 18:30:30 +0200 > Subject:Re: [TUHS] TUHS Digest, Vol 33, Issue 5 > > > On Mo, 2018-08-06 at 08:52 -0700, Bakul Shah wrote: > > > > What counts as a "formal spec"? Is it like Justice Potter Stewart's > > "I know it when I see it" definition or something better? > > > > For me, a "formal spec" should serve two goals: > 1) You can reason about the thing that is specified. > 2) The spec can be "executed" (i.e., there is an > interpreting mechanism, which lets the spec behave > like the real thing). > > Hellwig > > > > From: Tony Finch <dot(a)dotat.at> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 12:45:37 CEST > To: Michael Kjörling <michael(a)kjorling.se> > Cc: tuhs(a)minnie.tuhs.org > > > Michael Kjörling <michael(a)kjorling.se> wrote: >> >> I suspect I must stand corrected on this. Turns out that at least GNU >> bash 4.4.12(1) seems to not like a `;` at the beginning of the command >> line. > > This is a consequence of the POSIX shell grammar, which doesn't allow > empty commands. > > http://pubs.opengroup.org/onlinepubs/9699919799.2013edition/utilities/V3_ch… > > The prompt I have used since about 1997 (and I can't remember where I got > it from - somewhere on Usenet, probably) in its most distilled form is > > :; > > although in practice I have a load of extra fluff for username, hostname, > CWD, etc. usw. > > Tony. > -- > f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/ > Fair Isle, Faeroes: South or southwest 4 or 5, occasionally 6 for a time. > Slight or moderate, occasionally rough for a time. Showers. Moderate or good. > > > > From: Pete Turnbull <pete(a)dunnington.plus.com> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 13:24:20 CEST > To: tuhs(a)minnie.tuhs.org > > > On 07/08/2018 09:02, Michael Kjörling wrote: >> On 7 Aug 2018 06:54 +0000, from michael(a)kjorling.se (Michael Kjörling): >>> the shell will do The Right Thing (tm) >> I suspect I must stand corrected on this. Turns out that at least GNU >> bash 4.4.12(1) seems to not like a `;` at the beginning of the command >> line. >> $ /bin/bash --version | head -n1 >> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu) >> $ /bin/bash >> $ ; true >> bash: syntax error near unexpected token `;' >> $ echo $? >> 2 >> $ >> Hopefully other shells are more sane. > > ksh and sh on an IRIX system don't like it either: > > $ ; > ksh: syntax error: `;' unexpected > $ > > csh and tcsh don't mind. > > Of course it works in rc itself, which is the point, really, and I wonder how often anyone pasted from one shell into another. All the rc use I've seen did indeed use "; " as the prompt, but that was all at the University of York, starting in 1993. > > -- > Pete > Pete Turnbull > > > > > From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 14:34:16 CEST > To: tuhs(a)tuhs.org > > >> The Bourne shell (V7) had setable PS1 (start of command) and PS2 (continuation prompts) > > When PS2 came on the scene, Bob Morris noticed that it most often appeared > because of a missing close quote. Therefore he set PS2="hit interrupt". > > > > > From: Brian Zick <brian(a)zick.io> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 17:15:07 CEST > To: Kurt H Maier <khm(a)sciops.net> > Cc: tuhs(a)minnie.tuhs.org > > >>> rc uses ; >> >> Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the >> default value of $prompt. At least that's how it's described in the >> manual. > > In NetBSD 7 the default is ';', but I don't see any reference to a default $prompt in the manual on that system. I wonder if this was a change unique to Berkeley. > > B > > > > > From: "John P. Linderman" <jpl.jpl(a)gmail.com> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 17:52:57 CEST > To: Brian Zick <brian(a)zick.io> > Cc: Kurt H Maier <khm(a)sciops.net>, tuhs(a)minnie.tuhs.org > > > On vacation, with just an iPad keyboard, so I apologize for not doing more digging. As I noted, when taking the blame for the Great Echo Schism, my early exposure to a hp2640 terminal that allowed “rentry” of a previous command was partly to blame. It also led me to use a PS1 ending in @, the default line-kill. When I reentered a command, the @ wiped out the prompt stuff, and only the command survived. > > On Tue, Aug 7, 2018 at 10:15 AM Brian Zick <brian(a)zick.io <mailto:brian@zick.io>> wrote: > > > rc uses ; > > > > Does it? 10th edition Unix and Plan 9 rc both have ('% ' ' ') as the > > default value of $prompt. At least that's how it's described in the > > manual. > > In NetBSD 7 the default is ';', but I don't see any reference to a default $prompt in the manual on that system. I wonder if this was a change unique to Berkeley. > > B > > > > From: Lyndon Nerenberg <lyndon(a)orthanc.ca> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 19:35:49 CEST > To: Tony Finch <dot(a)dotat.at> > Cc: Michael Kjörling <michael(a)kjorling.se>, tuhs(a)minnie.tuhs.org > > >> The prompt I have used since about 1997 (and I can't remember where I got >> it from - somewhere on Usenet, probably) in its most distilled form is >> >> :; > > I forget where I stole this from. It lives in $home/lib/profile on my Plan9 machines: > > # /n/sources/contrib/lyndon/prompt.rc > fn : {} > fn setprompt { > prompt = (': '^`{cat /dev/user}^@^`{cat /dev/sysname}^':'^`{pwd}^'; ' ' ') > } > fn cd { builtin cd $* && setprompt } > setprompt > > > > > > From: Cág <ca6c(a)bitmessage.ch> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 20:09:51 CEST > To: tuhs(a)minnie.tuhs.org > > > Brian Zick wrote: > >> In NetBSD 7 the default is ';', but I don't see any reference to a >> default $prompt in the manual on that system. > > It's not. '$' is default for sh and ksh, and '%' for csh. I think > it maybe has never been ';'. > > -- > caóc > > > > > > From: arnold(a)skeeve.com > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 20:51:52 CEST > To: tuhs(a)minnie.tuhs.org, ca6c(a)bitmessage.ch > > > C??g <ca6c(a)bitmessage.ch> wrote: > >> Brian Zick wrote: >> >>> In NetBSD 7 the default is ';', but I don't see any reference to a >>> default $prompt in the manual on that system. >> >> It's not. '$' is default for sh and ksh, and '%' for csh. I think >> it maybe has never been ';'. >> >> -- >> ca??c >> > > Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc > and I think the default there is ';'. > > Arnold > > > > > From: Cág <ca6c(a)bitmessage.ch> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 21:00:22 CEST > To: tuhs(a)minnie.tuhs.org > > > arnold wrote: > >> Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc >> and I think the default there is ';'. > > rc is not shipped with NetBSD. There's Byron's rc in pkgsrc, so it could > be that. > > -- > caóc > > > > > > From: Brian Zick <brian(a)zick.io> > Subject: Re: [TUHS] Origins of shell prompt suffixes % $ > # > Date: 7 August 2018 at 21:06:03 CEST > To: tuhs(a)minnie.tuhs.org > > > On Tue, Aug 7, 2018, at 8:00 PM, Cág wrote: >> arnold wrote: >> >>> Brian was referring to rc(1) in NetBSD. I suspect it's Byron's rc >>> and I think the default there is ';'. >> >> rc is not shipped with NetBSD. There's Byron's rc in pkgsrc, so it could >> be that. > > Yes, I was referring to the rc in pkgsrc. > > B > > > > > > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs

6 years, 9 months

17
22
0 0

Re: [TUHS] Happy, birthday, Marvin Minsky

by Doug McIlroy

> ... Minsky ... invented neural networks A little baldy put. Minsky did study them and famously proved severe limitations on the learning capability of the simple perceptron model. Mathematical models of neural networks originaated with McCulloch and Pitts; perceptrons with Rosenblat. doug

6 years, 9 months

1
0
0 0

Re: [TUHS] Origins of shell prompt suffixes % $ > #

by jnc＠mercury.lcs.mit.edu

> From: Nemo > I will, no doubt, be flayed on this list but I tend to use "=>". Hey, if it works for you, go for it. After the Nth time I got confused as to exactly which machine I was typing to, I hacked the shell on my V6 Unix to read its prompt from ".profile". (Very clean, only one added line of code in the existing code.) Noel

6 years, 9 months

6
5
0 0

Happy birthday, Marvin Minsky!

by Dave Horsfall

We gained Marvin Minsky on this day in 1927; he was an AI researcher, computer scientist, invented neural networks etc, and is now thought to be cryogenically preserved. -- Dave

6 years, 9 months

1
0
0 0

Origins of shell prompt suffixes % $ > #

by Brian Zick

Hi, I usually just lurk on this list, but I've been curious lately about the origin of the symbols at the end of various interactive prompts. ksh (etc), bash, sh use $ for non-root, and # for root csh, tcsh and zsh use % for non-root and # for root fish and things like mysql, ftp, and interactive shells for a lot of scripting languages use > rc uses ; Where do these different conventions originate? B

6 years, 9 months

18
24
0 0

Misuse of TUHS Digest [Was: Re: TUHS Digest, Vol 33, Issue 7]

by Nemo

Maybe I am being a tad sensitive this morn but... >> On 8 Aug 2018, at 04:00, tuhs-request(a)minnie.tuhs.org wrote: [...] >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of TUHS digest..." let us please honour this request. Thank you. N. [Lots and lots and lots of stuff removed]

6 years, 9 months

1
0
0 0

Re: [TUHS] Origins of shell prompt suffixes % $ > #

by Doug McIlroy

> The Bourne shell (V7) had setable PS1 (start of command) and PS2 (continuation prompts) When PS2 came on the scene, Bob Morris noticed that it most often appeared because of a missing close quote. Therefore he set PS2="hit interrupt".

6 years, 9 months

1
0
0 0

Re: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel!

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he > could pretty much be described as the Father of the Internet. The problem with using the number of documents as a gauge for that is that Jon often acted as scribe, so that for many things published under his name, he was acting more as editor. As to who (if anyone) does deserve that title, I'm also not sure about the importance of Cerf and Kahn. NOTE: I am not saying they _didn't_ make the key contribution - I just haven't looked into it in enough detail to say. For example, before the TCP/IP effort got rolling, there was something called the International Packet Network Working Group (INWG) which had a big role, but which has been poorly documented. There's a note called "The Internet: On its International Origins and Collaborative Vision" by Rhonda Hauben, available here: http://www.columbia.edu/~rh120/other/misc/haubenpap.rtf which covers it some, and there's a more recent thing by Alex Mackenzie which is probably better, but I'm too lazy to go find it. Louis Pouzin (or whoever it was at CYCLADES who actually had the idea to move the reliability out of the packet switches, and into the hosts), also would have a good claim to the title. Anyway, sorry for the offtopic, but my 'fake history' alarm went off... Noel

6 years, 9 months

2
1
0 0

Latest Kernighan interview on Youtube

by Warren Toomey

in 3 parts: https://www.youtube.com/watch?v=zmYhR8cUX90 https://www.youtube.com/watch?v=VVpRj3Po6K4 https://www.youtube.com/watch?v=E6vtRm5M8I0 Cheers, Warren

6 years, 9 months

2
1
0 0

Re: [TUHS] TUHS Digest, Vol 33, Issue 5

by jnc＠mercury.lcs.mit.edu

> I'm not into that stuff, so I point you in the right direction. ^ Sorry, lost a "can't" there. Noel

6 years, 9 months

1
0
0 0

Re: [TUHS] TUHS Digest, Vol 33, Issue 5

by jnc＠mercury.lcs.mit.edu

> From: Bakul Shah > What counts as a "formal spec"? If you aren't familiar with the work in the field (it's been going on long enough, it was around when I was an undergrad), some of the earlier messages in the thread, e.g.: https://minnie.tuhs.org//pipermail/tuhs/2018-August/014365.html might provide some thing you could follow. (I'm not into that stuff, so I point you in the right direction.) Noel

6 years, 9 months

1
0
0 0

Re: [TUHS] TUHS Digest, Vol 33, Issue 5

by Steve Simon

well spec’ed machines where more common in the past. we had all the source for the interdata 3210 at college. we had the edition 7 source, the driver source, the diagnostic tape source, and even all the schematics. two of the lecturers even upgraded it from 1mb to 4mb of RAM, complete with address decoders on their backs with their legs in the air. -Steve > On 6 Aug 2018, at 03:00, tuhs-request(a)minnie.tuhs.org wrote: > > Send TUHS mailing list submissions to > tuhs(a)minnie.tuhs.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > or, via email, send a message with subject or body 'help' to > tuhs-request(a)minnie.tuhs.org > > You can reach the person managing the list at > tuhs-owner(a)minnie.tuhs.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TUHS digest..." > > > Today's Topics: > > 1. Re: In Memoriam: Per Brinch Hansen (Perry E. Metzger) > 2. Latest Kernighan interview on Youtube (Warren Toomey) > 3. In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel! > (Dave Horsfall) > 4. Re: In Memoriam: Edsger Dijkstra, and happy birthday Jon > Postel! (Noel Chiappa) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 5 Aug 2018 19:18:18 -0400 > From: "Perry E. Metzger" <perry(a)piermont.com> > To: Doug McIlroy <doug(a)cs.dartmouth.edu> > Cc: tuhs(a)tuhs.org > Subject: Re: [TUHS] In Memoriam: Per Brinch Hansen > Message-ID: <20180805191818.0ac05b0f(a)jabberwock.cb.piermont.com> > Content-Type: text/plain; charset=US-ASCII > > On Thu, 02 Aug 2018 08:44:56 -0400 Doug McIlroy > <doug(a)cs.dartmouth.edu> wrote: >> A tangential connection to early Unix experience: >> >> My collection of early computer manuals includes Brinch Hansen's >> manual for the RC 4000, which stands out for its precise >> description of the CPU logic--in Algol 60! It's the only manual I >> have seen that offers a good-to-the-last-bit formal description of >> the hardware. >> >> DEC presented something of the sort for the PDP-11, but punted where >> the woods got thick. When I wanted to know how they computed the >> last bit of floating-point results, I got no satisfaction. Amidst a >> thorough description of addressing came this formulation of the >> actual computation: "form floating point result". > > For those that are familiar with the RISC V architecture, there's a > formal specification of the architecture that was done in a system > built on Coq, and also a fully formally verified translation of the > specification into RTL. (The spec didn't include floating point as of > about a year ago but it may by now.) > > A good overview of the system involved is here: > > http://plv.csail.mit.edu/kami/papers/icfp17.pdf > > Followups might belong on the coff list, not sure. > > Perry > -- > Perry E. Metzger perry(a)piermont.com > > > ------------------------------ > > Message: 2 > Date: Mon, 6 Aug 2018 09:53:19 +1000 > From: Warren Toomey <wkt(a)tuhs.org> > To: tuhs(a)tuhs.org > Subject: [TUHS] Latest Kernighan interview on Youtube > Message-ID: <20180805235319.GA14811(a)minnie.tuhs.org> > Content-Type: text/plain; charset=us-ascii > > in 3 parts: > > https://www.youtube.com/watch?v=zmYhR8cUX90 > https://www.youtube.com/watch?v=VVpRj3Po6K4 > https://www.youtube.com/watch?v=E6vtRm5M8I0 > > Cheers, Warren > > > ------------------------------ > > Message: 3 > Date: Mon, 6 Aug 2018 10:04:17 +1000 (EST) > From: Dave Horsfall <dave(a)horsfall.org> > To: The Eunuchs Hysterical Society <tuhs(a)tuhs.org> > Subject: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday Jon > Postel! > Message-ID: > <alpine.BSF.2.21.9999.1808060955320.79568(a)aneurin.horsfall.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > What a weird day... > > We lost computer pioneer Edsger Dijkstra in 2002; he gave us ALGOL, > structured programming, semaphores, and ranted against the GOTO statement > (much to the distress of the Fortranites and their spaghetti coding). > Oh, and a certain Prof. Goto used to complain that everybody wanted to > eliminate him :-) > > However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he > could pretty much be described as the Father of the Internet. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." > > > ------------------------------ > > Message: 4 > Date: Sun, 5 Aug 2018 21:15:45 -0400 (EDT) > From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) > To: tuhs(a)tuhs.org > Cc: jnc(a)mercury.lcs.mit.edu > Subject: Re: [TUHS] In Memoriam: Edsger Dijkstra, and happy birthday > Jon Postel! > Message-ID: <20180806011545.29C1F18C09A(a)mercury.lcs.mit.edu> > >> From: Dave Horsfall > >> However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he >> could pretty much be described as the Father of the Internet. > > The problem with using the number of documents as a gauge for that is that Jon > often acted as scribe, so that for many things published under his name, he > was acting more as editor. > > As to who (if anyone) does deserve that title, I'm also not sure about the > importance of Cerf and Kahn. NOTE: I am not saying they _didn't_ make the key > contribution - I just haven't looked into it in enough detail to say. > > For example, before the TCP/IP effort got rolling, there was something called > the International Packet Network Working Group (INWG) which had a big role, > but which has been poorly documented. There's a note called "The Internet: On > its International Origins and Collaborative Vision" by Rhonda Hauben, > available here: > > http://www.columbia.edu/~rh120/other/misc/haubenpap.rtf > > which covers it some, and there's a more recent thing by Alex Mackenzie which > is probably better, but I'm too lazy to go find it. > > Louis Pouzin (or whoever it was at CYCLADES who actually had the idea to move > the reliability out of the packet switches, and into the hosts), also would > have a good claim to the title. > > > Anyway, sorry for the offtopic, but my 'fake history' alarm went off... > > Noel > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/tuhs > > ------------------------------ > > End of TUHS Digest, Vol 33, Issue 5 > ***********************************

6 years, 9 months

1
0
0 0

In Memoriam: Edsger Dijkstra, and happy birthday Jon Postel!

by Dave Horsfall

What a weird day... We lost computer pioneer Edsger Dijkstra in 2002; he gave us ALGOL, structured programming, semaphores, and ranted against the GOTO statement (much to the distress of the Fortranites and their spaghetti coding). Oh, and a certain Prof. Goto used to complain that everybody wanted to eliminate him :-) However, we gained Jon Postel in 1943; with umpteen RFCs to his name, he could pretty much be described as the Father of the Internet. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 9 months

1
0
0 0

Re: [TUHS] In Memoriam: Per Brinch Hansen

by Doug McIlroy

A tangential connection to early Unix experience: My collection of early computer manuals includes Brinch Hansen's manual for the RC 4000, which stands out for its precise description of the CPU logic--in Algol 60! It's the only manual I have seen that offers a good-to-the-last-bit formal description of the hardware. DEC presented something of the sort for the PDP-11, but punted where the woods got thick. When I wanted to know how they computed the last bit of floating-point results, I got no satisfaction. Amidst a thorough description of addressing came this formulation of the actual computation: "form floating point result". Doug

6 years, 9 months

5
4
0 0

Australian Computer Museum Society collection faces bulldozers

by asbesto

IDK if you know this, but https://www.itnews.com.au/news/australian-computer-museum-society-collectio… :( -- [ ::::::::: 73 de IW9HGS : http://freaknet.org/asbesto ::::::::::: ] [ Freaknet Medialab :: Poetry Hacklab : Dyne.Org :: Radio Cybernet ] [ NON SCRIVERMI USANDO LETTERE ACCENTATE - NON MANDARMI ALLEGATI ] [ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC and SPAM ]

6 years, 9 months

2
1
0 0

Re: [TUHS] Doug McIlroy's C++ regular expression library (mostly) revived

by Doug McIlroy

Why would anyone be interested in an old regex package that never was a part of any Unix distro? The driving force was Posix, whose regex spec was quite inscrutable. Could there be a reference implementation? It was easy to fool every implementation I could get my hands on, including Gnu's over-the-top 9000-line implementation. But as I got into it, I got fascinated by regexes per se. In making a recognizer, there's a tradeoff between contruction time and execution time. Linear execution can be achieved, but at a potentially exponential cost in construction time (and space). Backreferencing takes the regex languages out of the class of regular languages. Recalling that regular languages are closed under intersection and negation, I wondered about how to implement new regex operators, & and -. I came up with a scheme for this optional non-Posix feature that involved layering continuation-passing over more traditional methods. And while I was at it, I broke out smaller sublanguages for special treatment (as does Gnu), all the way down to Knuth-Morris-Pratt for expressions in which the only operation is catenation. And finally, having followed the development of C++ from its infancy, I wanted to try out its new template facility, so there's a bit of that in the package, too. Arnold has discovered that not only has C++ evolved, but also that without the discipline of -Wall to force clean code, I was rather cavalier about casting, both explicitly and implicitly. The only real customer the code ever had was the AST project, which translated it to C. After the C++ had sat idle for a half-dozen years, I thought to revive it in Linux, but found it riddled with incompatibilities with that new environment and gave up. Arnold deserves a citation for bravery in pushing that through 15 years further on. Doug

6 years, 9 months

3
2
0 0

In Memoriam: Per Brinch Hansen

by Dave Horsfall

[ I've always posted these to TUHS with no objections, so I have no idea whether COFF would be a better forum; feel free to spank me (I might even enjoy it!) ] We lost Per Brinch Hansen, a computer scientist, on this day in 2007. He specialised in operating systems and concurrent programming, and wrote the classic book "Operating System Principles" which was published in six languages for decades. He also wrote another book "The Architecture of Concurrent Programs" which demonstrated an entire operating system written in Concurrent Pascal (much like the Lions' books on Unix). -- Dave

6 years, 9 months

3
2
0 0

That tour through the C compiler...

by Dave Horsfall

My DuckDuckGo-fu appears to be on the blink (and I refuse to use Google out of privacy concerns); is there a PDF/PS/groff somewhere? I don't use fancy-wanky markup languages. Thanks. -- Dave

6 years, 10 months

2
1
0 0

Re: [TUHS] Looking for final C compiler by Dennis Ritchie

by Paul Ruizendaal

> Thank you for the info - I will certainly look at the USENIX tapes. > > I will try to port the C compiler to amd64 - while preserving as much of > the original code as I can. But not sure if this is even feasible. > > Thanks and Regards > Dibyendu If that is your goal, you might want to start with the version included with 2.11BSD. It is essentially the same as the version from V7, but with 15 more years of bug fixes. I used that source to port V6 Unix to the TI990 architecture back in 2014/2015 and the good thing about it is that it still compiles with a modern gcc. For your project, I think you would be able to use the first pass ‘c0’ almost unchanged. The second pass ‘c1’ would need major restructuring. It mainly builds a tree for each expression and then performs various transformations, many of which are PDP11 specific (but also portable ones, like handling of constant expressions). It then covers the tree with code fragments selected from a library. This library (‘optable') would need a full rewrite as well. The last pass ‘c2’ is the optimiser and is also highly PDP11 specific. It reads the assembler output of ‘c1’ function by function, building an instruction list. It then performs some portable optimisations (eliminating unnecessary jumps, etc.) and also more PDP11 specific optimisations (the most complex being removing redundant register loads - the concept of which would be reusable). There are about 12,000 lines of code and as a rough guess I would say that some 40% needs rewriting. A new code fragment library would probably be some 2 to 3 thousand lines. I recall reading about a project to revive the Ritchie C compiler one or two years ago, but a quick web search came up dry. Anybody else remember reading that?

6 years, 10 months

6
11
0 0

Frank Heart, Who Helped to Design the ArpaNet IMPs at BBN Dies at 89

by Clem Cole

Note the NY Times head lines this as 'pre-Internet' which is a little sad, but what can you do: https://www.nytimes.com/2018/06/25/technology/frank-heart- who-linked-computers-before-the-internet-dies-at-89.html

6 years, 10 months

2
2
0 0

Doug McIlroy's C++ regular expression library (mostly) revived

by Arnold Robbins

Hi All. I have (mostly) revived Doug McIlroy's C++ regular expression parsing library. I gratefully acknowledge and thank him for allowing me to publish the code and for his help in finding all the bits and pieces. It's available at https://github.com/arnoldrobbins/mcilroy-regex . The main things I've done are to gather all the bits and pieces, rename files to have a .cpp extension, and get everything to compile using current g++ and standard make. I'm at the point where I could use some help. The various tests do not all run successfully. 1. make retest - a number of tests fail 2. ./tesgrep.sh - a number of tests fail 3. ./testsed.sh - tests fail with core dumps Looking briefly, some of the code in sed plays C games, casting various things arouond to pointers of different types and dereferencing them; these things tend to cause trouble in C++. I'm hopeful that more eyes on this code will help it come back to life more quickly. Any and all help will be appreciated. Thanks, Arnold P.S. Let's not start a flame war about C vs. C++ etc. etc. If you can help, please just dive in. Otherwise, just go, "wow, neat work" and move on to something else. :-) Thanks.

6 years, 10 months

1
0
0 0

Speaking commands [Was: Bell System Technical Journal archive]

by Nemo

On 15/07/2018, Warren Toomey <wkt(a)tuhs.org> wrote (in part): > Also: > https://www.youtube.com/watch?v=NTfOnGZUZDk > > Where GREP Came From - Computerphile (with Brian Kernighan) I was intrigued by BMK's comment that "ed" was never spokend as "ed" by "those in the know", which leads me to wonder how things were spoken. Here is a litte list of how I pronounce things [with others' versions in brackets]. Others will no doubt be aghast. ls - "list" sometimes "l s"; rm - "remove"; chmod - "change mode" [but I have heard "ch-mode"] ar - "archive" [others have said "arrr"] N.

6 years, 10 months

7
9
0 0

Looking for final C compiler by Dennis Ritchie

by Dibyendu Majumdar

Hi I am interested in finding out if the last C compiler code (not the earliest versions which I know are available) written by Dennis Ritchie is available somewhere. I assume that the C compiler in V7 code was written by him? Thanks and Regards Dibyendu

6 years, 10 months

3
5
0 0

grep

by Paul Winalski

On 7/18/18, Doug McIlroy <doug(a)cs.dartmouth.edu> wrote: > > The famous exception is grep, which became a verb. I think the similarity to "grab" and "grope" helped. > "grep for" and "grep out". "grep for" I'm familiar with. What does it mean to "grep out"? -Paul W.

6 years, 10 months

2
1
0 0

Re: [TUHS] TUHS Digest, Vol 32, Issue 12

by Doug McIlroy

Arnold was clerly on the Unix Room wavelength. ^All those two-letter commands were spelled out in conversation, even m-v. The pronunciation of rmdir was hybrid: r-m-dir. But when one talked about an action--not a command per se--verbs would be used: move or copy a file, list a directory. The famous exception is grep, which became a verb. There was no snappy ready-made verb that covered all the aspects of its use: search for mentions in one file, find files that mention, look for patterns, filter data, check for malformed data, ... The verb had two idiomatic variants, "grep for" and "grep out". Doug

6 years, 10 months

8
7
0 0

Re: [TUHS] Any Good dmr Anecdotes?

by Hendrik Jan Thomassen

Several decades ago, Jim Joyce of San Francisco was one of the more colorful chaps in the UNIX scene. Among other ventures he had "The Independent UNIX Bookstore", and during Usenix conferences he would rent a nearby hotel suite to sell his books to the conference attendants. Jim once told me the following story (yes, the topic is about dmr anecdotes). One day a young man came to the hotel suite and asked, in a somewhat exaggerated voice, "the best book to learn C programming". Jim pointed at a gentleman in a nearby armchair, reading, and said: "ask that gentleman because he knows everything there is to know about C". So the young man approached said gentleman, and repeated his question. The answer he got was: "Sorry, I can't help you, because I never had to learn C". Which left the young man flabbergasted. -- Hendrik-Jan Thomassen <hjt(a)ATComputing.nl> AT Computing Linux opleiders & consultants Kerkenbos 1238 Tel +31 24 352 72 82 6546 BE Nijmegen www.atcomputing.nl 'If you think education is expensive, try ignorance.'

6 years, 10 months

1
0
0 0

Bell System Technical Journal archive

by Warren Toomey

https://archive.org/details/bstj-archives (just saw this). Also: https://www.youtube.com/watch?v=NTfOnGZUZDk Where GREP Came From - Computerphile (with Brian Kernighan) Cheers, Warren

6 years, 10 months

1
0
0 0

Any Good dmr Anecdotes?

by Warren Toomey

We do have ken on the list, so I won't be presumptious to ask for ken-related anecdotes, but would anybody like to share some dmr anecdotes? I never met Dennis in person, but he was generous with his time about my interest in Unix history; and also with sharing the material he still had. Dennis was very clever, though. He would bring out a new artifact and say: well, here's what I still have of X. Pity it will never execute again, sigh. I'm sure he knew that I would take that as a challenge. Mind you, it worked, which is why we now have the first Unix kernel in C, the 'nsys' kernel, and the first two C compilers, in executable format. Any other good anecdotes? Cheers, Warren

6 years, 10 months

18
29
0 0

Happy birthday, Maurice Wilkes!

by Dave Horsfall

As I continue to push the boundaries of subjective topicism, I'd like to mention that today was when Sir Maurice Wilkes FRS FReng was born way back in 1913. He had a bit to do with EDSAC, microprogramming, and that sort of thing. And dmmmit, I missed Alan Turing's birthday last Saturday (23rd June, 1912), and Komrad Zuse's back in 22nd June, 1910, along with the Qwerty keyboard being patented by one Christopher Sholes back in 1868 (long story). -- Dave

6 years, 10 months

2
1
0 0

Re: [TUHS] Any Good dmr Anecdotes?

by arnold＠skeeve.com

Hi All. Kudos to Warren for helping me track down the original USENET postings that make up a fun DMR story. In October of 1985, a guy from Teklabs posted a long rant against both Unix and the people at USENIX conferences. The original rant is available here (thanks Warren!): > https://www.tuhs.org/Usenet/comp.org.usenix/1985-October/000163.html > and in this text file: > https://www.tuhs.org/Usenet/comp.org.usenix/1985-October.txt.gz Dennis replied - the relevant part of what he was replying to is in his message available here: > https://www.tuhs.org/Usenet/comp.unix/1985-October/005952.html Here is the full text of Dennis's note: | Groupies | | dmr at dutoit.UUCP dmr at dutoit.UUCP | Wed Oct 9 15:30:04 AEST 1985 | |------------------------------------------------------------------------ | | tekadg!davidl writes, at considerable length and with widespread distribution: | | > ... Socially, Usenix is like a | > spherical glob, with a handful of original software authors at the center (the | > ones who wrote the original code, like the developers of Unix, C, etc. - the | > ones whose names are always being bandied about). Around these, there's a | > surrounding shell of what has been aptly called "Unix groupies" trying to | > associate themselves, both logically and physically, with the "illuminati" | > at the center. Typically, these loathsome little insects are system | > administrators and hackers who spend their time either on the net or | > endlessly rewriting UUCP or NROFF or, or, or... And, I'm told, there are | > even some real, honest-to-goodness groupies (of the rock-star variety) who | > spend their time trying get near the "inner circle" for - never mind... | > it's believable, though - it's certainly consistent with the demeanor of | > the rest of the proceedings. | | Usenix conventions, which are undeniably and appropriately narrow-minded | and introverted, sport more than a few bores, but are notable for absence | of loathsome insects. Even the irascible Rob Pike remarked after Portland, | "Goodness, there were very few loathesome insects there." | | They are also marked by a lack of honest-to-goodness rock-star-variety | groupies. Believe me on this. The free cocaine was nowhere in evidence, | I consumed no cigar-sized hash bombers, the insistent, complaisant | lovelies were elsewhere by the time I got back from dinner. Indeed, the | plaster of Paris I had obtained in case anyone wanted a cast of my genitals | went entirely unused. | | Still, I understand the party that AT&T threw in Washington | was pretty wild. Too bad I missed it. | | DMR All this was in October 1985. At the Atlanta USENIX in the summer of 1986, there was some kind of contest (I don't remember what) and they announced (undoubtedly as a joke) that one of the prizes was "a plaster cast of Dennis Ritchie's genitals." It got a good laugh. Arnold

6 years, 10 months

1
0
0 0

Re: [TUHS] ATT Hardware

by Norman Wilson

Ron Natalie: My favorite 3B2ism was that the power switch was soft (uncommon then, not so much now). I seem to recall that if the logged in user wasn't in a particular group, pushing the power button was a no-op. You didn't have sufficient privs to operate the power. ==== Surely you mean the current user didn't have sufficent power. Norman Wilson Toronto ON

6 years, 10 months

6
7
0 0

Re: [TUHS] Any Good dmr Anecdotes?

by Paul Ruizendaal

Not quite a dmr anecdote, but maybe this list can clear up a statement that dmr reputedly made: “streams means something different when shouted”. I think the claim goes back to around the turn of the millennium and as far as I know it is not disputed that dmr either said this or could have said this. Now, from reading this list over the years my understanding of the above statement is that dmr designed streams as a mechanism to clean up the kernel handling of line disciplines in a context of access via a terminal and/or modem, and that STREAMS developed this into a way to integrate network stacks with the kernel — hence streams meant something different when shouted. The original dmr paper (1984) on streams (http://cm.bell-labs.co/who/dmr/st.html) seemed to support this understanding, focussing on terminal handling in its discussion. Also, near the end it says: "Streams are linear connections; by themselves, they support no notion of multiplexing, fan-in or fan-out. [...] It seems likely that a general multiplexing mechanism could help in both cases, but again, I do not yet know how to design it.” This seemed to exclude usage for networking, which is typically multiplexed. However, now that the V8 sources are available it is clear that the streams mechanism was used (by dmr?) to implement TCP/IP networking. He explains how that tallies with the above quote on multiplexing in a 1985 usenet post: https://groups.google.com/forum/#!topicsearchin/net.unix-wizards/subject$3A… (if the post by dmr does not immediately appear, click on the 8-10-85 post by 'd...(a)dutoit.xn--uucp-y96a to make it fold out: this is the message I refer to). The way I read this usenet post, dmr was actually reasonably content with implementing a network stack on top of (lowercase) streams. This then implies that he was alluding to something else when saying “streams means something different when shouted” (or maybe he never said it). Any opinions on what he might have meant?

6 years, 10 months

1
0
0 0

Re: [TUHS] AT&T Hardware

by Doug McIlroy

Anent 3B's: Last time I visited Paul Allen's Living Computer Museum the only working Unix on display was running on a 3B2. Apparently the machine was robust if nothing else. doug

6 years, 10 months

5
4
0 0

Horrific AT&T Hardware

by Lyndon Nerenberg

I'm not sure if I should ask this, but here goes ... Have any of you had the misfortune of dealing with that wonder that was the 3B4000? --lyndon

6 years, 10 months

1
0
0 0

A New Mail List for TUHS chat

by Warren Toomey

All, I've removed the moderation on the TUHS list. Given that you would like to chat about non-TUHS stuff, I've made a new list: coff(a)tuhs.org E-mail me if you want to subscribe. I'll be in the road until the weekend but I will process requests daily. Cheers! Warren

6 years, 10 months

3
2
0 0

Rivers, the ragged right, and BCPL roff (was: Spooky action at a distance in line adjustment...sometimes)

by Doug McIlroy

> I was poking around on the Unix v7 man page archive the other day, and > discovered to my delight that BCPL roff's request list was documented > there. Yes, it's the same spec, though reimplementated; there was no BCPL compiler for the PDP-11. > Unfortunately, it was marked up in...BCPL roff embedded within > a man page, which hopelessly confused groff. I edited the v7 manual and I believe I proofread every man page. How could I have overlooked the misbehavior of the .li request*, which was even then not in the reference manual's list of n/troff requests? On closer examination, .li does appear in a condensed alphabetical list of requests--and it appears in the source. But if Joe never described it, it's no surprise that groff dropped it. It is totally unnecessary--a bit of special pleading rendered obsolete by Joe's elegant invention of \&. doug * .li causes the next line to be read literally, even if it begins with a dot.

6 years, 10 months

2
1
0 0

Re: [TUHS] Any Good dmr Anecdotes?

by Norman Wilson

Greg Lehey: No, that was Peter Weinberger, as dmr confirmed. There's quite a story behind what happened to the stencil. I'll let Warren tell it, but if you want to cheat, check http://www.lemis.com/grog/diary-oct2002.php#17 ==== There are many stories behind the use and abuse of Peter's face. The canonical source is http://spinroot.com/pico/pjw.html spinroot.com belongs to Gerard Holzman, who was involved with many creative uses of digitized photography during my time at the Labs. (Also much work on software reliability, which he now pursues at JPL.) The org chart with every face replaced by Peter's was on the wall of the UNIX Room when I first visited 1127 in February 1984. I suspect it appeared not long after Peter became a department head, but I don't know just when that was. Peter didn't really take the alleged glory of being a department head all that seriously, just the responsibilities. One of the official glories was that Department Heads were supposed to get carpet in their offices, atop the standard linoleum tiles. Peter didn't want it, and (as he told me the story later) had to argue with Facilities a lot not to get it. Somehow this resulted in a trophy: a small square of carpet stuck to the wall outside his office. Norman Wilson Toronto ON

6 years, 10 months

1
0
0 0

Unix Kernel Size

by Warner Losh

Greetings, I'd like to thank everybody that sent me data for my unix kernel size stuff. There's two artifacts I've crated. One I think I've shared before, which is my spreadsheet: https://docs.google.com/spreadsheets/d/13C77pmJFw4ZBmGJuNarBUvWBxBKWXG-jtvA… The second are some simplified graphs and the first half of my BSDcan talk: http://www.bsdcan.org/2018/schedule/events/934.en.html The video should be available soon for my talk as well, but it's not up yet. If there's interest, I'll post an update when it is. Warner

6 years, 10 months

2
2
0 0

Re: [TUHS] Masscomp oops [was: Any Good dmr Anecdotes?]

by jnc＠mercury.lcs.mit.edu

> From: Mike Markowski > a cute, slender gal came into the lab. ... I typed mkfs... On the plus > side, I ended up marrying the girl. OK, so now I _have_ to hear the backstory - _when_ did you tell her what happened? Then? (Maybe she noticed the look on your face once you realized what you'd done? :-) Later? Never? :-) Noel

6 years, 10 months

2
1
0 0

Re: [TUHS] Any Good dmr Anecdotes?

by Larry McVoy

I've told this story so much that my kids hear me start it and go "is that the Unix guy? Yeah, we've heard this". And I think many of you have heard it as well so you can hit delete, but for the newbies to the list here goes. Decades ago I was a grad student at UWisc and pretty active on comp.arch and comp.unix-wizards (I was not a wizard but I've lived through, and written up, the process of restoring a Masscomp after having done some variant of rm -rf / so a stupid wizard wanna be?) >From time to time, some Unix kernel thing would come up and I'd email ...!research!dmr and ask him how that worked. He *always* replied. To me, a nobody. All he cared was that the question wasn't retarded (and I bet to him some of mine were but the questions showed that I was thinking and that was good enough for him). I remember a long discussion about something, I think PIPEBUF but not sure, and at some point he sent me his phone number and said "call me". Email was too slow. So yeah, one of the inventors of Unix was cool enough to take some young nobody and educate him. That's Dennis. I've tried to pass some of that energy forward to my kids, telling them that if you want to learn, smart people like that and they will help you. Dennis was a humble man, a smart man, and a dude willing to pass on what he knew. I miss him and cherish the interactions I had with him.

6 years, 10 months

4
3
0 0

Moderation on for a bit

by Warren Toomey

OK, so now I'm a bit p*ssed off. We've losy Johnny a few days ago because of the traffic on the list and now Tim is asking to be unsubscribed. First up: Unix Heritage. I don't mind a bit of drift but seriously?! I put in a nugde to wind up the comp.arch chat but that didn't help. Secondly: a few of you need to pull your heads in. The TUHS list is going to be moderated for the next couple of days. If you really feel it necessary, you can post a _summary_ of your comp.arch position and then stop. Posts on Unix anecdotes and on-topic stuff I will let through. Cheers, Warren

6 years, 10 months

2
1
0 0

PDP-11 legacy, C, and modern architectures

by Nelson H. F. Beebe

There is a provocative article published today in the lastest issue of Communications of the ACM: David Chisnall C is not a low-level language Comm ACM 61(7) 44--48 July 2018 https://doi.org/10.1145/3209212 Because C is the implementation language of choice for a substantial part of the UNIX world, it seems useful to announce the new article to TUHS list members. David Chisnall discusses the PDP-11 legacy, the design of C, and the massive parallelism available in modern processors that is not so easy to exploit in C, particularly, portable C. He also observes: >> ... >> A processor designed purely for speed, not for a compromise between >> speed and C support, would likely support large numbers of threads, >> have wide vector units, and have a much simpler memory model. Running >> C code on such a system would be problematic, so, given the large >> amount of legacy C code in the world, it would not likely be a >> commercial success. >> ... ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 10 months

22
65
0 0

ATT Hardware

by ron＠ronnatalie.com

The recent reference to the Dennis's comments on ATT chip production had me feeling nostalgic to the 3B line of computers. In the late 80's I was in charge of all the UNIX systems (among other things) at the state university system in New Jersey. As a result we got a lot of this hardware gifted to us. The 3B5 and 3B2s were pretty doggy compared with the stuff on the market then. The best thing I could say about the 3B5 is that it stood up well to having many gallons of water dumped on it (that's another story, Rutgers had the computer center under a seven story building and it still had a leaky roof). The 3B20 was another thing. It was a work of telephone company art. You knew this when it came to power it down where you turned a knob inside the rack and held a button down until it clicked off. This is pretty akin to how you'd do things on classic phone equipment (for instance, the same procedure is used to loopback the old 303 "broadband" 50K modems that the Arpanet/Milnet was built out of). Of course, the 3B20 was built as phone equipment. It just got sort of "recycled" as a GP computer.

6 years, 10 months

5
7
0 0

Faster cpus at any cost

by Steve Simon

I know this is a dangerous game to play, but what of the future? I am intrigued by the idea of true optical computers, perhaps the $10M super-computer will return? GPUs have definitely taken over in some areas - even where SIMD would not seem a good fit. My previous employer does motion estimation of realtime video and has moved from custom electronics and FPGAs to using off the shelf GPUs in PCs. -Steve

6 years, 10 months

4
3
0 0

C Threading

by ron＠ronnatalie.com

Thread local storage and starting threads up is largely a rather inconsequential implementation detail. When it comes down to actual parallel programming, of which I have done more than a little, the big thing is thread synchronization. It's rather hardware dependent. You can pretty much entirely wipe out any parallism gains with a synchronization call that results in a context switch or even a serious cache impact. On one side you have machines like the Denelcor HEP where every memory word had a pair of semaphores on it and the instructions could stall the process while waiting for them and the hardware would schedule the other threads. On the other hand you have your x86, which you can do a few clever things with some atomic operations and inlined assembler but a lot of the "standard" (boost, pthread, etc...) synchs will kill you.

6 years, 10 months

2
1
0 0

please ignore this message

by Doug McIlroy

This tests a guess about anomalous behavior of the mailing-list digest. I apologize for inflicting it on everybody. Doug

6 years, 10 months

4
3
0 0

Any Definitive Unix Celebrations Next Year?

by Warren Toomey

All, I'm planning to come to the Usenix ATC next year on July 10-12 on the assumption that there will be some Unix 50th celebration there. Does anybody know of other events in the date range June 28 to July 9, as those are the dates I'll be able to get off work. And/or, if I'm in the U.S on these dates, does anybody want to catch up? Just trying to build an itinerary for this time next year. Thanks, Warren

6 years, 10 months

1
0
0 0

Re: [TUHS] PDP-11 legacy, C, and modern architectures

by jnc＠mercury.lcs.mit.edu

> But don't forget Clarke's Third Law! Ooops. Read my Web search results wrong. (Should have taken the time to click through, sigh.) Meant 'Clarke's First Law'. Noel

6 years, 10 months

1
0
0 0

Re: [TUHS] PDP-11 legacy, C, and modern architectures

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy > This is a really poor place for a younger person to come in and make > loud points, that is frowned upon. It's a fantastic place for a younger > person to come in and learn. But don't forget Clarke's Third Law! And maybe you can remember what it's like when you're young... :-) But Ted does have a point. 'Distributed' != 'parallel'. Noel

6 years, 10 months

1
0
0 0

Re: [TUHS] off-topic list

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > the MTA part is not there That system was using the MMDF MTA: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/mmdf written by David Crocker while he was at UDel (under Farber). Noel

6 years, 10 months

14
21
0 0

Re: [TUHS] core

by Nelson H. F. Beebe

The discussion of the last few days about the Colossus is getting somewhat off-topic for Unix heritage and history, but perhaps this list of titles (truncated to 80 characters) and locations may be of interest to some TUHS list readers. ------------------------------------------------------------------------ Papers and book chapters about the Colossus at Bletchley Park Journal- and subject specific Bibliography files are found at http://www.math.utah.edu/pub/tex/bib/NAME.bib and author-specific ones under http://www.math.utah.edu/pub/bibnet/authors/N/ where N is the first letter of the bibliography filename. The first line in each group contains the bibliography filename, and the citation label of the cited publication. DOIs are supplied whenever they are available. Paragraphs are sorted by filename. adabooks.bib Randell:1976:C The COLOSSUS annhistcomput.bib Good:1979:EWC Early Work on Computers at Bletchley https://doi.org/10.1109/MAHC.1979.10011 annhistcomput.bib deLeeuw:2007:HIS Tunny and Colossus: breaking the Lorenz Schl{\"u}sselzusatz traffic https://www.sciencedirect.com/science/article/pii/B978044451608450016X babbage-charles.bib Randell:1976:C The COLOSSUS cacm2010.bib Anderson:2013:MNF Max Newman: forgotten man of early British computing https://doi.org/10.1145/2447976.2447986 computer1990.bib Anonymous:1996:UWI Update: WW II Colossus computer is restored to operation cryptography.bib Good:1979:EWC Early Work on Computers at Bletchley cryptography1990.bib Anonymous:1997:CBP The Colossus of Bletchley Park, IEEE Rev., vol. 41, no. 2, pp. 55--59 [Book Revi https://doi.org/10.1109/MAHC.1997.560758 cryptography2000.bib Rojas:2000:FCH The first computers: history and architectures cryptography2010.bib Copeland:2010:CBG Colossus: Breaking the German `Tunny' Code at Bletchley Park. An Illustrated His cryptologia.bib Michie:2002:CBW Colossus and the Breaking of the Wartime ``Fish'' Codes debroglie-louis.bib Homberger:1970:CMN The Cambridge mind: ninety years of the booktitle Cambridge Review, 1879--1969 dijkstra-edsger-w.bib Randell:1980:C The COLOSSUS dyson-freeman-j.bib Brockman:2015:WTA What to think about machines that think: today's leading thinkers on the age of fparith.bib Randell:1977:CGC Colossus: Godfather of the Computer ieeeannhistcomput.bib Anonymous:1997:CBP The Colossus of Bletchley Park, IEEE Rev., vol. 41, no. 2, pp. 55--59 [Book Revi https://doi.org/10.1109/MAHC.1997.560758 lncs1997b.bib Carter:1997:BLC The Breaking of the Lorenz Cipher: An Introduction to the Theory behind the Oper lncs2000.bib Sale:2000:CGL Colossus and the German Lorenz Cipher --- Code Breaking in WW II master.bib Randell:1977:CGC Colossus: Godfather of the Computer mathcw.bib Randell:1982:ODC The Origins of Digital Computers: Selected Papers http://dx.doi.org/10.1007/978-3-642-61812-3 rutherford-ernest.bib Homberger:1970:CMN The Cambridge mind: ninety years of the booktitle Cambridge Review, 1879--1969 rutherfordj.bib Copeland:2010:CBG Colossus: Breaking the German `Tunny' Code at Bletchley Park. An Illustrated His sigcse1990.bib Plimmer:1998:MIW Machines invented for WW II code breaking https://doi.org/10.1145/306286.306309 turing-alan-mathison.bib Randell:1976:C The COLOSSUS von-neumann-john.bib Randell:1982:ODC The Origins of Digital Computers: Selected Papers ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 10 months

27
62
0 0

Re: [TUHS] Old mainframe I/O speed (was: core)

by Johnny Billquist

On 2018-06-22 20:01, Clem Cole<clemc(a)ccc.com> wrote: > One of the other BI people, who's name now escapes me, although I can see > his face in my mind, maybe I'll think of it later), would go on to do the > PCI for Alpha a couple of years later. As I said, DEC did manage to get > that one public, after the BI was made private as Erik points out. Clem, I think I saw you say something similar in an earlier post. To me it sounds as if you are saying that DEC did/designed PCI. Are you sure about that? As far as I know, PCI was designed and created by Intel, and the first users were just plain PC machines. Alpha did eventually also get PCI, but it was not where it started, and DEC had no control at all about PCI being public. Might you have been thinking of Turbobus, Futurebus, or some other thing that DEC did? Or do you have some more information about DEC being the creator of PCI? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

4
7
0 0

Masscomp Engineering Mailing List, Custom Products Engineering and the Manatee

by Clem Cole

Semi-Unix History.... Dave's "this date in history stuff" has reminded me of a great Masscomp story that really needs to be written down and not lost to Unix history. I'm hoping Warren can forgive me a little as the Unix history is the Masscomp part and people involved; but I think it is fun and should be more widely known. Some of you may know who Jack Burness is (and even be part of his humor mailing list - which is one of the most amazing who-is-who of the industry). Jack is probably most infamous for his being the author of RT-11 Moonlander <https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre)>. Some of his stunts over his career are legends, as our old friend and colleague Mike Leibensperger once said, I want to be like Jack, when he grows up (at ~70, I can assure you that he still has not). After Jack left DEC, he became the original one man Masscomp Graphics group. While the year really does not matter, at some point, Jack had been given a tear off desk calendar as a Christmas present from his girfriend called the 'Sex Fact of the Day Calendar.' Like Dave's daily reminders to us on TUHS, every morning he typed in the one line factiod and passed it on to the Masscomp Engineering Mailing List. This is important because the VCs had just given us a straight laced ex-IBM guy as a president named Gus Klein (aka Mr. Potatohead), who did not read email, and of course did not read the engineering mailing list. He wants to workspace to be 'professional' and look like his idea of an 'office' and his 'memos' were amazing as you can imagine. The other important note to the story is that the late Roger Gourd, our direct boss, had just created Masscomp's new Custom Product Engineering (CPE) group; to be the analog to DEC's CSS. When Roger had left DEC for Gould he had of course, moved to south Florida where they were based and become quite a fisherman and protector of natural resources. When he was recruited to come move back to New England to take on the reins in development at Masscomp be brought some of south Florida back with him. Well from Jack we had learn two important facts and from those facts realized that mediterranean fisherman were liars: at some time in March it was reported that fisherman in the med that caught a female manatee in their nets and brought it into their boat considered it bad luck unless they sodomized them because the manatee were thought to be mermaids; and some time in May we learned that the Roman Catholic Church would excommunicate any fisherman if it was discovered that said fisherman had caught a manatee and that manatee had been used as a sex toy. Upon learning this interesting catch-22, Gourd immediately sponsors the "Save the Manatee Society in South Florida" and makes it the Group Mascot for CPE. Well, manatees start popping up all over engineering. Mr. Potatohead is clueless of the significance of course. At his memorial I gave Roger's widow a stuffed manatee I still had from my desk from those days, she knew and laughed and laughed knowing that Roger would have approved. BTW: I do however, still keep 'Darth Tater, on my desk at Intel'.

6 years, 11 months

1
0
0 0

Re: [TUHS] off-topic list

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > I may have the the original Rand MH release somewhere. There's this: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC/mh Not sure how modified from the formal release this is, it may be pretty much the original (it's certainly quite old - pre-TCP/IP). Noel

6 years, 11 months

5
5
0 0

Re: [TUHS] off-topic list

by jnc＠mercury.lcs.mit.edu

> On 06/23/2018 04:38 PM, Steffen Nurpmeso wrote: > Others like DNS are pretty perfect and scale fantastic. It's perhaps worth noting that today's DNS is somewhat different from the original; some fairly substantial changes were made early on (although maybe it was just in the security, I don't quite recall). (The details escape me at this point, but at one point I did a detailed study of DNS, and DNS security, for writing the security architecture document for the resolution system in LISP - the networking one, not the language.) Noel

6 years, 11 months

5
5
0 0

Re: [TUHS] Old mainframe I/O speed (was: core)

by Norman Wilson

Paul Winalski: That was the VAXstation-11/RC. === Yep, that's the name. My first batch of discarded MicroVAX IIs were the original backbone routers for a large university campus, installed ca. 1990. That backbone ran over serial-line connections, at 56Kbps, which was quite impressive for the day given the physical distances involved. Either they had a bunch of Qbus backplanes lying around, or someone computed that the cost of an 11/RC plus a backplane was appreciably less than a system with an unobstructed backplane. In any case, they swapped most of the backplanes themselves. The one I got that still had the glue in was an anomaly; maybe it was a spare chassis. The MicroVAX routers ran Ultrix, and some of them had uptimes of five years when they were finally shut down to be discarded. All the hardware I rescued tested out fine, and some of it is still running happily in my basement. I've had a few disk failures over the years, and I think lost one power supply back around Y2K and maybe had a DZV11 fail, but that's it. We don't make hardware like that any more. Norman Wilson Toronto ON

6 years, 11 months

1
0
0 0

Re: [TUHS] Old mainframe I/O speed (was: core)

by Norman Wilson

Paul Winalski: Rather than design a new CPU, they just put NOPs in the Skipjack microcode to slow it down. The official code name for this machine was Flounder, but within DEC engineering we called it "Wimpjack". Customers could buy a field upgrade for Flounder microcode that restored it to Skipjack performance levels. ==== As I remember it, once it came out that the upgrade merely removed gratuitous nops, customers raised sufficient fuss that the denopped microcode was made available for free (perhaps only to those with service contracts) and Flounder (VAX 8500) was no longer sold. Norman Wilson Toronto ON

6 years, 11 months

1
0
0 0

Re: [TUHS] Old mainframe I/O speed (was: core)

by norman＠oclsc.org

Ron Minnich: Jon Hall used to love telling the story of the VAX backplane with the glue in the board slots, which clever customers managed to damage and have repaired with a non-glued-up backplane. ===== It wasn't exactly a VAX backplane; it was a QBus backplane, though I don't know whether this marketing-induced castration was performed on anywhere but on the backplaces of certain MicroVAX models. I think one of my saved-from-the-dumpster BA23s had one of those backplanes. I just declared it to be a source of spare parts, other than backplanes. Norman Wilson Toronto ON

6 years, 11 months

4
3
0 0

Re: [TUHS] off-topic list

by norman＠oclsc.org

Grant Taylor: Why do you have to give up one tool to start using a different tool? ==== I hereby declare this part of the conversation very much on-topic for TUHS. The question of what tools should exist, what should do what, whether to make a new tool or add something to an existing one, is a continuing thread in the history of UNIX and its use and abuse. Norman Wilson Toronto ON

6 years, 11 months

1
0
0 0

Re: [TUHS] Request: Unix Photos, scanned ephemera, anecdotes, stories, interviews

by Peter Adams

Over the last few years I’ve photographed many of the people listed on the wiki. You can see the photos here: http://facesofopensource.com -P- -- Peter Adams http://www.peteradamsphoto.com > On Jun 22, 2018, at 7:32 PM, Warren Toomey <wkt(a)tuhs.org> wrote: > > All, I've had a fair bit of positive feedback for my TUHS work. In reality > I'm just the facilitator, collecting the stuff that you send me and keeping > the mailing list going. > > I think we've captured nearly all we can of the 1970s Unix in terms of > software. After that it becomes commercial, but I am building up the > "Hidden Unix" archive to hold that. Just wish I could open that up ... > > What we haven't done a good job yet is to collect other things: photos, > stories, anecdotes, scanned ephemera. > > Photos & scanned things: I'm very happy to collect these, but does anybody > know of an existing place that accepts (and makes available online) photos > and scanned ephemera? They are a bit out of scope for bitsavers as far as > I can tell, but I'm happy to be corrected. Al? Other comments here? > > Stories & anecdotes: definitely type them in & e-mail them in and/or e-mail > them to me if you want me just to preserve them. There is the Unix wiki I > started here: https://wiki.tuhs.org/doku.php?id=start, but maybe there is > already a better place. Gunkies? > > Interviews: Sometimes it's easier to glean stories & knowledge with interviews. > I've never tried this but perhaps it's time. Who is up to have an audio > interview? I'll worry about the technical details eventually, but is there > interest? > > All of the above would slot in with the upcoming 50th anniversary. If you > do have photos, bits of paper, stories to tell etc., then let's try to > preserve them so that they are not lost. > > Cheers all, Warren >

6 years, 11 months

1
0
0 0

(Meta) mail about mail about mail ...

by Warren Toomey

I think it might be time for "Peter Out" to arrive here :-) Cheers, Warren

6 years, 11 months

1
0
0 0

Request: Unix Photos, scanned ephemera, anecdotes, stories, interviews

by Warren Toomey

All, I've had a fair bit of positive feedback for my TUHS work. In reality I'm just the facilitator, collecting the stuff that you send me and keeping the mailing list going. I think we've captured nearly all we can of the 1970s Unix in terms of software. After that it becomes commercial, but I am building up the "Hidden Unix" archive to hold that. Just wish I could open that up ... What we haven't done a good job yet is to collect other things: photos, stories, anecdotes, scanned ephemera. Photos & scanned things: I'm very happy to collect these, but does anybody know of an existing place that accepts (and makes available online) photos and scanned ephemera? They are a bit out of scope for bitsavers as far as I can tell, but I'm happy to be corrected. Al? Other comments here? Stories & anecdotes: definitely type them in & e-mail them in and/or e-mail them to me if you want me just to preserve them. There is the Unix wiki I started here: https://wiki.tuhs.org/doku.php?id=start, but maybe there is already a better place. Gunkies? Interviews: Sometimes it's easier to glean stories & knowledge with interviews. I've never tried this but perhaps it's time. Who is up to have an audio interview? I'll worry about the technical details eventually, but is there interest? All of the above would slot in with the upcoming 50th anniversary. If you do have photos, bits of paper, stories to tell etc., then let's try to preserve them so that they are not lost. Cheers all, Warren

6 years, 11 months

6
6
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: "John P. Linderman" > 4 bucks a bit! When IBM went to license the core patent(s?) from MIT, they offered MIT a choice of a large lump sump (the number US$20M sticks in my mind), or US$.01 a bit. The negotiators from MIT took the lump sum. When I first heard this story, I thought it was corrupt folklore, but I later found it in one of the IBM histories. This story repets itself over and over again, though: one of the Watson's saying there was a probably market for <single-digit> of computers; Ken Olsen saying people wouldn't want computers in their homes; etc, etc. Noel

6 years, 11 months

13
19
0 0

Slight TUHS Mailing List Policy Change

by Warren Toomey

[ A few list members asked me to re-post this out of the existing thread, so that it is more prominent. ] All, based on the comments we've had in the past day or so, it seems that you are mostly happy to stick with one list, and to tolerate a bit of off-topic material. I'm also aware that this list is approaching its own quarter-century anniversary and it has become an important historical record. So feel free to drift away from Unix now and then. But please self-regulate: if you (as an individual) think the S/N ratio is dropping, please ask the list to improve it. As always, I'll insert my own nudges and requests based on my own eclectic set of rules :-) Cheers all, Warren

6 years, 11 months

1
0
0 0

Re: [TUHS] off-topic list

by Doug McIlroy

Because some "off-topic" discussions wander into estoterica that's beyond me, I superficially thought an off-topic siding would be a good thing for some trains of thought. But then I wondered, if I ignore the siding how will I hear of new hear about new topics that get initiated there? I could miss good stuff. So I'm quite happy with the current arrangement where occasionally ever-patient Warren gives a nudge. (I'm a digest reader. If every posting came as a distinct message, I might feel otherwise.) Doug

6 years, 11 months

3
2
0 0

Re: [TUHS] Old mainframe I/O speed (was: core)

by jnc＠mercury.lcs.mit.edu

> From: "Erik E. Fair" > ordered a VAX-8810 to replace two 11/780s on the promise from DEC that > all our UniBus and MASSbus peripherals would still work ... which we > knew (from others on the Internet who'd and tried reported their > experiences) to be a lie. Just out of curiousity, why'd you all order something you knew wouldn't work? So you could get a better deal out of DEC for whatever you ordered instead, later, as they tried to make it up to you all for trying to sell you something broken? Noel

6 years, 11 months

2
1
0 0

Re: [TUHS] off-topic list

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey > Computing history is maybe too generic. There already is a "computer-history" list, hosted at the Postel Institute: http://www.postel.org/computer-history/ Unlike its sibling "Internet-history" list, it didn't catch on, though. (No traffic for some years now.) Noel

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Tim Bradshaw > There is a paper, by Flowers, in the Annals of the History of Computing > which discusses a lot of this. I am not sure if it's available online Yes: http://www.ivorcatt.com/47c.htm (It's also available behind the IEEE pay-wall.) That issue of the Annals (5/3) has a couple of articles about Colossus; the Coombs one on the design is available here: http://www.ivorcatt.com/47d.htm but doesn't have much on the reliability issues; the Chandler one on maintenance has more, but alas is only available behind the paywall: https://www.computer.org/csdl/mags/an/1983/03/man1983030260-abs.html Brian Randell did a couple of Colossus articles (in "History of Computing in the 20th Century" and "Origin of Digital Computers") for which he interviewed Flowers and others, there may be details there too. Noel

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by Nelson H. F. Beebe

Tim Bradshaw <tfb(a)tfeb.org> commented on a paper by Tommy Flowers on the design of the Colossus: here is the reference: Thomas H. Flowers, The Design of Colossus, Annals of the History of Computing 5(3) 239--253 July/August 1983 https://doi.org/10.1109/MAHC.1983.10079 Notice that it appeared in the Annnals..., not the successor journal IEEE Annals.... There is a one-column obituary of Tommy Flowers at http://doi.ieeecomputersociety.org/10.1109/MC.1998.10137 Last night, I finished reading this recent book: Thomas Haigh and Mark (Peter Mark) Priestley and Crispin Rope ENIAC in action: making and remaking the modern computer MIT Press 2016 ISBN 0-262-03398-4 https://doi.org/10.7551/mitpress/9780262033985.001.0001 It has extensive commentary about the ENIAC at the Moore School of Engineering at the University of Pennsylvania in Philadelphia, PA. Its construction began in 1943, with a major instruction set redesign in 1948, and was shutdown permanently on 2 October 1955 at 23:45. The book notes that poor reliability of vacuum tubes and thousands of soldered connections was a huge problem, and in the early years, only about 1 hour out of 24 was devoted to useful runs; the rest of the time was used for debuggin, problem setup (which required wiring plugboards), testing, and troubleshooting. Even so, runs generally had to be repeated to verify that the same answers could be obtained: often, they differed. The book also reports that reliability was helped by never turning off power: tubes were more susceptible to failure when power was restored. The book reports that reliability of the ENIAC improved significantly when on 28 April 1948, Nick Metropolis (co-inventor of the famous Monte Carlo method) had the clock rate reduced from 100kHz to 60kHz. It was only several years later that, with vacuum tube manufacturing improvements, the clock rate was eventually moved back to 100Khz. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by Doug McIlroy

Tim Bradshaw wrote: "Making tube (valve) machines reliable was something originally sorted out by Tommy Flowers, who understood, and convinced people with some difficulty I think, that you could make a machine with one or two thousand valves (1,600 for Mk 1, 2,400 for Mk 2) reliable enough to use, and then produced ten or eleven Colossi from 1943 on which were used to great effect in. So by the time of Whirlwind it was presumably well-understood that this was possible." "Colossus: The Secrest of Bletchley Park's Codebreaking Computers" by Copeland et al has little to say about reliability. But one ex-operator remarks, "Often the machine broke down." Whether it was the (significant) mechanical part or the electronics that typically broke is unclear. Failures in a machine that's always doing the same thing are easier to detect quickly than failures in a mchine that has a varied load. Also the task at hand could fail for many other reasons (e.g. mistranscribed messages) so there was no presumption of correctness of results--that was determined by reading the decrypted messages. So I think it's a stretch to argue that reliability was known to be a manageable issue. Doug

6 years, 11 months

2
1
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Core memory wiped out competing technologies (Williams tube, mercury > delay line, etc) almost instantly and ruled for over twent years. I never lived through that era, but reading about it, I'm not sure people now can really fathom just how big a step forward core was - how expensive, bulky, flaky, low-capacity, etc, etc prior main memory technologies were. In other words, there's a reason they were all dropped like hot potatoes in favour of core - which, looked at from our DRAM-era perspective, seems quaintly dinosaurian. Individual pieces of hardware you can actually _see_ with the naked eye, for _each_ bit? But that should give some idea of how much worse everything before it was, that it killed them all off so quickly! There's simply no question that without core, computers would not have advanced (in use, societal importance, technical depth, etc) at the speed they did without core. It was one of the most consequential steps in the development of computers to what they are today: up there with transistors, ICs, DRAM and microprocessors. > Yet late in his life Forrester told me that the Whirlwind-connected > invention he was most proud of was marginal testing Given the above, I'm totally gobsmacked to hear that. Margin testing was important, yes, but not even remotely on the same quantum level as core. In trying to understand why he said that, I can only suppose that he felt that core was 'the work of many hands', which it was (see e.g. "Memories That Shaped an Industry", pg. 212, and the things referred to there), and so he only deserved a share of the credit for it. Is there any other explanation? Did he go into any depth as to _why_ he felt that way? Noel

6 years, 11 months

4
3
0 0

Re: [TUHS] core

by Doug McIlroy

> > Yet late in his life Forrester told me that the Whirlwind-connected > > invention he was most proud of was marginal testing > I'm totally gobsmacked to hear that. Margin testing was > important, yes, but not even remotely on the same quantum > level as core. > In trying to understand why he said that, I can only suppose that he felt that > core was 'the work of many hands'...and so he only deserved a share of the > `credit for it. It is indeed a striking comment. Forrester clearly had grave concerns about the reliability of such a huge aggregation of electronics. I think jpl gets to the core of the matter, regardless of national security: > Whirlwind ... was tube based, and I think there was a tradeoff of speed, > as determined by power, and tube longevity. Given the purpose, early > warning of air attack, speed was vital, but so, too, was keeping it alive. > So a means of finding a "sweet spot" was really a matter of national > security. I can understand Forrester's pride in that context. If you extrapolate the rate of replacement of vacuum tubes in a 5-tube radio to a 5000-tube computer (say nothing of the 50,000-tube machines for which Whirlwind served as a prototype), computing looks like a crap shoot. In fact, thanks to the maintenance protocol, Whirlwind computed reliably--a sine qua non for the nascent industry.

6 years, 11 months

2
1
0 0

Re: [TUHS] core

by Johnny Billquist

On 2018-06-16 21:00, Clem Cole <clemc(a)ccc.com> wrote: > below... > On Sat, Jun 16, 2018 at 9:37 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote: >> >> Let's start with the UNIBUS. Why does it have only 18 address lines? (I >> have >> this vague memory of a quote from Gordon Bell admitting that was a mistake, >> but I don't recall exactly where I saw it.) > I think it was part of the same paper where he made the observation that > the greatest mistake an architecture can have is too few address bits. I think the paper you both are referring to is the "What have we learned from the PDP-11", by Gordon Bell and Bill Strecker in 1977. https://gordonbell.azurewebsites.net/Digital/Bell_Strecker_What_we%20_learn… There is some additional comments in https://gordonbell.azurewebsites.net/Digital/Bell_Retrospective_PDP11_paper… > My understanding is that the problem was that UNIBUS was perceived as an > I/O bus and as I was pointing out, the folks creating it/running the team > did not value it, so in the name of 'cost', more bits was not considered > important. Hmm. I'm not aware of anyone perceiving the Unibus as an I/O bus. It was very clearly designed a the system bus for all needs by DEC, and was used just like that until the 11/70, which introduced a separate memory bus. In all previous PDP-11s, both memory and peripherals were connected on the Unibus. Why it only have 18 bits, I don't know. It might have been a reflection back on that most things at DEC was either 12 or 18 bits at the time, and 12 was obviously not going to cut it. But that is pure speculation on my part. But, if you read that paper again (the one from Bell), you'll see that he was pretty much a source for the Unibus as well, and the whole idea of having it for both memory and peripherals. But that do not tell us anything about why it got 18 bits. It also, incidentally have 18 data bits, but that is mostly ignored by all systems. I believe the KS-10 made use of that, though. And maybe the PDP-15. And I suspect the same would be true for the address bits. But neither system was probably involved when the Unibus was created, but made fortuitous use of it when they were designed. > I used to know and work with the late Henk Schalke, who ran Unibus (HW) > engineering at DEC for many years. Henk was notoriously frugal (we might > even say 'cheap'), so I can imagine that he did not want to spend on > anything that he thought was wasteful. Just like I retold the > Amdahl/Brooks story of the 8-bit byte and Amdahl thinking Brooks was nuts; > I don't know for sure, but I can see that without someone really arguing > with Henk as to why 18 bits was not 'good enough.' I can imagine the > conversation going something like: Someone like me saying: *"Henk, 18 bits > is not going to cut it."* He might have replied something like: *"Bool > sheet *[a dutchman's way of cursing in English], *we already gave you two > more bit than you can address* (actually he'd then probably stop mid > sentence and translate in his head from Dutch to English - which was always > interesting when you argued with him). Quite possible. :-) > Note: I'm not blaming Henk, just stating that his thinking was very much > that way, and I suspect he was not not alone. Only someone like Gordon and > the time could have overruled it, and I don't think the problems were > foreseen as Noel notes. Bell in retrospect thinks that they should have realized this problem, but it would appear they really did not consider it at the time. Or maybe just didn't believe in what they predicted. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

5
7
0 0

Re: [TUHS] core

by Doug McIlroy

> jay forrester first described an invention called core memory in a lab notebook 69 years ago today. Core memory wiped out competing technologies (Williams tube, mercury delay line, etc) almost instantly and ruled for over twent years. Yet late in his life Forrester told me that the Whirlwind-connected invention he was most proud of was marginal testing: running the voltage up and down once a day to cause shaky vacuum tubes to fail during scheduled maintenance rather than randomly during operation. And indeed Wirlwind racked up a notable record of reliability. Doug

6 years, 11 months

2
1
0 0

core

by A. P. Garcia

jay forrester first described an invention called core memory in a lab notebook 69 years ago today. kill -3 mailx core dumped

6 years, 11 months

9
9
0 0

Re: [TUHS] core

by Doug McIlroy

> As best I now recall, the concept was that instead of the namespace having a root at the top, from which you had to allocate downward (and then recurse), it built _upward_ - if two previously un-connected chunks of graph wanted to unite in a single system, they allocated a new naming layer on top, in which each existing system appeared as a constituent. The Newcastle Connection (aka Unix United) implemented this idea. Name spaces could be pasted together simply by making .. at the roots point "up" to a new superdirectory. I do not remember whether UIDS had to agree across the union (as in NFS) or were mapped (as in RFS). Doug

6 years, 11 months

1
0
0 0

In memorium: T.J. Watson

by Dave Horsfall

We lost the founder of IBM, Thomas J. Watson, on this day in 1956 (and I have no idea whether or not he was buried 9-edge down). Oh, and I cannot find any hard evidence that he said "Nobody ever got fired for buying IBM"; can anyone help? I suspect that it was a media beat-up from his PR department i.e. "fake news"... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by Johnny Billquist

On 2018-06-18 14:17, Noel Chiappa wrote: > > The "separate" bus for the semiconductor memory is just a second Unibus > > Err, no. :-) There is a second UNIBUS, but... its source is a second port on > the FASTBUS memory, the other port goes straight to the CPU. The other UNIBUS > comes out of the CPU. It _is_ possible to join the two UNIBI together, but > on machines which don't do that, the _only_ path from the CPU to the FASTBUS > memory is via the FASTBUS. Ah. You and Ron are right. I am confused. So there were some previous PDP-11 models who did not have their memory on the Unibus. The 11/45,50,55 accessed memory from the CPU not through the Unibus, but through the fastbus, which was a pure memory bus, as far as I understand. You (obviously) could also have memory on the Unibus, but that would be slower then. Ah, and there is a jumper to tell which addresses are served by the fastbus, and the rest then go to the Unibus. Thanks, I had missed these details before. (To be honest, I have never actually worked on any of those machines.) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > My experience is that more often than not, it's less a failure to see > what a successful future might bring, and often one of well '*we don't > need to do that now/costs too much/we don't have the time*.' Right, which is why I later said a "successful architect has to pay _very_ close attention to both the 'here and now' (it has to be viable for contemporary use, on contemporary hardware, with contemporary resources)". They need to be sensitive to the (real and valid) concerns of people about who are looking at today. By the same token, though, the people you mention need to be sensitive to the long-term picture. Too often they just blow it off, and focus _solely_ on today. (I had a really bad experience with someone like that just before I retired.) They need to understand, and accept, that that's just as serious an error as an architect who doesn't care about 'workable today'. In retrospect, I'm not sure you can fix people who are like that. I think the only solution is to find an architect who _does_ respect the 'here and now', and put them in control; that's the only way. IBM kinda-sorta did this with the /360, and I think it showed/shows. > I can imagine that he did not want to spend on anything that he thought > was wasteful. Understandable. But see above... The art is in finding a path that leave the future open (i.e. reduces future costs, when you 'hit the wall'), without running up costs now. A great example is the QBUS 22-bit expansion - and I don't know if this was thought out beforehand, or if they just lucked out. (Given that the expanded address pins were not specifically reserved for that, probably the latter. Sigh - even with the experience of the UNIBUS, they didn't learn!) Anyway.. lots of Q18 devices (well, not DMA devices) work fine on Q22 because of the BBS7 signal, which indicates an I/O device register is being looked at. Without that, Q18 devices would have either i) had to incur the cost now of more bus address line transceivers, or ii) stopped working when the bus was upgraded to 22 address lines. They managed to have their cake (fairly minimal costs now) and eat it too (later expansion). > Just like I retold the Amdahl/Brooks story of the 8-bit byte and Amdahl > thinking Brooks was nuts Don't think I've heard that one? >> the decision to remove the variable-length addresses from IPv3 and >> substitute the 32-bit addresses of IPv4. > I always wondered about the back story on that one. My understanding is that the complexity of variable-length address support (which impacted TCP, as well as IP) was impacting the speed/schedule for getting stuff done. Remember, it was a very small effort, code-writing resources were limited, etc. (I heard, at the time, from someone who was there, that one implementer was overheard complaining to Vint about the number of pointer registers available at interrupt time in a certain operating system. I don't think it was _just_ that, but rather the larger picture of the overall complexity cost.) > 32-bits seemed infinite in those days and no body expected the network > to scale to the size it is today and will grow to in the future Yes, but like I said: they failed to ask themselves 'what are things going to look like in 10 years if this thing is a success'? Heck, it didn't even last 10 years before they had to start kludging (adding A/B/C addresses)! And ARP, well done as it is (its ability to handle just about any combo of protocol and hardware addresses is because DCP and I saw eye-to-eye about generality), is still a kludge. (Yes, yes, I know it's another binding layer, and in some ways, another binding layer is never a bad thing, but...) The IP architectural concept was to carry local hardware addresses in the low part of the IP address. Once Ethernet came out, that was toast. >> So, is poor vision common? All too common. > But to be fair, you can also end up with being like DEC and often late > to the market. Gotta do a perfect job of balance on that knife edge - like an Olympic gymnast on the beam... This is particularly true with comm system architecture, which has about the longest lifetime of _any_ system. If someone comes up with a new editor or OS paradigm, people can convert to it if they want. But converting to a new communication system - if you convert, you cut yourself off. A new one has to be a _huge_ improvement over the older gear (as TCP/IP was) before conversion makes sense. So networking architects have to pay particularly strong attention to the long term - or should, if they are to be any good. > I think in both cases would have been allowed Alpha to be better > accepted if DEC had shipped earlier with a few hacks, but them improved > Tru64 as a better version was developed (*i.e.* replace the memory > system, the I/O system, the TTY handler, the FS just to name a few that > got rewritten from OSF/1 because folks thought they were 'weak'). But you can lose with that strategy too. Multics had a lot of sub-systems re-written from the ground up over time, and the new ones were always better (faster, more efficient) - a common even when you have the experience/knowledge of the first pass. Unfortunately, by that time it had the reputation as 'horribly slow and inefficient', and in a lot of ways, never kicked that: http://www.multicians.org/myths.html Sigh, sometimes you can't win! Noel

6 years, 11 months

2
1
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: "Theodore Y. Ts'o" > To be fair, it's really easy to be wise to after the fact. Right, which is why I added the caveat "seen to be such _at the time_ by some people - who were not listened to". > failed protocols and designs that collapsed of their own weight because > architects added too much "maybe it will be useful in the future" And there are also designs which failed because their designers were too un-ambitious! Converting to a new system has a cost, and if the _benefits_ (which more or less has to mean new capabilities) of the new thing don't outweigh the costs of conversion, it too will be a failure. > Sometimes having architects being successful to add their "vision" to a > product can be worst thing that ever happened A successful architect has to pay _very_ close attention to both the 'here and now' (it has to be viable for contemporary use, on contemporary hardware, with contemporary resources), and also the future (it has to have 'room to grow'). It's a fine edge to balance on - but for an architecture to be a great success, it _has_ to be done. > The problem is it's hard to figure out in advance which is poor vision > versus brilliant engineering to cut down the design so that it is "as > simple as possible", but nevertheless, "as complex as necessary". Absolutely. But it can be done. Let's look (as an example) at that IPv3->IPv4 addressing decision. One of two things was going to be true of the 'Internet' (that name didn't exist then, but it's a convenient tag): i) It was going to be a failure (in which case, it probably didn't matter what was done, or ii) it was going to be a success, in which case that 32-bit field was clearly going to be a crippling problem. With that in hand, there was no excuse for that decision. I understand why they ripped out variable-length addresses (I was just about to start writing router code, and I know how hard it would have been), but in light of the analysis immediately above, there was no excuse for looking _only_ at the here and now, and not _also_ looking to the future. Noel

6 years, 11 months

2
2
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Tony Finch <dot(a)dotat.at> > Was this written down anywhere? Alas, no. It was a presentation at a group seminar, and used either hand-drawn transparencies, or a white-board - don't recall exactly which. I later tried to dig it up for use in Nimrod, but without success. As best I now recall, the concept was that instead of the namespace having a root at the top, from which you had to allocate downward (and then recurse), it built _upward_ - if two previously un-connected chunks of graph wanted to unite in a single system, they allocated a new naming layer on top, in which each existing system appeared as a constituent. Or something like that! :-) The issue with 'top-down' is that you have to have some global 'authority' to manage the top level - hand out chunks, etc, etc. (For a spectacular example of where this can go, look at NSAP's.) And what do you do when you run out of top-level space? (Although in the NSAP case, they had such a complex top couple of layers, they probably would have avoided that issue. Instead, they had the problem that their name-space was spectacularly ill-suited to path selection [routing], since in very large networks, interface names [adddresses] must have a topological aspect if the path selection is to scale. Although looking at the Internet nowadays, perhaps not!) 'Bottom-up' is not without problems of course (e.g. what if you want to add another layer, e.g. to support potentially-nested virtual machines). I'm not sure how well Dave understood the issue of path selection scaling at the time he proposed it - it was very early on, '78 or so - since we didn't understand path selection then as well as we do now. IIRC, I think he was mostly was interested in it as a way to avoid having to have an asssignment authority. The attraction for me was that it was easier to ensure that the names had the needed topological aspect. Noel

6 years, 11 months

2
1
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > idiots keep repeating those "quotes" ... in some sort of an effort to > make the so-called "experts" look silly; a form of reverse > jealousy/snobbery or something? It really pisses me off You've just managed to hit one of my hot buttons. I can't speak to the motivations of everyone who repeats these stories, but my professional career has been littered with examples of poor vision from technical colleagues (some of whom should have known better), against which I (in my role as an architect, which is necessarily somewhere where long-range thinking is - or should be - a requirement) have struggled again and again - sometimes successfully, more often, not. So I chose those two only because they are well-known examples - but, as you correctly point out, they are poor examples, for a variety of reasons. But they perfectly illustrate something I am _all_ too familiar with, and which happens _a lot_. And the original situation I was describing (the MIT core patent) really happened - see "Memories that Shaped an Industry", page 211. Examples of poor vision are legion - and more importantly, often/usually seen to be such _at the time_ by some people - who were not listened to. Let's start with the UNIBUS. Why does it have only 18 address lines? (I have this vague memory of a quote from Gordon Bell admitting that was a mistake, but I don't recall exactly where I saw it.) That very quickly became a major limitation. I'm not sure why they did it (the number of contact on a standard DEC connector probably had something do with it, connected to the fact that the first PDP-11 had only 16-bit addressing anyway), but it should have been obvious that it was not enough. And a major one from the very start of my career: the decision to remove the variable-length addresses from IPv3 and substitute the 32-bit addresses of IPv4. Alas, I was too junior to be in the room that day (I was just down the hall), but I've wished forever since that I was there to propose an alternate path (the details of which I will skip) - that would have saved us all countless billions (no, I am not exaggerating) spent on IPv6. Dave Reed was pretty disgusted with that at the time, and history shows he was right. Dave also tried to get a better checksum algorithm into TCP/UDP (I helped him write the PDP-11 code to prove that it was plausible) but again, it got turned down. (As did his wonderful idea for bottom-up address allocation, instead of top-down. Oh well.) People have since discussed issues with the TCP/IP checksum, but it's too late now to change it. One place where I _did_ manage to win was in adding subnetting support to hosts (in the Host Requirements WG); it was done the way I wanted, with the result that when CIDR came along, even though it hadn't been forseen at the time we did subnetting, it required _no_ hosts changes of any kind. But mostly I lost. :-( So, is poor vision common? All too common. Noel

6 years, 11 months

6
6
0 0

Re: [TUHS] core

by Johnny Billquist

On 2018-06-18 04:00, Ronald Natalie <ron(a)ronnatalie.com> wrote: >> Well, it is an easy observable fact that before the PDP-11/70, all PDP-11 models had their memory on the Unibus. So it was not only "an ability at the lower end", b > That’s not quite true. While the 18 bit addressed machines all had their memory directly accessible from the Unibus, the 45/50/55 had a separate bus for the (then new) semiconductor (bipolar or MOS) memory. Eh... Yes... But... The "separate" bus for the semiconductor memory is just a second Unibus, so the statement is still true. All (earlier) PDP-11 models had their memory on the Unibus. Including the 11/45,50,55. It's just that those models have two Unibuses. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

2
1
0 0

In Memorium: Alan Turing

by Dave Horsfall

We lost the Father of Computing, Alan Turing, on this day when he suicided in 1954 (long story). Just imagine where computing would've been now... Yes, there are various theories surrounding his death, such as a jealous lover, the FBI knowing that he knew about Verona and could be compromised as a result of his sexuality, etc. Unless they speak up (and they ain't), we will never know. Unix reference? Oh, that... No computable devices (read his paper), no computers... And after dealing with a shitload of OSs in my career, I daresay that there is no more computable OS than Unix. Sorry, penguins, but you seem to require a fancy graphical interface these days, just like Windoze. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 11 months

5
5
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Derek Fawcus <dfawcus+lists-tuhs(a)employees.org> > my scan of it suggests that only the host part of the address which were > extensible Well, the division into 'net' and 'rest' does not appear to have been a hard one at that point, as it later became. > The other thing obviously missing in the IEN 28 version is the TTL Yes... interesting! > it has the DF flag in the TOS field, and an OP bit in the flags field Yeah, small stuff like that got added/moved/removed around a lot. > the CIDR vs A/B/C stuff didn't really change the rest. It made packet processing in routers quite different; routing lookups, the routing table, etc became much more complex (I remember that change)! Also in hosts, which had not yet had their understanding of fields in the addresses lobotomized away (RFC-1122, Section 3.3.1). Yes, the impact on code _elsewhere_ in the stack was minimal, because the overall packet format didn't change, and addresses were still 32 bits, but... > The other bit I find amusing are the various movements of the port > numbers Yeah, there was a lot of discussion about whether they were properly part of the internetwork layer, or the transport. I'm not sure there's really a 'right' answer; PUP: http://gunkies.org/wiki/PARC_Universal_Packet made them part of the internetwork header, and seemed to do OK. I think we eventually decided that we didn't want to mandate a particular port name size across all transports, and moved it out. This had the down-side that there are some times when you _do_ want to have the port available to an IP-only device, which is why ICMP messages return the first N bytes of the data _after_ the IP header (since it's not clear where the port field[s] will be). But I found, working with PUP, there were some times when the defined ports didn't always make sense with some protocols (although PUP didn't really have a 'protocol' field per se); the interaction of 'PUP type' and 'socket' could sometimes be confusing/problemtic. So I personally felt that was at least as good a reason to move them out. 'Ports' make no sense for routing protocols, etc. Overall, I think in the end, TCP/IP got that all right - the semantics of the 'protocol' field are clear and simple, and ports in the transport layer have worked well; I can't think of any places (other than routers which want to play games with connections) where not having ports in the internetwork layer has been an issue. Noel

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Derek Fawcus > Are you able to point to any document which still describes that > variable length scheme? I see that IEN 28 defines a variable length > scheme (using version 2) That's the one; Version 2 of IP, but it was for Version 3 of TCP (described here: IEN-21, Cerf, "TCP 3 Specification", Jan-78 ). > and that IEN 41 defines a different variable length scheme, but is > proposing to use version 4. Right, that's a draft only (no code ever written for it), from just before the meeting that substituted 32-bit addresses. > (IEN 44 looks a lot like the current IPv4). Because it _is_ the current IPv4 (well, modulo the class A/B/C addressing stuff). :-) Noel

6 years, 11 months

2
1
0 0

Re: [TUHS] maybe off-topic: Unix on a microcontroller

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > It's a separate image (/netnix) that gets loaded at boot time, but it's > run in the context of the kernel. ISTR reading that it runs in Supervisor mode (no doubt so it could use the Supervisor mode virtual address space, and not have to go crazy with overlays in the Kernet space). Never looked at the code, though. Noel

6 years, 11 months

2
1
0 0

Re: [TUHS] maybe off-topic: Unix on a microcontroller

by Johnny Billquist

On 2018-06-17 04:00, jnc(a)mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Johnny Billquist > > > It's a separate image (/netnix) that gets loaded at boot time, but it's > > run in the context of the kernel. > > ISTR reading that it runs in Supervisor mode (no doubt so it could use the > Supervisor mode virtual address space, and not have to go crazy with overlays > in the Kernet space). Yes. That rings a bell now that you mention it. Pretty sure you are correct. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist > incidentally have 18 data bits, but that is mostly ignored by all > systems. I believe the KS-10 made use of that, though. And maybe the > PDP-15. The 18-bit data thing is a total kludge; they recycled the two bus parity lines as data lines. The first device that I know of that used it is the RK11-E: http://gunkies.org/wiki/RK11_disk_controller#RK11-E which is the same cards as the RK11-D, with a jumper set for 18-bit operation, and a different clock crystal. The other UNIBUS interface that could do this was the RH11 MASSBUS controller. Both were originally done for the PDP-15; they were used with the UC15 Unichannel. The KS10: http://gunkies.org/wiki/KS10 wound up using the 18-bit RH11 hack, but that was many years later. Noel

6 years, 11 months

1
0
0 0

Re: [TUHS] maybe off-topic: Unix on a microcontroller

by Johnny Billquist

On 2018-06-16 04:00, Tom Ivar Helbekkmo<tih(a)hamartun.priv.no> wrote: > Warner Losh<imp(a)bsdimp.com> writes: > >> It looks like retrobsd hasn't been active in the last couple of years >> though. A cool accomplishment, but with some caveats. All the network >> is in userland, not the kernel, for example. > Isn't 2.11BSD networking technically in userland? I forget. Johnny? No, networking in 2.11BSD is not in userland. But it's not a part of /unix either. It's a separate image (/netnix) that gets loaded at boot time, but it's run in the context of the kernel. I'd have to go and check this if anyone wants details. It's been quite a while since I was fooling around inside there. Or maybe someone else remembers more details on how it integrates. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

1
0
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > The 8 pretty much had a base price in the $30k range in the mid to late > 60s. His statement was made in 1977 (ironically, the same year as the Apple II). (Not really that relevant, since he was apparently talking about 'smart homes'; still, the history of DEC and personal computers is not a happy one; perhaps why that quotation was taken up.) > Later models used TTL and got down to a single 3U 'drawer'. There was eventually a single-chip micro version, done in the mid-70's; it was used in a number of DEC word-processing products. Noel

6 years, 11 months

6
5
0 0

Re: [TUHS] core

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> >> one of the Watson's saying there was a probably market for >> <single-digit> of computers; Ken Olsen saying people wouldn't want >> computers in their homes; etc, etc. > I seem to recall reading somewhere that these were urban myths... Does > anyone have actual references in their contexts? Well, for the Watson one, there is some controversy: https://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_attribution My guess is that he might actually have said it, and it was passed down orally for a while before it was first written down. The thing is that he is alleged to have said it in 1943, and there probably _was_ a market for only 5 of the kind of computing devices available at that point (e.g. the Mark I). > E.g. Watson was talking about the multi-megabuck 704/709/7094 etc No. The 7094 is circa 1960, almost 20 years later. > Olsens's quote was about the DEC-System 10... Again, no. He did say it, but it was not about PDP-10s: https://en.wikiquote.org/wiki/Ken_Olsen "Olsen later explained that he was referring to smart homes rather than personal computers." Which sounds plausible (in the sense of 'what he meant', not 'it was correct'), given where he said it (a World Future Society meeting). Noel

6 years, 11 months

2
1
0 0

maybe off-topic: Unix on a microcontroller

by arnold＠skeeve.com

https://hackaday.com/2018/06/03/its-unix-on-a-microcontroller/ A neat hack, if nothing else. :-) Arnold

6 years, 11 months

4
4
0 0

Happy birthday, Leonard Kleinrock!

by Dave Horsfall

An ARPAnet pioneer, apparently he was born on this day in 1934, and was famous for sending the first message over the ARPAnet in October 1969 (it got as far as "LO" before crashing). -- Dave

6 years, 11 months

1
0
0 0

Re: [TUHS] NROFF & Model 37s

by Doug McIlroy

> Here's a Gootoob video (11m): it's a mechanical marvel! A wonderful model, but quite unlike a TTY 37, where sender and receiver are the same machine. Doug

6 years, 11 months

1
0
0 0

Re: [TUHS] NROFF & Model 37s

by Doug McIlroy

> I think RS took it and left it behind someone's car at one as a practical joke. That behemoth was built to last. It would surely stop a car. Moving it single-handed would be quite a feat. When Andy Hall retired his, he was able to push it as far as his back porch, where it remained for more than a year. Under the keyboard was remarkable mechanical crossbar encoder that dripped machine oil. Fortunately the operator's knees were protected by a drip pan. The oil smell led me to keep mine in my workshop; its fragrance reminded me of the first major piece of computing equipment I saw as a child: Vennevar Bush's mechanical differential analyzer, a room-size table of shafts, gears and integrators that was redolent of machine shop. Doug

6 years, 11 months

2
1
0 0

NROFF & Model 37s

by Ron Natalie

Hopkins had a KSR37 that was our standard word processing output for a long time before the daisy wheel printers started showing up. It even had the "greek box" so when eqn or whatever wanted that, it just sent shift-in/shift-out (control-n, -o). Years later I managed to pick up a surplus ASR37 from Rocky Flats. I had it in my kitchen for years on a modem. It was great fun to have one of the few terminals that nroff would send all those ESC-8/9 things for the vertical positioning without needing an output filter. No greek box, though. It also had a giant NEWLINE key and didn't need to have the nl mode turned on. Amusingly the thing would sit there quiet until the modem was powered up and then DSR ready would bring it to life. When CD came up an giant green PROCEED light illuminated above the keyboard. The paper tape unit was a monster side car. I never got around to programming the "here-is" drum. I think RS took it and left it behind someone's car at one as a practical joke.

6 years, 11 months

2
2
0 0

where did the term daemon come from?

by ron minnich

someone asked me today, and I only remember using that term in 1975 but can't recall the origin.

6 years, 11 months

3
2
0 0

ANTS (was: In memory of: J. Presper Eckert)

by Paul Ruizendaal

ANTS was written by Gary Grossman and the experience with ANTS and ANTS 2 was the direct inspiration for NCP Unix (which was probably what Mike installed): http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=ncpunix The source for NCP Unix is available on the Unix Tree webpage: https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC > Date: Sun, 3 Jun 2018 13:42:00 -0400 > From: "Ron Natalie" <ron(a)ronnatalie.com> > > While Mike and I still shared an office in 394, the ENIAC room was where the IMP 29 on the ARPANET was and a PDP-11/40 system that ran a terminal server called ANTS (ArpaNet Terminal Server) complete with little ants silkscreened on the rack tops. When the ARPANET went to long leaders, Mike replaced that software with a UNIX host giving the BRL their real first HOST on the Arpanet. Years later I recycled those racks (discarding the 11/40) to hold BRL Gateways (retaining the ants).

6 years, 11 months

2
1
0 0

In memory of: J. Presper Eckert

by Dave Horsfall

(Yeah, I was asked to not use "RIP", so...) We lost J. Presper Eckert back in 1995; he was a co-inventor of ENIAC (one of the world's first "electronic brains"). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

6 years, 11 months

3
2
0 0

Re: [TUHS] Serial communications (was Control-T (was top))

by Norman Wilson

Clem Cole: WE212 modems worked on dz11 for input but just barely and could not use a WE dialer for output (who's number I now forget). Remember the AT command dialer stuff was not originally a standard from the telcos. The modems were independent of the dialer (which used the RS-4xx standard and I also have some where and I forget the number). ===== There was certainly some WECo modems-in-a-rack-with-one-dialer setup that could be driven by DZ11s. I know that because that is what the UUCP node `research' used in the 1980s, when I was at Bell Labs. I don't know what the modem hardware was; maybe it was newer than what Clem describes, or maybe someone (likely Bill Marshall or Joe Condon) made some special hardware to make it work. But the UNIX side of things was a VAX-11/750 running Research UNIX with a DZ11; I'm quite sure of that. I'm also sure that the modems were genuine WECo and spoke the 212 protocol, max speed 1200bps. Aside: when I arrived at the Labs, the standard in the Computing Science Center was that everyone got a Jerq terminal (AT&T 5620, commercial descendant of the Blit) at work and at home. For the home end everyone got a modem with attached telephone (that's the way the official Bell stuff came back then) and a second phone line paid for by the Labs. There was a pool of modems dedicated to dialin for people working from home. A few months later, it was discovered that a Japanese modem manufacturer (Fujitsu? I forget) had a 9600bps modem that required a four-wire leased line but had a reasonable cost, and that New Jersey Bell had a new offering for leased lines at a reasonable cost too. So the Labs paid for a pair of the modems and a leased line for each of us, and we all brought the old 212 modems back in when convenient, and most of the second phone lines were cancelled. (A few people wanted to keep them, because they were business lines from which one could make calls to BTL offices etc without having to submit your home phone bills for reimbursement.) The modems had LCD status displays. In the early samples we had for initial testing, I vaguely remember a few spelling errors in the status messages; in particular SIGNAL QUARITY IS POOR. The error had been fixed in the big bulk order. There was one more step in the evolution of RS-232-to-home: several years later New Jersey Bell began offering a new service called Co-LAN to those served by certain central offices (including me). The customer was given a box with input phone jack, output phone jack, and a DB25 connector. The latter afforded a serial connection to the CO, multiplexed with the POTS signal (presumably a forerunner of what is now called DSL). At the CO, the serial line was plugged into a Datakit switch. So I would turn on my terminal and get a Datakit prompt, type a network address referring to a system on our Datakit network at MH, type a network-access password, and I was connected the same as if I were at work, at 9600 bps. New Jersey Bell hoped to sell both the service and Datakit to other corporations; hence the password, so customers could get only to the networks for which they were authorized. I don't know whether that happened much. It was sure convenient for Bell Labs, though. Norman Wilson Toronto ON

6 years, 11 months

2
1
0 0

Re: [TUHS] Control-T (was top)

by Johnny Billquist

On 31.05.18 04:00, Pete Turnbull<pete(a)dunnington.plus.com> wrote: > On 30/05/2018 23:10, Johnny Billquist wrote: >> On 30.05.18 02:19, Clem cole wrote: >>> 1). If you grab ^s/^q from the alphabet it means you can send raw 8 >>> bit data because they are valid characters (yes you can use escape >>> chars but it gets very bad) >> But this has nothing to do with 8 bit data. > [...] >> What you are talking about is simply the problem when you have inband >> signalling, and is a totally different problem than 8bit data. > True, but what I believe Clem meant was "binary data". He did write > "raw data". Clem originally said: "And the other issue was besides not enough buffering DZ11s and the TU58 assumes software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate. So this of course made 8bit data diificult too." And that is what I objected to. If we're talking about just getting data through a communications channel cleanly, then obviously inband signalling like XON/XOFF is a problem, but that was not what Clem claimed. By the way, while I'm on this topic. The TU58 (aka DECtape II - curse that name) initially did have overrun problems, and that was because the protocol did not have proper handshaking. There is flow control when the TU58 sends data to the host, but there is no handshaking, which amplifies the problem with flow control on that device. The protocol the TU58 uses is called RSP, for Radial Serial Protocol. DEC realized the problem, and modified the protocol, which were then called MRSP, or Modified Radial Serial Protocol, which addressed the specific problem of handshaking when sending data to the host. But in addition to the lack of handshaking, the TU58 is normally always expected to be connected to a DL11, and the DL11 is the truly stupid, simple device that only have a 1 character buffer. So that interface can easily drop characters on reception. Flow control or not. And the TU58 is not really to blame. And if you have an updated TU58 which uses MRSP, you are better off. >> RTS/CTS signalling is certainly a part of the standard, but it is not >> meant for flow control. It is for half duplex and the way to signal when >> you want to change the direction of communication. >> >> It is meant for*half duplex* communication. Not flow control. > Actually, for both, explicitly in the standard. The standard (which I > have in front of me, RS232C August 1969 reaffirmed June 1981) does > indeed explain at length how to use it for half duplex turnaround but > also indicates how to use it for flow control. It states the use on > one-way channels and full-duplex channels to stop transmission in a > paragraph before the paragraph discussing half duplex. Using RTS/CTS for flow control have eventually made it into the standard, but this only happened around 1990 with RS-232E-E. See https://groups.google.com/forum/#!original/comp.dcom.modems/iOZRZkTKc-o/Zcd… for some background story on that. And that obviously is way after DEC was making any of these serial interfaces. Wikipedia have a pretty decent explanation of how these signals were defined back in the day: "The RTS and CTS signals were originally defined for use with half-duplex (one direction at a time) modems such as the Bell 202. These modems disable their transmitters when not required and must transmit a synchronization preamble to the receiver when they are re-enabled. The DTE asserts RTS to indicate a desire to transmit to the DCE, and in response the DCE asserts CTS to grant permission, once synchronization with the DCE at the far end is achieved. Such modems are no longer in common use. There is no corresponding signal that the DTE could use to temporarily halt incoming data from the DCE. Thus RS-232's use of the RTS and CTS signals, per the older versions of the standard, is asymmetric." See Wikipedia itself if you want to get even more signals explained. If you have a copy of the 1969 standards document, could you share it? I was trying to locate a copy now, but failed. I know I've read it in the past, but have no recollection on where I had it then, or where I got it from. >> The AT "standard" was never actually a standard. It's only a defacto >> standard, but is just something Hayes did, as I'm sure you know. > Except for ITU-T V.250, which admittedly is a Recommendation not a Standard. This also becomes a question of who you accept as an authority to establish standards. One could certainly in one sense say that the Hayes AT commands were a standard. But all of that also happened long after DEC made these interfaces, and as such are also pretty irrelevant. The link to the post in news back in 1990 is from the standards representative from Hayes, by the way. So they were certainly working with the standards bodies to establish how to do things. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

2
1
0 0

Re: [TUHS] Control-T (was top)

by Johnny Billquist

On 2018-05-29 04:00, Clem cole<clemc(a)ccc.com> wrote: > > And the other issue was besides not enough buffering DZ11s and the TU58 assumes software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate. So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money. Uh? Say what? What does XON/XOFF flow control have to do with 8bit data? And no, DEC was not trying to save money. They were actually sticking to the standard. Something very few companies managed to do, especially when it came to the RS-232 standard. The "hardware flow control" is actually an abuse of the half duplex signalling. And it does not necessarily work as you might expect if modems are in the middle. You could get by with just three wires on serial ports, but DEC usually did want people to have more wires connected, in order to detect when a device was connected or not. But no, they did not abuse the half duplex control to do hardware flow control. The DZ11 also have partial modem control. You cannot run them in half-duplex mode, and they do not support the secondary channel stuff, but they do support more than just the 3 wires. > A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope. Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control. Yes. It's essentially a DH11 with a partial DM11 on just one board, while the original DH11/DM11 was a fully 9-slot backplane. So it was a really good alternative. The DH11 is much better than the DZ11, but did in fact cost more. The Able board gave the DH11 capabilities at a much lower cost, and taking much less space in the box. And it actually performed better than the DH11. But it did not support the full functionality of the DM11. But what was lacking was the half duplex stuff, which noone really cared about anymore anyway. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

6 years, 11 months

4
5
0 0

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