On 10 Nov 2017 12:00 -0600, from will.senn(a)gmail.com (Will Senn): Semi-related thought, possibly helpful: Did the manuals (I mean the printed ones) have indexes that were meaningful for such purposes? I'm thinking something like the output of apropos / man -k, not just a listing of command names and page numbers. Sure knowing that the description for how to use ls was in section 1 page 42 might have been _helpful_, but not really for finding out _how to list files_ in the first place... -- Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)

Ø My question for you citizens of that long-ago era :), is this - what was it like to sit down and learn unix V7 on a PDP? Not from a hardware or ergonomics perspective, but from a human information processing perspective. What resources did you consult in your early days… I remember this well. Actually, I started with V6 UNIX. The biggest difference between using a simulator versus what happened back in 1977 when I started was that I didn’t have exclusive access to the machine. The Johns Hopkins EE department computer was at the time run by a group called the Undergraduate Computing Society. Mike Muuss and Pete Koziar were the system programmers at the time I started. Joe Pistritto was head of operations. George Toth was in charge of documentation and Bill Lindeman was in charge of hardware, if I remember all this correctly. The first edition K&R and the printed man pages and related documents were what I started with. I set about learning C (along with nroff which I had used to write a few freshman papers). My freshman year, after one too many security failures in the UCS, the EE department pulled the plug on the UCS and gave us adult supervision. Of course, the work was still done by the students, we just reported to the professor now. Robert Jesse took over as head of operations and induced me to become an operator. What I had to learn was the structure of the V6 filesystem and what could go wrong and how to detect and fix things with icheck, dcheck, clri, and the like. I then badged Mike into giving me access to the UNIX source code (in printed form, the kernel source disk couldn’t be left mounted all the time due to lack of drives). I can’t tell you how many times I started reading buf.h trying to understand it. We didn’t have access to the Lyons book at the time. Finally, one day George Toth was writing a driver for a printer we had gotten and he said he’d write it but wouldn’t debug it. I volunteered to take it through to completion. So with a night of scheduled downtime, and Mike supervising me by sleeping in the beenbag chair we had next to the console, I tested and fixed the hardware driver. After that, I was sort of the go-to guy for driver work. I also spent a lot of time looking for ways to break security and/or crash the system and then fixing them. Of course, I soon also became adept at fixing holes other people had exploited. Around my junior year, the PDP-11/23 came out and one of the labs upstairs got one to run experiments (biomedical engineering). I got tasked with maintaining that machine and that gave me a nicer platform for kernel hacks because as long as it wasn’t needed for one of the PhD student’s research, I could have it to myself. Coupled with this hands on was the fact that Mike Muuss believed in liberally applying comments to the UNIX kernel to explain what was going on. He was so incensed about the “You’re not expected to understand this” comment on the retu/aretu/setka6 code snippet, that he wrote almost a page of explanation as to what was going on. He was a bit livid when he sent things off to Berkeley for inclusion in BSD releases that they (McKusick?) enforced a common commenting style by deleting all of Mike’s additions. -Ron

On Fri, 10 Nov 2017 12:00:15 -0600 Will Senn <will.senn(a)gmail.com> wrote: Will Senn writes: ... I learned by trying out pretty much *every* command in /bin and /usr/bin. I would read the man page, play with the command, read the man page some more, and so on. I wrote toy programs to learn about common libc functions. I tried out pretty much every vi command to become better at editing. Fotunately v7 was a small enough system that one could actually learn something about every command, every device driver, every syscall, every libc function etc. I read the documentation bundled with v7 & BSD, and I read unix source code as well as observed and learned from seasoned unix hackers. But I would switch to writing (and rewriting) code ASAP as I learn better by building something. And debugging. There are lots of learning opportunities there! The key is not give up until you find the root cause. Debugging can give a more intuitive sense of how things work as you start paying more attention to even little things.