TUHS

tuhs@tuhs.org

12 participants
6534 discussions

Re: [TUHS] What was your "Aha, Unix!" moment?

by jnc＠mercury.lcs.mit.edu

> From: Sean Dwyer > chdir seems to be a syscall in 7 (sys4.c) It's been a system call forever, see e.g.: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1/man/man2/chdir.2 (And the working dir was a property of the process, not data in the shell.) Noel

5 years, 8 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Norman Wilson

Bakul Shah: Being an OS student I had read "The Unix Timesharing System" paper by Ritchie and Thompson and had wanted to use Unix years before I actually had the chance. I don't remember an "Aha!" moment but I took to it like a duck to water. Most everything felt just so comfortable and right. It was very much as I had imagined it to be. ===== That's more or less what it was like to me. Not so much an aha! moment, more just a feeling of coming home. It took a while to understand the different way things worked in UNIX (I had previously used TOPS-10 for several years) but as it all sank in it felt more and more right. C felt the same way. It took me a while to grok the pointer syntax (I had done a lot of MACRO-10 programming so I certainly understood the concept, just not how it fit into the higher- level language), but things like the three-clause condition in for so that all control for a loop could be in one place were just magically right. I don't think I read the CACM paper before I touched UNIX, but I had read both editions of Software Tools, so my brain was perhaps pre-seeded with some of the ideas. Norman Wilson Toronto ON

5 years, 8 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey <wkt(a)tuhs.org> > But wasn't "chdir" built into the PDP-7 Unix shell? No. See "The Evolution of the Unix Time-sharing System", in section "Process control". Also, the old 'cd' had different syntax than today's (since there was no notion of a pathname in the earliest Unix); it took instead a list of directories (e.g. "cd dd ken"). Noel

5 years, 8 months

Re: [TUHS] TUHS Digest, Vol 47, Issue 31

by Will Senn

On 10/21/19 9:05 AM, tuhs-request(a)minnie.tuhs.org wrote: > Message: 17 > Date: Mon, 21 Oct 2019 08:10:00 -0400 (EDT) > From:jnc@mercury.lcs.mit.edu (Noel Chiappa) > To:tuhs@minnie.tuhs.org > Cc:jnc@mercury.lcs.mit.edu > Subject: Re: [TUHS] What was your "Aha, Unix!" moment? > Message-ID:<20191021121000.34E3B18C09F(a)mercury.lcs.mit.edu> > > > From: Warren Toomey<wkt(a)tuhs.org> > > > But wasn't "chdir" built into the PDP-7 Unix shell? > > No. See "The Evolution of the Unix Time-sharing System", in section "Process > control". > > Also, the old 'cd' had different syntax than today's (since there was no notion > of a pathname in the earliest Unix); it took instead a list of directories (e.g. > "cd dd ken"). > > Noel > Wanna have some fun? chdir system then try to find your way back 'home'... v0's subdirectories suck. -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

5 years, 8 months

Re: [TUHS] Vaxen, my children...

by Pat Barron

On the copy of this story that appears here: http://crash.com/fun/texts/vaxen-dont.html it is atrributed as such: 'The author of this piece is Jack Harvey, harvey(at)eisner.decus.org, and it was originally published under the title "The Immortal Murderer" on January 18th, 1989 on DECUServe, the DECUS member bulletin board.' --Pat.

5 years, 8 months

Re: [TUHS] 1: jmp 1b

by Norman Wilson

In `UNIX Assembler Reference Manual,' Dennis credits Knuth for numeric temporary labels, with a reference to volume 1 of The Art of Computer Programming. I'm several thousand kilometers from my copy of Knuth (though rather nearer to Knuth himself, albeit not within asking range), so I'll leave it to others to track down the exact reference. Norman Wilson Toronto ON (temporarily Sacramento CA)

5 years, 8 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by jnc＠mercury.lcs.mit.edu

{Been meaning to get to this one for a while...} > From: Pat Barron <patbarron(a)acm.org> > The idea of processes being able to talk to each other (without some > kind of pre-arrangement, like setting up a pipe between them, or using > temporary files) was just amazing ... On V7m, I stumbled across the > mpx(5) man page. It's probably worth pointing out that before V7, stock Unix _didn't_ have a way for two un-related processes to communicate, hence the invention of port() by Rand. See: https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6/doc/ipc (Note: BBN did _not_ do the original port() stuff, they just used it.) Noel

5 years, 8 months

Vaxen, my children...

by Dave Horsfall

A little off-topic, but quite amusing... -- Dave ---------- Forwarded message ---------- 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

5 years, 8 months

1: jmp 1b

by ron minnich

where did the relative labels come from? I still show them to people when we're doing assembly and still use them all the time. Most people have not seen them and find them wonderfully convenient. I know they were in as by the time I came along in 1976; when did they first show up?

5 years, 8 months

Re: [TUHS] Recovered /etc/passwd files

by Norman Wilson

I'm amused (in a good way) that this thread persists, and without becoming boring. Speaking as someone who was Ken's sysadmin for six years, I find it hard to get upset over someone cracking a password hash that has been out in the open for decades, using an algorithm that became pragmatically unsafe slightly fewer decades ago. It really shouldn't be in use anywhere any more anyway. Were I still Ken's sysadmin I'd have leaned on him to change it long ago. So far as I know, my password from that era didn't escape the Labs, but nevertheless I abandoned it long ago--when I left the Labs myself, in fact. I do have one password that has been unchanged since the mid-1990s and is stored in heritage hash on a few computers that don't even have /etc/shadow, but those are not public systems. And it's probably time I changed it anyway. None of this is to excuse the creeps who steal passwords these days, nor to promote complacency. At the place I now work we had a possible /etc/shadow exposure some years back, and we reacted by pushing everyone to change their passwords and also by taking various measures to keep even the hashes better-hidden. But there is, or should be, a difference between a password that is still in use and one that was exposed so long ago, and in what is now so trivial an algorithm, that it is no more than a puzzle for fans of the old-fart days. Norman Wilson Toronto ON

5 years, 8 months

Re: [TUHS] Space Travel, was New: The Earliest UNIX Code

by Doug McIlroy

Apropos of OCR on shabby typewriting, I've had good luck with doing the OCR twice with the paper differently positioned, then using diff to spot discrepancies. For a final proofreading, a team of two--one reading the original aloud, the other checking the copy, works much faster and more accurately than a single person checking side-by-side texts. Doug

5 years, 8 months

Re: [TUHS] Recovered /etc/passwd files

by Norman Wilson

Back in the heyday of uucp, some sites were lazy and allowed uucico access to any file in the file system (that was accessible to the uucp user). A common ploy for white hats and black hats was to try uucp remotesys!/etc/passwd ~/remotesys or the like, and see what came in and whether it had any easy hashes (shadow password files didn't quite exist yet). The system known to the uucp world as research! was more careful: / was mapped to /usr/spool/uucp. We left a phony etc/passwd file there, containing plausible-looking entries with hashes that, if cracked, spelled out why are you wasting your time I don't remember whether anyone ever stole it by uucp, though I think Bill Cheswick used it to set up the phony system environment for Berferd to play in (Google for `cheswick berferd' if you don't know the story). Norman Wilson Toronto ON

5 years, 8 months

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

5 years, 8 months

New: The Earliest UNIX Code - From the Collection of the Software History Center, Computer History Museum

by Lyle Bickley

THE EARLIEST UNIX CODE: AN ANNIVERSARY SOURCE CODE RELEASE http://bit.ly/31pWcvM Cheers, Lyle -- 73 NM6Y Bickley Consulting West Inc. https://bickleywest.com "Black holes are where God is dividing by zero"

5 years, 8 months

Sun Spacewar

by Lars Brinkhoff

Hello, A 1983 implementation of the Spacewar game for a Sun computer has appeared. Here is some information from the author: http://www.classiccmp.org/pipermail/cctalk/2019-October/050060.html Here is a copy of the tarball: https://github.com/PDP-10/Spacewar/blob/not-pdp10/orbit.tar.gz?raw=true

5 years, 8 months

New: The Earliest UNIX Code - From the Collection of the Software History Center, Computer History Museum

by Lyle Bickley

5 years, 8 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Doug McIlroy

> From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) > > > From: Doug McIlroy > > > doing legwork for Multics I ran the following experiment on a lot of > > then-current time-sharing systems. > > Fascinating; you don't happen to remember the ones you tried, do you? > > Also, when you say "legwork for Multics", was this something done during > the planning stages (so, say '64-'65), or later on? It was probably 1965. The places we visited included at least Rand, NBS, Michigan, and Dartmouth. I specifically remember trying the experiment at Michigan and Dartmouth. There were other places, too, but they've dropped from memory. Doug

5 years, 8 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Pat Barron

I don't know that I had a single "Aha!" moment, but there were a few things that just got hold of me and led me down the Unix path... The first Unix I used was V7m on a PDP-11/40, in college. By this point, I was "aware" of Unix, in theory I even knew C - but never had an actual system to try it out on until this point. I'd used other operating systems (or things that called themselves operating systems...), primarily TRSDOS, CP/M, OS1100, TOPS-10, TOPS-20, and VMS. Unix was certainly the first multiuser operating system that I ever had administrator access on. 1) The idea of taking the output of one program, and using it directly as input to another program - and the simplicity by which it was done - was revolutionary to me. It was not unusual for me at that time to do things like this by having the first program create a temporary file, and then having another program open this temporary file and use it as input, but the whole paradigm of stdin/stdout/pipes made it so you didn't even have to "know" in your program that you might need to use the output of some other program (via a temporary file) as input. That was amazing to me. 2) Unix was really the first operating system that I had full, buildable sources for. (I theoretically had access to VMS source code, but it was on microfiche and not in machine-readable form, so it was just a read-only reference.) If I wanted to see how the OS was doing something, I could look. If I wanted to change something the OS did, or add something to the OS (either in the kernel, or as a user space utility), I could do that (and I did on a couple of occasions). If something was broken, I could try to figure it out and fix it. There was this bug in V7m, where if you were on a non-separate I&D system that didn't have the floating point option (and our 11/40 did not), and you tried to run an "a.out" file that was zero length, you'd get a kernel panic. We were using the system for a computer architecture course, students were programming in assembly language, and if there was a problem with the source file the assembler would leave a zero length executable behind. Of course, students would try to run it anyway, even though "as" produced errors. We'd sometimes get 3 or 4 system crashes in the course of an evening. The students and the instructors were all up in arms because any time this would happen, everyone would lose whatever they were working on (and maybe more, if the filesystem got messed up during the panic), and if there was no one around who had a key to the computer room when it happened, it would stay down until they could find someone who had physical access and the knowledge to know how to deal with "fsck"... (The construction in the lab was pretty minimal, and the walls to most of the rooms didn't go all the way to the ceiling - sometimes when it crashed and no one was around, they'd take to climbing over the wall to reboot the system themselves - which could produce disasterous results of there were filesystem issues...) I found the problem, and I fixed it. That was my first adventure in kernel debugging... (Later, we migrated to a PDP-11/24 and we ordered the KEF11-A floating point option for it, so that problem became moot.) 3) The idea of processes being able to talk to each other (without some kind of pre-arrangement, like setting up a pipe between them, or using temporary files) was just amazing, and this was the first time I'd really seen it. I knew VMS had this thing called a "mailbox", but I never used it for anything and didn't even know what it was for. On V7m, I stumbled across the mpx(5) man page. I think the first time I came across it, I stared at it for hours, looking at the description and trying to figure out what you'd even use that functionality for. At some point it was like a lightning bolt hit me - "Oh, wait! You can use this to send messages between unrelated processes!" Except V7m came with one little proviso - the mpx code was there, but it didn't work... So I dug into it, and made it work - at least, well enough for what I wanted to use it for. I wrote a multiuser chat program with it (isn't that the first thing any undergrad does when they discover interprocess communications? :-) ). I had a similar epiphany with sockets on 4.2BSD a year or two later, under similar circumstances. The one thing I found in command with both mpx and sockets was that the documentation described the low-level functionality - but there was nothing that clearly stated, "This functionaliy is used to allow processes to talk to each other"... I'm sure there are plenty more experiences with early Unix that ensured that I'd continue down this path, but I think these are my favorites. --Pat.

5 years, 8 months

The Unix Game

by Diomidis Spinellis

The game at https://www.unixgame.io/unix50 has you solve challenges by arranging Scratch-like blocks into shell pipelines. Neat! Diomidis

5 years, 8 months

Re: [TUHS] Simple Unix install? (was: What was your "Aha, Unix!" moment?)

by Pat Barron

Possibly the most time consuming install I did was installing Xenix on a bunch of Intel i310 systems. Xenix was a "secondary" OS for these systems, the main OS being iRMX. Xenix for these systems was distributed on 5.25" floppies. Lots and lots of floppies... They came in a 3-ring binder, many pages of floppies... We also had a couple of i380 systems, Xenix for those came on 8" floppies... That was time consuming, but it was just manual labor. The most unpleasasnt install I can recall was AIX 2.2.1 on the IBM-PC/RT. Which also was really (under the covers) Interactive UNIX, with some other stuff mixed in. Not only was this also time-consuming with a binder full of 5.25" floppies, but my recollection is that there were too many opportunities to make a tiny little mistake during the install and have to start all over again. --Pat.

5 years, 8 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by Doug McIlroy

Apropos of Steve Johnson's evocative description of JCL and other pre-Unix OS interfaces, doing legwork for Multics I ran the following experiment on a lot of then-current time-sharing systems. As a model of creating and installing a new compiler, I used a very short Fortran program that simply copied its input to its output, stopping after finding END in column 7 of the input. The drill was compile the program run it, using its own source as input compile the freshly made output file This failed on every system I tried it on, though local experts could intervene with magic to overcome the gratuitous file-type distinctions that typically got in the way. Dartmouth's DTSS came closest, but inexplicably, even to the gurus, it had a special prohibition against a program reading the source from which it was compiled. Incidentally, my favorite manifestation of JCL-like mumbo jumbo was the ironically named FUTIL control card in GECOS. Doug

5 years, 8 months

Celebrating 50 years of Unix

by Caipenghui

Unix has a history of 50 years. Unix has a tremendous impact on the Internet. Is Unix ready for the next computing era?

5 years, 9 months

UNIX at 50

by John P. Linderman

Here's the schedule <https://www.bell-labs.com/unix50/event/>

5 years, 9 months

Unix @ 50

by José Guerra

https://www.bell-labs.com/unix50/event/

5 years, 9 months

Re: [TUHS] What was your "Aha, Unix!" moment?

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy > doing legwork for Multics I ran the following experiment on a lot of > then-current time-sharing systems. Fascinating; you don't happen to remember the ones you tried, do you? Also, when you say "legwork for Multics", was this something done during the planning stages (so, say '64-'65), or later on? Noel

5 years, 9 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS