TUHS

tuhs@tuhs.org

6 participants
6532 discussions

Start a nNew thread

Nice article on porting Unix

by KenUnix

I have not seen this before. Nice article on porting Unix includes an 8086 CPU. Ken -- WWL 📚

2 years, 4 months

Unix v7 ps command question

by KenUnix

Hi, When executing ps alx on the interdata sim I get good output: # ps alx F S UID PID PPID CPU PRI NICE ADDR SZ WCHAN TTY TIME CMD 3 S 0 0 0 255 0 20 2235 2 4262 ? 36:48 swapper 1 S 0 1 0 0 30 20 2255 8 46060 ? 0:00 /etc/init 1 S 0 19 1 0 30 20 2745 11 46114 co 0:00 -sh 1 R 0 301 19 4 50 20 4056 20 co 0:00 ps alx 1 S 0 12 1 0 40 20 2545 5 140000 ? 0:00 /etc/update 1 S 1 18 1 0 40 20 2625 10 140000 ? 0:00 /etc/cron # When executing ps alx on the pdp11 sim I get bad output: # ps alx F S UID PID PPID CPU PRI NICE ADDR SZ WCHAN TTY TIME CMD 115 5120 0 0 1 26 1 55 1 3003 ? 120150:37 swapper # I tried copying the source from one machine to the other. No luck, same issue. I have attached the source from both machines. Any help appreciated. Ken -- WWL 📚

2 years, 4 months

Re: A second Unix Patent

by jnc＠mercury.lcs.mit.edu

> From: Douglas McIlroy > Typo, in v3 through v6 ... > 26^3 16-bit trigram counts didn't fit in the PDP-11 memory Being mildly curious, I fed '26 3 ^p' into 'dc' to see just how big it was - and got "17576", a 16-bit word array of which would fit into a PDP-11 64KB address space. I think the answer is in the first line - V3 didn't use the PDP-11 memory management, so the kernel _and_ the application had to fit into 56KB. So there may well have not been 36KB available to hold a 26^3 array of 16-bit words. The other possible explanation is that it was perfectly possible to run UNIXes of that era (V4 on) on machines without enough main memory to hold the kernel and a 'full-sized' process simultaneously. (Our original machine, an -11/40, started out without a lot of memory; I don't recall exactly how much, though. It had, I'm pretty sure, 3 banks of core; I was thinking it was 3 MM11-L core units, which would be 3x16KB, or only 48KB, but my memory must be wrong; that's not really enough.) Noel

2 years, 4 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole wrote: > It had more colorful name originally - fsck (pronounced as fisk BTW) > was finished. I suspect the fcheck name was a USG idea. I dunno. I don't think we at MIT wold have gratuitously changed the name to 'fcheck'; I rather think that was its original name - and we pretty definitely got it from CMU. 'fsck' was definitely descended from 'fcheck' (below). > From: Jonathan Gray >> (are 'fsck' and 'fcheck' the same program?) > https://www.tuhs.org/cgi-bin/utree.pl?file=V7addenda/fsck Having looked the the source to both, it's quite clear that 'fcheck' is a distant ancestor of 'fsck' (see below for thoughts on the connection(s)). The latter has been _very_ extensively modified, but there are still some traces of 'fcheck' left. A lot of the changes are to increase the portability, and also to come into compliance with the latest 'C' (e.g. function prototypes); others are just to get rid of oddities in the original coding style. E.g.: unsigned dsize, fmin, fmax ; Perfectly legal C, but nobody uses that style. > From: Jonathan Gray > fcheck is from Hal Pierson at Bell according to > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/readme.txt Hmm. "the major features that were added to UNIX by CB/UNIX ... Hal Person (or Pierson?) also rewrote the original check disk command into something that was useful by someone other than researchers." I poked around in CB/UNIX, and found 'check(1M)': https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man1_01.pdf (dated November 1979). Alas, the source isn't there, but it's clearly in the fheck/fsck family. (CB/UNIX also has chkold(1M), which looks to me like it's 'icheck'.) So now we have a question about the ancestry of 'check' and 'fcheck' - is one an ancestor of the other, and if so, which - or are they independent creations? Without the source, it's hard to be definitive, bur from the messages (as given in the manual), they do seem related. Clem's message of 3 Mar, 14:35 seems to indicate the the original was from CMU, authored by Ted Kowalski; he also: https://wiki.tuhs.org/doku.php?id=anecdotes:clem_cole_student says "Ted Kowalski shows up for his OYOC year in the EE dept after his summer at Bell Labs ... He also brought his cool (but unfinished) program he had started to write originally at U Mich - fsck". So maybe the CB/UNIX 'check' is descended from a version that Ted left behind at Bell Labs? Is anyone in touch with Hal Pierson? He could surely clear up these questions. Noel

2 years, 4 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

> From: KenUnix > So is it safe to say there is no fsck or similar for v7? There was a version of 'fcheck' (are 'fsck' and 'fcheck' the same program?) for V7, but I don't know if it's available. It would be really easy to convert the 'fcheck.c' that I put up to a V7 version; the V6 and V7 file systems are almost identical, except for the block size, I think. > From: Dan Cross > I believe you posted a link to end(3) here back in 2018 Yes, but that does't talk about '_end' not being defined if there are missing externals, either! All it says is: "Values are given to these symbols by the link editor 'ld' when, and only when, they are referred to but not defined in the set of programs loaded." Now that I think about it, I have this vague memory we had to look at the source for 'ld.c' to verify what was going on! > From: Jonathan Gray > That is close, but slightly different to the PWB fcheck.c Interesting. I wonder how 'fcheck' made it from CMU to Bell? Clem and I discussed how it made it from CMU to MIT, and we think it was via Wayne Gramlich, who'd been an undergrad at CMU, and then went to grad school at MIT. I'm pretty sure the reason we liked it was not any auto-repair capabilities, but ISTR it was somewhat faster than icheck/dcheck. (Interesting that they were separate programs in V6; V5 seems to have only had check: http://squoze.net/UNIX/v5man/man8/check https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/check.c which contained the functionality of both. I wonder why they were split? Space?) > From: Rich Salz > But the amazing point was it worked regardless of bit order. I forgot to mention thast, but yes, its input was the number in bit-serial form. I suspect there's a connection between the property he mentioned, and the fact that the grad student could design something which would work with binary numbers fed in from either end, but I can't bring myself to devote the brain cells to figure it out. > From: John Cowan > I didn't know that one was done at MIT. Yes; see: https://www.hactrn.net/sra/alice/alice.intro There's a really funny story at the end of that about the real Ann Marie Finn. In Rob's version, she took the role of KAREN in the earlier one. That would be Karen Prendergast, Patrick Winston's admin; why we used her I don't know, since I didn't really know her, but I guess she had a reputation as a bit of a 'tough cookie'. >> I think that the person fails their oral. I have no idea if it's a >> true story. > That's vicious. Hey, this _is_ the school that used to tell incoming freshpeople, at the welcoming picnic 'look at the person to your left, and to your right; at graduation, one of you won't be here'. I don't remeber if they said the same thing at mine, or if the story had just been passed down from class to class. Noel

2 years, 4 months

A second Unix Patent

by Warner Losh

In looking at the first AUUGN today, I noticed the following at the end of a letter John Lions sent home when he spent a sabbatical at Bell Labs [image: image.png] I've seen the first patent, but not the second one... That's got to be a joke or inside joke, right? Anybody know anything else about it?

2 years, 4 months

Unix v7 programs to share

by KenUnix

Unix v7 programs to share With all your help I thought I would share a couple of programs I had a hand in. more.c is like 'more' for Linux. more abc.txt or cat abc.txt | more or ls -l | more pg.c is a 'pager' program. pg abc.txt def.txt cls. is a clear screen home cursor program using VT100 codes. It works on the console or telnet or putty. All can be compiled and placed in /usr/bin cc -o /usr/bin/cls cls.c cc -o /usr/bin/more more.c cc -o /usr/bin/pg pg.c https://drive.google.com/file/d/1LR3Q11sGADXuqA2C2c2gEKmJOrsXA8QC/view?usp=… https://drive.google.com/file/d/1_IUnyPwsRvYMAuqO9xb8Z8MZDbKLST70/view?usp=… https://drive.google.com/file/d/1t88SNnJjWIbPrGuTFfFZM-7qKhD6AS6S/view?usp=… More to come. Ken -- WWL 📚

2 years, 4 months

simtel20 unix-c software archive

by A. P. Garcia

There was a well known ftp site in the early 1990s called simtel20.army.mil. It was mostly known as a repository for ms-dos utilities, but it also had a collection of source code to various user-contributed unix utilities. I just uploaded those to the Internet Archive: https://archive.org/details/oak-unix-c--full-mirror-1999.12.14

2 years, 4 months

Any Bell 8-bit UNIX Efforts?

by segaloco

So in working on an unrelated 6502 project, I got to wondering about UNIX on it and other 8-bits. Did some Googling, and while I was able to turn up some attempts at UNIX-likes on 6502 as well as Z80, the only one I found that might have some Bell connection is "uNIX" as documented here: https://bitsavers.org/pdf/uNIX/uNIX_Jan82.pdf A forum post I read suggested those involved were some former Bell folks from NJ. In any case, this begs the question for me: Were there ever any serious attempts at an 8-bit UNIX in the labs or Bell System at large? Certainly it would've provided quite the challenge without much return compared with 16 and 32-bit efforts, but does anyone know if, say, an LSX/Mini-UNIX-ish attempt was ever made at the 6502, Z80, or other 8-bits? Thanks all! - Matt G.

2 years, 4 months

Unix v7 tape drive question

by KenUnix

Hi, I am trying to use the 'dump' program but it references rmt1. My system only has rmt0. I have been unable to find how to create this device. I have looked over the reference material but it only references rmt0. Is there any way to redirect a dump to use rmt0? Any help is appreciated. # ls -l total 4 drwxr-xr-x 2 root 336 Mar 1 16:56 . drwxr-xr-x 8 root 288 Feb 21 17:18 .. crw--w--w- 1 root 0, 0 Mar 2 07:47 console crw-r--r-- 1 bin 8, 1 Jan 10 1979 kmem -rw-rw-r-- 1 bin 775 Jan 10 1979 makefile crw-r--r-- 1 bin 8, 0 Jan 10 1979 mem *brw-rw-rw- 1 root 3, 0 Mar 1 20:42 mt0* crw-rw-rw- 1 root 12,128 Dec 31 1969 nrmt0 crw-rw-rw- 1 bin 8, 2 Dec 31 1969 null *crw-rw-rw- 1 root 12, 0 Feb 23 15:55 rmt0* brw-r--r-- 1 root 6, 0 Mar 2 07:47 rp0 brw-r--r-- 1 root 6, 15 Dec 31 1969 rp3 crw-r--r-- 1 root 14, 0 Dec 31 1969 rrp0 crw-r--r-- 1 root 14, 15 Dec 31 1969 rrp3 brw-r--r-- 1 root 6, 1 Dec 31 1969 swap crw-rw-rw- 1 bin 17, 0 Mar 1 19:39 tty crw--w--w- 1 root 3, 0 Mar 1 19:41 tty00 crw--w--w- 1 root 3, 1 Feb 23 16:47 tty01 crw--w--w- 1 root 3, 2 Feb 21 16:56 tty02 crw--w--w- 1 root 3, 3 Feb 21 16:56 tty03 Not only that but when attempting to use dump it creates a file and consumes all the space on rp0 In dev it creates: -rw-rw-r-- 1 root 174080 Mar 2 09:20 rmt1 Sample run: # dump date = Thu Mar 2 09:20:16 2023 dump date = the epoch dumping /dev/rrp3 to */dev/rmt1* I II estimated 24870 tape blocks on 0 tape(s) III IV *no space on dev 6/0* no space on dev 6/0 no space on dev 6/0 no space on dev 6/0 Thanks, Ken -- WWL 📚

2 years, 4 months

Unix v7 programs to share

by KenUnix

2 years, 4 months

A second Unix Patent

by Douglas McIlroy

> This one, perhaps: > https://patents.google.com/patent/US3964059A/en Yes, that's the Typo patent. Notice that it features "method and apparatus". The bizarre idea of doing it in hardware was a figment of the patent department's imagination. This was a dance to circumvent the belief at the time that software could not be patented. Software was smuggled in by stating that it was one way to realize the apparatus in the patent disclosure. The now obsolete belief was fallout from Gottsschalk v Benson, in which the Supreme Court invalidated another Bell Labs patent, on a trick to save a few cycles in converting integers between BCD and binary. The grounds for rejection were roughly that software was math (a "mental step") and therefore not patentable. The Benson decision, written by William O. Douglas, makes ludicrous reading: it argues, though the patent does not claim, that a patent on this narrow method could be enforced against any program that converts BCD to binary. Apparently Douglas thought that all black-box programs for a given purpose were the same, although the patent office did not so conflate different mechanical or electrical apparatuses that have a common purpose. Doug

2 years, 4 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

> I am having a problem clearing a dup inode. V6 had almost no tools for automagically fixing file system corruption. To do it, you need to i) understand how the FS works (see: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5 but it's pretty simple); ii) understand what the few tools (dcheck; icheck; clri) do; iii) dive in. I recall I used to use 'adb' a lot, to manually patch things when there was a problem, so you'll want to study up on the 'db' syntax (no 'adb' in vanilla V6, but for this, they are basically equivalent): https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man1/db.1 You'll have to use the non-raw version of the device (the raw version can only read/write complete blocks), and then judiciously use 'sync' to flush the updated blocks out to the 'physical' disk. (There are some corner cases where data is stored elsewhere, such as when one is patching the inode of an open file, but I'm going to ignore them.) > # icheck -s /dev/rp0 'icheck -s' only rebuilds the free list; it doesn't help with any other error (e.g. a block being assigned to two different files). > 4244 dup; inode=323 Which is probably what is happening here. 'icheck': https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/icheck.8 is not telling you what _else_ is using that block, because it has already forgotten that by the time it discovers this second claimant (it only keeps a bit array of 'used' blocks). > # icheck -b 323 /dev/rp0 Err, you wanted to say 'icheck -b 4244' to find out who else was using block 4244. I'm not sure if 'fsck' would fix these; I have a V6 one, if anyone wants it. The 'easy' way to fix this is i) copy the second file to somewhere else, ii) delete the original, iii) re-build the free list (because the duplicate block will now be in both the first file, and the free list), iv) examine both files, and see which one has the smashed contents. I'll turn this into a 'Fixing damaged V5/V6 file systems' article on the CHWiki. Noel

2 years, 4 months

Early GUI on Linux

by Paul Ruizendaal

I think discussion of early Linux is in scope for this list, after all that is 30 years ago. Warren, if that is a mis-assumption please slap my wrist. Following on from the recent discussion of early workstations and windowing systems, I’m wondering about early windowing on Linux. I only discovered Linux in the later nineties (Red Hat 4.x I think), and by that time Linux already seemed to have settled on Xfree86. At that time svgalib was still around but already abandoned. By 1993 even student class PC hardware already outperformed the workstations of the early/mid eighties, memory was much more abundant and pixels were no longer bits but bytes (making drawing easier). Also, early Linux was (I think) more local machine oriented, not LAN oriented. Maybe a different system than X would have made sense. In short, I could imagine a frame buffer device and a compositor for top-level windows (a trail that had been pioneered by Oriel half a decade before), a declarative widget set inspired by the contemporary early browsers and the earlier NeWS, etc. Yet nothing like that happened as far as I know. I vaguely recall an OS from the late 90’s that mixed Linux with a partly in-kernel GUI called “Berlin” or something like that, but I cannot find any trace of that today, so maybe I misremember. So here are a few things that I am interested in and folks on this list might remember: - were there any window systems popular on early Linux other than X? - was there any discussion of alternatives to X? - was there any discussion of what kernel support for graphics was appropriate?

2 years, 4 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

> From: KenUnix > things are missing: > Undefined: > _setexit > _reset > _seek > _alloc > _end > Yes, I am trying to compile it on Unix v7. Well, there's your answer. They are all in the V6 library. Here's the source for setexit/reset: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s5/reset.s You do realize that if you got it compiled under V7 and ran it, it would trash the disk, right? (The V6 and V7 filesystems are different; very similar, but block nubers are 16 bits on V6, ans 32 bits on V7.) > Is there a makefile? No. No 'make' in V6. Which is why you find those 'run' shell files: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/run everywhere. > From: John Cowan > It was an update/rewrite of the MIT version. Which one? There were two: "MIT's AI Lab", by CSTACY, Alan Wecsler, and me; which Rob Austein re-wrote into "Alice's PDP-10". I thought the original was centered around ITS, but my memory was poor (hey, it has been ~40 years :-), it seems to sort of be about LISP Machines. Rob's version was about TWENEX (yech). The original was written in 926, MOON's office; I can't believe he put up with me hanging out there! >> Although I like the old story about the person at their oral exam and >> the Coke bottle in the window. > Details? So they're giving someone an oral exam. They can't make up their minds, or something, and they ask the person to step out for a second. When the person comes back in, they point to a Coke bottle sitting on a window-sill in the sunlight, and ask them to examine it. The person notices that it's warm on one side - the side facing the window. 'Why that side?', they ask. So the person goes into a long explanation about how the curved glass must have focused the light, yadda-yadda. WRONG! They turned it around while the person was out of the room. I think that the person fails their oral. I have no idea if it's a true story. Steve Ward told another oral story which I'm pretty sure _is_ true, though. They ask the candidate to design a state machine (or digital logic, I forget which) which can tell if a number is divisible by three (I think I have the details correct, but I'm not absolutely certain). So they describe one - and then point out that you can feed the number in from either end (most or least significant end first) - and proves that it will work either way! The committee was blown away. Noel

2 years, 4 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

> I'm not sure if 'fsck' would fix these Turns out it was called 'fcheck' when we had it. > I have a V6 one I'd already put it on my Web site, here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c if anyone wants it. > From: "Ron Natalie" > You had adb? Yeah, MIT had a lot of stuff that 'fell off the back of a truck' (including things like the circuit design tools, etc). Well, having an undergrad who was in the famous Boy Scout troop at Bell helped... :-) > From: KenUnix <ken.unix.guy(a)gmail.com> > What I finally did was restore the ".disk" files from a previous backup You may sit with Arlo Guthrie on the 'Windows user' bench. :-) > From: "Theodore Ts'o" > some have argued that if someone doesn't do backups of their research > data, maybe they don't *deserve* to get their Ph.D. :-) 'Think of it as evolution in action.' Although I like the old story about the person at their oral exam and the Coke bottle in the window. Noel

2 years, 4 months

Re: Unix v7 icheck dup problem

by jnc＠mercury.lcs.mit.edu

>> _end > They are all in the V6 library. Oops, not _end. In the V6 linker, "_end" is not defined if there are still undefined symbols at the end of the linking run. I remember finding this in some obscure place in the V6 documents; it's not in 'ld(I)'. Anyone remember where it's discussed? Noel

2 years, 4 months

Unix Systems Administration Texts

by Will Senn

I've been doing a lot of reading of systems admin books lately including: Frisch, E. (1991). Essential System Administration (3rd edition is my fattest book other than Unabridged Shakespeare) Hunter, B. H., & Hunter, K. B. (1991). UNIX Systems Advanced Administration and Management Handbook (Opinionated praxis) Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty) Tons of other more recent drivel. I have been working on my ancient and not so ancient Unix library for a while now, and it's kind of funny. It seems like once I read a book, be it new or old, I hardly need it anymore - most of them wind up back at half-price books. The exceptions are those that I find myself going back to over and over and over again and wow are those few and far between. An example of one of the gems is S. R. Bourne's The UNIX System, another is Kernighan and Pike's The UNIX Programming Environment, and a couple of newcomers for me are Volumes 3 and 8 of O'Reilly's The Definitive Guides to the X Window System. I've written in the margins so many times with these that there are sections where I can't fit any more notes. That's the kind of sys admin guide I'd like to hear about. So, my question for y'all is, what did y'all think about sys admin texts as they were coming out? Were they well received, were they water to a dying horse, were they paperweights, what? If you are of the camp, "we don't need no stinking admin guide", or "we did it all by muscle memory and didn't use books", don't reply. I'm curious about the experience of those of y'all who actually used them. Were there any early standouts and why did they stand out? Anything from 1970 on is fair game. Later, Will P.S. Can you believe that 2000 is fast becoming 'history' worth preserving? In 1997, we were rewriting our gas pump and credit card transaction systems, which were written in C, to deal with upcoming Y2K bugs. Oh, how the worm has turned :).

2 years, 4 months

Init History Ala MERT, CB-UNIX, and USG Generic

by segaloco

So now that I'm done futzing with the 4.1 manual for a while, I've decided to look around a few others to try and get a better feel for the continuity of different features as well as documentation practices between branches. On that note, the more I compare, the more continuity I find between PWB 1.0 and UNIX System III. Between that, various emails here, and some info from Clem, I feel fairly confident calling System III and V as well as the 4.1 in between PWB releases, at least as far as version continuity is concerned, so I may start using that nomenclature more here and there. On the flip side, the name UNIX/TS seems to bear less and less relevance outside of whatever efforts it did originate with in the late 70's. I eventually mean to aggregate all the references I've found together to develop a better picture of what that was, but just know that documentation consistency points to PWB 3, 4, and 5 as the true identity of the USG releases in the 80s, not UNIX/TS as I have referenced previously. So now for an interesting bit of init history I've managed to piece together. The 4.1 manual still indicates the same init system as System III, based on a file called /etc/inittab but with a slightly different format and semantics from what we ultimately see in System V. That init, seen earliest thus far in PWB 3.0, seems to have been developed around that time. I'm struggling to find the email right now but I think someone on the list mentioned having written this one in either '79 or '80. As for the init in System V, it likely entered the PWB line from CB-UNIX based on the CB-UNIX 2.3 manual which can be found here: https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man5.pdf . I say likely as some recent perusal of the MERT Release 0 manual has now cast some doubt on that. So to start, CB-UNIX 2.3 appears to be somewhat contemporaneous with UNIX 5.0 in that the manual has pages labeled specifically UNIX 5.0. That said, the issue date on the front pages of the manuals is over a year apart, so the 5.0 additions could be just that, added pages after the formal 2.3 issue. Anyway, in common between them is an init system utilizing likewise a file named /etc/inittab, but with a slightly different format and some expanded functionality. The CB-UNIX manpage for this inittab(5) can be found on page 29 of the above document. I had never looked further in that one though, and a couple days ago, I was cataloging all of the pages present in that manual when I came across page 34. This is a page for lines(5) that simply says "No longer used. See inittab(5)." Curious, so perhaps this stream of init once called the file /etc/lines, then renamed it inittab to match PWB? The very next page answers part of that question. Page 35, also lines(5), contains a description of a file very similar to the inittab(5) entry except a line is 5 fields wide, including a "shellcm" field. Unfortunately, the remaining pages of this entry are not in the PDF, presumably this was a mistaken entry. I have another such mistaken entry in a moment. Anywho, what is there of the page indicates the id field actually had an impact on the /dev entry for the terminal line in that it would be named /dev/ln<id>, and goes on to say that if a line monitor other than /etc/getty is used this must be accounted for. So interesting little note there about using something besides getty for line monitoring. Otherwise the page reads pretty similar for what is there, indicating a likely continuity between this /etc/lines-based init and the CB variant of the /etc/inittab system. One interesting note is that /etc/lines supports C-style comments, /etc/inittab instead uses sh conventions. This lines file also indicates there is a run-level 7 which may have become the S run-level. The respawn and wait actions are there, and that's where the page cuts off, so no further evidence here of what was in /etc/lines in 1979 in CB-UNIX 2.1. By 1980 it is replaced with /etc/inittab. So aside from the lines(5) stuff, this has been pretty well understood that System V init came from or at least strongly resembles CB-UNIX init as far as what is available documentation-wise. Well, as I mentioned above, the MERT Release 0 manual may shed some further light on this matter, albeit without fully illuminating it. So first, some MERT context. This document details the origins of MERT Release 0 pretty succinctly: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs%2037-… . Basically MERT 0 is the first "supported" release by the "Small Systems Planning and Development Department (8234)" at Murray Hill. The manual is based on the USG Program Generic Issue 3 version of the manual which was issued in early 1977. This manual, in turn, is from October 1977. This intro goes on to indicate that this product will eventually be released instead as "UNIX/RT" to accompany the in-progress "UNIX/TS" which is said here to be based on V7 with additions from USG Generic 3 and PWB. The MERT-specific portion of this manual is technically considered the second edition, presumably in that the first was the material maintained and distributed by Lycklama and Bayer. So in any case, the landscape of the time seems to be that V7 is starting to go around to the various streams, with UNIX/TS in the works to present it with USG/PWB stuff and then UNIX/RT being planned as the MERT-counterpart. This isn't quite my focus here, but does provide some UNIX/TS "stuff" that has been explained to varying degrees already. So where this all relates to the init though is this: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Pgs%2001-…'s%20Manual%20for%20MERT.pdf On page 4 of this document is a list of pages that one must replace in a standard USG Program Generic 3 manual to produce a MERT Release 0 manual. In other words, this essentially lists which pages are changed for MERT. Of interest to this discussion is the V File Formats section on page 5. The instructions are to remove a page called "lines" and to add a page called "ttys". If you then go on to read through the manual, in section V, the ttys file suggests an init system akin to the research init system. This is also indicated by replacement of the init page itself with one describing a system closer to that of research than anything else: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Pr… . So based on this, it sounds like USG Generic 3 may have had the same /etc/lines init that we see hints of in CB-UNIX. This also then suggests that CB-UNIX 2.3 may have some basis in USG Generic 3 just like MERT. Based on yet another email I'm struggling to find, another user here had offered up some info regarding a USG Generic 2 manual he has from days past. That manual contained an init similar in flavor to the research init as well, indicating that this init system shows up as part of Generic 3. So now for that other misprint that also bears some relevance. In the UNIX 4.1 manual I recently finished restoring, there was an errant gettydefs(4) page which was only the very last few lines of the manpage (basically the SEE ALSO) section. This file is not part of the pages one needs to discard to create a MERT manual and is not otherwise in the manual, so does not appear to be a part of Generic 3. However, this file does show up in CB-UNIX 2.3, and from there presumably gets sucked into System V, but the misprint suggests such a manpage existed somewhere that would've accidentally wound up in a UNIX 4.1 typesetting run. In any case, it is very well possible this init system may have started popping up in the PWB line before 5.0, but I can't confirm this. In any case, to consolidate this information, here's a bit of a timeline for the init as I see it: 1975 May - V6 issued. Begins getting adopted as the standard base for various streams 1976 January - USG Generic 2 issued. From what has been discussed, this still has a research-style init based on /etc/rc and /etc/ttys 1977 March - USG Generic 3 issued. This allegedly features the addition of the /etc/lines-based init that eventually becomes System V init 1977 May - PWB 1.0 issued. Forks the documentation style quite a bit, starts trends that continue to System III and beyond, still research-style init 1977 October - MERT 0 issued. This uses Generic 3 as a base but reverts to a research-style init system 1979 January - V7 issued. Still using /etc/rc and /etc/ttys 1979 November - CB-UNIX 2.1 issued. This appears to be using a Generic 3-style /etc/lines init 1980 June - PWB 3.0 issued. This has the first known appearance of /etc/inittab but with a different implementation from USG Generic 3 1981 May - CB-UNIX 2.3 issued. By this point, /etc/lines has morphed into /etc/inittab and /etc/gettydefs has been added 1981 June - PWB 4.1 issued. The manual still features the PWB 3.0-style init but an errant page suggests at least possibly /etc/gettydefs support 1982 June - PWB 5.0 issued. The transformation is complete, PWB now uses Generic 3-descended init with CB-UNIX gettydefs This all makes me wonder what PWB 2.0 and UNIX/TS (if it ever coalesced) would've used. Precedent would say PWB 2.0 would use research-style init and UNIX/TS would've likely used Generic 3 if the aim was continuity with the USG Generics, but who knows. Anywho, hope that info's helpful to anyone else researching init systems. Of course if you have info that contradicts or enhances any of this I'd love to hear it! - Matt G.

2 years, 4 months

Unix v7 programs to share

by KenUnix

With all your help I thought I would share a couple of programs I had a hand in. more.c is like 'more' for Linux. more abc.txt or cat abc.txt | more or ls -l | more pg.c is a 'pager' program. pg abc.txt def.txt cls. is a clear screen home cursor program using VT100 codes. It works on the console or telnet or putty. All can be compiled and placed in /usr/bin cc -o /usr/bin/cls cls.c cc -o /usr/bin/pg pg.c cc -o /usr/bin/more more.c More to come. Enjoy. Ken -- WWL 📚

2 years, 4 months

Unix v7 icheck dup problem

by KenUnix

Hi, I am having a problem clearing a dup inode. Here is what I have tried: # icheck /dev/rp0 <=== Ran this /dev/rp0: 4244 dup; inode=323, class=data (small) <=== Dup files 231 (r=207,d=7,b=4,c=13) used 4265 (i=115,ii=2,iii=0,d=4146) free 537 missing 0 # icheck -s /dev/rp0 <== Tried to rebuild /dev/rp0: 4244 dup; inode=323, class=data (small) # icheck /dev/rp0 /dev/rp0: 4244 dup; inode=323, class=data (small) files 231 (r=207,d=7,b=4,c=13) used 4265 (i=115,ii=2,iii=0,d=4146) free 536 missing 0 # icheck -b 323 /dev/rp0 <=== Tried /dev/rp0: 4244 dup; inode=323, class=data (small) <=== Dup persists files 231 (r=207,d=7,b=4,c=13) used 4265 (i=115,ii=2,iii=0,d=4146) free 536 missing 0 # Thanks, Ken -- WWL 📚

2 years, 4 months

Re: Unix V7 enblock.c

by jnc＠mercury.lcs.mit.edu

> From: Michael Huff > All of the simh vax tutorials on Gunkies still give instructions to turn > all of the tar files (plus things like miniroot) into a single tap file > for installation. If those are out-of-date, you/someone should get a CHWiki account and update them! :-) Documentation skew from code has always been a problem... Noel

2 years, 4 months

Unix V7 enblock.c

by KenUnix

Morning, I am using enblock to create tap files from tar files. Was a program ever written to convert tap files to tar files or a Linux program that could read tap files? I also see that writing to a tap file from Unix the size increases when writing multiple files however when writing 1 file to the tap file "tar cv0 ..." the tap file still remains at its larger size from the previous larger writes. Is this what is expected? Thanks, Ken -- WWL 📚

2 years, 4 months

Unix/Linux games [was Re: Early GUI on Linux]

by Andy Kosela

On Monday, February 27, 2023, Dan Cross <crossd(a)gmail.com> wrote: > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS <tuhs(a)tuhs.org> > wrote: > > Thanks all for the insights. Let me attempt a summary. > > > <SNIP> > Oh, and lots of games; I had a nice > Solitaire version that I can no longer recall the name of. > > Coming from the 8-bit microcomputer world (Atari 8-bit, C64), and then upgrading to 16-bit (Amiga and PC MS-DOS) I experienced a myriad of unforgettable games on those platforms. They were mostly commercial but they were very much different from modern games. It was the era of innovation and pouring all your soul into the games you produce. I still think that some of them have not been surpassed in quality and playability. I still play them on period correct hardware as they are still extremely fun and challenging. This is my top 10 list (sorted by year): * Prince of Persia * The Secret of Monkey Island * Civilization * Dune II * Master of Orion * Reunion * Warcraft * Ascendancy * Quake * Half-Life As I started to play with Linux in the mid 90s I remember a port of Doom and then Quake, but not that many other games. Can you elaborate more on what Unix afficionados played in the late 80s/early 90s? --Andy

2 years, 4 months

Fwd: Re: Generational development [was Re: Re: Early GUI on Linux]

by Adam Thornton

And, you know, let's say you have all the time and patience in the world and you download the source and read it carefully and determine it's not malicious... I believe there might have been a lecture/paper about this once. https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrust… (I can just hear them damn kids standing on my lawn chanting "You can't spell 'trust' without 'rust'!") I keep trying to give VSCode a go. It seems really nifty. And somehow I keep bouncing off and landing in Emacs, every time. Maybe when I finally get around to writing, rather than cargo-culting TypeScript, or Unity/C#, it'll be a better fit. But for my current life, which is mostly Python...I appear to be sticking with Emacs. Adam

2 years, 4 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS