From clemc at ccc.com Wed Mar 1 01:28:57 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Feb 2023 10:28:57 -0500 Subject: [TUHS] Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: <202302280759.31S7xt4e001399@freefriends.org> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> <202302272022.31RKMG2L004091@freefriends.org> <202302280759.31S7xt4e001399@freefriends.org> Message-ID: On Tue, Feb 28, 2023 at 3:00 AM wrote: > As Dan said, this is nuanced. > That is so true - I suspect it is a multi-edged sword, probably more than two edges. > > While I'm sure there's lots of mediocre programmers writing mediocre code, > (a) there probably always has been [think COBOL on mainframes] and (b) it > is not universal. Sure. CS students are still not getting introduced to FORTRAN even though over 90% of all production supercomputer code uses it. Again I don't program it, but I accept that modern Fortran is not a terrible language - because I looked at it and know a bit about it (I'm not too snooty to do so). So modern FORTRAN courses are now taught in science departments and passed from professor to student (and it paid my salary as long as I made systems that ran it well). My 30 yr CS major daughter, who has been at Google for a few years, never saw FORTRAN (or Snobol - much less awk/sed) in her comparative languages course. I think that's a sin. She's fluent in Python and Java - as well as a ton of tools for 'cloud development and deployment.' Clearly these are valuable skills and the way a lot of modern programs are deployed. She can work with C++ and Go (and I think Rust) and saw a dialect of LISP (racket) in her comparative languages course. In her university time, they taught they all about regular expressions and made her and her classmates all use grep/awk/sed in her original algorithms course years ago. > I have generally been fortunate to find interesting > and challenging work in a fairly long career; there's lots of interesting > problems out there that need solving which can't be dealt with by just > stringing together existing class libraries using an IDE on autopilot. > You have to look for it, and then hope you're qualified enough that they'll > hire you. > Exactly. However, the cool things that we are yet to see will be created by Matt and my daughter's generation, and I'm sure they will be great and *just as important in the long run* as some of the neat things a few of us on this list created. As Dan said, CS did not stop in 1989. Dennis said it well: *“From an operating system research point of view, Unix is if not dead certainly old stuff, and it’s clear that people should be looking beyond it.”* The important thing is not to reject something just because it is old and jump to something because it's new. I find the current class-library/frameworks cruft as bad (and not a lot different from) the 'access methods' that IBM created in the 1960s, and Multics and UNIX boldly rejected with all the worlds a 'segment' or later file. This is the importance of teaching and exposing students to ideas (good and bad) from the past so as not to repeat them. BTW: just because an idea failed previously does not mean it will not work later or that such an idea is a good or bad one now. This is why experience is so important - for a >>great read<< Peter Novigs Teach Yourself Programming in Ten Years I often refer to this as picking up 'good taste.' I agree with Arnold that learning an IDE often seems like you are losing the ability to have a foundation. I've pointed out reading >>and doing the exercises<< in Rob and Brian's excellent text: The Unix Programming Environment really should be part of all young programmers' experience (even learning to use a document compiler like the runoff family. Once you master ed, regular expressions and the like make you a better programmer. I'm not saying you must be fluent/use vi or emacs as your primary editor to be a great programmer. Still, I would place a large bet that the best programmers all know how to use at least one of those tools - and I'll also bet that they all could use a QED-derived line editor if that is what was available. The key to the UNIX philosophy is teaching to think *vs.* spoon-feeding a current answer. Sometimes, the latter has its place (I use many GUI-based applications on my mac), but I always have several 'iterm2' windows open with a shell prompt. The problem is that when the former is all you know, your only real experience, I think people that have a wider field of view and a more open mind are going to understand that your experience is quite limited and thus the ability to judge the good/bad-ness of a something might be a tad suspect. Curmudgeon-ly yours, Clem ᐧ ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Wed Mar 1 01:45:23 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Tue, 28 Feb 2023 10:45:23 -0500 Subject: [TUHS] Unix V7 enblock.c Message-ID: 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 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Wed Mar 1 01:50:43 2023 From: athornton at gmail.com (Adam Thornton) Date: Tue, 28 Feb 2023 08:50:43 -0700 Subject: [TUHS] Fwd: Re: Generational development [was Re: Re: Early GUI on Linux] In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <202302272004.31RK4aGG001510@freefriends.org> <2f6faeb4-5e73-cf18-b0ff-edc3e1658f72@case.edu> <202302272022.31RKMG2L004091@freefriends.org> <202302280759.31S7xt4e001399@freefriends.org> Message-ID: 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_ReflectionsonTrustingTrust.pdf (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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Wed Mar 1 01:51:02 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Tue, 28 Feb 2023 10:51:02 -0500 Subject: [TUHS] Unix V7 enblock.c In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023 at 10:45, KenUnix wrote: > 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 > Hi Ken, Questions like this are probably better suited to the SIMH mailing list. https://groups.io/g/simh That being said, is there a reason you're bothering to convert to tap format? Modern versions of SIMH can do "attach [file] -f tar [device]" to directly attach a tar file to a tape device. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mah at mhorton.net Wed Mar 1 02:49:50 2023 From: mah at mhorton.net (Mary Ann Horton) Date: Tue, 28 Feb 2023 08:49:50 -0800 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: <7wbklet6ga.fsf@junk.nocrew.org> References: <7wbklet6ga.fsf@junk.nocrew.org> Message-ID: <4bea6304-e275-c336-042b-899aaf3cab35@mhorton.net> Didn't Peter Langston have a bunch of CHUI games for V6? ISTR a car racing game where the 24x80 screen showed the driver's view to the front, including a rear view mirror that could show other cars. Thanks, /Mary Ann Horton/ (she/her/ma'am) maryannhorton.com "This is a great book" - Monica Helms "Brave and Important" - Laura L. Engel       Available on Amazon and bn.com! On 2/28/23 02:44, Lars Brinkhoff wrote: > Andy Kosela wrote: >> Can you elaborate more on what Unix afficionados played in the late >> 80s/early 90s? > Dungeon/Zork > Rogue > Nethack > Mazewar > XPilot -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Mar 1 04:59:14 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 28 Feb 2023 18:59:14 +0000 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: Sounds like Idris and uNIX are the closest we get with ex-Bell personnel being involved with both projects. I haven't found anything in the surviving Bell streams that suggests any 8-bit attempts internally, and various portability documents suggest 16-bit and 32-bit targets abound but nothing like a 6502 or Z80 running UNIX inside Bell, again not that it would really be that worthwhile of an experiment at the time given their focus on minis. Anywho, if anything ever does show up in my study I'll happily share the details. - Matt G. ------- Original Message ------- On Monday, February 27th, 2023 at 2:57 AM, Jonathan Gray wrote: > On Sat, Feb 25, 2023 at 07:48:45PM +0000, segaloco via TUHS wrote: > > > 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. > > > If by Bell connection you mean people. Plauger left in 1975, > joined Yourdon Inc in 1975, started Whitesmiths Ltd in 1978[1]. > Whitesmiths created Idris, a clone of Unix. > > "Idris can run comfortably where UNIX can't event fit: On an > MC68000 with no memory management hardware, for example. > On a bank-switched 8080 or Z80. Or on any LS-11 or PDP-11 > with memory management." > Whitesmiths advertisement in Computerworld, Mar 1983 [2]. > > Yourdon Inc, announced Omnix in 1980, a Unix-like system for Z80[3]. > By 1981 it "had to be withdrawn when Yourdon were let down by its > developers" [4]. > > [1] https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf > [2] https://books.google.com/books?id=RAe4jAHXAgwC&pg=PA50 > [3] https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V02.3.pdf > [4] https://dl.acm.org/doi/pdf/10.1145/1164679.1164681 > > The last article is "UNIX on a Micro" by Cornelia Boldyreff. > It briefly mentions other 8-bit Unix-likes: Cromemco's Cromix, > Thinker Toys/Morrow's Micronix, Technical Systems Consultants' UniFLEX. From lm at mcvoy.com Wed Mar 1 05:03:20 2023 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 28 Feb 2023 11:03:20 -0800 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: <20230228190320.GC8514@mcvoy.com> Well if you think about how hard the orginal folks worked to fit useful programs in 64K, it's hard to imagine there was much appetite for trying to fit in smaller processors. All the focus was on machines with more memory, banked PDP-11s and then the VAX. The 8 bit market was all home owner CP/M machines. On Tue, Feb 28, 2023 at 06:59:14PM +0000, segaloco via TUHS wrote: > Sounds like Idris and uNIX are the closest we get with ex-Bell personnel being involved with both projects. > > I haven't found anything in the surviving Bell streams that suggests any 8-bit attempts internally, and various portability documents suggest 16-bit and 32-bit targets abound but nothing like a 6502 or Z80 running UNIX inside Bell, again not that it would really be that worthwhile of an experiment at the time given their focus on minis. Anywho, if anything ever does show up in my study I'll happily share the details. > > - Matt G. > > ------- Original Message ------- > On Monday, February 27th, 2023 at 2:57 AM, Jonathan Gray wrote: > > > > On Sat, Feb 25, 2023 at 07:48:45PM +0000, segaloco via TUHS wrote: > > > > > 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. > > > > > > If by Bell connection you mean people. Plauger left in 1975, > > joined Yourdon Inc in 1975, started Whitesmiths Ltd in 1978[1]. > > Whitesmiths created Idris, a clone of Unix. > > > > "Idris can run comfortably where UNIX can't event fit: On an > > MC68000 with no memory management hardware, for example. > > On a bank-switched 8080 or Z80. Or on any LS-11 or PDP-11 > > with memory management." > > Whitesmiths advertisement in Computerworld, Mar 1983 [2]. > > > > Yourdon Inc, announced Omnix in 1980, a Unix-like system for Z80[3]. > > By 1981 it "had to be withdrawn when Yourdon were let down by its > > developers" [4]. > > > > [1] https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf > > [2] https://books.google.com/books?id=RAe4jAHXAgwC&pg=PA50 > > [3] https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V02.3.pdf > > [4] https://dl.acm.org/doi/pdf/10.1145/1164679.1164681 > > > > The last article is "UNIX on a Micro" by Cornelia Boldyreff. > > It briefly mentions other 8-bit Unix-likes: Cromemco's Cromix, > > Thinker Toys/Morrow's Micronix, Technical Systems Consultants' UniFLEX. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From clemc at ccc.com Wed Mar 1 05:42:00 2023 From: clemc at ccc.com (Clem Cole) Date: Tue, 28 Feb 2023 14:42:00 -0500 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: Just so you know, the folks in Western Electric's Teletype team retargeted the Ritchie compiler to become a Z80 cross-compiler/assembler dev tools suite. That implementation was floating around the Bell System in the 76/77/78 time frame. I know Karn had brought it with him and started using it for his original KA9Q IP/TCP implementation, initially for his CP/M box and ham radio system; (as he ran it as a cross compiler on my 11/34 at CMU's Mellon Institute -- I trade cycles for access to the compiler). I don't know if anyone ever tried to use the Teletype Z80 C compiler to build a UNIX or UNIX-like port for the z80 with it. I have since forgotten how complete it was. A bit later, Loer Zohlman wrote BDS C, which was pretty darned good/fairly complete C implementation for the time; and a few years back, he put it in the Public Domain [ you can download it from his website]. Missing/lost is/was the UNIX-like system they were working on to go along with the compiler - which I am trying to remember if it was quite complete/much less made it out for sale like his compiler was at the time. However, at an early Boston USENIX, Leor had it running "good enough" that he brought it and showed it in his room on a dual floppy Z80 IMSAI box with some 4K bank switching HW (I don't remember how much memory - probably 128Kish). I was there when he demo'ed it to Dennis and a few other hackers. Dennis's response at the time was it reminded him of the early UNIX efforts. I just thought it was pretty cool. A year or so later, Onyx folks brought their Z8000 based V7 system to USENIX, causing quite a stir ᐧ ᐧ ᐧ ᐧ On Tue, Feb 28, 2023 at 1:59 PM segaloco via TUHS wrote: > Sounds like Idris and uNIX are the closest we get with ex-Bell personnel > being involved with both projects. > > I haven't found anything in the surviving Bell streams that suggests any > 8-bit attempts internally, and various portability documents suggest 16-bit > and 32-bit targets abound but nothing like a 6502 or Z80 running UNIX > inside Bell, again not that it would really be that worthwhile of an > experiment at the time given their focus on minis. Anywho, if anything > ever does show up in my study I'll happily share the details. > > - Matt G. > > ------- Original Message ------- > On Monday, February 27th, 2023 at 2:57 AM, Jonathan Gray > wrote: > > > > On Sat, Feb 25, 2023 at 07:48:45PM +0000, segaloco via TUHS wrote: > > > > > 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. > > > > > > If by Bell connection you mean people. Plauger left in 1975, > > joined Yourdon Inc in 1975, started Whitesmiths Ltd in 1978[1]. > > Whitesmiths created Idris, a clone of Unix. > > > > "Idris can run comfortably where UNIX can't event fit: On an > > MC68000 with no memory management hardware, for example. > > On a bank-switched 8080 or Z80. Or on any LS-11 or PDP-11 > > with memory management." > > Whitesmiths advertisement in Computerworld, Mar 1983 [2]. > > > > Yourdon Inc, announced Omnix in 1980, a Unix-like system for Z80[3]. > > By 1981 it "had to be withdrawn when Yourdon were let down by its > > developers" [4]. > > > > [1] > https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf > > [2] https://books.google.com/books?id=RAe4jAHXAgwC&pg=PA50 > > [3] https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V02.3.pdf > > [4] https://dl.acm.org/doi/pdf/10.1145/1164679.1164681 > > > > The last article is "UNIX on a Micro" by Cornelia Boldyreff. > > It briefly mentions other 8-bit Unix-likes: Cromemco's Cromix, > > Thinker Toys/Morrow's Micronix, Technical Systems Consultants' UniFLEX. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Mar 1 05:45:43 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 28 Feb 2023 19:45:43 +0000 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: <4bea6304-e275-c336-042b-899aaf3cab35@mhorton.net> References: <7wbklet6ga.fsf@junk.nocrew.org> <4bea6304-e275-c336-042b-899aaf3cab35@mhorton.net> Message-ID: We all pretty much started with Adventure (Dungeon, Collosal Cave) whatever you want to call it. We got Zork later on. There was Peter Langston’s Empire that had a huge following at BRL. We thought we had it in check because the game had it’s own limits on how much you could play it you were limited to 60 minutes of clock time a day and how many BTUs (bureaucratic time units) your capital made. The problem was people would spend their time online downloading maps and then spend the afternoon pouring over tomorrows moves. The director finally made us shut it down. There was a multiplayer game called “search” that we would play. Late in the day you’d hear someone yell “Search’s up” and off we go. Then we got the SGI workstations and flew the flight simulator. They had a multiplayer dogfight but it used XNS which our network wasn’t going to handle (at least not off the local subnet). I recoded it to use TCP. Rather than using broadcast packets, each “airplane” opened a connection to a server I called “Air Traffic Control.” From there I could watch the whole thing. I also added an anti-aircraft gun to shoot at people hanging around the airfield waiting to attack aircraft that newly appeared in the game there. A few months later I was at Nasa Ames for an IETF meeting and mentioned I had done this and they made me sit down and ftp over the code so NASA’s productivity could also be destroyed. Ron “A hollow voice says ‘plugh’ Natalie -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Wed Mar 1 05:57:16 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Tue, 28 Feb 2023 11:57:16 -0800 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: <8EF8F0A1-262F-4373-9887-1DABBC4EF98E@iitbombay.org> There was Cromix from Cromemco, released in 1979. It was supposed to be a lot like Unix and had its own C compiler. https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1667547 I did use Leor Zolman's BDS C on my z80 imsai box in 1979-80. Written in Assembly language! Sources here: http://www.cpm.z80.de/develop.htm > On Feb 28, 2023, at 11:42 AM, Clem Cole wrote: > > Just so you know, the folks in Western Electric's Teletype team retargeted the Ritchie compiler to become a Z80 cross-compiler/assembler dev tools suite. That implementation was floating around the Bell System in the 76/77/78 time frame. I know Karn had brought it with him and started using it for his original KA9Q IP/TCP implementation, initially for his CP/M box and ham radio system; (as he ran it as a cross compiler on my 11/34 at CMU's Mellon Institute -- I trade cycles for access to the compiler). I don't know if anyone ever tried to use the Teletype Z80 C compiler to build a UNIX or UNIX-like port for the z80 with it. I have since forgotten how complete it was. > > A bit later, Loer Zohlman wrote BDS C,  which was pretty darned good/fairly complete C implementation for the time; and a few years back, he put it in the Public Domain [ you can download it from his website]. Missing/lost is/was the UNIX-like system they were working on to go along with the compiler - which I am trying to remember if it was quite complete/much less made it out for sale like his compiler was at the time. However, at an early Boston USENIX, Leor had it running "good enough" that he brought it and showed it in his room on a dual floppy Z80 IMSAI box with some 4K bank switching HW (I don't remember how much memory - probably 128Kish). I was there when he demo'ed it to Dennis and a few other hackers. Dennis's response at the time was it reminded him of the early UNIX efforts. I just thought it was pretty cool. > > A year or so later, Onyx folks brought their Z8000 based V7 system to USENIX, causing quite a stir > ᐧ > ᐧ > ᐧ > ᐧ > > On Tue, Feb 28, 2023 at 1:59 PM segaloco via TUHS > wrote: >> Sounds like Idris and uNIX are the closest we get with ex-Bell personnel being involved with both projects. >> >> I haven't found anything in the surviving Bell streams that suggests any 8-bit attempts internally, and various portability documents suggest 16-bit and 32-bit targets abound but nothing like a 6502 or Z80 running UNIX inside Bell, again not that it would really be that worthwhile of an experiment at the time given their focus on minis. Anywho, if anything ever does show up in my study I'll happily share the details. >> >> - Matt G. >> >> ------- Original Message ------- >> On Monday, February 27th, 2023 at 2:57 AM, Jonathan Gray > wrote: >> >> >> > On Sat, Feb 25, 2023 at 07:48:45PM +0000, segaloco via TUHS wrote: >> > >> > > 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. >> > >> > >> > If by Bell connection you mean people. Plauger left in 1975, >> > joined Yourdon Inc in 1975, started Whitesmiths Ltd in 1978[1]. >> > Whitesmiths created Idris, a clone of Unix. >> > >> > "Idris can run comfortably where UNIX can't event fit: On an >> > MC68000 with no memory management hardware, for example. >> > On a bank-switched 8080 or Z80. Or on any LS-11 or PDP-11 >> > with memory management." >> > Whitesmiths advertisement in Computerworld, Mar 1983 [2]. >> > >> > Yourdon Inc, announced Omnix in 1980, a Unix-like system for Z80[3]. >> > By 1981 it "had to be withdrawn when Yourdon were let down by its >> > developers" [4]. >> > >> > [1] https://indico.cern.ch/event/318305/attachments/612388/842557/PJPlauger-ITSeminar-Fifty_years.pdf >> > [2] https://books.google.com/books?id=RAe4jAHXAgwC&pg=PA50 >> > [3] https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V02.3.pdf >> > [4] https://dl.acm.org/doi/pdf/10.1145/1164679.1164681 >> > >> > The last article is "UNIX on a Micro" by Cornelia Boldyreff. >> > It briefly mentions other 8-bit Unix-likes: Cromemco's Cromix, >> > Thinker Toys/Morrow's Micronix, Technical Systems Consultants' UniFLEX. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Wed Mar 1 06:01:25 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 28 Feb 2023 20:01:25 +0000 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: References: <7wbklet6ga.fsf@junk.nocrew.org> <4bea6304-e275-c336-042b-899aaf3cab35@mhorton.net> Message-ID: There's also the venerable Hunt the Wumpus. We had an RS/6000 gathering dust in the server room at my old lab. I would often rsh into it to play wump or quiz when things were slow. I don't remember what all else it had, it was some AIX 4.x release. If that server is still extant I should see if they're planning on offloading it any time soon.....a personal RS/6000 could be fun... - Matt G. ------- Original Message ------- On Tuesday, February 28th, 2023 at 11:45 AM, Ron Natalie wrote: > We all pretty much started with Adventure (Dungeon, Collosal Cave) whatever you want to call it. > > We got Zork later on. > > There was Peter Langston’s Empire that had a huge following at BRL. We thought we had it in check because the game had it’s own limits on how much you could play it you were limited to 60 minutes of clock time a day and how many BTUs (bureaucratic time units) your capital made. The problem was people would spend their time online downloading maps and then spend the afternoon pouring over tomorrows moves. The director finally made us shut it down. > > There was a multiplayer game called “search” that we would play. Late in the day you’d hear someone yell “Search’s up” and off we go. > > Then we got the SGI workstations and flew the flight simulator. They had a multiplayer dogfight but it used XNS which our network wasn’t going to handle (at least not off the local subnet). I recoded it to use TCP. Rather than using broadcast packets, each “airplane” opened a connection to a server I called “Air Traffic Control.” From there I could watch the whole thing. I also added an anti-aircraft gun to shoot at people hanging around the airfield waiting to attack aircraft that newly appeared in the game there. A few months later I was at Nasa Ames for an IETF meeting and mentioned I had done this and they made me sit down and ftp over the code so NASA’s productivity could also be destroyed. > > Ron “A hollow voice says ‘plugh’ Natalie -------------- next part -------------- An HTML attachment was scrubbed... URL: From iain at csp-partnership.co.uk Wed Mar 1 06:24:30 2023 From: iain at csp-partnership.co.uk (Dr Iain Maoileoin) Date: Tue, 28 Feb 2023 20:24:30 +0000 Subject: [TUHS] Unix/Linux games [was Re: Early GUI on Linux] In-Reply-To: References: <7wbklet6ga.fsf@junk.nocrew.org> <4bea6304-e275-c336-042b-899aaf3cab35@mhorton.net> Message-ID: <365C08E2-AE4E-440F-B785-4E98CB59AF67@csp-partnership.co.uk> > On 28 Feb 2023, at 19:45, Ron Natalie wrote: > > We all pretty much started with Adventure (Dungeon, Collosal Cave) whatever you want to call it. > > We got Zork later on. > > ….. > > There was a multiplayer game called “search” that we would play. Late in the day you’d hear someone yell “Search’s up” and off we go. Help me here please. I have been hunting for the source of search for ages. I want to fly through that universe again - curses and all! We modified the source of our version at the Uni to make it a bit more Scottish and to include objects that had names based on local lectures/students etc. My search skills in searching for search have let me down badly. I would like to get search up on one of my VAXEN and show my staff what a real 80s computer game was about ;-) Does anybody have any ideas if the source is still extant? Iain > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Mar 1 09:31:59 2023 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 1 Mar 2023 10:31:59 +1100 (EST) Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Tue, 28 Feb 2023, Clem Cole wrote: [...] > A bit later, Loer Zohlman wrote BDS C, which was pretty darned > good/fairly complete C implementation for the time; [...] I'm glad that you qualified it with "for the time"; I've used it, and calling it a "C compiler" was a bit of a stretch[*]. Later on I bought the Hi-Tech C compiler, and it was full ANSI, with function prototypes etc. [*] I think it was Henry Spencer who said (in relation to some other product): "Somehow, to be called a C compiler it ought to at least be able to compile C". -- Dave From jsg at jsg.id.au Wed Mar 1 10:31:14 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 1 Mar 2023 11:31:14 +1100 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Tue, Feb 28, 2023 at 02:42:00PM -0500, Clem Cole wrote: > Just so you know, the folks in Western Electric's Teletype team retargeted > the Ritchie compiler to become a Z80 cross-compiler/assembler dev tools > suite. That implementation was floating around the Bell System in the > 76/77/78 time frame. I know Karn had brought it with him and started using > it for his original KA9Q IP/TCP implementation, initially for his CP/M box > and ham radio system; (as he ran it as a cross compiler on my 11/34 at > CMU's Mellon Institute -- I trade cycles for access to the compiler). I > don't know if anyone ever tried to use the Teletype Z80 C compiler to build > a UNIX or UNIX-like port for the z80 with it. I have since forgotten how > complete it was. > > A bit later, Loer Zohlman wrote BDS C, > which > was pretty darned good/fairly complete C implementation for the time; and a > few years back, he put it in the Public Domain [ you can download it from > his website]. Missing/lost is/was the UNIX-like system they were working > on to go along with the compiler - which I am trying to remember if it was > quite complete/much less made it out for sale like his compiler was at the > time. However, at an early Boston USENIX, Leor had it running "good > enough" that he brought it and showed it in his room on a dual floppy Z80 > IMSAI box > > with > some 4K bank switching HW (I don't remember how much memory - probably > 128Kish). I was there when he demo'ed it to Dennis and a few other > hackers. Dennis's response at the time was it reminded him of the early > UNIX efforts. I just thought it was pretty cool. 'BDS C version 1 has just about saturated its framework; version 2 is now being developed in close conjunction with the MARC Disk Operating System (the work of Edwin P. Ziemba) to provide a unified software development system for release sometime in 1981. MARC is a "Unix-like" operating system that happens to fit quite comfortably in non-gargantuan 8080/Z8O-based machines.' http://www.bitsavers.org/pdf/bd_software/BDS_C_1.46_Users_Guide_Mar82.pdf 'I had the pleasure of meeting Dennis once at the Boston Usenix conference around 1980, where Ed Ziemba and I had set up a demo of Ed’s MARC operating system (single-user single-process Unix clone that ran parasitically on CP/M-80 machines). I think that one of the high points of my life was giving a demo of a software project to Dennis Ritchie and seeing it bring a big smile to his face.' Leor Zolman, in the comments on https://herbsutter.com/2011/10/16/your-first-c-program/ 'Ed Ziemba, the originator, guiding force and one of the primary authors of the UNIX-like operating system MARC, was killed June 7 in a freak accident while snorkeling' InfoWorld 17 Aug 1981 https://books.google.com/books?id=pD0EAAAAMBAJ&pg=PT14 There was a short writeup on MARC in the Dec 1982 issue of Byte https://archive.org/details/byte-magazine-1982-12/page/n219/mode/2up From lm at mcvoy.com Wed Mar 1 10:39:16 2023 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 28 Feb 2023 16:39:16 -0800 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: <20230301003916.GA15064@mcvoy.com> On Wed, Mar 01, 2023 at 10:31:59AM +1100, Dave Horsfall wrote: > On Tue, 28 Feb 2023, Clem Cole wrote: > > [...] > > > A bit later, Loer Zohlman wrote??BDS C,??which was pretty darned > > good/fairly complete C implementation for the time; [...] > > I'm glad that you qualified it with "for the time"; I've used it, and > calling it a "C compiler" was a bit of a stretch[*]. Later on I bought > the Hi-Tech C compiler, and it was full ANSI, with function prototypes > etc. BDS C wasn't ANSI by any stretch but it was small, fast, and available when everything else was slow (except Turbo Pascal, crazy fast, but, um, Pascal. 'Nuf said). While I had to relearn the stdio lib for real C, I did not find it hard at all to switch back and forth and I wrote a ton of useful stuff in BDS C. Super grateful to have had it. From rich.salz at gmail.com Wed Mar 1 11:21:42 2023 From: rich.salz at gmail.com (Rich Salz) Date: Tue, 28 Feb 2023 20:21:42 -0500 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: > > > I'm glad that you qualified it with "for the time"; I've used it, and > calling it a "C compiler" was a bit of a stretch[*]. Later on I bought > the Hi-Tech C compiler, and it was full ANSI, with function prototypes > etc. > Hmm. K&R publication date was February 1978. BDS C was released in August 1979. So it was certainly C as known at that time. X3J11 was convened in 1983 and published in 1985. Doesn't seem like a good comparison. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Wed Mar 1 11:27:01 2023 From: imp at bsdimp.com (Warner Losh) Date: Tue, 28 Feb 2023 18:27:01 -0700 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Tue, Feb 28, 2023, 6:21 PM Rich Salz wrote: > >> I'm glad that you qualified it with "for the time"; I've used it, and >> calling it a "C compiler" was a bit of a stretch[*]. Later on I bought >> the Hi-Tech C compiler, and it was full ANSI, with function prototypes >> etc. >> > > Hmm. K&R publication date was February 1978. BDS C was released in August > 1979. So it was certainly C as known at that time. X3J11 was convened in > 1983 and published in 1985. Doesn't seem like a good comparison. > I have a memory of a star trek themed illustration/poster of Bones holding the ANSI C standard that said "It's C Jim but not as we know it..." my Google fu is insufficient to find it though... Warner > >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Wed Mar 1 11:38:15 2023 From: will.senn at gmail.com (Will Senn) Date: Tue, 28 Feb 2023 19:38:15 -0600 Subject: [TUHS] Unix Systems Administration Texts Message-ID: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> 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 :). -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Wed Mar 1 12:07:06 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Wed, 01 Mar 2023 02:07:06 +0000 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: The first chapter of K&R was out as a technical paper at least a year prior to the book coming out. By the time the book had come out, there had already been some evolution in the language. The “Phototypesetter” and soon after “Version 7” versions of the compiler were heading toward what would be come ANSI by the time BDS came out. Amusingly, I ended up working for an unrelated company called BDS and ended up with the BDS.COM domain. Eventually, we changed the name of the company and after brief inquiry from them donated the BDS.COM domain to the compiler guys. At least it didn’t come with a prayer book like the Metalware compiler (which really needed all the divine intervention that it could get). ------ Original Message ------ >From "Rich Salz" To "Dave Horsfall" Cc "The Eunuchs Hysterical Society" Date 2/28/2023 8:21:42 PM Subject [TUHS] Re: Any Bell 8-bit UNIX Efforts? >> >>I'm glad that you qualified it with "for the time"; I've used it, and >>calling it a "C compiler" was a bit of a stretch[*]. Later on I >>bought >>the Hi-Tech C compiler, and it was full ANSI, with function prototypes >>etc. > >Hmm. K&R publication date was February 1978. BDS C was released in >August 1979. So it was certainly C as known at that time. X3J11 was >convened in 1983 and published in 1985. Doesn't seem like a good >comparison. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Mar 1 12:34:33 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 28 Feb 2023 21:34:33 -0500 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: On Tue, Feb 28, 2023 at 8:38 PM Will Senn wrote: > 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? This is not going to be popular, but... > Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty) This book gave me some terrible advice when I was very young and impressionable. In there somewhere it says something about not doing something unless you're prepared to do it right lest one spend more time working around a work-around than one would have spent just doing it well in the first place. The conclusion is, of course, true, but the admonition ignores all sorts of externalities, like waiting users. And in some cases it could really lead to paralysis ("omg _everything_ is broken and I can't do X until I do Y, but to do Y I have to do this other thing and if I really want to do it right I need to start by traveling to Nepal and shaving this Yak, but I need to get my passport renewed and damn I really oughta lose 20 pounds before I get my passport photo taken for the next ten years, so I guess I oughta join a gym...but I can't even find one because the network is down and I can't get to Google, but how can I fix the network if I have not shaved the Nepalese yak?!"). Talk about letting the perfect be the enemy of the good. Hopefully nowadays we have a better appreciation of the power of incrementalism; those grand plans for the perfect system rarely come to fruition. It's better to be flexible and make small, impactful changes along the way towards a better system, always being mindful of and tamping down encroaching entropy. - Dan C. From crossd at gmail.com Wed Mar 1 12:35:44 2023 From: crossd at gmail.com (Dan Cross) Date: Tue, 28 Feb 2023 21:35:44 -0500 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Tue, Feb 28, 2023 at 9:07 PM Ronald Natalie wrote: > [snip] > At least it didn’t come with a prayer book like the Metalware compiler (which really needed all the divine intervention that it could get). Was that the one that shipped with the IBM RT? Is it just my imagination or did some of the error messages contain biblical references? - Dan C. From ron at ronnatalie.com Wed Mar 1 12:38:22 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Wed, 01 Mar 2023 02:38:22 +0000 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: I don’t know. We used it with the Intel i860 processor when we were doing work for IBM so it was possible that is how we were hooked up with them. ------ Original Message ------ >From "Dan Cross" To "Ronald Natalie" Cc "Rich Salz" ; "Dave Horsfall" ; "The Eunuchs Hysterical Society" Date 2/28/2023 9:35:44 PM Subject Re: [TUHS] Re: Any Bell 8-bit UNIX Efforts? >On Tue, Feb 28, 2023 at 9:07 PM Ronald Natalie wrote: >>[snip] >>At least it didn’t come with a prayer book like the Metalware compiler (which really needed all the divine intervention that it could get). > >Was that the one that shipped with the IBM RT? Is it just my >imagination or did some of the error messages contain biblical >references? > > - Dan C. From jsg at jsg.id.au Wed Mar 1 12:50:30 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Wed, 1 Mar 2023 13:50:30 +1100 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: On Wed, Mar 01, 2023 at 02:07:06AM +0000, Ronald Natalie wrote: > The first chapter of K&R was out as a technical paper at least a year prior > to the book coming out. > By the time the book had come out, there had already been some evolution in > the language. The “Phototypesetter” and soon after “Version 7” versions > of the compiler were heading toward what would be come ANSI by the time BDS > came out. The background to BDS C is described in an interview with Leor Zolman http://www.znode51.de/articles/int4.htm "I wrote the first cut of BDS C between January and April, 1979, specifically in order to compile a C version of the Othello game written by Robert Halstead at the Real-Time Systems Lab at MIT" > > Amusingly, I ended up working for an unrelated company called BDS and ended > up with the BDS.COM domain. Eventually, we changed the name of the company > and after brief inquiry from them donated the BDS.COM domain to the compiler > guys. > > At least it didn’t come with a prayer book like the Metalware compiler > (which really needed all the divine intervention that it could get). MetaWare High C, used by AIS/AOS on the PC RT > > ------ Original Message ------ > > From "Rich Salz" > To "Dave Horsfall" > Cc "The Eunuchs Hysterical Society" > Date 2/28/2023 8:21:42 PM > Subject [TUHS] Re: Any Bell 8-bit UNIX Efforts? > > > > > > > I'm glad that you qualified it with "for the time"; I've used it, and > > > calling it a "C compiler" was a bit of a stretch[*]. Later on I > > > bought > > > the Hi-Tech C compiler, and it was full ANSI, with function prototypes > > > etc. > > > > Hmm. K&R publication date was February 1978. BDS C was released in > > August 1979. So it was certainly C as known at that time. X3J11 was > > convened in 1983 and published in 1985. Doesn't seem like a good > > comparison. > > > From sauer at technologists.com Wed Mar 1 13:02:17 2023 From: sauer at technologists.com (Charles H. Sauer) Date: Tue, 28 Feb 2023 21:02:17 -0600 Subject: [TUHS] IBM RT/PC compilers [was Re: Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: <1F9F6472-6F10-4E5D-81A4-BC0C6EB1F5BE@technologists.com> > On Feb 28, 2023, at 8:35 PM, Dan Cross wrote: > > On Tue, Feb 28, 2023 at 9:07 PM Ronald Natalie wrote: >> [snip] >> At least it didn’t come with a prayer book like the Metalware compiler (which really needed all the divine intervention that it could get). > > Was that the one that shipped with the IBM RT? Is it just my > imagination or did some of the error messages contain biblical > references? > > - Dan C. It may be that Metaware was available for AIX on the RT, but, if so, not bundled with AIX. AIX 1 releases bundled a fairly vanilla pcc as provided by ISC. AIX 2 releases bundled pcc with the HCR optimization phase added. I’m not sure about AIX 3 and beyond, since I left before they were released. The “strategic” plan was a reimplementation of the PL.8 compiler as a C compiler with the work done by an IBM group in Toronto. I suspect that was extra cost option and that pcc with HCR was still bundled in the base. I have the impression that AOS (BSD for RT) eventually also included the HCR phase. See https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ for more context. CHS -- voice: +1.512.784.7526 e-mail: sauer at technologists.com fax: +1.512.346.5240 web: https://technologists.com/sauer/ Facebook/Google/LinkedIn/Twitter: CharlesHSauer -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Mar 1 13:24:23 2023 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 28 Feb 2023 19:24:23 -0800 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: <20230301032423.GG15064@mcvoy.com> On Tue, Feb 28, 2023 at 09:34:33PM -0500, Dan Cross wrote: > On Tue, Feb 28, 2023 at 8:38???PM Will Senn wrote: > > 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? > > This is not going to be popular, but... > > > Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty) > > This book gave me some terrible advice when I was very young and impressionable. Yet another reason I'm not a Evi Nemeth fan. I could go on but I won't. From ggm at algebras.org Wed Mar 1 14:02:44 2023 From: ggm at algebras.org (George Michaelson) Date: Wed, 1 Mar 2023 14:02:44 +1000 Subject: [TUHS] IBM RT/PC compilers [was Re: Any Bell 8-bit UNIX Efforts? In-Reply-To: <1F9F6472-6F10-4E5D-81A4-BC0C6EB1F5BE@technologists.com> References: <1F9F6472-6F10-4E5D-81A4-BC0C6EB1F5BE@technologists.com> Message-ID: I used BSD/RT and I don't recall anything that good and my C is pretty terrible: if there were biblical error codes I would have expected to tickle them. On Wed, Mar 1, 2023 at 1:02 PM Charles H. Sauer wrote: > > > > On Feb 28, 2023, at 8:35 PM, Dan Cross wrote: > > On Tue, Feb 28, 2023 at 9:07 PM Ronald Natalie wrote: > > [snip] > At least it didn’t come with a prayer book like the Metalware compiler (which really needed all the divine intervention that it could get). > > > Was that the one that shipped with the IBM RT? Is it just my > imagination or did some of the error messages contain biblical > references? > > - Dan C. > > > It may be that Metaware was available for AIX on the RT, but, if so, not bundled with AIX. AIX 1 releases bundled a fairly vanilla pcc as provided by ISC. AIX 2 releases bundled pcc with the HCR optimization phase added. I’m not sure about AIX 3 and beyond, since I left before they were released. The “strategic” plan was a reimplementation of the PL.8 compiler as a C compiler with the work done by an IBM group in Toronto. I suspect that was extra cost option and that pcc with HCR was still bundled in the base. I have the impression that AOS (BSD for RT) eventually also included the HCR phase. See https://notes.technologists.com/notes/2017/03/08/lets-start-at-the-very-beginning-801-romp-rtpc-aix-versions/ for more context. CHS > > -- > voice: +1.512.784.7526 e-mail: sauer at technologists.com > fax: +1.512.346.5240 web: https://technologists.com/sauer/ > Facebook/Google/LinkedIn/Twitter: CharlesHSauer > From sjenkin at canb.auug.org.au Wed Mar 1 18:34:22 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 1 Mar 2023 19:34:22 +1100 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: <9AE07C8D-0117-4E73-AD4D-BC24AFABBC65@canb.auug.org.au> I liked the book by Tom Limoncelli & Christine Hogan. Limoncelli went on to write more books. I’ve got a copy of Garfield & Spafford, "Practical UNIX and Internet Security", but I don’t know what the Cool Kids use these days. Security is something you need to do all the time and stay current with… It’s a constant battle with no end, something I didn’t want to devote my life to. Evi Nemeth taught a course in Sys Admin & maybe had a group/dept as well. The book came out of the course - undergrads had to do prac work, put in ‘hours’. The Book ’the standard’ for Admins I knew for many years. Nemeth et al built “sudo” to solve the “give limited privileges to undergrads” problem. [ Implementing a "Capability-based” kernel & tools may have been a better solution ] It was a good enough design and spread widely. I never used it’s full feature set, never in an environment that needed it. However, the University of Colorado Boulder environment was much larger in some ways than any I worked in and met very different needs. They had to cope with many students printing jobs, resetting passwords, filling up disk quotas, email queues and more - with an admin group staffed mainly by undergrads, I believe. > On 1 Mar 2023, at 12:38, Will Senn wrote: > > 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) -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From sjenkin at canb.auug.org.au Wed Mar 1 19:03:25 2023 From: sjenkin at canb.auug.org.au (steve jenkin) Date: Wed, 1 Mar 2023 20:03:25 +1100 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: Dan, I used the Nemeth book when I didn’t know how to do the odd thing or finding a tool, but the book was predicated on a very specific Academic environment. You can see why she’d suggest making tools reliable, robust and ‘complete’ (done ‘properly’) in their environment with a large, constantly changing workforce, kids all too prone to ‘exploring’ things or breaking something and then not knowing what to do… From 1995, I spent around a decade doing contract SysAdmin. The well run, well staffed and “no drama” sites never needed me :) I got “parachuted behind enemy lines”, having to fight my way out, so many times that I discovered I had a process for “Digging myself Out” The key is to gain time by automating tasks, starting with what gains the most time for you, not business or managerial priorities. There’s at least three levels of script / tool, I thought were all covered in that Bill Plauger PDF recently but aren’t: 1. Stuff for yourself. 2. A "Program Product" for a small, competent group. 3. A hardened product / Application that the unwashed masses will use and test to destruction. As a lone Sys Admin it’s incumbent on you to leverage the Automation under your control, not drown in entropy. If you do Admin in seriously large sites, eg AWS or GOOG, practices have to be adapted to avoid outages - any outage will have massive impact. At Internet Scale, the only methodology that can work is: "systems are cattle not pets”- create tools that easily scale to the entire fleet & are particularly robust & reliable. Admins can’t be allowed to ever type at a production console - much more controlled than the old Boulder Uni environment. HTH sj > On 1 Mar 2023, at 13:34, Dan Cross wrote: > >> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty) > > This book gave me some terrible advice when I was very young and impressionable. > > In there somewhere it says something about not doing something unless > you're prepared to do it right lest one spend more time working around > a work-around than one would have spent just doing it well in the > first place. > > The conclusion is, of course, true, but the admonition ignores all > sorts of externalities, like waiting users. And in some cases it could > really lead to paralysis ("omg _everything_ is broken and I can't do X > until I do Y, but to do Y I have to do this other thing and if I > really want to do it right I need to start by traveling to Nepal and > shaving this Yak, but I need to get my passport renewed and damn I > really oughta lose 20 pounds before I get my passport photo taken for > the next ten years, so I guess I oughta join a gym...but I can't even > find one because the network is down and I can't get to Google, but > how can I fix the network if I have not shaved the Nepalese yak?!"). > Talk about letting the perfect be the enemy of the good. > > Hopefully nowadays we have a better appreciation of the power of > incrementalism; those grand plans for the perfect system rarely come > to fruition. It's better to be flexible and make small, impactful > changes along the way towards a better system, always being mindful of > and tamping down encroaching entropy. > > - Dan C. -- Steve Jenkin, IT Systems and Design 0412 786 915 (+61 412 786 915) PO Box 38, Kippax ACT 2615, AUSTRALIA mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin From mphuff at gmail.com Wed Mar 1 21:45:12 2023 From: mphuff at gmail.com (Michael Huff) Date: Wed, 1 Mar 2023 02:45:12 -0900 Subject: [TUHS] Unix V7 enblock.c In-Reply-To: References: Message-ID: On Tue, Feb 28, 2023 at 6:51 AM Henry Bent wrote: > On Tue, 28 Feb 2023 at 10:45, KenUnix wrote: > >> 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 >> > > Hi Ken, > > Questions like this are probably better suited to the SIMH mailing list. > https://groups.io/g/simh > > That being said, is there a reason you're bothering to convert to tap > format? Modern versions of SIMH can do "attach [file] -f tar [device]" to > directly attach a tar file to a tape device. > > -Henry > Hi, Henry, Ken and TUHS 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. I don't know if that is the reason that Ken wants to do that, however. If it is, he should look at the mkdisttap.pl utility on those pages. Ken, there are a couple of other utilities to convert tar files to opensim tap files simtools collection, mksimtape and tar2mt here is the link to the collection: https://github.com/open-simh/simtools/tree/master/converters If there's a utility to convert tap files to tar files, I'm oblivious to it -sorry. -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Mar 1 22:32:58 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Mar 2023 07:32:58 -0500 (EST) Subject: [TUHS] Unix V7 enblock.c Message-ID: <20230301123258.D26CC18C07E@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 From chet.ramey at case.edu Thu Mar 2 00:12:02 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 1 Mar 2023 09:12:02 -0500 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: Message-ID: <31604b56-d527-bfc1-3d33-8c9e4a3b117c@case.edu> On 2/28/23 9:35 PM, Dan Cross wrote: > On Tue, Feb 28, 2023 at 9:07 PM Ronald Natalie wrote: >> [snip] >> At least it didn’t come with a prayer book like the Metalware compiler (which really needed all the divine intervention that it could get). > > Was that the one that shipped with the IBM RT? Is it just my > imagination or did some of the error messages contain biblical > references? Yes! High C from Metaware. I wrestled with that compiling bash a lot; I did a ton of development on AOS. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From ken.unix.guy at gmail.com Thu Mar 2 00:19:48 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Wed, 1 Mar 2023 09:19:48 -0500 Subject: [TUHS] Unix v7 icheck dup problem Message-ID: 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 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Mar 2 01:09:05 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Mar 2023 10:09:05 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230301150905.AA4CD18C07B@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 From ron at ronnatalie.com Thu Mar 2 02:18:59 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 01 Mar 2023 16:18:59 +0000 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: You had adb? They hadn’t even released that when we were fixing things up. If we had a mountable disk that got too corrupt to fix using the tools, we usually wrote our own and fixed the disk (all our packs in those days were pretty much RK05s) from a running sytsem. It was reqiured before you could come on the operations staff at my college to be able to be quizzed on just how the (then version 6) filesystem was layed out and what the possible corruptions were and how to fix them. The original V6 filesystem was pretty ugly in that it wasn’t careful in even trying to do operations in the right order so as not to lead to hideous corruptions (duplicated blocks etc…). One of our summer projects at the BRL when we were interning up there was that one of us (not me) was to write an automatic disk fixer (I had a different project). Bob never got too far with that. Clri was especially problematic as a tool. If you wanted to zap a node that was a 0..0 (i.e., with a zero reference count AND not in any directory referneces), it would irreverably write zeros over all of it. We changed it to “clam” which only zonked the mode bits which if you did it to the wrong inode, you could usually get back to some working state. Running icheck and dcheck were standard on reboots. ncheck was pretty darned slow and we used it mostly for hunting down file names for things we knew were corrupted and relinking chunks of the filesystem that got detached from the root. The world changed when we got better file system code and fsck. From pnr at planet.nl Thu Mar 2 02:39:48 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 1 Mar 2023 17:39:48 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: Thank you for highlighting that! Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent. This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought. > On 27 Feb 2023, at 21:30, Dan Cross wrote: > > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: >> Thanks all for the insights. Let me attempt a summary. >> >> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. > > While that was literally true, I think it was a little more nuanced. > I'd perhaps put it that people wanted their familiar environments. > Many people were used to running a lot of xterms on their > workstations, of course, but there were other X applications people > used regularly. > > Some I remember where `gv` to look at PostScript documents, `xv` to > view image files, `gnuplot` could generate plots in a window, `xdvi` > to look at TeX/LaTeX output, and text editors like `emacs` had X > front-ends that offered syntax highlighting and the like; some folks I > knew liked `nedit`. `exmh` was my preferred email client for a while, > and things like `xman` (was there a `tkman`, too?) was nice. Some > system monitoring tools `xload` were considered essentials; `xbiff` > could be useful (I could have sworn there was a `tkbiff`, too). A > clock like `xclock` or `oclock` or something was also nice. Some folks > liked graphical newsreaders, chat programs (I guess IRC was a thing > back then, and I believe some `talk` client had an X front-end). There > was a fractal viewer that I thought was fun, but I don't remember it > much anymore (even the name...). Oh, and lots of games; I had a nice > Solitaire version that I can no longer recall the name of. `xeyes` was > cute, and running `xroach` was a popular (?) prank for an unsuspecting > (but amenable) colleague. > > A lot of us spent a lot of time customizing our environments, and many > eschewed the vendor-standard environment. For instance, a lot of > people I knew used `twm` and derivatives (`ctwm` and `tvtwm` were > popular), and spent a lot of time tweaking menus and stuff to set > things up the way we liked. A lot of folks also wrote custom tools > using `tk` or `expectk`. Giving all of that up to run on Linux was a > bitter pill to swallow, so there was a real impetus to get X running > quickly. Personally, I kept my `tvtwm`-based environment going until I > switched to plan9 and then to the Mac as a daily driver. I'm not sure > I miss it, but at the time it was head-and-shoulders above anything > you could get on Windows or (classic) MacOS. > > So it wasn't just that people wanted a "familiar terminal multiplexor" > as that people wanted the environments they had put a lot of time and > energy into building up for themselves, and again, that often meant X. > >> It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today’s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals. > > I think it probably depends on what people are doing. I more or less > switched to using VS Code for my editor, and I'm using a Mac Studio to > write this, but my desktop is still littered with terminal windows, > I've got a `drawterm` session open to my local Plan 9 network, and am > logged into a bunch of old systems (Multics, TOPS-20, VMS, an IBM > mainframe, CDC Cyber, RSTS/E, PR1ME), etc. > > But the way we write software has changed pretty dramatically in the > last 3 or so decades. I used to start with an empty C file and write > my stuff. Things like linked-lists? Mostly implemented by hand. These > days, there are other languages and vast collections of libraries for > almost anything imaginable; much of what "programming" is today is > glueing together different libraries and making them interact in > sophisticated, often quite complex ways. I don't know that it's > better, nor that it's always worse, but it is qualitatively different. > So almost necessarily the toolsets and environment have changed > accordingly. > >> This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense. > > It may be instructive to look at the early X window managers in this > regard. One I remember was `uwm` (I think); I recall being struck > that it reminded me of rio when I saw it. > >> It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it. > > I remember the X mantra was, "mechanism, not policy." Which was fine, > except that there wasn't much of even a default policy, which made X > (IMHO) a bit of a bear to program and meant that interfaces were > pretty wildly inconsistent across programs. By contrast, writing > simple programs to draw lines on the Mac was easy. > > Interestingly, frustration with this caused an almost cambrian > explosion of new windowing environments within a few years of Linux's > arrival on the scene. From larger efforts like Gtk (and then GNOME), > KDE, GNUStep (which I guess might predate Linux, but not by much...), > etc, to less ambitious things components like fvwm and Enlightenment, > we kind of went from "OpenWindows or Motif or roll your own stuff > around twm or something" to a whole plethora of things. It's still a > bit of a mess, though. > >> It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that? > > Lots! See above. > > - Dan C. From ken.unix.guy at gmail.com Thu Mar 2 02:45:37 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Wed, 1 Mar 2023 11:45:37 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: Thanks for all your suggestions. What I finally did was restore the ".disk" files from a previous backup 'tar -xf ~/research-backups/backup-mu-0228.tar' under Linux then restored my backup copies of files using 'tar x0 backup.tap' under Unix v7. All is well now. Thanks Ken On Wed, Mar 1, 2023 at 11:19 AM Ron Natalie wrote: > You had adb? They hadn’t even released that when we were fixing > things up. If we had a mountable disk that got too corrupt to fix > using the tools, we usually wrote our own and fixed the disk (all our > packs in those days were pretty much RK05s) from a running sytsem. > > It was reqiured before you could come on the operations staff at my > college to be able to be quizzed on just how the (then version 6) > filesystem was layed out and what the possible corruptions were and how > to fix them. > > The original V6 filesystem was pretty ugly in that it wasn’t careful in > even trying to do operations in the right order so as not to lead to > hideous corruptions (duplicated blocks etc…). One of our summer > projects at the BRL when we were interning up there was that one of us > (not me) was to write an automatic disk fixer (I had a different > project). Bob never got too far with that. > > Clri was especially problematic as a tool. If you wanted to zap a node > that was a 0..0 (i.e., with a zero reference count AND not in any > directory referneces), it would irreverably write zeros over all of it. > We changed it to “clam” which only zonked the mode bits which if you > did it to the wrong inode, you could usually get back to some working > state. > > Running icheck and dcheck were standard on reboots. ncheck was pretty > darned slow and we used it mostly for hunting down file names for things > we knew were corrupted and relinking chunks of the filesystem that got > detached from the root. > > The world changed when we got better file system code and fsck. > > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Mar 2 02:54:46 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Mar 2023 08:54:46 -0800 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <20230301165446.GB26409@mcvoy.com> It's worth pointing out that X had won before Linux. I was a contractor in 1987, worked on all sorts of different workstations with all sorts of vendor provided window systems, and the first thing I did was to bring up my trusty X10R3 tape. The vendor windowing systems were all oh-so-great (according to the vendors) but as a contractor, I could have cared less. I wanted my dev enviroment so I could get work done, learning the ins and outs of $VENDOR's $WINDOW_SYSTEM was just a waste of my time, I'd be done and on to the next job and all that specific knowledge was a waste of effort. All of that predated my exposure to Linux (which was early, way before Linux had networking or distributions, I brought it up from floppies). As a useful (to me) aside, I got very good at what I call "pruning the tree" when bringing up X10. There were a ton of #ifdefs and (even then) quite a few frame buffer drivers and there was no way I could have brought it up in any reasonable time if I tracked down the root cause of each reason it wouldn't compile. So I got good at looking at the source, going, huh, I don't need this and changing stuff like int whatever_function_that_I_did_not_need( Thank you for highlighting that! > > Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent. > > This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought. > > > > On 27 Feb 2023, at 21:30, Dan Cross wrote: > > > > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: > >> Thanks all for the insights. Let me attempt a summary. > >> > >> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. > > > > While that was literally true, I think it was a little more nuanced. > > I'd perhaps put it that people wanted their familiar environments. > > Many people were used to running a lot of xterms on their > > workstations, of course, but there were other X applications people > > used regularly. > > > > Some I remember where `gv` to look at PostScript documents, `xv` to > > view image files, `gnuplot` could generate plots in a window, `xdvi` > > to look at TeX/LaTeX output, and text editors like `emacs` had X > > front-ends that offered syntax highlighting and the like; some folks I > > knew liked `nedit`. `exmh` was my preferred email client for a while, > > and things like `xman` (was there a `tkman`, too?) was nice. Some > > system monitoring tools `xload` were considered essentials; `xbiff` > > could be useful (I could have sworn there was a `tkbiff`, too). A > > clock like `xclock` or `oclock` or something was also nice. Some folks > > liked graphical newsreaders, chat programs (I guess IRC was a thing > > back then, and I believe some `talk` client had an X front-end). There > > was a fractal viewer that I thought was fun, but I don't remember it > > much anymore (even the name...). Oh, and lots of games; I had a nice > > Solitaire version that I can no longer recall the name of. `xeyes` was > > cute, and running `xroach` was a popular (?) prank for an unsuspecting > > (but amenable) colleague. > > > > A lot of us spent a lot of time customizing our environments, and many > > eschewed the vendor-standard environment. For instance, a lot of > > people I knew used `twm` and derivatives (`ctwm` and `tvtwm` were > > popular), and spent a lot of time tweaking menus and stuff to set > > things up the way we liked. A lot of folks also wrote custom tools > > using `tk` or `expectk`. Giving all of that up to run on Linux was a > > bitter pill to swallow, so there was a real impetus to get X running > > quickly. Personally, I kept my `tvtwm`-based environment going until I > > switched to plan9 and then to the Mac as a daily driver. I'm not sure > > I miss it, but at the time it was head-and-shoulders above anything > > you could get on Windows or (classic) MacOS. > > > > So it wasn't just that people wanted a "familiar terminal multiplexor" > > as that people wanted the environments they had put a lot of time and > > energy into building up for themselves, and again, that often meant X. > > > >> It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today???s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals. > > > > I think it probably depends on what people are doing. I more or less > > switched to using VS Code for my editor, and I'm using a Mac Studio to > > write this, but my desktop is still littered with terminal windows, > > I've got a `drawterm` session open to my local Plan 9 network, and am > > logged into a bunch of old systems (Multics, TOPS-20, VMS, an IBM > > mainframe, CDC Cyber, RSTS/E, PR1ME), etc. > > > > But the way we write software has changed pretty dramatically in the > > last 3 or so decades. I used to start with an empty C file and write > > my stuff. Things like linked-lists? Mostly implemented by hand. These > > days, there are other languages and vast collections of libraries for > > almost anything imaginable; much of what "programming" is today is > > glueing together different libraries and making them interact in > > sophisticated, often quite complex ways. I don't know that it's > > better, nor that it's always worse, but it is qualitatively different. > > So almost necessarily the toolsets and environment have changed > > accordingly. > > > >> This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense. > > > > It may be instructive to look at the early X window managers in this > > regard. One I remember was `uwm` (I think); I recall being struck > > that it reminded me of rio when I saw it. > > > >> It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it. > > > > I remember the X mantra was, "mechanism, not policy." Which was fine, > > except that there wasn't much of even a default policy, which made X > > (IMHO) a bit of a bear to program and meant that interfaces were > > pretty wildly inconsistent across programs. By contrast, writing > > simple programs to draw lines on the Mac was easy. > > > > Interestingly, frustration with this caused an almost cambrian > > explosion of new windowing environments within a few years of Linux's > > arrival on the scene. From larger efforts like Gtk (and then GNOME), > > KDE, GNUStep (which I guess might predate Linux, but not by much...), > > etc, to less ambitious things components like fvwm and Enlightenment, > > we kind of went from "OpenWindows or Motif or roll your own stuff > > around twm or something" to a whole plethora of things. It's still a > > bit of a mess, though. > > > >> It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that? > > > > Lots! See above. > > > > - Dan C. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tytso at mit.edu Thu Mar 2 02:57:01 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 1 Mar 2023 11:57:01 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 01, 2023 at 10:09:05AM -0500, Noel Chiappa wrote: > 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. In honor of dcheck, icheck, and clri, when I creating debugfs(8) for ext2/ext3/ext4 file system, I implemented the dcheck, icheck, and clri commands. I've been known to use them (and other debugfs commands) from time to time when someone needs emergency data recovery (say, someone who has ten years of Ph.D. research without ever doing backups, and then the file system get scrambled --- although some have argued that if someone doesn't do backups of their research data, maybe they don't *deserve* to get their Ph.D. :-) - Ted From pnr at planet.nl Thu Mar 2 03:22:49 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 1 Mar 2023 18:22:49 +0100 Subject: [TUHS] Early GUI on Linux In-Reply-To: <20230301165446.GB26409@mcvoy.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <20230301165446.GB26409@mcvoy.com> Message-ID: <616F16D5-5906-4E30-A421-FE8978CA9E8E@planet.nl> That is very quick. X10R3 came out in Feb 1986 (which I understand was the first ‘outside' release) and by 1987 it was already the dominant windowing system? Or did you mean that it had won prior to 1991? > On 1 Mar 2023, at 17:54, Larry McVoy wrote: > > It's worth pointing out that X had won before Linux. I was a contractor > in 1987, worked on all sorts of different workstations with all sorts of > vendor provided window systems, and the first thing I did was to bring > up my trusty X10R3 tape. > On Wed, Mar 01, 2023 at 05:39:48PM +0100, Paul Ruizendaal wrote: >> Thank you for highlighting that! >> >> Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent. >> >> This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought. >> >> >>> On 27 Feb 2023, at 21:30, Dan Cross wrote: >>> >>> On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: >>>> Thanks all for the insights. Let me attempt a summary. >>>> >>>> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. >>> >>> While that was literally true, I think it was a little more nuanced. >>> I'd perhaps put it that people wanted their familiar environments. >>> Many people were used to running a lot of xterms on their >>> workstations, of course, but there were other X applications people >>> used regularly. From lm at mcvoy.com Thu Mar 2 03:52:32 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Mar 2023 09:52:32 -0800 Subject: [TUHS] Early GUI on Linux In-Reply-To: <616F16D5-5906-4E30-A421-FE8978CA9E8E@planet.nl> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <20230301165446.GB26409@mcvoy.com> <616F16D5-5906-4E30-A421-FE8978CA9E8E@planet.nl> Message-ID: <20230301175232.GF26409@mcvoy.com> It was the answer for me, I wanted "sameness" across platforms (which was what Unix was advertising and then the vendors all diverged into their "value add"). I can't believe that 1987 was my first exposure to bringing up X, pretty sure I had done it at UW-Madison for the same reasons. But maybe not, I dunno, it was a long time ago. All I know is that, at the time, X10R3 was the only hope I had of getting the same dev environment no matter what I was working on. Whether I had brought it up or not at UW-Madison, I had been using some version of X for years, at least 5 years and probably more, prior to going out in industry in 1987. And that wasn't my doing, UW-Madison was very much a hackers school, a good one, and they had X-something running on everything, micro vaxen, RTs, Suns, everything. So it wasn't like 1987 happened and I "picked" X over some alternative, it was already the answer well before that, years and years before that. I know I was running it as an undergrad. On Wed, Mar 01, 2023 at 06:22:49PM +0100, Paul Ruizendaal wrote: > That is very quick. X10R3 came out in Feb 1986 (which I understand was the first ???outside' release) and by 1987 it was already the dominant windowing system? Or did you mean that it had won prior to 1991? > > > > On 1 Mar 2023, at 17:54, Larry McVoy wrote: > > > > It's worth pointing out that X had won before Linux. I was a contractor > > in 1987, worked on all sorts of different workstations with all sorts of > > vendor provided window systems, and the first thing I did was to bring > > up my trusty X10R3 tape. > > > On Wed, Mar 01, 2023 at 05:39:48PM +0100, Paul Ruizendaal wrote: > >> Thank you for highlighting that! > >> > >> Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent. > >> > >> This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought. > >> > >> > >>> On 27 Feb 2023, at 21:30, Dan Cross wrote: > >>> > >>> On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: > >>>> Thanks all for the insights. Let me attempt a summary. > >>>> > >>>> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. > >>> > >>> While that was literally true, I think it was a little more nuanced. > >>> I'd perhaps put it that people wanted their familiar environments. > >>> Many people were used to running a lot of xterms on their > >>> workstations, of course, but there were other X applications people > >>> used regularly. -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From tuhs at tuhs.org Thu Mar 2 04:34:52 2023 From: tuhs at tuhs.org (Pete Wright via TUHS) Date: Wed, 1 Mar 2023 10:34:52 -0800 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: <20230301183452.rcf6rftetpgfmree@topanga> On Tue, Feb 28, 2023 at 09:34:33PM -0500, Dan Cross wrote: > On Tue, Feb 28, 2023 at 8:38 PM Will Senn wrote: > > 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? > > This is not going to be popular, but... > > > Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty) > > This book gave me some terrible advice when I was very young and impressionable. > > > In there somewhere it says something about not doing something unless > you're prepared to do it right lest one spend more time working around > a work-around than one would have spent just doing it well in the > first place. > i'll agree here with you on that, but i will say that as a front line sysadmin at the time it was one of the few resources i had that covered how to do basic tasks correctly across many unix systems. it helped me alot as a sysadmin for hire early in my career - esp when i had to fix something at a site with a poorly maintained unix i may not have had much experience with at the time - "sure i can fix your print spooler running hpux". -pete -- Pete Wright pete at nomadlogic.org From imp at bsdimp.com Thu Mar 2 04:41:00 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 1 Mar 2023 11:41:00 -0700 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: <9AE07C8D-0117-4E73-AD4D-BC24AFABBC65@canb.auug.org.au> References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> <9AE07C8D-0117-4E73-AD4D-BC24AFABBC65@canb.auug.org.au> Message-ID: On Wed, Mar 1, 2023 at 1:34 AM steve jenkin wrote: > However, the University of Colorado Boulder environment was much larger in > some ways than any I worked in and met very different needs. > They had to cope with many students printing jobs, resetting passwords, > filling up disk quotas, email queues and more - with an admin group staffed > mainly by undergrads, I believe. > csops at CU did all the sysadmin for a time of the Unix machines. It was mostly random undergrads that could be trusted to do these tasks (many would later go on to be well known in open source and other places like Todd Miller), with the occasional more senior person overseeing them. This was not a group that had an excess of resources. The user community was also not very forgiving. The preference for doing things right vs hacks came from many painful instances where the hacks wound up costing extra time. It was also an ideal, not an absolute. Evi and the csops folks were very pragmatic, and often would do a hack to get things going or keep them going while doing things right to keep what we'd call today 'technical debt' sane. Evi was a hoot! I still miss seeing her from time to time... I'm still half expecting her to show up after being lost at sea for a decade now :(. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Thu Mar 2 04:59:10 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 1 Mar 2023 13:59:10 -0500 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: On Wed, Mar 01, 2023 at 05:39:48PM +0100, Paul Ruizendaal wrote: > > This also explains that MGR on Linux was so short-lived: although it > provided the terminal multiplexing that was the key use case, it did > not have the application ecosystem that was apparently already > important enough to motivate people to make X run on Linux very > early in its existence. I had always thought of those early X > applications as little more than gimmicks, but apparently they were > more appreciated than I thought. One of the critical applications that a lot of us needed were being able to view postscript and dvi files. Sure, in the Unix days you could take a 'roff file and typeset it using either troff/ditroff or nroff, but if you are downloading a paper which was published as a postscript file, or you are authoring your problem set for a MIT math class (where the recitation instructor was too lazy to create their own answer sheet, so students competed to have their problem sets to be reproduced as the official answer sheet for that problem set, so some of us took to typesetting our weekly problem sets using TeX or LaTeX), you really want a graphical windowing system. > > It makes me wonder when true graphical applications started to > > appear for X / Unix / Linux (other than stuff like terminal, > > clock, calculator, etc.). The graphical browser certainly is one > > (1993). StarOffice and Applix seem to have arrived around > > 1995. Anything broadly used before that? I was typesetting problem sets using xdvi as early as 1987-1988; using the IBM PC/RT as well as VAXstations as an undergraduate. So if it was just xterm and emacs, maybe you could use alternatives like screen, tmux, mgr, etc. But as Larry and Dan have said, what folks wanted was a home Unix "workstation", and by the late 80's, X Windows had clearly won, having dominated alternatives like Sun's NeWS and NeXTSTEP. - Ted From dave at horsfall.org Thu Mar 2 06:52:02 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 2 Mar 2023 07:52:02 +1100 (EST) Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Wed, 1 Mar 2023, Noel Chiappa wrote: > > 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: I could've sworn that I wrote a paper for AUUGN on that very thing, but I'm damned if I can find it... Anyone here remember it? It explained exactly how to use icheck/dcheck/ncheck/clri on a creamed file system (and no, I no longer have the document). -- Dave From jnc at mercury.lcs.mit.edu Thu Mar 2 07:29:16 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Mar 2023 16:29:16 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230301212916.0583418C07B@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 > 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 From ken.unix.guy at gmail.com Thu Mar 2 07:54:34 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Wed, 1 Mar 2023 16:54:34 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301212916.0583418C07B@mercury.lcs.mit.edu> References: <20230301212916.0583418C07B@mercury.lcs.mit.edu> Message-ID: Noel, Downloaded your fsck.c to play with but things are missing: # cc fsck.c Undefined: _setexit _reset _seek _alloc _end Is there a makefile? Yes, I am trying to compile it on Unix v7. Ken On Wed, Mar 1, 2023 at 4:29 PM Noel Chiappa wrote: > > 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 > > > 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 > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Mar 2 07:55:47 2023 From: cowan at ccil.org (John Cowan) Date: Wed, 1 Mar 2023 16:55:47 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301212916.0583418C07B@mercury.lcs.mit.edu> References: <20230301212916.0583418C07B@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 1, 2023 at 4:29 PM Noel Chiappa > You may sit with Arlo Guthrie on the 'Windows user' bench. :-) > http://vrici.lojban.org/~cowan/alice_flame.txt This is AFAIK the only parody ever to appear on Arlo's own site (it is no longer there). It was an update/rewrite of the MIT version. > Although I like the old story about the person at their oral exam and > the Coke bottle in the window. > Details? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Thu Mar 2 08:15:41 2023 From: nobozo at gmail.com (Jon Forrest) Date: Wed, 1 Mar 2023 14:15:41 -0800 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301212916.0583418C07B@mercury.lcs.mit.edu> References: <20230301212916.0583418C07B@mercury.lcs.mit.edu> Message-ID: <9e567e95-2635-6cb6-6881-fed18d9ec916@gmail.com> On 3/1/2023 1:29 PM, Noel Chiappa wrote: > Although I like the old story about the person at their oral exam and > the Coke bottle in the window. What Coke bottle? Jon From ads at salewski.email Thu Mar 2 08:57:11 2023 From: ads at salewski.email (Alan D. Salewski) Date: Wed, 01 Mar 2023 17:57:11 -0500 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: On Tue, Feb 28, 2023, at 21:34, Dan Cross wrote: > On Tue, Feb 28, 2023 at 8:38 PM Will Senn wrote: >> 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? > > This is not going to be popular, but... > >> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System Administration Handbook (5th edition is another fatty) > > This book gave me some terrible advice when I was very young and impressionable. > > In there somewhere it says something about not doing something unless > you're prepared to do it right lest one spend more time working around > a work-around than one would have spent just doing it well in the > first place. > > The conclusion is, of course, true, but the admonition ignores all > sorts of externalities, like waiting users. And in some cases it could > really lead to paralysis [...] > Hopefully nowadays we have a better appreciation of the power of > incrementalism; those grand plans for the perfect system rarely come > to fruition. It's better to be flexible and make small, impactful > changes along the way towards a better system, always being mindful of > and tamping down encroaching entropy. > > - Dan C. Yeah, good or bad advice at just the right time can have quite an impact. In the under-celebrated "Minimal Perl"[0], Tim Maher notes in the last paragraph of section 5.8: In your own career, I'd advise you to develop an appreciation an appreciation and an aptitude for both the /quick-and-dirty/ and /elegant-and-formal/ styles of programming, and to cultivate the ability to produce either kind on demand, as circumstances warrant. Seems obvious, in retrospect -- but of course many things do with the benefit of hindsight. For me, that articulated something that I sensed was the right way to approach things, but was contrary to much of the one-dimensional advice I had received up to that point. It pairs well with one of the "lesser tenets" noted by Gancarz: "Look for the 90 percent solution"[1]. In my own career, I've found I can often use the quick-and-dirty approach to buy myself time to afford the "detour to build the tools"[2] that could not be justified (to others) up-front. And nothing gets it done faster than a shell script. Five or ten scrappy N-line shell scripts that get the job done sub-optimally, and lacking any real thought toward usability or generality buy time to build better tools (usually more, better-written shell scripts). And sometimes a scrappy script is "good enough" (for years, even). -Al [0] Minimal Perl for Unix People and Linux People by Tim Maher Forward by Damian Conway Manning 2007 p. 175 ISBN-10: 1-932394-50-8 [1] The Unix Philosophy by Mike Gancarz Digital Press 1995 p. 117 ISBN-10: 1-55558-123-4 [2] [McIlroy78] The Bell System Technical Journal. Bell Laboratories. M. D. McIlroy, E. N. Pinson, and B. A. Tague. "Unix Time-Sharing System Forward". 1978. 57 (6, part 2). p. 1902. https://archive.org/details/bstj57-6-1899/page/n3/mode/2up Also quoted in ESR's "The Art of Unix Programming" Addison-Wesley 2004 p. 12 ISBN-13: 9-780131-429017 https://www.catb.org/~esr/writings/taoup/html/ch01s06.html -- a l a n d. s a l e w s k i ads at salewski.email salewski at att.net https://github.com/salewski From imp at bsdimp.com Thu Mar 2 08:59:52 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 1 Mar 2023 15:59:52 -0700 Subject: [TUHS] A second Unix Patent Message-ID: 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? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 46129 bytes Desc: not available URL: From athornton at gmail.com Thu Mar 2 10:41:53 2023 From: athornton at gmail.com (Adam Thornton) Date: Wed, 1 Mar 2023 17:41:53 -0700 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: I liked the Frisch and Limoncelli/Hogan books. Nemeth less so. Adam On Wed, Mar 1, 2023 at 3:59 PM Alan D. Salewski wrote: > > > On Tue, Feb 28, 2023, at 21:34, Dan Cross wrote: > > On Tue, Feb 28, 2023 at 8:38 PM Will Senn wrote: > >> 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? > > > > This is not going to be popular, but... > > > >> Nemeth, E., Synder, G., & Seebass, S. (1989). UNIX System > Administration Handbook (5th edition is another fatty) > > > > This book gave me some terrible advice when I was very young and > impressionable. > > > > In there somewhere it says something about not doing something unless > > you're prepared to do it right lest one spend more time working around > > a work-around than one would have spent just doing it well in the > > first place. > > > > The conclusion is, of course, true, but the admonition ignores all > > sorts of externalities, like waiting users. And in some cases it could > > really lead to paralysis > [...] > > > Hopefully nowadays we have a better appreciation of the power of > > incrementalism; those grand plans for the perfect system rarely come > > to fruition. It's better to be flexible and make small, impactful > > changes along the way towards a better system, always being mindful of > > and tamping down encroaching entropy. > > > > - Dan C. > > Yeah, good or bad advice at just the right time can have quite an > impact. > > In the under-celebrated "Minimal Perl"[0], Tim Maher notes in the > last paragraph of section 5.8: > > In your own career, I'd advise you to develop an appreciation an > appreciation and an aptitude for both the /quick-and-dirty/ and > /elegant-and-formal/ styles of programming, and to cultivate the > ability to produce either kind on demand, as circumstances > warrant. > > > Seems obvious, in retrospect -- but of course many things do with > the benefit of hindsight. For me, that articulated something that I > sensed was the right way to approach things, but was contrary to > much of the one-dimensional advice I had received up to that > point. It pairs well with one of the "lesser tenets" noted by > Gancarz: "Look for the 90 percent solution"[1]. > > In my own career, I've found I can often use the quick-and-dirty > approach to buy myself time to afford the "detour to build the > tools"[2] that could not be justified (to others) up-front. And > nothing gets it done faster than a shell script. Five or ten scrappy > N-line shell scripts that get the job done sub-optimally, and > lacking any real thought toward usability or generality buy time to > build better tools (usually more, better-written shell scripts). And > sometimes a scrappy script is "good enough" (for years, even). > > -Al > > > [0] Minimal Perl for Unix People and Linux People > by Tim Maher > Forward by Damian Conway > Manning 2007 > p. 175 > ISBN-10: 1-932394-50-8 > > [1] The Unix Philosophy > by Mike Gancarz > Digital Press 1995 > p. 117 > ISBN-10: 1-55558-123-4 > > [2] [McIlroy78] The Bell System Technical Journal. Bell Laboratories. > M. D. McIlroy, E. N. Pinson, and B. A. Tague. > "Unix Time-Sharing System Forward". 1978. 57 (6, part 2). p. 1902. > https://archive.org/details/bstj57-6-1899/page/n3/mode/2up > > Also quoted in ESR's "The Art of Unix Programming" > Addison-Wesley 2004 > p. 12 > ISBN-13: 9-780131-429017 > https://www.catb.org/~esr/writings/taoup/html/ch01s06.html > > -- > a l a n d. s a l e w s k i > ads at salewski.email > salewski at att.net > https://github.com/salewski > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Thu Mar 2 10:44:01 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Wed, 1 Mar 2023 19:44:01 -0500 Subject: [TUHS] Unix v7 programs to share Message-ID: 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 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Mar 2 11:17:25 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 2 Mar 2023 12:17:25 +1100 Subject: [TUHS] Early GUI on Linux In-Reply-To: <20230301175232.GF26409@mcvoy.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <20230301165446.GB26409@mcvoy.com> <616F16D5-5906-4E30-A421-FE8978CA9E8E@planet.nl> <20230301175232.GF26409@mcvoy.com> Message-ID: X10R3 was also included in the 4.3BSD tape https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD/usr/contrib/X On Wed, Mar 01, 2023 at 09:52:32AM -0800, Larry McVoy wrote: > It was the answer for me, I wanted "sameness" across platforms (which was > what Unix was advertising and then the vendors all diverged into their > "value add"). > > I can't believe that 1987 was my first exposure to bringing up X, pretty > sure I had done it at UW-Madison for the same reasons. But maybe not, > I dunno, it was a long time ago. > > All I know is that, at the time, X10R3 was the only hope I had of getting > the same dev environment no matter what I was working on. > > Whether I had brought it up or not at UW-Madison, I had been using some > version of X for years, at least 5 years and probably more, prior to > going out in industry in 1987. And that wasn't my doing, UW-Madison > was very much a hackers school, a good one, and they had X-something > running on everything, micro vaxen, RTs, Suns, everything. > > So it wasn't like 1987 happened and I "picked" X over some alternative, > it was already the answer well before that, years and years before that. > I know I was running it as an undergrad. > > On Wed, Mar 01, 2023 at 06:22:49PM +0100, Paul Ruizendaal wrote: > > That is very quick. X10R3 came out in Feb 1986 (which I understand was the first ???outside' release) and by 1987 it was already the dominant windowing system? Or did you mean that it had won prior to 1991? > > > > > > > On 1 Mar 2023, at 17:54, Larry McVoy wrote: > > > > > > It's worth pointing out that X had won before Linux. I was a contractor > > > in 1987, worked on all sorts of different workstations with all sorts of > > > vendor provided window systems, and the first thing I did was to bring > > > up my trusty X10R3 tape. > > > > > On Wed, Mar 01, 2023 at 05:39:48PM +0100, Paul Ruizendaal wrote: > > >> Thank you for highlighting that! > > >> > > >> Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent. > > >> > > >> This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought. > > >> > > >> > > >>> On 27 Feb 2023, at 21:30, Dan Cross wrote: > > >>> > > >>> On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: > > >>>> Thanks all for the insights. Let me attempt a summary. > > >>>> > > >>>> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. > > >>> > > >>> While that was literally true, I think it was a little more nuanced. > > >>> I'd perhaps put it that people wanted their familiar environments. > > >>> Many people were used to running a lot of xterms on their > > >>> workstations, of course, but there were other X applications people > > >>> used regularly. > > -- > --- > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat > From tuhs at tuhs.org Thu Mar 2 11:33:32 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 02 Mar 2023 01:33:32 +0000 Subject: [TUHS] Init History Ala MERT, CB-UNIX, and USG Generic Message-ID: 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, 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-38%20Introduction.pdf . 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-38%20Unix%20Programmer'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%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/System%20Programs%20-%20man8/init.8.pdf . 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. From jnc at mercury.lcs.mit.edu Thu Mar 2 11:36:28 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Mar 2023 20:36:28 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230302013628.8E40618C07B@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 From jsg at jsg.id.au Thu Mar 2 11:46:36 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 2 Mar 2023 12:46:36 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Thu, Mar 02, 2023 at 07:52:02AM +1100, Dave Horsfall wrote: > On Wed, 1 Mar 2023, Noel Chiappa wrote: > > > > 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: > > I could've sworn that I wrote a paper for AUUGN on that very thing, but > I'm damned if I can find it... Anyone here remember it? It explained > exactly how to use icheck/dcheck/ncheck/clri on a creamed file system (and > no, I no longer have the document). > > -- Dave "A Proposal for a Simple Bad Block Utility" page 8 of https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V03.5.pdf From cowan at ccil.org Thu Mar 2 11:56:12 2023 From: cowan at ccil.org (John Cowan) Date: Wed, 1 Mar 2023 20:56:12 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230302013628.8E40618C07B@mercury.lcs.mit.edu> References: <20230302013628.8E40618C07B@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 1, 2023 at 8:36 PM Noel Chiappa wrote: > Which one? There were two: "MIT's AI Lab", by CSTACY, Alan Wecsler, and me; That one. Mine should really be rewritten now. > which Rob Austein re-wrote into "Alice's PDP-10". > I didn't know that one was done at MIT. > I think that the person fails their oral. I > have no idea if it's a true story. > That's vicious. It reminds me of the medical oral exam where the last question is "How many cranial nerves are there in Great Britain?" Of course the candidate tries to remember how many people there are and multiplies it by 12, on the fly. The answer is "One more than in the U.S.", because one subdivided nerve is/was considered two distinct nerves there. "Mr. Asimov, what can you tell us about the endochronic properties of resublimated thiotimoline?" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Mar 2 11:59:30 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Mar 2023 20:59:30 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230302015930.8A48F18C07B@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 From tuhs at tuhs.org Thu Mar 2 12:02:12 2023 From: tuhs at tuhs.org (Jan Schaumann via TUHS) Date: Wed, 1 Mar 2023 21:02:12 -0500 Subject: [TUHS] Unix Systems Administration Texts In-Reply-To: References: <2cfef728-ef06-20e4-e29e-9a0c83af8334@gmail.com> Message-ID: Adam Thornton wrote: > I liked the Frisch and Limoncelli/Hogan books. Nemeth less so. Having taught a system administration grad level class for many years now, I think there's an evolution of the profession whereby books that were previously practically useful are less so now. Nemeth et al was useful in a very practical sense (e.g., Pete's example of "fix printer spooler on HP-UX"), but Limoncelli's books were always stronger in principles. Taking it further up the layer of abstractions, I then found Mark Burgess's works more valuable, but that very much leaves the realm of vocation (which I maintain is hard to capture in books anyway) and goes towards the more theoretical side. The profession has evolved (or even splintered) dramatically, with DevOps, SRE, and cloud computing covering overlapping but different sets of work in this area. All that is very different from the early days of administering Unix systems. I still struggle with the balance of teaching students basic Unix skills, conveying (true) Unix multiuser system concepts, translating administrative principles into containerized, ephemeral environments, especially at large scale... -Jan From bakul at iitbombay.org Thu Mar 2 12:12:02 2023 From: bakul at iitbombay.org (Bakul Shah) Date: Wed, 1 Mar 2023 18:12:02 -0800 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230302013628.8E40618C07B@mercury.lcs.mit.edu> References: <20230302013628.8E40618C07B@mercury.lcs.mit.edu> Message-ID: On Mar 1, 2023, at 5:36 PM, Noel Chiappa wrote: > > 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. Doesn't everyone know that a number is divisible by 3 if the one digit result after casting out 9s is divisible by 3? From crossd at gmail.com Thu Mar 2 12:11:57 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 1 Mar 2023 21:11:57 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230302015930.8A48F18C07B@mercury.lcs.mit.edu> References: <20230302015930.8A48F18C07B@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 1, 2023 at 8:59 PM Noel Chiappa wrote: > >> _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? I believe you posted a link to end(3) here back in 2018: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man3/end.3 - Dan C. From rich.salz at gmail.com Thu Mar 2 12:46:09 2023 From: rich.salz at gmail.com (Rich Salz) Date: Wed, 1 Mar 2023 21:46:09 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230302013628.8E40618C07B@mercury.lcs.mit.edu> Message-ID: > > > > 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. > > Doesn't everyone know that a number is divisible by 3 if the one digit > result after casting out 9s is divisible by 3? Sure. But the amazing point was it worked regardless of bit order. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Mar 2 13:05:45 2023 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 2 Mar 2023 14:05:45 +1100 (EST) Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Thu, 2 Mar 2023, Jonathan Gray wrote: > > I could've sworn that I wrote a paper for AUUGN on that very thing, > > but I'm damned if I can find it... Anyone here remember it? It > > explained exactly how to use icheck/dcheck/ncheck/clri on a creamed > > file system (and no, I no longer have the document). > > "A Proposal for a Simple Bad Block Utility" > page 8 of > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V03.5.pdf Boy, that takes me back! And I can't believe that I used American spelling such as "utilizing" etc... Anyway, that's not the one. It occurred to me that I wrote it before AUUGN was published, as all that we had until then were just informal notes. Oh well, more CSU history lost (along with our version of V6 which was almost but not quite V7) :-{ PS: I never did get to write FLAW... -- Dave From jsg at jsg.id.au Thu Mar 2 14:16:39 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 2 Mar 2023 15:16:39 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230301212916.0583418C07B@mercury.lcs.mit.edu> References: <20230301212916.0583418C07B@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 01, 2023 at 04:29:16PM -0500, Noel Chiappa wrote: > > 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. That is close, but slightly different to the PWB fcheck.c https://www.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/source/s8/fcheck.c UNSW also had /* * chk: fast combination of icheck+dcheck * * Original from Vrije Universiteit, Amsterdam. * Modified by Kevin Hill, University of NSW. */ https://www.tuhs.org/cgi-bin/utree.pl?file=AUSAM/source/S/chk.c From lm at mcvoy.com Thu Mar 2 14:28:18 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Mar 2023 20:28:18 -0800 Subject: [TUHS] Early GUI on Linux In-Reply-To: <20230301175232.GF26409@mcvoy.com> References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <20230301165446.GB26409@mcvoy.com> <616F16D5-5906-4E30-A421-FE8978CA9E8E@planet.nl> <20230301175232.GF26409@mcvoy.com> Message-ID: <20230302042817.GA26839@mcvoy.com> On Wed, Mar 01, 2023 at 09:52:32AM -0800, Larry McVoy wrote: > Whether I had brought it up or not at UW-Madison, I had been using some > version of X for years, at least 5 years and probably more, prior to > going out in industry in 1987. And that wasn't my doing, UW-Madison > was very much a hackers school, a good one, and they had X-something > running on everything, micro vaxen, RTs, Suns, everything. Paul gently took me to task in private and pointed out that my timeline doesn't make sense, there is no way I was running X anything in 1982. And he's right, there were a number of years on vt52 and vt100 and whatever was the heath one, I loved that terminal because you could code it to put status in the 25th line. A lot of time on terminals connected to a Vax 780. I was an undergrad from 1980-85, grad in 96 and 87. I'm pretty sure I was running some version of X as an undergrad, probably as a senior. But not for 5 years before I graduated as I said so my bad. I'm a fisherman, the fish get bigger every time I tell the story and the years I used X back in the day get longer :) Whatever the details are, I left Wisconsin with X as my dev environment and I believe I brought it up on Suns, HPs, SGIs, Linux of course, maybe SCO (I might have skipped that and just used console ttys, the SCO I used was warmed over V7) and who knows what else. X was to me in windowing as Unix was to me in operating systems, they were what I wanted simply because I got more work done in those environments. --lm From douglas.mcilroy at dartmouth.edu Thu Mar 2 14:41:17 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Wed, 1 Mar 2023 23:41:17 -0500 Subject: [TUHS] A second Unix Patent In-Reply-To: References: Message-ID: Typo, in v3 through v6, may be the most creative Unix program to have come out of Bell Labs. It served as a spell checker before spell(1), though it knew nothing about spelling beyond a list of the most common words in the language. This brainchild of Bob Morris would, in his words, work just as well in Urdu as in English. The beautiful trick: gather trigram frequencies in the document, then print out a list of the individual words in increasing order of the likelihood that they came from the statistical source that those frequencies characterize. Typos (as distinct from phonetic misspellings) generally floated toward the beginning of the list and so were easy to spot. But that's not all that Bob invented. 26^3 16-bit trigram counts didn't fit in the PDP-11 memory, so he counted them in 8-bit bytes. To do so he invented the trick of "counting large integers in small registers". Roughly speaking, when you see a word whose current count is in the range 2^(n-1) to 2^n-1, you increment the count with probability 1/2^n, thus getting an approximation to lg n, which serves in estimating the entropy of each word. This counting method merited a patent and is now recognized as the first of what is now an active subfield of theoretical computer science--memory-bounded streaming algorithms. Doug On Wed, Mar 1, 2023 at 6:00 PM Warner Losh wrote: > 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? > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 46129 bytes Desc: not available URL: From davida at pobox.com Thu Mar 2 15:16:53 2023 From: davida at pobox.com (David Arnold) Date: Thu, 2 Mar 2023 16:16:53 +1100 Subject: [TUHS] A second Unix Patent In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Mar 2 16:41:31 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 02 Mar 2023 06:41:31 +0000 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: (John Cowan's message of "Wed, 1 Mar 2023 20:56:12 -0500") References: <20230302013628.8E40618C07B@mercury.lcs.mit.edu> Message-ID: <7wsfenslic.fsf@junk.nocrew.org> John Cowan writes: >> which Rob Austein re-wrote into "Alice's PDP-10". > I didn't know that one was done at MIT. This spells out the details: https://www.hactrn.net/sra/alice/alice.glossary From lars at nocrew.org Thu Mar 2 16:46:37 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 02 Mar 2023 06:46:37 +0000 Subject: [TUHS] X timeline In-Reply-To: <20230302042817.GA26839@mcvoy.com> (Larry McVoy's message of "Wed, 1 Mar 2023 20:28:18 -0800") References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> <20230301165446.GB26409@mcvoy.com> <616F16D5-5906-4E30-A421-FE8978CA9E8E@planet.nl> <20230301175232.GF26409@mcvoy.com> <20230302042817.GA26839@mcvoy.com> Message-ID: <7wo7pbsl9u.fsf_-_@junk.nocrew.org> Larry McVoy wrote: > Paul gently took me to task in private and pointed out that my timeline > doesn't make sense, there is no way I was running X anything in 1982. I recently collected some information about the X timeline: https://github.com/larsbrinkhoff/absolutely-not-a-vaxstation100-emulator/issues/1 Corrections welcome. From arnold at skeeve.com Thu Mar 2 17:27:52 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Mar 2023 00:27:52 -0700 Subject: [TUHS] Early GUI on Linux In-Reply-To: References: <58626A0B-EF9C-4920-8E20-CE0C4210BA6A@planet.nl> Message-ID: <202303020727.3227RqxE014058@freefriends.org> I will say that if you didn't care about lots of apps or your windowm manager tweeks, MGR was great. I ran it on a small sparcstation for a while in the early 90s, and it was M U C H faster than X on the same hardware. Arnold Paul Ruizendaal wrote: > Thank you for highlighting that! > > Several folks had already hinted at such, but your comments make clear that by 1991 the X ecosystem had come out on top in a winner-takes-all dynamic: people wanted X because that had the apps, and the apps were for X because that was the most prevalent. > > This also explains that MGR on Linux was so short-lived: although it provided the terminal multiplexing that was the key use case, it did not have the application ecosystem that was apparently already important enough to motivate people to make X run on Linux very early in its existence. I had always thought of those early X applications as little more than gimmicks, but apparently they were more appreciated than I thought. > > > > On 27 Feb 2023, at 21:30, Dan Cross wrote: > > > > On Mon, Feb 27, 2023 at 12:22 PM Paul Ruizendaal via TUHS wrote: > >> Thanks all for the insights. Let me attempt a summary. > >> > >> What it boils down to is that X arrived on Linux very early, because what the Linux hackers needed/wanted was a familiar terminal multiplexer. > > > > While that was literally true, I think it was a little more nuanced. > > I'd perhaps put it that people wanted their familiar environments. > > Many people were used to running a lot of xterms on their > > workstations, of course, but there were other X applications people > > used regularly. > > > > Some I remember where `gv` to look at PostScript documents, `xv` to > > view image files, `gnuplot` could generate plots in a window, `xdvi` > > to look at TeX/LaTeX output, and text editors like `emacs` had X > > front-ends that offered syntax highlighting and the like; some folks I > > knew liked `nedit`. `exmh` was my preferred email client for a while, > > and things like `xman` (was there a `tkman`, too?) was nice. Some > > system monitoring tools `xload` were considered essentials; `xbiff` > > could be useful (I could have sworn there was a `tkbiff`, too). A > > clock like `xclock` or `oclock` or something was also nice. Some folks > > liked graphical newsreaders, chat programs (I guess IRC was a thing > > back then, and I believe some `talk` client had an X front-end). There > > was a fractal viewer that I thought was fun, but I don't remember it > > much anymore (even the name...). Oh, and lots of games; I had a nice > > Solitaire version that I can no longer recall the name of. `xeyes` was > > cute, and running `xroach` was a popular (?) prank for an unsuspecting > > (but amenable) colleague. > > > > A lot of us spent a lot of time customizing our environments, and many > > eschewed the vendor-standard environment. For instance, a lot of > > people I knew used `twm` and derivatives (`ctwm` and `tvtwm` were > > popular), and spent a lot of time tweaking menus and stuff to set > > things up the way we liked. A lot of folks also wrote custom tools > > using `tk` or `expectk`. Giving all of that up to run on Linux was a > > bitter pill to swallow, so there was a real impetus to get X running > > quickly. Personally, I kept my `tvtwm`-based environment going until I > > switched to plan9 and then to the Mac as a daily driver. I'm not sure > > I miss it, but at the time it was head-and-shoulders above anything > > you could get on Windows or (classic) MacOS. > > > > So it wasn't just that people wanted a "familiar terminal multiplexor" > > as that people wanted the environments they had put a lot of time and > > energy into building up for themselves, and again, that often meant X. > > > >> It seems that the pattern persists till the present day (and yes, it matches with my own dev setup/needs). I wonder to what extent this is a generational thing though. Maybe today’s twenty-somethings spend their days in front of Xcode, VStudio, Eclipse, etc. more than using multiple terminals. > > > > I think it probably depends on what people are doing. I more or less > > switched to using VS Code for my editor, and I'm using a Mac Studio to > > write this, but my desktop is still littered with terminal windows, > > I've got a `drawterm` session open to my local Plan 9 network, and am > > logged into a bunch of old systems (Multics, TOPS-20, VMS, an IBM > > mainframe, CDC Cyber, RSTS/E, PR1ME), etc. > > > > But the way we write software has changed pretty dramatically in the > > last 3 or so decades. I used to start with an empty C file and write > > my stuff. Things like linked-lists? Mostly implemented by hand. These > > days, there are other languages and vast collections of libraries for > > almost anything imaginable; much of what "programming" is today is > > glueing together different libraries and making them interact in > > sophisticated, often quite complex ways. I don't know that it's > > better, nor that it's always worse, but it is qualitatively different. > > So almost necessarily the toolsets and environment have changed > > accordingly. > > > >> This ties in with another observation on early window systems. The earliest Unix window system that I could find (i.e. documented) was NUnix from 1981/82. Its desktop was designed around the idea of a dozen or so top level windows, each one being either a shell window or a graphics canvas, with no real concept of a widget set, dialogs, etc., or even of sub-windows. This paradigm seems to have been more or less the same in the Blit terminal, and carried through in MGR, Mux and even as late as 8 1/2. In the context where this serves the needs of core user group, such makes sense. > > > > It may be instructive to look at the early X window managers in this > > regard. One I remember was `uwm` (I think); I recall being struck > > that it reminded me of rio when I saw it. > > > >> It is in stark contrast with developments at the lower/consumer end of the market. The original Mac, GEM and Windows all placed much more emphasis on being a graphical user interface, with standard widgets and UI design elements. On Unix and X it remained a mess. It seems that this was both for technical reasons (X not imposing a standard) and for economic reasons (the Unix wars). Linux then inherited the mess and the core user/developer demographic had no need/wish/time to fix it. > > > > I remember the X mantra was, "mechanism, not policy." Which was fine, > > except that there wasn't much of even a default policy, which made X > > (IMHO) a bit of a bear to program and meant that interfaces were > > pretty wildly inconsistent across programs. By contrast, writing > > simple programs to draw lines on the Mac was easy. > > > > Interestingly, frustration with this caused an almost cambrian > > explosion of new windowing environments within a few years of Linux's > > arrival on the scene. From larger efforts like Gtk (and then GNOME), > > KDE, GNUStep (which I guess might predate Linux, but not by much...), > > etc, to less ambitious things components like fvwm and Enlightenment, > > we kind of went from "OpenWindows or Motif or roll your own stuff > > around twm or something" to a whole plethora of things. It's still a > > bit of a mess, though. > > > >> It makes me wonder when true graphical applications started to appear for X / Unix / Linux (other than stuff like terminal, clock, calculator, etc.). The graphical browser certainly is one (1993). StarOffice and Applix seem to have arrived around 1995. Anything broadly used before that? > > > > Lots! See above. > > > > - Dan C. > From arnold at skeeve.com Thu Mar 2 17:34:47 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Mar 2023 00:34:47 -0700 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: <202303020734.3227YlJT014832@freefriends.org> Dave Horsfall wrote: > On Wed, 1 Mar 2023, Noel Chiappa wrote: > > > > 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: > > I could've sworn that I wrote a paper for AUUGN on that very thing, but > I'm damned if I can find it... Anyone here remember it? It explained > exactly how to use icheck/dcheck/ncheck/clri on a creamed file system (and > no, I no longer have the document). > > -- Dave So Dave, did you clri the wrong inode such that your lost the paper? :-) :-) From cowan at ccil.org Thu Mar 2 17:56:30 2023 From: cowan at ccil.org (John Cowan) Date: Thu, 2 Mar 2023 02:56:30 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Wed, Mar 1, 2023 at 10:05 PM Dave Horsfall wrote: > Boy, that takes me back! And I can't believe that I used American > spelling such as "utilizing" etc... > Perhaps whoever typed it was an American or Canadian, or conceivably an Oxonian. Typists routinely corrected, or "corrected", authors' spellings in those days. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Mar 2 18:01:56 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 2 Mar 2023 19:01:56 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Thu, Mar 02, 2023 at 02:05:45PM +1100, Dave Horsfall wrote: > On Thu, 2 Mar 2023, Jonathan Gray wrote: > > > > I could've sworn that I wrote a paper for AUUGN on that very thing, > > > but I'm damned if I can find it... Anyone here remember it? It > > > explained exactly how to use icheck/dcheck/ncheck/clri on a creamed > > > file system (and no, I no longer have the document). > > > > "A Proposal for a Simple Bad Block Utility" > > page 8 of > > https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V03.5.pdf > > Boy, that takes me back! And I can't believe that I used American > spelling such as "utilizing" etc... > > Anyway, that's not the one. It occurred to me that I wrote it before > AUUGN was published, as all that we had until then were just informal > notes. > > Oh well, more CSU history lost (along with our version of V6 which was > almost but not quite V7) :-{ part of it is in https://www.tuhs.org/Archive/Applications/Spencer_Tapes/unsw3.tar.gz usr/source/csu/ "Software from Computing Services Unit" From usotsuki at buric.co Thu Mar 2 18:53:01 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 2 Mar 2023 03:53:01 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Message-ID: On Thu, 2 Mar 2023, John Cowan wrote: > On Wed, Mar 1, 2023 at 10:05 PM Dave Horsfall wrote: > >> Boy, that takes me back! And I can't believe that I used American >> spelling such as "utilizing" etc... > > Perhaps whoever typed it was an American or Canadian, or conceivably an > Oxonian. Typists routinely corrected, or "corrected", authors' spellings > in those days. Which reminds me of some bibles I have that were jointly produced by Cambridge University Press and Trinitarian Bible Society. Any of the stuff in there that came from Cambridge would say "Authorized" etc., while if it came from Trinitarian, it would say "Authorised". -uso. From tuhs at tuhs.org Thu Mar 2 19:05:44 2023 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Thu, 2 Mar 2023 10:05:44 +0100 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: <31604b56-d527-bfc1-3d33-8c9e4a3b117c@case.edu> References: <31604b56-d527-bfc1-3d33-8c9e4a3b117c@case.edu> Message-ID: > On 1 Mar 2023, at 15:12, Chet Ramey wrote: > > Yes! High C from Metaware. I wrestled with that compiling bash a lot; I > did a ton of development on AOS. Once I was told that the compiler originally started live as a Pascal compiler and later C compilation was added to the product. jaap -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 267 bytes Desc: Message signed with OpenPGP URL: From ken.unix.guy at gmail.com Thu Mar 2 22:45:35 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 2 Mar 2023 07:45:35 -0500 Subject: [TUHS] Unix v7 programs to share Message-ID: 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=sharing https://drive.google.com/file/d/1_IUnyPwsRvYMAuqO9xb8Z8MZDbKLST70/view?usp=sharing https://drive.google.com/file/d/1t88SNnJjWIbPrGuTFfFZM-7qKhD6AS6S/view?usp=sharing More to come. Ken -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Thu Mar 2 23:28:14 2023 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 2 Mar 2023 08:28:14 -0500 Subject: [TUHS] A second Unix Patent Message-ID: > 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 From ken.unix.guy at gmail.com Fri Mar 3 00:27:34 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 2 Mar 2023 09:27:34 -0500 Subject: [TUHS] Unix v7 tape drive question Message-ID: 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 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Mar 3 00:39:57 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 2 Mar 2023 09:39:57 -0500 Subject: [TUHS] Unix v7 tape drive question In-Reply-To: References: Message-ID: On Thu, Mar 2, 2023 at 9:28 AM KenUnix wrote: > 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. I'd start with the man page. Dump(1M) says that argument `f` causes `dump` to, "Place the dump on the next argument file instead of the tape". Did you try using that option with `/dev/rmt0`? Alternatively, I don't see why you couldn't hard-link /dev/rmt1 to /dev/rmt0: # cd /dev # ln rmt1 rmt0 Or use `mknod` to create a device file with the same major/minor numbers: # cd /dev # /etc/mknod rmt1 c 12 0 Or even, as a very last resort, edit the source and change the default dump device. It's in /usr/src/cmd/dump.c Hope that helps! - Dan C. From ken.unix.guy at gmail.com Fri Mar 3 01:00:56 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 2 Mar 2023 10:00:56 -0500 Subject: [TUHS] Unix v7 tape drive question In-Reply-To: References: Message-ID: Dan, Thanks, that did the trick. # dump date = Thu Mar 2 09:52:02 2023 dump date = the epoch dumping /dev/rrp3 to /dev/rmt1 I II estimated 24870 tape blocks on 0 tape(s) III IV level 9 dump on Thu Mar 2 09:52:02 2023 DONE 25228 tape blocks on 1 tape(s) And, I will change dump.c and dumpdir.c to use tm0. Ken On Thu, Mar 2, 2023 at 9:40 AM Dan Cross wrote: > On Thu, Mar 2, 2023 at 9:28 AM KenUnix wrote: > > 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. > > I'd start with the man page. > > Dump(1M) says that argument `f` causes `dump` to, "Place the dump on > the next argument file instead of the tape". Did you try using that > option with `/dev/rmt0`? > > Alternatively, I don't see why you couldn't hard-link /dev/rmt1 to > /dev/rmt0: > > # cd /dev > # ln rmt1 rmt0 > > Or use `mknod` to create a device file with the same major/minor numbers: > > # cd /dev > # /etc/mknod rmt1 c 12 0 > > Or even, as a very last resort, edit the source and change the default > dump device. It's in /usr/src/cmd/dump.c > > Hope that helps! > > - Dan C. > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Fri Mar 3 01:15:10 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 2 Mar 2023 10:15:10 -0500 Subject: [TUHS] Unix v7 programs to share Message-ID: 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=sharing https://drive.google.com/file/d/1_IUnyPwsRvYMAuqO9xb8Z8MZDbKLST70/view?usp=sharing https://drive.google.com/file/d/1t88SNnJjWIbPrGuTFfFZM-7qKhD6AS6S/view?usp=sharing Ken -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Mar 3 02:57:01 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 2 Mar 2023 11:57:01 -0500 Subject: [TUHS] Unix v7 tape drive question In-Reply-To: References: Message-ID: On Thu, Mar 2, 2023 at 9:28 AM KenUnix wrote: > 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? > Some thoughts... 1.) start with the man page: https://man.cat-v.org/unix_7th/1/dump You note the first key parameter described is f - i.e. dump fu0 /dev/rmtXXX /dev/rrpY Remember on traditional research systems like V6/V7you should use rmtX and rrpY not mtX and rpY as you don't what to use the buffer cache (modern UNIXs & Linux use the paging HW so things like need for the old I/O buffer cache are avoided). 2.) next: read: https://man.cat-v.org/unix_7th/4/tm cd /dev; ls -l *mt* (if you type: cat makefile that would not hurt) I suspect you will see three devices: mt0 (a blocked device i.e. thru the buffer cache and then copied in/out to your program) and two raw devices: rmt0 and nrmt0 (character devices i.e. direct I/O to your program). Using mknod create the next Unit number - i.e. three more device files: mt1 rmt1 and nrmt1 - don't forget chmod them too Now with simh, you can add: attach tm1 some_local_file 3.) since you are using simh, you could also use the RH11/RH70 based Tapes which are the ht devices: https://man.cat-v.org/unix_7th/4/ht The makefile in dev will create 2 drives for you and make sure you use a UNIX kernel configured with the ht driver included. Also in simh, enable TU0 and TU1 instead of TM0 and TM1 I would not recommend recompiling the tape utilities, although as Dan said you could do that. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Fri Mar 3 04:43:57 2023 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Thu, 2 Mar 2023 13:43:57 -0500 Subject: [TUHS] simtel20 unix-c software archive Message-ID: 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 From clemc at ccc.com Fri Mar 3 05:26:36 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 2 Mar 2023 14:26:36 -0500 Subject: [TUHS] Any Bell 8-bit UNIX Efforts? In-Reply-To: References: <31604b56-d527-bfc1-3d33-8c9e4a3b117c@case.edu> Message-ID: below... On Thu, Mar 2, 2023 at 4:06 AM Jaap Akkerhuis via TUHS wrote: > > > On 1 Mar 2023, at 15:12, Chet Ramey wrote: > > Yes! High C from Metaware. I wrestled with that compiling bash a lot; I > did a ton of development on AOS. > > > Once I was told that the compiler originally started live as a > Pascal compiler and later C compilation was added to the product. > > > That rings a bell for me also FWIW. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Fri Mar 3 11:03:48 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 2 Mar 2023 17:03:48 -0800 Subject: [TUHS] simtel20 unix-c software archive In-Reply-To: References: Message-ID: <20230303010348.GC2758@mcvoy.com> Wow. There is an ftp site I haven't thought of in 30+ years. Cool find! On Thu, Mar 02, 2023 at 01:43:57PM -0500, A. P. Garcia wrote: > 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 -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From dave at horsfall.org Fri Mar 3 11:06:31 2023 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 3 Mar 2023 12:06:31 +1100 (EST) Subject: [TUHS] simtel20 unix-c software archive In-Reply-To: <20230303010348.GC2758@mcvoy.com> References: <20230303010348.GC2758@mcvoy.com> Message-ID: On Thu, 2 Mar 2023, Larry McVoy wrote: > Wow. There is an ftp site I haven't thought of in 30+ years. Cool find! IIRC, there were people still connected waiting for the switch to be flipped... -- Dave From steve.mynott at gmail.com Fri Mar 3 23:29:13 2023 From: steve.mynott at gmail.com (Steve Mynott) Date: Fri, 3 Mar 2023 13:29:13 +0000 Subject: [TUHS] A second Unix Patent In-Reply-To: References: Message-ID: <20230303132913.ab5mqzuwlut64saw@risey.fivesnap.com> While poking around I discovered a modern go rewrite by Rob Pike https://github.com/robpike/typo On Wed, Mar 01, 2023 at 11:41:17PM -0500, Douglas McIlroy typed: > Typo, in v3 through v6, may be the most creative Unix program to have come > out of Bell Labs. It served as a spell checker before spell(1), though it > knew nothing about spelling beyond a list of the most common words in the > language. This brainchild of Bob Morris would, in his words, work just as > well in Urdu as in English. > > The beautiful trick: gather trigram frequencies in the document, then print > out a list of the individual words in increasing order of the likelihood > that they came from the statistical source that those frequencies > characterize. Typos (as distinct from phonetic misspellings) generally > floated toward the beginning of the list and so were easy to spot. > > But that's not all that Bob invented. 26^3 16-bit trigram counts didn't fit > in the PDP-11 memory, so he counted them in 8-bit bytes. To do so he > invented the trick of "counting large integers in small registers". Roughly > speaking, when you see a word whose current count is in the range 2^(n-1) > to 2^n-1, you increment the count with probability 1/2^n, thus getting an > approximation to lg n, which serves in estimating the entropy of each word. > > This counting method merited a patent and is now recognized as the first of > what is now an active subfield of theoretical computer > science--memory-bounded streaming algorithms. -- Steve Mynott rsa3072/629FBB91565E591955B5876A79CEFAA4450EBD50 From martymcg at fastmail.com Sat Mar 4 01:03:43 2023 From: martymcg at fastmail.com (MIT Book Club) Date: Fri, 03 Mar 2023 10:03:43 -0500 Subject: [TUHS] Unix v7 programs to share In-Reply-To: References: Message-ID: <90b9dbd9-6b82-4179-8a5e-fff197d0e740@app.fastmail.com> Ken U Guy, thanks especially for the Text Editor. i'm sharing it in our community who think a word processor is. =*+[]+ Marty McGowan +1 908 230-3739 The MIT Book Club, Princeton and Northern NJ On Thu, Mar 2, 2023, at 07:45, KenUnix wrote: > 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=sharing > https://drive.google.com/file/d/1_IUnyPwsRvYMAuqO9xb8Z8MZDbKLST70/view?usp=sharing > https://drive.google.com/file/d/1t88SNnJjWIbPrGuTFfFZM-7qKhD6AS6S/view?usp=sharing > > More to come. > > Ken > > -- > > WWL 📚 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Mar 4 04:22:00 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 3 Mar 2023 13:22:00 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230303182200.B951918C08D@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 From frew at ucsb.edu Sat Mar 4 05:19:57 2023 From: frew at ucsb.edu (James Frew) Date: Fri, 3 Mar 2023 11:19:57 -0800 Subject: [TUHS] A second Unix Patent In-Reply-To: <20230303132913.ab5mqzuwlut64saw@risey.fivesnap.com> References: <20230303132913.ab5mqzuwlut64saw@risey.fivesnap.com> Message-ID: This qualifies as a true Service to the Profession™. If you doubt that, take a look at the original C version, completely free of pesky comments. (Would've made a great CS PhD exam question: "What does this code do?") /Frew P.S.: All you cats waiting on the books I promised: they're all boxed up on the spare bed behind me, shipping Real Soon Now™. On 2023-03-03 05:29, Steve Mynott wrote: > While poking around I discovered a modern go rewrite by Rob Pike > > https://github.com/robpike/typo > > On Wed, Mar 01, 2023 at 11:41:17PM -0500, Douglas McIlroy typed: >> Typo, in v3 through v6, may be the most creative Unix program to have come >> out of Bell Labs. From chet.ramey at case.edu Sat Mar 4 05:25:09 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 3 Mar 2023 14:25:09 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230303182200.B951918C08D@mercury.lcs.mit.edu> References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: On 3/3/23 1:22 PM, Noel Chiappa wrote: > 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. A former CWRU president (very soon after the merger) used to tell freshmen the same thing during his annual address to the incoming class. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From clemc at ccc.com Sat Mar 4 05:35:37 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 3 Mar 2023 14:35:37 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230303182200.B951918C08D@mercury.lcs.mit.edu> References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 3, 2023 at 1:22 PM Noel Chiappa wrote: > > From: KenUnix > > > So is it safe to say there is no fsck or similar for v7? > Last fall, I recovered the original CMU sources to both. And I told Warren after I clean things up, I'll push them to TUHS both source and binaries but I have a number of other projects ahead of that. > > Yes, but that does't talk about '_end' not being defined if there > are missing externals, either! >From V7: https://man.cat-v.org/unix_7th/1/ld <--- this should only be a URL - let me know if Chrome/gmail is peeing on it again The symbols `_etext', `_edata' and `_end' (`etext', `edata' and `end' in C) are reserved, and if referred to, are set to the first location above the program, the first location above initialized data, and the first location above all data respectively. It is erroneous to define these symbols. Then check the section 3 man page: https://man.cat-v.org/unix_7th/3/end which describes them in more detail. > Interesting. I wonder how 'fcheck' made it from CMU to Bell? The late Ted Kowaski - the primary author. Undergrad EE UMICH (Bill Joy's roommate) and Grad EE at CMU (and my programming/lab partner originally in Dan Sieworick's grad RT course and Gordon Bell System Architecture courses). MTS and TSS had a disk scavenger from IBM for their common FS [which Ted has used at MICH and I had CMU]. icheck/ncheck/dcheck seemed less useful. A new program was started when he was an undergrad and never finished. It had more colorful name originally - fsck (pronounced as fisk BTW) was finished. I suspect the fcheck name was a USG idea. The reason why many of the error messages are upper case is that was the IBM convention which both MTS and TSS used for system programs. > 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 > CMU only ran V5 for a very short time and never in the EE Dept. I only knew of one system that ever ran it. We were a hacked V6 most of the time I was there. V7 showed up at the end, although parts of V7 and PWB leaked to us via different students who worked at Bell (that story was similar at many sites). > > which contained the functionality of both. I wonder why they were split? > Space? > Table space to support larger disk was always a huge problem. Since we mostly ran UNIX on 11/40 class systems, it had to be able to run on non-I/D (45 class) machines. A lot of creativity was used to keep it small. It was fine for RK05s and RP03s but Ted's temp space hack was done when the first RP04-like disk showed up - it was an IBM disk on an aftermarket Unibus controller made to look like an RP in EE and then Dan Klein and I got the very low serial # RK07 at Mellon Institute and that was my first Unix driver which we hacked together one weekend. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Sat Mar 4 07:26:03 2023 From: cowan at ccil.org (John Cowan) Date: Fri, 3 Mar 2023 16:26:03 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 3, 2023 at 2:25 PM Chet Ramey wrote: > A former CWRU president (very soon after the merger) used to tell freshmen > the same thing during his annual address to the incoming class. > I remember being told that when I arrived at Case in 1976; sure enough, within a year I was the one who had departed. I didn't belong there anyway. I wound up, for family reasons, at CCNY and signed up for the Communications and Mass Media program, but I haunted the college bookstore and picked up the computer-science books (this was back when casuals could actually afford to buy them; one I got then was the Elements of Programming Style). I have never allowed schooling to interfere with my education. Two other things I remember from that speech were that Michelson was a Casie and Morley was a Reservie, and that (as the campus was completely covered with mud at the time), we were never to trust 100-year flood estimates in the United States, as there was not enough evidence to go on, and that in fact that was the third 100-year flood in Cleveland in the last 16 years. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Sat Mar 4 09:00:11 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 4 Mar 2023 10:00:11 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230303182200.B951918C08D@mercury.lcs.mit.edu> References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 03, 2023 at 01:22:00PM -0500, Noel Chiappa wrote: > > 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. https://www.tuhs.org/Archive/Distributions/Research/v7addenda.tar.gz https://www.tuhs.org/cgi-bin/utree.pl?file=V7addenda/fsck From chet.ramey at case.edu Sat Mar 4 10:23:11 2023 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 3 Mar 2023 19:23:11 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: <59d19eec-dca8-aed6-f9dc-ba8be6b648cf@case.edu> On 3/3/23 4:26 PM, John Cowan wrote: > > > On Fri, Mar 3, 2023 at 2:25 PM Chet Ramey > wrote: > > A former CWRU president (very soon after the merger) used to tell freshmen > the same thing during his annual address to the incoming class. > > > I remember being told that when I arrived at Case in 1976; sure enough, > within a year I was the one who had departed. That's Louis Toepfer. Also famous for the other line he was fond of: "Learning is suffering." > Two other things I remember from that speech were that Michelson was a > Casie and Morley was a Reservie, Quite true. That distinction was more important back then, closer to the merger. There were still "Casies" and "Reservies" when I went, but the subsequent administrations have done a lot of work to unify the campus. and that (as the campus was completely > covered with mud at the time), we were never to trust 100-year flood > estimates in the United States, as there was not enough evidence to go on, > and that in fact that was the third 100-year flood in Cleveland in the last > 16 years. Doan Creek (buried and yet) still floods from time to time, most recently a few years ago. It flooded the basement and parking garage of the building where I work. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From jnc at mercury.lcs.mit.edu Sat Mar 4 11:57:46 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 3 Mar 2023 20:57:46 -0500 (EST) Subject: [TUHS] A second Unix Patent Message-ID: <20230304015746.DD95518C08D@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 From jsg at jsg.id.au Sat Mar 4 12:45:50 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 4 Mar 2023 13:45:50 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 03, 2023 at 02:35:37PM -0500, Clem Cole wrote: > > > Interesting. I wonder how 'fcheck' made it from CMU to Bell? > > The late Ted Kowaski - the primary author. Undergrad EE UMICH (Bill Joy's > roommate) and Grad EE at CMU (and my programming/lab partner originally in > Dan Sieworick's grad RT course and Gordon Bell System Architecture > courses). MTS and TSS had a disk scavenger from IBM for their common FS > [which Ted has used at MICH and I had CMU]. icheck/ncheck/dcheck seemed > less useful. > A new program was started when he was an undergrad and never finished. > > It had more colorful name originally - fsck (pronounced as fisk BTW) was > finished. I suspect the fcheck name was a USG idea. The reason why many > of the error messages are upper case is that was the IBM convention which > both MTS and TSS used for system programs. It is difficult to determine when fsck appeared in the USG releases. fsck was perhaps present in USG Program Generic PG-1C300 Issue 3 (March 1977), as it was in the MERT Release 0 manual: https://www.tuhs.org/Archive/Documentation/Manuals/MERT_Release_0/Unix%20Programmer%20Manual%20-%20UPM%20-%20White%20Tabs/System%20Programs%20-%20man8/fsck.8.pdf "I would like to thank Larry A. Wehr for advice that lead to the first version of fsck and Rick B. Brandt for adapting fsck to UNIX/TS." T. J. Kowalski, FSCK - The UNIX/TS File System Check Program included in System III manuals 'Credit for the various pieces involved goes to Ted Kowalski of CMU and BTL, Mike Accetta of CMU, and George Goble of Purdue Univ. Kowalski wrote the "fsck," file system check program, which does all that icheck/dcheck did and more and also repairs errors that it finds. In the Purdue V6 system Goble had added code to ensure that inodes and indirect blocks on disk were always in a consistent state so that the worst that could happen in a sudden halt or crash was that the file system may have some dups in free, but never dups between files. Accetta enhanced these and added a few of his own. In the current Berkeley distribution (4BSD) all of these techniques are provided as well as some additions.' Bill Joy, A Crash-resistant UNIX file system https://archive.org/details/login_january-1981/page/30/mode/2up From jsg at jsg.id.au Sat Mar 4 19:07:08 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Sat, 4 Mar 2023 20:07:08 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230303182200.B951918C08D@mercury.lcs.mit.edu> References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 03, 2023 at 01:22:00PM -0500, Noel Chiappa wrote: > > 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. fcheck is from Hal Pierson at Bell according to https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/readme.txt From ralph at inputplus.co.uk Sat Mar 4 19:22:16 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 04 Mar 2023 09:22:16 +0000 Subject: [TUHS] A second Unix Patent In-Reply-To: <20230304015746.DD95518C08D@mercury.lcs.mit.edu> References: <20230304015746.DD95518C08D@mercury.lcs.mit.edu> Message-ID: <20230304092216.287E22020E@orac.inputplus.co.uk> Hi, Noel wrote: > 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'm a fan of dc(1), but also of units(1) and since both seem underused here's an alternative method. $ units -1v '26^3 16 bit' 64KiB 26^3 16 bit = 0.53637695 * 64KiB -- Cheers, Ralph. From ken.unix.guy at gmail.com Sat Mar 4 21:19:47 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sat, 4 Mar 2023 06:19:47 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230303182200.B951918C08D@mercury.lcs.mit.edu> Message-ID: After downloading fsck.c from v7addenda.tar.gz this happens: w fsck.c 33044 q # cc fsck.c fsck.c:1441: s_dinfo undefined; func. makefree fsck.c:1441: Illegal structure ref fsck.c:1441: Incompatible structures fsck.c:1442: Illegal structure ref fsck.c:1442: Incompatible structures fsck.c:1453: s_dinfo undefined; func. makefree fsck.c:1453: Illegal structure ref fsck.c:1453: Incompatible structures fsck.c:1454: Illegal structure ref fsck.c:1454: Incompatible structures fsck.c lines of interest 1440-1455: #define superblk sblk.b_un.b_fs if(cylsize == 0 || stepsize == 0) { step = superblk.s_dinfo[0]; cyl = superblk.s_dinfo[1]; } else { step = stepsize; cyl = cylsize; } if(step > cyl || step <= 0 || cyl <= 0 || cyl > MAXCYL) { error("Default free list spacing assumed\n"); step = STEPSIZE; cyl = CYLSIZE; } superblk.s_dinfo[0] = step; superblk.s_dinfo[1] = cyl; clear(flg,sizeof(flg)); #define superblk sblk.b_un.b_fs Ken On Sat, Mar 4, 2023 at 4:07 AM Jonathan Gray wrote: > On Fri, Mar 03, 2023 at 01:22:00PM -0500, Noel Chiappa wrote: > > > 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. > > fcheck is from Hal Pierson at Bell according to > > https://wiki.tuhs.org/doku.php?id=misc:snippets:mert1 > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/readme.txt > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sun Mar 5 00:41:34 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 4 Mar 2023 09:41:34 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230304144134.A3AFD18C091@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 From ken.unix.guy at gmail.com Sun Mar 5 00:49:54 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sat, 4 Mar 2023 09:49:54 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230304144134.A3AFD18C091@mercury.lcs.mit.edu> References: <20230304144134.A3AFD18C091@mercury.lcs.mit.edu> Message-ID: Attached is the one I have been toying with. Ignore the 'v7' part I added. Ken On Sat, Mar 4, 2023 at 9:41 AM Noel Chiappa wrote: > > 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 > -- End of line JOB TERMINATED -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: v7fsck.c Type: text/x-csrc Size: 33044 bytes Desc: not available URL: From clemc at ccc.com Sun Mar 5 01:08:28 2023 From: clemc at ccc.com (Clem Cole) Date: Sat, 4 Mar 2023 10:08:28 -0500 Subject: [TUHS] A second Unix Patent In-Reply-To: <20230304015746.DD95518C08D@mercury.lcs.mit.edu> References: <20230304015746.DD95518C08D@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 3, 2023 at 8:58 PM Noel Chiappa wrote: > 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.) > It's interesting - we did the same thing at CMU - almost all of the 11/40's, 40e's and /34's we had in the 1970s running UNIX. We would order them with very minimalist - i.e. 48K and run UNIX swapping to RK05's (slowly) until we had the money to buy more memory and rotating storage ( which was almost always aftermarket - not from DEC) and then those systems would be maxed to 256K. Mellon actually got an original RK07 cheap, so its disks were all Digital (tape was aftermarket), but most of the Unix boxes had dual RK05's and then some storage that we could get cheap. A couple of years later, after I graduated and moved on, I think many groups put Enable's in a couple of them so they could break the 256K barrier - as I sent that code back to Ted and Mike after I wrote it at Tektronix. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Sun Mar 5 05:49:33 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Sat, 4 Mar 2023 14:49:33 -0500 Subject: [TUHS] Unix v7 ps command question Message-ID: 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 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ps1.c Type: text/x-csrc Size: 11080 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ps2.c Type: text/x-csrc Size: 7029 bytes Desc: not available URL: From tuhs at tuhs.org Mon Mar 6 01:01:57 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Sun, 5 Mar 2023 16:01:57 +0100 Subject: [TUHS] Origins of the frame buffer device Message-ID: I am confused on the history of the frame buffer device. On Linux, it seems that /dev/fbdev originated in 1999 from work done by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bellard?). However, it would seem at first glance that early SunOS also had a frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature (a character device that could be mmap’ed to give access to the hardware frame buffer, and ioctl’s to probe and configure the hardware). Is that correct, or were these entirely different in nature? Paul From tuhs at tuhs.org Mon Mar 6 03:29:27 2023 From: tuhs at tuhs.org (Grant Taylor via TUHS) Date: Sun, 5 Mar 2023 10:29:27 -0700 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: Message-ID: On 3/5/23 8:01 AM, Paul Ruizendaal via TUHS wrote: > However, it would seem at first glance that early SunOS also had a > frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar > in nature (a character device that could be mmap’ed to give access > to the hardware frame buffer, and ioctl’s to probe and configure the > hardware). Is that correct, or were these entirely different in nature? My limited understanding is that PC compatibles, and thus Linux, with their VGA et al. cards had /text/ character support that other systems did not have. As such PCs ~> Linux /didn't/ /need/ frame buffer support in the beginning. Conversely all systems that didn't have such cards /did/ /need/ frame buffer from the start. I consider Linux's frame buffer to be a late comer compared to other systems. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4017 bytes Desc: S/MIME Cryptographic Signature URL: From kennethgoodwin56 at gmail.com Mon Mar 6 04:25:23 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Sun, 5 Mar 2023 13:25:23 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: Message-ID: The first frame buffers from Evans and Sutherland were at University of Utah, DOD SITES and NYIT CGL as I recall. Circa 1974 to 1978. They were 19 inch RETMA racks. Took three to get decent RGB. 8 bits per pixel per FB. On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS wrote: > I am confused on the history of the frame buffer device. > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by > Martin Schaller and Geert Uytterhoeven (and some input from Fabrice > Bellard?). > > However, it would seem at first glance that early SunOS also had a frame > buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature > (a character device that could be mmap’ed to give access to the hardware > frame buffer, and ioctl’s to probe and configure the hardware). Is that > correct, or were these entirely different in nature? > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon Mar 6 04:52:02 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 5 Mar 2023 13:52:02 -0500 (EST) Subject: [TUHS] Origins of the frame buffer device Message-ID: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> > From: Kenneth Goodwin > The first frame buffers from Evans and Sutherland were at University of > Utah, DOD SITES and NYIT CGL as I recall. > Circa 1974 to 1978. Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to PDP-10's; '74-'78 sounds like an interim period.) Noel From robpike at gmail.com Mon Mar 6 06:43:48 2023 From: robpike at gmail.com (Rob Pike) Date: Mon, 6 Mar 2023 07:43:48 +1100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> References: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> Message-ID: There was a Three Rivers Graphic Wonder (a vector display) on the University of Toronto PDP-11/45 in 1975, maybe 1974. There wasn't a frame buffer until Dave Tennenhouse built one around 1978 - not sure of that date, maybe a little later . 256x256, 8 bits per pixel, or 65kilobytes, the full data address space of the PDP-11. -rob On Mon, Mar 6, 2023 at 5:52 AM Noel Chiappa wrote: > > From: Kenneth Goodwin > > > The first frame buffers from Evans and Sutherland were at University > of > > Utah, DOD SITES and NYIT CGL as I recall. > > Circa 1974 to 1978. > > Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to > PDP-10's; '74-'78 sounds like an interim period.) > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Mon Mar 6 18:14:27 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Mar 2023 03:14:27 -0500 (EST) Subject: [TUHS] Unix v7 icheck dup problem Message-ID: <20230306081427.4F81A18C083@mercury.lcs.mit.edu> > I'll turn this into a 'Fixing damaged V5/V6 file systems' article on > the CHWiki. Here'a a first crack at it: https://gunkies.org/wiki/Repairing_early_UNIX_file_systems Any suggestions for improvements/additions will be gratefully received! I've also been amusing myself trying to figure out who wrote: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c and how it got to MIT - which might give us a clue as to who wrote it. (It's clearly a distant ancestor to 'fsck'.) The fact that we've lost Ted Kowalski is really hindering, alas. Interestingly, Dale DeJager, head of the CB-UNIX group, earlier remembered Hal Pierson working on a file system checker early on: "Hal also implemented the first file system check routine that was written in C. It replaced an .. assembler version from research" but it's not clear if the thing Hal wrote, mentioned there, has any relationship with the 'check' of V5: https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/check.c Maybe one of the Labs old-timers here remembers where the V5 thing came from? (I.e. did Ken or Dennis write it, or did it come from Columbus?) If you do, it would be a big help! Noel From tuhs at tuhs.org Mon Mar 6 18:51:50 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 6 Mar 2023 09:51:50 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: Message-ID: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Thanks for this. My question was unclear: I wasn't thinking of the hardware, but of the software abstraction, i.e. the device files living in /dev I’ve now read through SunOS man pages and it would seem that the /dev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite the same though, as initially it seems to have been tied to the kernel part of the SunWindows software. My understanding of the latter is still limited though. The later Linux usage is designed around mmap() and I am not sure when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, but was not implemented at that time). Maybe at the time of the Sun-1 and Sun-2 it worked differently. The frame buffer hardware is exposed differently in Plan9. Here there are device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are not designed around mmap(), which does not exist on Plan9 by design. It later develops into the /dev/draw/... files. However, my understanding of graphics in Plan9 is also still limited. All in all, finding a conceptually clean but still performant way to expose the frame buffer (and acceleration) hardware seems to have been a hard problem. Arguably it still is. > On 5 Mar 2023, at 19:25, Kenneth Goodwin wrote: > > The first frame buffers from Evans and Sutherland were at University of Utah, DOD SITES and NYIT CGL as I recall. > > Circa 1974 to 1978. > > They were 19 inch RETMA racks. > Took three to get decent RGB. > > 8 bits per pixel per FB. > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS wrote: > I am confused on the history of the frame buffer device. > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bellard?). > > However, it would seem at first glance that early SunOS also had a frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature (a character device that could be mmap’ed to give access to the hardware frame buffer, and ioctl’s to probe and configure the hardware). Is that correct, or were these entirely different in nature? > > Paul > From robpike at gmail.com Mon Mar 6 18:57:35 2023 From: robpike at gmail.com (Rob Pike) Date: Mon, 6 Mar 2023 19:57:35 +1100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: I would think you have read Sutherland's "wheel of reincarnation" paper, but if you haven't, please do. What fascinates me today is that it seems for about a decade now the bearings on that wheel have rusted solid, and no one seems interested in lubricating them to get it going again. -rob On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS wrote: > Thanks for this. > > My question was unclear: I wasn't thinking of the hardware, but of the > software abstraction, i.e. the device files living in /dev > > I’ve now read through SunOS man pages and it would seem that the /dev/fb > file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite > the same though, as initially it seems to have been tied to the kernel part > of the SunWindows software. My understanding of the latter is still limited > though. The later Linux usage is designed around mmap() and I am not sure > when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, > but was not implemented at that time). Maybe at the time of the Sun-1 and > Sun-2 it worked differently. > > The frame buffer hardware is exposed differently in Plan9. Here there are > device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are > not designed around mmap(), which does not exist on Plan9 by design. It > later develops into the /dev/draw/... files. However, my understanding of > graphics in Plan9 is also still limited. > > All in all, finding a conceptually clean but still performant way to > expose the frame buffer (and acceleration) hardware seems to have been a > hard problem. Arguably it still is. > > > > > On 5 Mar 2023, at 19:25, Kenneth Goodwin > wrote: > > > > The first frame buffers from Evans and Sutherland were at University of > Utah, DOD SITES and NYIT CGL as I recall. > > > > Circa 1974 to 1978. > > > > They were 19 inch RETMA racks. > > Took three to get decent RGB. > > > > 8 bits per pixel per FB. > > > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS > wrote: > > I am confused on the history of the frame buffer device. > > > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by > Martin Schaller and Geert Uytterhoeven (and some input from Fabrice > Bellard?). > > > > However, it would seem at first glance that early SunOS also had a frame > buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature > (a character device that could be mmap’ed to give access to the hardware > frame buffer, and ioctl’s to probe and configure the hardware). Is that > correct, or were these entirely different in nature? > > > > Paul > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Mon Mar 6 18:58:54 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 6 Mar 2023 19:58:54 +1100 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: <20230306081427.4F81A18C083@mercury.lcs.mit.edu> References: <20230306081427.4F81A18C083@mercury.lcs.mit.edu> Message-ID: On Mon, Mar 06, 2023 at 03:14:27AM -0500, Noel Chiappa wrote: > > I've also been amusing myself trying to figure out who wrote: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c According to Guy Harris in https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/4mcL76lKbmMJ 'they had to replace "icheck" and "dcheck" with a new program which would do most of the dirty work of file system repair for them - Hal wrote one called "fcheck", which cleaned V6 file systems, and which appeared in source-code form on the PWB/UNIX 1.0 distribution tape. Unfortunately, PWB/UNIX 1.0 modified the V6 file system so that it didn't support "huge" files, and the eighth indirect pointer pointed directly to a block as the other seven did, so the "fcheck" there wouldn't fix a vanilla PWB/UNIX file system, but it worked just fine on a vanilla V6 FS.' From jsg at jsg.id.au Mon Mar 6 20:43:38 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Mon, 6 Mar 2023 21:43:38 +1100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> Message-ID: A 256x256 frame buffer at the University of Toronto is mentioned in Ronald M. Baecker Interactive graphics as a vehicle for the enhancement of human creativity Proceedings of the 5th Canadian Man-Computer Communications Conference: Calgary, Alberta, Canada, 26 - 27 May 1977 https://graphicsinterface.org/wp-content/uploads/cmccc1977-10.pdf https://graphicsinterface.org/proceedings/cmccc1977/cmccc1977-10/ USA/Canada Visit, August 1977 by Bob Hopgood http://www.chilton-computing.org.uk/acd/literature/reports/p002.htm some discussion on early frame buffers in Ronald Baecker Digital video display systems and dynamic graphics ACM SIGGRAPH August 1979 https://dl.acm.org/doi/pdf/10.1145/965103.807424 https://dl.acm.org/doi/10.1145/965103.807424 On Mon, Mar 06, 2023 at 07:43:48AM +1100, Rob Pike wrote: > There was a Three Rivers Graphic Wonder (a vector display) on the > University of Toronto PDP-11/45 in 1975, maybe 1974. There wasn't a frame > buffer until Dave Tennenhouse built one around 1978 - not sure of that > date, maybe a little later > . > 256x256, 8 bits per pixel, or 65kilobytes, the full data address space of > the PDP-11. > > -rob > > > On Mon, Mar 6, 2023 at 5:52 AM Noel Chiappa wrote: > > > > From: Kenneth Goodwin > > > > > The first frame buffers from Evans and Sutherland were at University > > of > > > Utah, DOD SITES and NYIT CGL as I recall. > > > Circa 1974 to 1978. > > > > Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to > > PDP-10's; '74-'78 sounds like an interim period.) > > > > Noel > > > > From henry.r.bent at gmail.com Mon Mar 6 21:09:22 2023 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 6 Mar 2023 06:09:22 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: The paper Rob refers to is https://dl.acm.org/doi/10.1145/363347.363368 -Henry On Mon, 6 Mar 2023 at 03:57, Rob Pike wrote: > I would think you have read Sutherland's "wheel of reincarnation" paper, > but if you haven't, please do. What fascinates me today is that it seems > for about a decade now the bearings on that wheel have rusted solid, and no > one seems interested in lubricating them to get it going again. > > -rob > > > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS > wrote: > >> Thanks for this. >> >> My question was unclear: I wasn't thinking of the hardware, but of the >> software abstraction, i.e. the device files living in /dev >> >> I’ve now read through SunOS man pages and it would seem that the /dev/fb >> file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite >> the same though, as initially it seems to have been tied to the kernel part >> of the SunWindows software. My understanding of the latter is still limited >> though. The later Linux usage is designed around mmap() and I am not sure >> when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, >> but was not implemented at that time). Maybe at the time of the Sun-1 and >> Sun-2 it worked differently. >> >> The frame buffer hardware is exposed differently in Plan9. Here there are >> device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are >> not designed around mmap(), which does not exist on Plan9 by design. It >> later develops into the /dev/draw/... files. However, my understanding of >> graphics in Plan9 is also still limited. >> >> All in all, finding a conceptually clean but still performant way to >> expose the frame buffer (and acceleration) hardware seems to have been a >> hard problem. Arguably it still is. >> >> >> >> > On 5 Mar 2023, at 19:25, Kenneth Goodwin >> wrote: >> > >> > The first frame buffers from Evans and Sutherland were at University of >> Utah, DOD SITES and NYIT CGL as I recall. >> > >> > Circa 1974 to 1978. >> > >> > They were 19 inch RETMA racks. >> > Took three to get decent RGB. >> > >> > 8 bits per pixel per FB. >> > >> > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS >> wrote: >> > I am confused on the history of the frame buffer device. >> > >> > On Linux, it seems that /dev/fbdev originated in 1999 from work done >> by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice >> Bellard?). >> > >> > However, it would seem at first glance that early SunOS also had a >> frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in >> nature (a character device that could be mmap’ed to give access to the >> hardware frame buffer, and ioctl’s to probe and configure the hardware). Is >> that correct, or were these entirely different in nature? >> > >> > Paul >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Tue Mar 7 02:02:14 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Mon, 6 Mar 2023 11:02:14 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: <20230306160214.GA959362@mit.edu> On Mon, Mar 06, 2023 at 06:09:22AM -0500, Henry Bent wrote: > The paper Rob refers to is https://dl.acm.org/doi/10.1145/363347.363368 A PDF of the paper is available here: http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-design-of-display-processors.pdf From tuhs at tuhs.org Tue Mar 7 08:47:29 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Mon, 6 Mar 2023 23:47:29 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> I had read that paper and I have just read it again. I am not sure I understand the point you are making. My take away from the paper -- reading beyond its 1969 vista -- was that it made two points: 1. We put ever more compute power behind our displays 2. The compute power tends to grow by first adding special purpose hardware for some core tasks, that then develops into a generic processor and the process repeats From this one could imply a third point: we always tend to want displays that are at the high end of what is economically feasible, even if that requires an architectural wart. More narrowly it concludes that the compute power behind the display is better organised as being general to the system than to be dedicated to the display. The wikipedia page with a history of GPU’s since 1970 (https://en.wikipedia.org/wiki/Graphics_processing_unit) shows the wheel rolling decade after decade. However, the above observations are probably not what you wanted to direct my attention to ... > On 6 Mar 2023, at 09:57, Rob Pike wrote: > > I would think you have read Sutherland's "wheel of reincarnation" paper, but if you haven't, please do. What fascinates me today is that it seems for about a decade now the bearings on that wheel have rusted solid, and no one seems interested in lubricating them to get it going again. > > -rob > > > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS wrote: > Thanks for this. > > My question was unclear: I wasn't thinking of the hardware, but of the software abstraction, i.e. the device files living in /dev > > I’ve now read through SunOS man pages and it would seem that the /dev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite the same though, as initially it seems to have been tied to the kernel part of the SunWindows software. My understanding of the latter is still limited though. The later Linux usage is designed around mmap() and I am not sure when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, but was not implemented at that time). Maybe at the time of the Sun-1 and Sun-2 it worked differently. > > The frame buffer hardware is exposed differently in Plan9. Here there are device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are not designed around mmap(), which does not exist on Plan9 by design. It later develops into the /dev/draw/... files. However, my understanding of graphics in Plan9 is also still limited. > > All in all, finding a conceptually clean but still performant way to expose the frame buffer (and acceleration) hardware seems to have been a hard problem. Arguably it still is. > > > > > On 5 Mar 2023, at 19:25, Kenneth Goodwin wrote: > > > > The first frame buffers from Evans and Sutherland were at University of Utah, DOD SITES and NYIT CGL as I recall. > > > > Circa 1974 to 1978. > > > > They were 19 inch RETMA racks. > > Took three to get decent RGB. > > > > 8 bits per pixel per FB. > > > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS wrote: > > I am confused on the history of the frame buffer device. > > > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bellard?). > > > > However, it would seem at first glance that early SunOS also had a frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature (a character device that could be mmap’ed to give access to the hardware frame buffer, and ioctl’s to probe and configure the hardware). Is that correct, or were these entirely different in nature? > > > > Paul > > > From robpike at gmail.com Tue Mar 7 09:10:11 2023 From: robpike at gmail.com (Rob Pike) Date: Tue, 7 Mar 2023 10:10:11 +1100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: Through the 1970s and 1980s, there was a continuous invention in how graphics, computing, and software interacted. With the dominance of the PC and the VGA card, we now have a largely fixed architecture for graphics in personal computers. There is some playing around with the software model, but basically we have a powerful, privately managed external "card" that does the graphics, and we talk to it with one particular mechanism. During my work on Plan 9, it got harder over time to try new things because the list of ways to talk to the card was shrinking, and other than the blessed ones, slower and slower. For example, a shared-memory frame buffer, which I interpret as the mechanism that started this conversation, is now a historical artifact. Back when, it was a thing to play with. As observed by many others, there is far more grunt today in the graphics card than the CPU, which in Sutherland's timeline would mean it was time to push that power back to the CPU. But no. Not a value judgement, just an observation. The wheel has stopped turning, mostly. -rob On Tue, Mar 7, 2023 at 9:47 AM Paul Ruizendaal wrote: > I had read that paper and I have just read it again. I am not sure I > understand the point you are making. > > My take away from the paper -- reading beyond its 1969 vista -- was that > it made two points: > > 1. We put ever more compute power behind our displays > > 2. The compute power tends to grow by first adding special purpose > hardware for some core tasks, that then develops into a generic processor > and the process repeats > > From this one could imply a third point: we always tend to want displays > that are at the high end of what is economically feasible, even if that > requires an architectural wart. > > More narrowly it concludes that the compute power behind the display is > better organised as being general to the system than to be dedicated to the > display. > > The wikipedia page with a history of GPU’s since 1970 ( > https://en.wikipedia.org/wiki/Graphics_processing_unit) shows the wheel > rolling decade after decade. > > However, the above observations are probably not what you wanted to direct > my attention to ... > > > > > On 6 Mar 2023, at 09:57, Rob Pike wrote: > > > > I would think you have read Sutherland's "wheel of reincarnation" paper, > but if you haven't, please do. What fascinates me today is that it seems > for about a decade now the bearings on that wheel have rusted solid, and no > one seems interested in lubricating them to get it going again. > > > > -rob > > > > > > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS > wrote: > > Thanks for this. > > > > My question was unclear: I wasn't thinking of the hardware, but of the > software abstraction, i.e. the device files living in /dev > > > > I’ve now read through SunOS man pages and it would seem that the /dev/fb > file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite > the same though, as initially it seems to have been tied to the kernel part > of the SunWindows software. My understanding of the latter is still limited > though. The later Linux usage is designed around mmap() and I am not sure > when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, > but was not implemented at that time). Maybe at the time of the Sun-1 and > Sun-2 it worked differently. > > > > The frame buffer hardware is exposed differently in Plan9. Here there > are device files (initially /dev/bit/screen and /dev/bit/bitblt) but these > are not designed around mmap(), which does not exist on Plan9 by design. It > later develops into the /dev/draw/... files. However, my understanding of > graphics in Plan9 is also still limited. > > > > All in all, finding a conceptually clean but still performant way to > expose the frame buffer (and acceleration) hardware seems to have been a > hard problem. Arguably it still is. > > > > > > > > > On 5 Mar 2023, at 19:25, Kenneth Goodwin > wrote: > > > > > > The first frame buffers from Evans and Sutherland were at University > of Utah, DOD SITES and NYIT CGL as I recall. > > > > > > Circa 1974 to 1978. > > > > > > They were 19 inch RETMA racks. > > > Took three to get decent RGB. > > > > > > 8 bits per pixel per FB. > > > > > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS > wrote: > > > I am confused on the history of the frame buffer device. > > > > > > On Linux, it seems that /dev/fbdev originated in 1999 from work done > by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice > Bellard?). > > > > > > However, it would seem at first glance that early SunOS also had a > frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in > nature (a character device that could be mmap’ed to give access to the > hardware frame buffer, and ioctl’s to probe and configure the hardware). Is > that correct, or were these entirely different in nature? > > > > > > Paul > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Tue Mar 7 09:16:19 2023 From: norman at oclsc.org (Norman Wilson) Date: Mon, 6 Mar 2023 18:16:19 -0500 (EST) Subject: [TUHS] Origins of the frame buffer device Message-ID: <8BD57BAB138946830AF560E17376A63B.for-standards-violators@oclsc.org> Rob Pike: As observed by many others, there is far more grunt today in the graphics card than the CPU, which in Sutherland's timeline would mean it was time to push that power back to the CPU. But no. ==== Indeed. Instead we are evolving ways to use graphics cards to do general-purpose computation, and assembling systems that have many graphics cards not to do graphics but to crunch numbers. My current responsibilities include running a small stable of those, because certain computer-science courses consider it important that students learn to use them. I sometimes wonder when someone will think of adding secondary storage and memory management and network interfaces to GPUs, and push to run Windows on them. Norman Wilson Toronto ON From tuhs at tuhs.org Tue Mar 7 09:20:22 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Mon, 06 Mar 2023 23:20:22 +0000 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: <4nTxKwDpHfGp_UnVOUXR9bqHYa4KaRjXKfM_-KyDU-AQFFwNnN8vcsq85l8_bVWwyzKP8dcO6kUikL0t4LXlrGDDrrSVgZrcCTnpEQGfaFA=@protonmail.com> I don't know if this is what Rob was getting at, but I've also been thinking about the relative homogenization of the display technologies field in recent years. Massively-parallel vector engines calculating vertices, geometry, tesselation, and pixel color after rasterization are pretty much the only game in town these days. Granted, we're finding new and exciting ways to *use* the data these technologies generate, but put pixels on a surface inside a VR headset, on a flat-panel monitor in front of my face, or on a little bundle of plastic, glass, and silicon in my pocket, and the general behavior is still the same: I'm going to give the card a bunch of vertices and data, it's going to then convert that data into a bunch of parallel jobs that eventually land as individual pixels on my screen. One area I am actually interested to see how it develops though is hologram-type stuff. VR is one thing, you're still creating what is ultimately a 2D image composed of individual samples (pixels) that capture a sampling of the state of a hypothetical 3D environment maintained in your application. With AR, you're a little closer, basing depth on the physical environment around you, but I wouldn't be surprised if that same depth is still just put in a depth buffer, pixels are masked accordingly, and the application pastes a 2D rasterized image of the content over the camera display every 1/60th of a second (or whatever absurd refresh rates we're using now.) However, a hologram must maintain the concept of 3D space, at least well enough that if multiple objects were projected, they wouldn't simply disappear from view because one was "behind" another from just one viewpoint, the way the painters algorithm for most depth culling in 3D stuff works. Although I guess I just answered my own quandary, that one would just disable depth culling and display the results before the rasterizer, but still, there's implications beyond just sample this 3D "scene" into a 2D matrix of pixels. Another area that I wish there was more development in, but it's probably too late, is 2D acceleration ala 80's arcade hardware. Galaxian is allegedly the first, at least as held in lore, to provide a chip in which the scrolling background was based on a constantly updating coordinate into a scrollplane and the individual moving graphics were implemented as hardware sprites. I haven't researched much further back on scrollplane 2D acceleration, but I personally see it as still a very valid and useful technology, one that has been overlooked in the wake of 3D graphics and GPUs. Given that many, many computer users don't really tax the 3D capabilities of their machine, they'd probably benefit from the lower costs and complexity involved with accelerating the movement of windows and visual content via this kind of hardware instead of GPUs based largely on vertex arrays. Granted, I don't know how a modern windowing system leverages GPU technology to provide for window acceleration, but if it's using vertex arrays and that sort of thing, that's potentially a lot of extra processing of flat geometric stuff into vertices to feed a GPU, then in the GPU back into pixels, when the 2D graphics already exist and could easily be moved around by coordinate using a scrolling/spriting chip. Granted the "thesis" on my thoughts on 2D scrolling vs GPU efficiency is half-baked, it's something I think about every so often. Anywho, not sure if that's what you meant by things seeming to have rusted a bit, but that's my general line of thought when the state of graphics/display technology comes up. Anything that is just another variation on putting a buffer of vertex properties on a 2k+-core vector engine to spit out a bunch of pixels isn't really pushing into new territory. I don't care how many more triangles it can do nor how many of those pixels there are, and certainly not how close those pixels are to my eyeballs, it's still the same technology just keeping up with Moore's Law. That all said, GPGPU on the other hand is such an interesting field and I hope to learn more in the coming years and start working compute shading into projects in earnest... - Matt G. ------- Original Message ------- On Monday, March 6th, 2023 at 2:47 PM, Paul Ruizendaal via TUHS wrote: > I had read that paper and I have just read it again. I am not sure I understand the point you are making. > > My take away from the paper -- reading beyond its 1969 vista -- was that it made two points: > > 1. We put ever more compute power behind our displays > > 2. The compute power tends to grow by first adding special purpose hardware for some core tasks, that then develops into a generic processor and the process repeats > > From this one could imply a third point: we always tend to want displays that are at the high end of what is economically feasible, even if that requires an architectural wart. > > More narrowly it concludes that the compute power behind the display is better organised as being general to the system than to be dedicated to the display. > > The wikipedia page with a history of GPU’s since 1970 (https://en.wikipedia.org/wiki/Graphics_processing_unit) shows the wheel rolling decade after decade. > > However, the above observations are probably not what you wanted to direct my attention to ... > > > > On 6 Mar 2023, at 09:57, Rob Pike robpike at gmail.com wrote: > > > > I would think you have read Sutherland's "wheel of reincarnation" paper, but if you haven't, please do. What fascinates me today is that it seems for about a decade now the bearings on that wheel have rusted solid, and no one seems interested in lubricating them to get it going again. > > > > -rob > > > > On Mon, Mar 6, 2023 at 7:52 PM Paul Ruizendaal via TUHS tuhs at tuhs.org wrote: > > Thanks for this. > > > > My question was unclear: I wasn't thinking of the hardware, but of the software abstraction, i.e. the device files living in /dev > > > > I’ve now read through SunOS man pages and it would seem that the /dev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite the same though, as initially it seems to have been tied to the kernel part of the SunWindows software. My understanding of the latter is still limited though. The later Linux usage is designed around mmap() and I am not sure when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, but was not implemented at that time). Maybe at the time of the Sun-1 and Sun-2 it worked differently. > > > > The frame buffer hardware is exposed differently in Plan9. Here there are device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are not designed around mmap(), which does not exist on Plan9 by design. It later develops into the /dev/draw/... files. However, my understanding of graphics in Plan9 is also still limited. > > > > All in all, finding a conceptually clean but still performant way to expose the frame buffer (and acceleration) hardware seems to have been a hard problem. Arguably it still is. > > > > > On 5 Mar 2023, at 19:25, Kenneth Goodwin kennethgoodwin56 at gmail.com wrote: > > > > > > The first frame buffers from Evans and Sutherland were at University of Utah, DOD SITES and NYIT CGL as I recall. > > > > > > Circa 1974 to 1978. > > > > > > They were 19 inch RETMA racks. > > > Took three to get decent RGB. > > > > > > 8 bits per pixel per FB. > > > > > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS tuhs at tuhs.org wrote: > > > I am confused on the history of the frame buffer device. > > > > > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by Martin Schaller and Geert Uytterhoeven (and some input from Fabrice Bellard?). > > > > > > However, it would seem at first glance that early SunOS also had a frame buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature (a character device that could be mmap’ed to give access to the hardware frame buffer, and ioctl’s to probe and configure the hardware). Is that correct, or were these entirely different in nature? > > > > > > Paul From lm at mcvoy.com Tue Mar 7 09:24:29 2023 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 6 Mar 2023 15:24:29 -0800 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <8BD57BAB138946830AF560E17376A63B.for-standards-violators@oclsc.org> References: <8BD57BAB138946830AF560E17376A63B.for-standards-violators@oclsc.org> Message-ID: <20230306232429.GL5398@mcvoy.com> On Mon, Mar 06, 2023 at 06:16:19PM -0500, Norman Wilson wrote: > Rob Pike: > > As observed by many others, there is far more grunt today in the graphics > card than the CPU, which in Sutherland's timeline would mean it was time to > push that power back to the CPU. But no. > > ==== > > Indeed. Instead we are evolving ways to use graphics cards to > do general-purpose computation, and assembling systems that have > many graphics cards not to do graphics but to crunch numbers. > > My current responsibilities include running a small stable of > those, because certain computer-science courses consider it > important that students learn to use them. > > I sometimes wonder when someone will think of adding secondary > storage and memory management and network interfaces to GPUs, > and push to run Windows on them. It's funny because back in my day those GPUs would have been called vector processors, at least I think they would. It seems like somewhere along the way, vector processors became a dirty word but GPUS are fine. Color me confused. About the only reason I can see to keep things divided between the CPU and the GPU is battery power, or power consumption in general. From what little I know, it seems like GPUs are pretty power thirsty so maybe they keep them as optional devices so people who don't need them don't pay the power budget. But even that seems suspect, I would think they could put some logic in there that just doesn't feed power to the GPU if you aren't using it but maybe that's harder than I think. If it's not about power then I don't get it, there are tons of transistors waiting to be used, they could easily plunk down a bunch of GPUs on the same die so why not? Maybe the dev timelines are completely different (I suspect not, I'm just grabbing at straws). From ken.unix.guy at gmail.com Tue Mar 7 10:32:24 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Mon, 6 Mar 2023 19:32:24 -0500 Subject: [TUHS] Nice article on porting Unix Message-ID: I have not seen this before. Nice article on porting Unix includes an 8086 CPU. Ken -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: UNIX_Operating_System_Porting_Experiences.pdf Type: application/pdf Size: 55990 bytes Desc: not available URL: From kennethgoodwin56 at gmail.com Tue Mar 7 11:21:11 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 6 Mar 2023 20:21:11 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> References: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> Message-ID: Pdp 11/04 as a device controller. As I recall, they used a Dec parallel interface to connect the frame buffer controller to the host systems. Tom Duff would be the subject matter expert on the actual hardware. (If you can get his attention and drag him out of retirement for a bit.) This was pre networks. There was a second company that entered the market a few years later. The name is unfortunately in external offline storage... We have come a LONG WAY since those days.. On Sun, Mar 5, 2023, 1:52 PM Noel Chiappa wrote: > > From: Kenneth Goodwin > > > The first frame buffers from Evans and Sutherland were at University > of > > Utah, DOD SITES and NYIT CGL as I recall. > > Circa 1974 to 1978. > > Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to > PDP-10's; '74-'78 sounds like an interim period.) > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Tue Mar 7 11:24:54 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 6 Mar 2023 20:24:54 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: As I recall the device file names on our systems at NYIT CGL were simply /dev/fb0 /dev/fb1 Etc. There might have been raw device as well as well as a control channel device to the pdp 11/04 One path to the frame buffer memory and a separate path to the 11/04. But TD would remember better than I. On Mon, Mar 6, 2023, 3:52 AM Paul Ruizendaal via TUHS wrote: > Thanks for this. > > My question was unclear: I wasn't thinking of the hardware, but of the > software abstraction, i.e. the device files living in /dev > > I’ve now read through SunOS man pages and it would seem that the /dev/fb > file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite > the same though, as initially it seems to have been tied to the kernel part > of the SunWindows software. My understanding of the latter is still limited > though. The later Linux usage is designed around mmap() and I am not sure > when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, > but was not implemented at that time). Maybe at the time of the Sun-1 and > Sun-2 it worked differently. > > The frame buffer hardware is exposed differently in Plan9. Here there are > device files (initially /dev/bit/screen and /dev/bit/bitblt) but these are > not designed around mmap(), which does not exist on Plan9 by design. It > later develops into the /dev/draw/... files. However, my understanding of > graphics in Plan9 is also still limited. > > All in all, finding a conceptually clean but still performant way to > expose the frame buffer (and acceleration) hardware seems to have been a > hard problem. Arguably it still is. > > > > > On 5 Mar 2023, at 19:25, Kenneth Goodwin > wrote: > > > > The first frame buffers from Evans and Sutherland were at University of > Utah, DOD SITES and NYIT CGL as I recall. > > > > Circa 1974 to 1978. > > > > They were 19 inch RETMA racks. > > Took three to get decent RGB. > > > > 8 bits per pixel per FB. > > > > On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS > wrote: > > I am confused on the history of the frame buffer device. > > > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by > Martin Schaller and Geert Uytterhoeven (and some input from Fabrice > Bellard?). > > > > However, it would seem at first glance that early SunOS also had a frame > buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature > (a character device that could be mmap’ed to give access to the hardware > frame buffer, and ioctl’s to probe and configure the hardware). Is that > correct, or were these entirely different in nature? > > > > Paul > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Tue Mar 7 11:54:16 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 6 Mar 2023 20:54:16 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: Message-ID: The NYIT setup had multiple Barcovision color CRT monitors connected to the frame buffers via multiple coax video cables I presume through some sort of video switch hardware. 8 bits per pixel. (Unsigned char) The numbers stored in the pixel frame buffer memory were used to index a color map that held the actual RGB or HSV values for the actual color. Cycling the color map array values was a cheap animation trick that Alex Schure had a particular fondness for. On Sun, Mar 5, 2023, 10:02 AM Paul Ruizendaal via TUHS wrote: > I am confused on the history of the frame buffer device. > > On Linux, it seems that /dev/fbdev originated in 1999 from work done by > Martin Schaller and Geert Uytterhoeven (and some input from Fabrice > Bellard?). > > However, it would seem at first glance that early SunOS also had a frame > buffer device (/dev/cgoneX. /dev/bwoneX, etc.) which was similar in nature > (a character device that could be mmap’ed to give access to the hardware > frame buffer, and ioctl’s to probe and configure the hardware). Is that > correct, or were these entirely different in nature? > > Paul > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kennethgoodwin56 at gmail.com Tue Mar 7 12:05:13 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Mon, 6 Mar 2023 21:05:13 -0500 Subject: [TUHS] Unix v7 icheck dup problem In-Reply-To: References: <20230306081427.4F81A18C083@mercury.lcs.mit.edu> Message-ID: Anyone remember PFSCK, aka parallel fsck that fired up multiple parallel fsck instances, one per filesystem and used bidirectional pipes to pass commands from the operator to each individual fsck stream. Cut boot times down quite a bit on healthy systems. I believe the filesystem MOUNT table file on ROOT had fields related to controlling PFSCK behavior I remember hacking it for some reason related to performance, But GOK why...... On Mon, Mar 6, 2023, 3:59 AM Jonathan Gray wrote: > On Mon, Mar 06, 2023 at 03:14:27AM -0500, Noel Chiappa wrote: > > > > I've also been amusing myself trying to figure out who wrote: > > > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c > > According to Guy Harris in > https://groups.google.com/g/net.unix/c/-H9x36DMOBQ/m/4mcL76lKbmMJ > > 'they had to replace "icheck" and "dcheck" with a new program which > would do most of the dirty work of file system repair for them - > Hal wrote one called "fcheck", which cleaned V6 file systems, and > which appeared in source-code form on the PWB/UNIX 1.0 distribution > tape. Unfortunately, PWB/UNIX 1.0 modified the V6 file system so > that it didn't support "huge" files, and the eighth indirect pointer > pointed directly to a block as the other seven did, so the "fcheck" > there wouldn't fix a vanilla PWB/UNIX file system, but it worked > just fine on a vanilla V6 FS.' > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Mar 7 14:03:11 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Mar 2023 21:03:11 -0700 Subject: [TUHS] An odd disclaimer on the Lions Commentary Message-ID: Recently, I stumbled upon a photo of the Lions Commentary that didn't have a bell disclaimer, but a Wollongong Group disclaimer on it. Not Wollongong University, but The Wollongong Group (a company I coincidentally used to work for). I wish I'd saved the images, because now I can't find it. Has anybody else seen this? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.perrine+tuhs at gmail.com Tue Mar 7 14:40:45 2023 From: tom.perrine+tuhs at gmail.com (Tom Perrine) Date: Mon, 6 Mar 2023 20:40:45 -0800 Subject: [TUHS] An odd disclaimer on the Lions Commentary In-Reply-To: References: Message-ID: I have a copy of Lyons from my first job ca 1982. I'm guessing that they aren't exactly rare? I'll dig it out this from storage to see which disclaimer it has. --tep On Mon, Mar 6, 2023 at 8:03 PM Warner Losh wrote: > Recently, I stumbled upon a photo of the Lions Commentary that didn't have > a bell disclaimer, but a Wollongong Group disclaimer on it. Not Wollongong > University, but The Wollongong Group (a company I coincidentally used to > work for). I wish I'd saved the images, because now I can't find it. Has > anybody else seen this? > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Tue Mar 7 15:26:06 2023 From: imp at bsdimp.com (Warner Losh) Date: Mon, 6 Mar 2023 22:26:06 -0700 Subject: [TUHS] An odd disclaimer on the Lions Commentary In-Reply-To: References: Message-ID: It was on Facebook... internet old farts club On Mon, Mar 6, 2023, 9:03 PM Warner Losh wrote: > Recently, I stumbled upon a photo of the Lions Commentary that didn't have > a bell disclaimer, but a Wollongong Group disclaimer on it. Not Wollongong > University, but The Wollongong Group (a company I coincidentally used to > work for). I wish I'd saved the images, because now I can't find it. Has > anybody else seen this? > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FB_IMG_1678166605296.jpg Type: image/jpeg Size: 111780 bytes Desc: not available URL: From arnold at skeeve.com Tue Mar 7 22:08:21 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 07 Mar 2023 05:08:21 -0700 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230306232429.GL5398@mcvoy.com> References: <8BD57BAB138946830AF560E17376A63B.for-standards-violators@oclsc.org> <20230306232429.GL5398@mcvoy.com> Message-ID: <202303071208.327C8Lgw026058@freefriends.org> Larry McVoy wrote: > It's funny because back in my day those GPUs would have been called vector > processors, at least I think they would. It seems like somewhere along > the way, vector processors became a dirty word but GPUS are fine. > > Color me confused. I think vector processing is used for things like for (i = 0; i < SOME_CONSTANT; i++) a[i] = b[i] + c[i] that is, vectoring general purpose code. GPUS are pretty specialized SIMD machines which sort of happen to be useful for certain kinds of parallelizable general computations, like password cracking. Today there are both standardized and proprietary ways of programming them. > About the only reason I can see to keep things divided between the CPU > and the GPU is battery power, or power consumption in general. From > what little I know, it seems like GPUs are pretty power thirsty so > maybe they keep them as optional devices so people who don't need them > don't pay the power budget. > > But even that seems suspect, I would think they could put some logic > in there that just doesn't feed power to the GPU if you aren't using > it but maybe that's harder than I think. You're on target, not just in the GPU world but also in the CPU world. Modern Intel CPUS have a lot of circuits for turning power consumption up and down dynamically. Modern-day CPU development is much harder than we software types generally realize. I worked at Intel as a software guy (bad juju there, let me tell you!) and learned a lot about it, from the outside. For a given x86 microarchitecture, from planning until it's in the box in the store is like a 5+ year journey. These days maybe even more, as I left Intel 7.5 years ago. Arnold From tytso at mit.edu Wed Mar 8 02:42:14 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Tue, 7 Mar 2023 11:42:14 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230306232429.GL5398@mcvoy.com> References: <8BD57BAB138946830AF560E17376A63B.for-standards-violators@oclsc.org> <20230306232429.GL5398@mcvoy.com> Message-ID: <20230307164214.GC960946@mit.edu> (Moving to COFF) On Mon, Mar 06, 2023 at 03:24:29PM -0800, Larry McVoy wrote: > But even that seems suspect, I would think they could put some logic > in there that just doesn't feed power to the GPU if you aren't using > it but maybe that's harder than I think. > > If it's not about power then I don't get it, there are tons of transistors > waiting to be used, they could easily plunk down a bunch of GPUs on the > same die so why not? Maybe the dev timelines are completely different > (I suspect not, I'm just grabbing at straws). Other potential reasons: 1) Moving functionality off-CPU also allows for those devices to have their own specialized video memory that might be faster (SDRAM) or dual-ported (VRAM) without having to add that complexity to the more general system DRAM and/or the CPU's Northbridge. 2) In some cases, having an off-chip co-processor may not need any access to the system memory at well. An example of this is the "bump in the wire" in-line crypto engines (ICE) which is located between the Southbridge and the eMMC/UFS flash storage device. If you are using a Android device, it's likely to have an ICE. The big advantage is that it avoids needing to have a bounce buffer on the write path, where the file system encryption layer has to copy-and-encrypt data from the page cache to a bounce buffer, and then the encrypted block will then get DMA'ed to the storage device. 3) From an architectural perspective, not all use cases need various co-processors, whether it is to doing cryptography, or running some kind of machine-learning module, or image manipulation to simulate bokeh, or create HDR images, etc. While RISC-V does have the concept of instructure set extensions, which can be developed without getting permission from the "owners" of the core CPU ISA (e.g., ARM, Intel, etc.), it's a lot more convenient for someone who doesn't need to bend the knee to ARM, inc. (or their new corporate overloads) or Intel, to simply put that extension outside the core ISA. (More recently, there is an interesting lawsuit about whether it's "allowed" to put a 3rd party co-processor on the same SOC without paying $$$$$ to the corporate overload, which may make this point moot --- although it might cause people to simply switch to another ISA that doesn't have this kind of lawsuit-happy rent-seeking....) In any case, if you don't need to play Quake with 240 frames per second, then there's no point putting the GPU in the core CPU architecture, and it may turn out that the kind of co-processor which is optimized for running ML models is different, and it is often easier to make changes to the programming model for a GPU, compared to making changes to a CPU's ISA. - Ted From gingell at computer.org Wed Mar 8 13:07:13 2023 From: gingell at computer.org (Rob Gingell) Date: Tue, 7 Mar 2023 19:07:13 -0800 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: On 3/6/23 12:51 AM, Paul Ruizendaal via TUHS wrote: > I’ve now read through SunOS man pages and it would seem that the /dev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite the same though, as initially it seems to have been tied to the kernel part of the SunWindows software. /dev/fb was a basic device-independent interface that indirected to the hardware that was actually installed for operations like open(), ioctl(), and mmap(). Through those the window systems figured out what they were actually working with. The (4S) man pages had entries for each of the frame buffers and graphics processors if you're able to find them. Sunview did have some kernel support but /dev/fb and the support of mmap() were more generic and used by the non-kernel parts of the window systems (as well as diagnostics). Sun had quite a collection of frame buffers through the years, including oscillating usage of graphics accelerators that might be viewed as wobbles in the wheel rather than true rotation per Sutherland's paper. (Cultural note: the Computer History Museum published a 2-part oral history with Ivan Sutherland, and its home page currently features the interviews. The first part can be found at https://youtu.be/Bjr7qLeyvlw. Each part is several hours long.) On 3/6/23 12:51 AM, Paul Ruizendaal via TUHS wrote: > The later Linux usage is designed around mmap() and I am not sure when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, but was not implemented at that time). Maybe at the time of the Sun-1 and Sun-2 it worked differently. mmap() was in SunOS starting (I believe) with the BSD-derived SunOS 1.x. Prior to 4.0 it could be used with character devices that supported being mapped into an address space: frame buffers, graphics accelerators, and the bus address spaces of VME or Multibus being possible sources. There might have been others that I'm not recalling now. The implementation had a number of restrictions from the BSD specification. All mappings had to be MAP_SHARED. The caller had to specify (page-aligned) addresses within its data segment as the process address space had the traditional text, data, and stack segments vs. being available as a vector of pages. From lars at nocrew.org Wed Mar 8 15:43:25 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 08 Mar 2023 05:43:25 +0000 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> (Noel Chiappa's message of "Sun, 5 Mar 2023 13:52:02 -0500 (EST)") References: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> Message-ID: <7w7cvr4x36.fsf@junk.nocrew.org> Noel Chiappa wrote: >> The first frame buffers from Evans and Sutherland were at University >> of Utah, DOD SITES and NYIT CGL as I recall. Circa 1974 to 1978. > > Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to > PDP-10's; '74-'78 sounds like an interim period.) The Picture System from 1974 was based on a PDP-11/05. It looks like vector graphics rather than a frame buffer though. http://archive.computerhistory.org/resources/text/Evans_Sutherland/EvansSutherland.3D.1974.102646288.pdf From tuhs at tuhs.org Wed Mar 8 17:26:45 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 08 Mar 2023 07:26:45 +0000 Subject: [TUHS] Fifth Edition Manual Restoration Message-ID: So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: https://gitlab.com/segaloco/v5man There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. - Matt G. From aap at papnet.eu Wed Mar 8 20:02:28 2023 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 8 Mar 2023 11:02:28 +0100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: Message-ID: I've done this a couple of years ago: http://squoze.net/UNIX Cheers, Angelo On 08/03/23, segaloco via TUHS wrote: > So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: > > https://gitlab.com/segaloco/v5man > > There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. > > I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. > > - Matt G. From tuhs at tuhs.org Wed Mar 8 22:51:10 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Wed, 8 Mar 2023 13:51:10 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> Message-ID: <28C479A6-053A-4D95-B6CE-13254FBD8068@planet.nl> > On 8 Mar 2023, at 04:07, Rob Gingell wrote: > > On 3/6/23 12:51 AM, Paul Ruizendaal via TUHS wrote: >> I’ve now read through SunOS man pages and it would seem that the /dev/fb file was indeed similar to /dev/fbdev on Linux 15 years later. Not quite the same though, as initially it seems to have been tied to the kernel part of the SunWindows software. > > /dev/fb was a basic device-independent interface that indirected to the hardware that was actually installed for operations like open(), ioctl(), and mmap(). Through those the window systems figured out what they were actually working with. The (4S) man pages had entries for each of the frame buffers and graphics processors if you're able to find them. > > Sunview did have some kernel support but /dev/fb and the support of mmap() were more generic and used by the non-kernel parts of the window systems (as well as diagnostics). > > Sun had quite a collection of frame buffers through the years, including oscillating usage of graphics accelerators that might be viewed as wobbles in the wheel rather than true rotation per Sutherland's paper. > > (Cultural note: the Computer History Museum published a 2-part oral history with Ivan Sutherland, and its home page currently features the interviews. The first part can be found at https://youtu.be/Bjr7qLeyvlw. Each part is several hours long.) > > On 3/6/23 12:51 AM, Paul Ruizendaal via TUHS wrote: >> The later Linux usage is designed around mmap() and I am not sure when that arrived in SunOS (the mmap call exists in the manpages of 4.2BSD, but was not implemented at that time). Maybe at the time of the Sun-1 and Sun-2 it worked differently. > > mmap() was in SunOS starting (I believe) with the BSD-derived SunOS 1.x. Prior to 4.0 it could be used with character devices that supported being mapped into an address space: frame buffers, graphics accelerators, and the bus address spaces of VME or Multibus being possible sources. There might have been others that I'm not recalling now. > > The implementation had a number of restrictions from the BSD specification. All mappings had to be MAP_SHARED. The caller had to specify (page-aligned) addresses within its data segment as the process address space had the traditional text, data, and stack segments vs. being available as a vector of pages. Thank you for those clarifications. The man pages for SunOS 1.1 (March ’84) are available on Bitsavers and your comments helped me along. Your memory is correct: the man pages for SunOS 1.1 describe it that way, and this description matches with the mmap kernel code in 4.2BSD (it is ifdef'ed out there; I had always assumed it was non-functional, but now it seems to have been a Sun special -- unfortunately there is no matching driver in the 4.2BSD tree). As far as I can tell, in SunOS 1.1 mmap only worked on the frame buffer device. Its mmap implementation mapped out the normal memory pages for a data area and then mapped in the frame buffer location into that area; I suppose this means that the data area of graphics programs contained a large array as a placeholder for this space. With that knowledge it is I think safe to say that SunOS had an mmap’ed frame buffer device file as its access abstraction from its earliest days and that this design did not really change throughout the lifetime of SunOS (it is still there in version 4.1.3). It is then surprising that Linux did not come up with /dev/fbdev until 1999, especially in view of the importance of X to the early Linux developers. Maybe the reason was that the headache of video drivers was delegated to the XFree community. From pnr at planet.nl Wed Mar 8 22:53:21 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 Mar 2023 13:53:21 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: > There is some playing around with the software model, but basically we have a powerful, privately managed external "card" that does the graphics, and we talk to it with one particular mechanism. During my work on Plan 9, it got harder over time to try new things because the list of ways to talk to the card was shrinking, and other than the blessed ones, slower and slower. > > For example, a shared-memory frame buffer, which I interpret as the mechanism that started this conversation, is now a historical artifact. Back when, it was a thing to play with. Ah, now it is clear. This also has a relation to the point about what constitutes a "workstation" and one of the comments was that it needs to have "integrated graphics". What is integrated in this historical context -- is it a shared memory frame buffer, is it a shared CPU, is it physically in the same box or just an integrated user experience? It seems to me that it is not easy to delineate. Consider a Vax connected to a Tek raster scan display, a Vax connected to a Blit, Clem’s Magnolia and a networked Sun-1. Which ones are workstations? If shared memory is the key only Clem’s Magnolia and the Sun-1 qualify. If it is a shared CPU only a standalone Sun-1 qualifies, but its CPU would be heavily taxed when doing graphics, so standalone graphics was maybe not a normal use case. For now my rule of thumb is that it means (in a 1980’s-1990’s context) a high-bandwidth path between the compute side and display side, with enough total combined power to drive both the workload and the display. This is also what is underlying the question about the /dev/fbdev etc. devices. In Unix exposing the screen as a file seems a logical choice, although with challenges on how to make this efficient. SunOS 1.1 had a /dev/fb device that accesses the shared memory frame buffer. It seems that Sun made 4.2BSD mmap work specifically for this device only; only later on this became more generic. The 1999 Linux /dev/fbdev device seems to have more or less copied this SunOS design, providing the illusion of a shared memory frame buffer even when that was not always the underlying hardware reality. Access to acceleration was through display commands issued via ioctl. Early Plan9 has the /dev/bit/screen device, which is read-only. Writing to the screen appears to have been through display commands written to /dev/bit/bitblt. Later this was refined into the /dev/draw/data and /dev/draw/ctl devices. No mmap of course, and it was possible to remotely mount these devices. Considering these abstractions, did it matter all that much how the screen hardware was organised? The 1986 Whitechapel MG-1 / Oriel window system used a very different approach: applications drew to private window bitmaps in main memory, which the kernel composited to an otherwise user-inaccessible frame buffer upon request. In a way it resembles the current approach. I’m surprised this was workable with the hardware speeds and memory sizes of the era. However, maybe it did not work well at all, as they went out of business after just a few years. From imp at bsdimp.com Wed Mar 8 23:05:32 2023 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Mar 2023 06:05:32 -0700 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <28C479A6-053A-4D95-B6CE-13254FBD8068@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <28C479A6-053A-4D95-B6CE-13254FBD8068@planet.nl> Message-ID: On Wed, Mar 8, 2023, 4:51 AM Paul Ruizendaal via TUHS wrote: > It is then surprising that Linux did not come up with /dev/fbdev until > 1999, especially in view of the importance of X to the early Linux > developers. Maybe the reason was that the headache of video drivers was > delegated to the XFree community. > Mapping /dev/mem was good enough for SVGA cards. No surprise there: just be lazy. Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Mar 8 23:10:08 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Mar 2023 08:10:08 -0500 (EST) Subject: [TUHS] 'Huge' file support removed from PWB1 Message-ID: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> In PWB1, support for 'huge' files appears to have been removed. If one compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double indirect block" code is gone. I guess PWB didn't need very large (> 8*256*512 = 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it were, though - unless PWB was generating lots of files of between 7*256*512 and 8*256*512 bytes in length, and they wanted to avoid the overhead of the double-indirect block? (The savings in code space are derisory - unlike in LSX/MINI-UNIX.) Anyone know? Noel From tuhs at tuhs.org Wed Mar 8 23:17:47 2023 From: tuhs at tuhs.org (Arno Griffioen via TUHS) Date: Wed, 8 Mar 2023 14:17:47 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <28C479A6-053A-4D95-B6CE-13254FBD8068@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <28C479A6-053A-4D95-B6CE-13254FBD8068@planet.nl> Message-ID: On Wed, Mar 08, 2023 at 01:51:10PM +0100, Paul Ruizendaal via TUHS wrote: > It is then surprising that Linux did not come up with /dev/fbdev until 1999, > especially in view of the importance of X to the early Linux developers. The PC/intel 'birthplace' of Linux had the advantage that the video hardware always had an ASCII mode, so from that viewpoint there was no need for any fb interface initially to get things going. If I remember correctly, things like SCO Unix also did not use any fb-style interface for their X11. > Maybe the reason was that the headache of video drivers was delegated to > the XFree community. Correct. There was definitely a sense that keeping all the graphics bits out of the kernel and just letting Xfree open /dev/mem and do it's magic was the preferred way. Also meant that Xfree wasn't waiting on kernel bits and vice-versa and could keep going in parallel. Unlike today where there's only a few cards/manufacturers left, we had hundreds of similar-but-not-quite-the-same PC videocards on the market, so it was an understandable sentiment as change was fast and frequent on the Xfree end. The FBdev idea really started brewing because of the non-intel Linux ports that did not have the luxury of a built-in ASCII-capable 'console' so needed to get something going there (after initial porting with serial output). Something was needed 'in kernel' even for a plain console on the framebuffer and to keep it from falling apart some sort of general interface for some sort of generic X11 (even un-accelerated) as well. Most of the non-PC framebuffer hardware was too 'obscure' for Xfree to spend much time on as well.. The Linux/M68k port with Geert being very active here and really pushing to getting a more generalised display setup going that would work on the wildly different framebuffer hardware between all the m68k platforms but make basically use of 1 simple X server that didn't need to know that much about the hardware. Ultimately this led to the general FBdev project for all platforms. Bye, Arno. From crossd at gmail.com Thu Mar 9 00:23:56 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Mar 2023 09:23:56 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: On Wed, Mar 8, 2023 at 7:53 AM Paul Ruizendaal wrote: > This also has a relation to the point about what constitutes a "workstation" and one of the comments was that it needs to have "integrated graphics". What is integrated in this historical context -- is it a shared memory frame buffer, is it a shared CPU, is it physically in the same box or just an integrated user experience? It seems to me that it is not easy to delineate. Consider a Vax connected to a Tek raster scan display, a Vax connected to a Blit, Clem’s Magnolia and a networked Sun-1. Which ones are workstations? If shared memory is the key only Clem’s Magnolia and the Sun-1 qualify. If it is a shared CPU only a standalone Sun-1 qualifies, but its CPU would be heavily taxed when doing graphics, so standalone graphics was maybe not a normal use case. For now my rule of thumb is that it means (in a 1980’s-1990’s context) a high-bandwidth path between the compute side and display side, with enough total combined power to drive both the workload and the display. I wouldn't try to be too rigid in your terms here. The term "workstation" was probably never well-defined; it had more of an intuitive connotation of a machine that was more powerful than something you could get on the consumer market (like a PC or 8-bit microcomputer), but wasn't a minicomputer or mainframe/supercomputer. By the early 90s this was understood to mean a single-user machine in a desktop or deskside form factor with a graphics display, and a more advanced operating system than something you'd get on a consumer-grade machine. But the term probably predated that. Generally, workstations were machines marketed towards science/engineering/technology applications, and so intended for a person doing "work", as opposed to home computing or large scale business data-processing. Would a Tek 4014 connected to a VAX count? Maybe? I mean, bicycles have saddles, but we also put saddles on horses, so sure, in the late 70s or early 80s, why not. By the 1990s, maybe not so much. - Dan C. From pnr at planet.nl Thu Mar 9 01:06:35 2023 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 Mar 2023 16:06:35 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: <30409071-EB8E-4370-A1E6-8364FC3A662E@planet.nl> > On 8 Mar 2023, at 15:23, Dan Cross wrote: > > On Wed, Mar 8, 2023 at 7:53 AM Paul Ruizendaal wrote: >> This also has a relation to the point about what constitutes a "workstation" and one of the comments was that it needs to have "integrated graphics". What is integrated in this historical context -- is it a shared memory frame buffer, is it a shared CPU, is it physically in the same box or just an integrated user experience? It seems to me that it is not easy to delineate. Consider a Vax connected to a Tek raster scan display, a Vax connected to a Blit, Clem’s Magnolia and a networked Sun-1. Which ones are workstations? If shared memory is the key only Clem’s Magnolia and the Sun-1 qualify. If it is a shared CPU only a standalone Sun-1 qualifies, but its CPU would be heavily taxed when doing graphics, so standalone graphics was maybe not a normal use case. For now my rule of thumb is that it means (in a 1980’s-1990’s context) a high-bandwidth path between the compute side and display side, with enough total combined power to drive both the workload and the display. > > I wouldn't try to be too rigid in your terms here. The term > "workstation" was probably never well-defined; it had more of an > intuitive connotation of a machine that was more powerful than > something you could get on the consumer market (like a PC or 8-bit > microcomputer), but wasn't a minicomputer or mainframe/supercomputer. Yes, I got a bit carried away there. The point I was trying to make was in context of the wheel of reincarnation, though: if the system is a Vax and a Blit, we could conceptually think of the Blit as an accelerated graphics card for the Vax, having made one full revolution. If this is nonsense, why is the Magnolia different? From tuhs at tuhs.org Thu Mar 9 02:02:03 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 08 Mar 2023 16:02:03 +0000 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: Message-ID: Ouch....well I'm glad I shared then, I had no idea someone had already done this....well good to know, I guess I can move on to the CB and MERT manuals then. - Matt G. ------- Original Message ------- On Wednesday, March 8th, 2023 at 2:02 AM, Angelo Papenhoff wrote: > I've done this a couple of years ago: > http://squoze.net/UNIX > > Cheers, > Angelo > > On 08/03/23, segaloco via TUHS wrote: > > > So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: > > > > https://gitlab.com/segaloco/v5man > > > > There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. > > > > I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. > > > > - Matt G. From aap at papnet.eu Thu Mar 9 02:30:43 2023 From: aap at papnet.eu (Angelo Papenhoff) Date: Wed, 8 Mar 2023 17:30:43 +0100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: Message-ID: Something I'd like is to recreate the original troff output exactly. I used troff from plan 9 (so same lineage as original troff) but something causes the output to not look exactly like the original. I don't remember what it is exactly but you can easily check by comparing my pdfs with the scan. Line lengths, page length, something like that. I don't know if this is just a troff setting or if troff had changed enough to cause this difference. Unfortunately the original troff is lost so no way to compare. v7 (or PWB?) is the earliest version of troff that's still around. And even then one would need CAT emulation, which I haven't bothered with yet. Cheers, Angelo On 08/03/23, segaloco wrote: > Ouch....well I'm glad I shared then, I had no idea someone had already done this....well good to know, I guess I can move on to the CB and MERT manuals then. > > - Matt G. > > ------- Original Message ------- > On Wednesday, March 8th, 2023 at 2:02 AM, Angelo Papenhoff wrote: > > > > I've done this a couple of years ago: > > http://squoze.net/UNIX > > > > Cheers, > > Angelo > > > > On 08/03/23, segaloco via TUHS wrote: > > > > > So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: > > > > > > https://gitlab.com/segaloco/v5man > > > > > > There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. > > > > > > I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. > > > > > > - Matt G. From tytso at mit.edu Thu Mar 9 02:55:38 2023 From: tytso at mit.edu (Theodore Ts'o) Date: Wed, 8 Mar 2023 11:55:38 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: <20230308165538.GB1867364@mit.edu> On Wed, Mar 08, 2023 at 09:23:56AM -0500, Dan Cross wrote: > > By the early 90s this was understood to mean a single-user machine in > a desktop or deskside form factor with a graphics display, and a more > advanced operating system than something you'd get on a consumer-grade > machine. But the term probably predated that. Generally, workstations > were machines marketed towards science/engineering/technology > applications, and so intended for a person doing "work", as opposed to > home computing or large scale business data-processing. It's perhaps interesting to look at the history of A/UX. In 1988 Apple released a version of Unix based on SVR2. It was massively criticized for being command-line only (no X windows or any other kind of GUI). A year later, they came out with a version with X Windows, which made it roughly comprable to a low-end Sun Workstation, at a price of $9k. Given that in addition to the 3M's (1 MIPS, 1 Meg of Memory, and 1 Megapixel graphics display), it also adhered to the "4th M", costing roughly $10k, or a "Megapenny". :-) It seems to me that in the late 80's / early 90's, it was pretty clear what people were expecting if you wanted something more than a "toy" (err..., sorry, a "home") computer. And Apple wanted to get into that game and play, too. Of course, they later decided this wasn't a place where they really could compete, especially since in 1990 Sun released a low-end Workstation for $5k (the Sparcstation SLC). And by 1992, you could get a very credible Linux home machine with X Windows, for about $2k. It's kind of amazing how quickly a personal Workstation became quite affordable, even for a graduate student or a new college grad (like me!), out of their own personal checking account. - Ted From clemc at ccc.com Thu Mar 9 03:45:01 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Mar 2023 12:45:01 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: On Wed, Mar 8, 2023 at 9:24 AM Dan Cross wrote: > I wouldn't try to be too rigid in your terms here. The term > "workstation" was probably never well-defined > I agree. > By the early 90s this was understood to mean a single-user machine in > a desktop or deskside form factor with a graphics display, and a more > advanced operating system than something you'd get on a consumer-grade > machine. But the term probably predated that. > Definitely. > > Would a Tek 4014 connected to a VAX count? > And herein lies the issue. The term was taken from the engineering/architecture style definition of the 50s/60s - where someone had a desk/table/bench and *area to do 'work'*. With the CTSS/Multrics et al., the birth of interactive computing is the term used to define an area (usually in a shared computer terminal room). By the time of Tek 4014 and ME-CAD in particular, you often saw darkened rooms where one or two Tek 4000 series terminals might be attached to a large (more capable) computer - be it a PDP-10, IBM, or later Vaxen. At this point, everything is shared - because the computer is shared - only on the terminal itself is a single user, but this was called a 'workstation,' at that time *as the place where you did work*.. Fast forward to the first personal (mini) computer - *a.k.a.* the. Xerox Alto These were intended to be single-user computer systems, and the CPU was not a shared resource like a time-shared system. Next, we see the MIT LISP machine and the PascALTO [*a.k.a*. the. 3-Rivers Perq] -- same thing. BTW: I also just looked at my copy of the CMU SPICE (Scientific Personal Integrated Computing Environment). In none of these does the term workstation show up (be. used) *to describe the computer itself* - *i.e.,* the term is still only used in the context of the place/area you do work. All of these use the term *personal computer *to describe the device being used in that place*.* We also start to see the birth of firms like Apollo, Masscomp, and later VLSI Systems (later renamed Sun Microsystems). But also build personal computers that can perform the same computing task as 32-bit minicomputers such as the Vax. Fast forward to the IBM release of the IBM 5150 Personal Computer based on an Intel 8088 - which is decidedly a much less capable computer than what is being sold by the folks using Vaxen, M68000s, or Zilion Z8000. While this system can be a fine replacement for a 'word processor' and even run the business friends 'Visicalc' - it is not suited for the CAD style work that is ruining on minicomputers. But ... IBM usurps the term 'Personal Computer' to describe their new product (and make it sound a bit more than what it really was). But now you have a problem in the market at large. Marketing folks at places like 3-Rivers, Apollo, and the like need a new term to start to describe the capabilities of the computer in their more expensive products to differentiate them from the new IBM product and explain their value for that extra cost -> i.e. they were no selling personal computers, but complete and much more capable systems that integrated into a network, had raster graphics, *etc*. and to perform tasks that the IBM PC was unable. So they took the term of how the product was being used -> *to create a place to do work, to be the device that allowed you to do (real) work*. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Mar 9 03:46:57 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Mar 2023 12:46:57 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230308165538.GB1867364@mit.edu> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> <20230308165538.GB1867364@mit.edu> Message-ID: On Wed, Mar 8, 2023 at 11:55 AM Theodore Ts'o wrote: > A year later, they came out with a version with X Windows, which made > it roughly comprable to a low-end Sun Workstation, at a price of $9k. > Given that in addition to the 3M's (1 MIPS, 1 Meg of Memory, and 1 > Megapixel graphics display), it also adhered to the "4th M", costing > roughly $10k, or a "Megapenny". :-) > CMU's SPICE proposal was for a 3M machine at under $5K by 1985. But you are right $10-15K was typical in those days. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Thu Mar 9 04:12:48 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 08 Mar 2023 18:12:48 +0000 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: <7gRmYrV9xZLqALpbW8Y9EuB9rwaGBUKwNrgdHsepRTRVMFCHkPYaRWy68zZvwTcIpY6ZMcoFqxi2puDOS-D2Z6VUQypSYkyA2uNzDdHO8oQ=@protonmail.com> I've always liked the "Workbench" terminology that AT&T used, it summons to mind a more communal environment than the idea of a "workstation" does. The former makes me think of my time in the lab "at the bench" with my coworkers, whereas the latter makes me think of my current remote programming job where my break room chat is limited to the cat. It's a shame we all have multiple timesharing systems in our homes, pockets, etc. these days but a dearth of communal computing environments. That said, it's understandable given how many bad actors there are out there, a computing utility would be a frequent target...curse the crackers for ruining that along with the term hacking.... - Matt G. ------- Original Message ------- On Wednesday, March 8th, 2023 at 9:45 AM, Clem Cole wrote: > On Wed, Mar 8, 2023 at 9:24 AM Dan Cross wrote: > >> I wouldn't try to be too rigid in your terms here. The term >> "workstation" was probably never well-defined > > I agree. > >> By the early 90s this was understood to mean a single-user machine in >> a desktop or deskside form factor with a graphics display, and a more >> advanced operating system than something you'd get on a consumer-grade >> machine. But the term probably predated that. > > Definitely. > >> Would a Tek 4014 connected to a VAX count? > > And herein lies the issue. The term was taken from the engineering/architecture style definition of the 50s/60s - where someone had a desk/table/bench and area to do 'work'. > > With the CTSS/Multrics et al., the birth of interactive computing is the term used to define an area (usually in a shared computer terminal room). By the time of Tek 4014 and ME-CAD in particular, you often saw darkened rooms where one or two Tek 4000 series terminals might be attached to a large (more capable) computer - be it a PDP-10, IBM, or later Vaxen.At this point, everything is shared - because the computer is shared - only on the terminal itself is a single user, but this was called a 'workstation,' at that time as the place where you did work.. > > Fast forward to the first personal (mini) computer - a.k.a. the. Xerox Alto > > These were intended to be single-user computer systems, and the CPU was not a shared resource like a time-shared system. Next, we see the MIT LISP machine and the PascALTO [a.k.a. the. 3-Rivers Perq] -- same thing. BTW: I also just looked at my copy of the CMU SPICE (Scientific Personal Integrated Computing Environment). In none of these does the term workstation show up (be. used) to describe the computer itself - i.e., the term is still only used in the context of the place/area you do work. All of these use the term personal computer to describe the device being used in that place. > > We also start to see the birth of firms like Apollo, Masscomp, and later VLSI Systems (later renamed Sun Microsystems). But also build personal computers that can perform the same computing task as 32-bit minicomputers such as the Vax. > > Fast forward to the IBM release of the IBM 5150 Personal Computer based on an Intel 8088 - which is decidedly a much less capable computer than what is being sold by the folks using Vaxen, M68000s, or Zilion Z8000. While this system can be a fine replacement for a 'word processor' and even run the business friends 'Visicalc' - it is not suited for the CAD style work that is ruining on minicomputers. But ... IBM usurps the term 'Personal Computer' to describe their new product (and make it sound a bit more than what it really was). But now you have a problem in the market at large. > > Marketing folks at places like 3-Rivers, Apollo, and the like need a new term to start to describe the capabilities of the computer in their more expensiveproducts to differentiate them from the new IBM product and explain their value for that extra cost -> i.e. they were no selling personal computers, but complete and much more capable systems that integrated into a network, had raster graphics, etc. and to perform tasks that the IBM PC was unable. So they took the term of how the product was being used -> to create a place to do work, to be the device that allowed you to do (real) work. > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Mar 9 04:21:20 2023 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 8 Mar 2023 10:21:20 -0800 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <7gRmYrV9xZLqALpbW8Y9EuB9rwaGBUKwNrgdHsepRTRVMFCHkPYaRWy68zZvwTcIpY6ZMcoFqxi2puDOS-D2Z6VUQypSYkyA2uNzDdHO8oQ=@protonmail.com> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> <7gRmYrV9xZLqALpbW8Y9EuB9rwaGBUKwNrgdHsepRTRVMFCHkPYaRWy68zZvwTcIpY6ZMcoFqxi2puDOS-D2Z6VUQypSYkyA2uNzDdHO8oQ=@protonmail.com> Message-ID: <20230308182120.GL5993@mcvoy.com> I really miss terminal rooms. I learned so much looking over the shoulders of more experienced people. Wait, you can run a paragraph of text through fmt(1)? How the heck did you do that? I don't really miss it for me, I'm retired, but I think kids learning are sort of at a disadvantage. Not sure there is a youtube video that teaches you to say: :map , !}fmt On Wed, Mar 08, 2023 at 06:12:48PM +0000, segaloco via TUHS wrote: > I've always liked the "Workbench" terminology that AT&T used, it summons to mind a more communal environment than the idea of a "workstation" does. The former makes me think of my time in the lab "at the bench" with my coworkers, whereas the latter makes me think of my current remote programming job where my break room chat is limited to the cat. > > It's a shame we all have multiple timesharing systems in our homes, pockets, etc. these days but a dearth of communal computing environments. That said, it's understandable given how many bad actors there are out there, a computing utility would be a frequent target...curse the crackers for ruining that along with the term hacking.... > > - Matt G. > ------- Original Message ------- > On Wednesday, March 8th, 2023 at 9:45 AM, Clem Cole wrote: > > > On Wed, Mar 8, 2023 at 9:24???AM Dan Cross wrote: > > > >> I wouldn't try to be too rigid in your terms here. The term > >> "workstation" was probably never well-defined > > > > I agree. > > > >> By the early 90s this was understood to mean a single-user machine in > >> a desktop or deskside form factor with a graphics display, and a more > >> advanced operating system than something you'd get on a consumer-grade > >> machine. But the term probably predated that. > > > > Definitely. > > > >> Would a Tek 4014 connected to a VAX count? > > > > And herein lies the issue. The term was taken from the engineering/architecture style definition of the 50s/60s - where someone had a desk/table/bench and area to do 'work'. > > > > With the CTSS/Multrics et al., the birth of interactive computing is the term used to define an area (usually in a shared computer terminal room). By the time of Tek 4014 and ME-CAD in particular, you often saw darkened rooms where one or two Tek 4000 series terminals might be attached to a large (more capable) computer - be it a PDP-10, IBM, or later Vaxen.At this point, everything is shared - because the computer is shared - only on the terminal itself is a single user, but this was called a 'workstation,' at that time as the place where you did work.. > > > > Fast forward to the first personal (mini) computer - a.k.a. the. Xerox Alto > > > > These were intended to be single-user computer systems, and the CPU was not a shared resource like a time-shared system. Next, we see the MIT LISP machine and the PascALTO [a.k.a. the. 3-Rivers Perq] -- same thing. BTW: I also just looked at my copy of the CMU SPICE (Scientific Personal Integrated Computing Environment). In none of these does the term workstation show up (be. used) to describe the computer itself - i.e., the term is still only used in the context of the place/area you do work. All of these use the term personal computer to describe the device being used in that place. > > > > We also start to see the birth of firms like Apollo, Masscomp, and later VLSI Systems (later renamed Sun Microsystems). But also build personal computers that can perform the same computing task as 32-bit minicomputers such as the Vax. > > > > Fast forward to the IBM release of the IBM 5150 Personal Computer based on an Intel 8088 - which is decidedly a much less capable computer than what is being sold by the folks using Vaxen, M68000s, or Zilion Z8000. While this system can be a fine replacement for a 'word processor' and even run the business friends 'Visicalc' - it is not suited for the CAD style work that is ruining on minicomputers. But ... IBM usurps the term 'Personal Computer' to describe their new product (and make it sound a bit more than what it really was). But now you have a problem in the market at large. > > > > Marketing folks at places like 3-Rivers, Apollo, and the like need a new term to start to describe the capabilities of the computer in their more expensiveproducts to differentiate them from the new IBM product and explain their value for that extra cost -> i.e. they were no selling personal computers, but complete and much more capable systems that integrated into a network, had raster graphics, etc. and to perform tasks that the IBM PC was unable. So they took the term of how the product was being used -> to create a place to do work, to be the device that allowed you to do (real) work. > > ??? -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From kennethgoodwin56 at gmail.com Thu Mar 9 04:43:45 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Wed, 8 Mar 2023 13:43:45 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230308182120.GL5993@mcvoy.com> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> <7gRmYrV9xZLqALpbW8Y9EuB9rwaGBUKwNrgdHsepRTRVMFCHkPYaRWy68zZvwTcIpY6ZMcoFqxi2puDOS-D2Z6VUQypSYkyA2uNzDdHO8oQ=@protonmail.com> <20230308182120.GL5993@mcvoy.com> Message-ID: On Wed, Mar 8, 2023, 1:21 PM Larry McVoy wrote: > I really miss terminal rooms. I learned so much looking over the > shoulders of more experienced people. Wait, you can run a paragraph of > text through fmt(1)? How the heck did you do that? > > I don't really miss it for me, I'm retired, but I think kids learning > are sort of at a disadvantage. Not sure there is a youtube video that > teaches you to say: > > :map , !}fmt > You could all create those videos. How to"s The histories Evolution. Working with the Legends of Computer Science Insights into working on the R&D side Give them an insight into the problems you faced and how you approached finding a solution. Teaches critical thinking, how to approach the impossible problem >From a personal perspective. The emotional side of great research The eureka moments in your lives. Teach inspire The olde Geezer Geeks Educational Video Series for Young Minds and New Hackers. > On Wed, Mar 08, 2023 at 06:12:48PM +0000, segaloco via TUHS wrote: > > I've always liked the "Workbench" terminology that AT&T used, it summons > to mind a more communal environment than the idea of a "workstation" does. > The former makes me think of my time in the lab..... > -- > --- > Larry McVoy Retired to fishing > http://www.mcvoy.com/lm/boat > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Thu Mar 9 04:45:59 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 08 Mar 2023 19:45:59 +0100 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230308182120.GL5993@mcvoy.com> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> <7gRmYrV9xZLqALpbW8Y9EuB9rwaGBUKwNrgdHsepRTRVMFCHkPYaRWy68zZvwTcIpY6ZMcoFqxi2puDOS-D2Z6VUQypSYkyA2uNzDdHO8oQ=@protonmail.com> <20230308182120.GL5993@mcvoy.com> Message-ID: <20230308184559._JD0M%steffen@sdaoden.eu> Larry McVoy wrote in <20230308182120.GL5993 at mcvoy.com>: |I really miss terminal rooms. I learned so much looking over the |shoulders of more experienced people. Wait, you can run a paragraph of |text through fmt(1)? How the heck did you do that? | |I don't really miss it for me, I'm retired, but I think kids learning |are sort of at a disadvantage. Not sure there is a youtube video that |teaches you to say: | |:map , !}fmt vim can do this built-in (sufficiently for me). map {gq} Rarely (GNU) fmt (only, the latter) can really do better map M :'{,'}!fmt 64 66 map m :'{,'}!fmt --uniform-spacing --width=66 --goal=64 I have forgotten the cryptic meaning - Don't ask me no question, I know a little, All i can do is write about it, Am i losin', I never dreamed That smell (sweet home alabama). I must now get explicitly rid of things in [ci]?map however (like , C-X, C-E etc) to be a free bird. 'Just a Simple Man. But enough Lynyrd Skynyrd southern US! (Sorry!) For decades i want to check out vile, but never made it there for long. (Now that i switched back to tabulator indentation maybe. It now can spaces, on the other hand, i think. Comments auto-joining back over lines in vim's C mode is so nice, then again.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rminnich at gmail.com Thu Mar 9 05:05:35 2023 From: rminnich at gmail.com (ron minnich) Date: Wed, 8 Mar 2023 11:05:35 -0800 Subject: [TUHS] the wheel of reincarnation goes sideways Message-ID: The wheel of reincarnation discussion got me to thinking: What I'm seeing is reversing the rotation of the wheel of reincarnation. Instead of pulling the task (e.g. graphics) from a special purpose device back into the general purpose domain, the general purpose computing domain is pushed into the special purpose device. I first saw this almost 10 years ago with a WLAN modem chip that ran linux on its 4 core cpu, all of it in a tiny package. It was faster, better, and cheaper than its traditional embedded predecessor -- because the software stack was less dedicated and single-company-created. Take Linux, add some stuff, voila! WLAN modem. Now I'm seeing it in peripheral devices that have, not one, but several independent SoCs, all running Linux, on one card. There's even been a recent remote code exploit on, ... an LCD panel. Any of these little devices, with the better part of a 1G flash and a large part of 1G DRAM, dwarfs anything Unix ever ran on. And there are more and more of them, all over the little PCB in a laptop. The evolution of platforms like laptops to becoming full distributed systems continues. The wheel of reincarnation spins counter clockwise -- or sideways? I'm no longer sure the whole idea of the wheel or reincarnation is even applicable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Mar 9 05:35:49 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Mar 2023 14:35:49 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <30409071-EB8E-4370-A1E6-8364FC3A662E@planet.nl> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> <30409071-EB8E-4370-A1E6-8364FC3A662E@planet.nl> Message-ID: On Wed, Mar 8, 2023 at 10:06 AM Paul Ruizendaal wrote: > > On 8 Mar 2023, at 15:23, Dan Cross wrote: > > I wouldn't try to be too rigid in your terms here. The term > > "workstation" was probably never well-defined; it had more of an > > intuitive connotation of a machine that was more powerful than > > something you could get on the consumer market (like a PC or 8-bit > > microcomputer), but wasn't a minicomputer or mainframe/supercomputer. > > Yes, I got a bit carried away there. The point I was trying to make was in context of the wheel of reincarnation, though: if the system is a Vax and a Blit, we could conceptually think of the Blit as an accelerated graphics card for the Vax, having made one full revolution. If this is nonsense, why is the Magnolia different? I don't think it's nonsense. I do think it is reaching a bit to draw an analogy that was probably unconsidered at the time, but that's ok. I think the study of history turns up such things all the time. - Dan C. From crossd at gmail.com Thu Mar 9 05:52:43 2023 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Mar 2023 14:52:43 -0500 Subject: [TUHS] the wheel of reincarnation goes sideways In-Reply-To: References: Message-ID: [bumping to COFF] On Wed, Mar 8, 2023 at 2:05 PM ron minnich wrote: > The wheel of reincarnation discussion got me to thinking: > > What I'm seeing is reversing the rotation of the wheel of reincarnation. Instead of pulling the task (e.g. graphics) from a special purpose device back into the general purpose domain, the general purpose computing domain is pushed into the special purpose device. > > I first saw this almost 10 years ago with a WLAN modem chip that ran linux on its 4 core cpu, all of it in a tiny package. It was faster, better, and cheaper than its traditional embedded predecessor -- because the software stack was less dedicated and single-company-created. Take Linux, add some stuff, voila! WLAN modem. > > Now I'm seeing it in peripheral devices that have, not one, but several independent SoCs, all running Linux, on one card. There's even been a recent remote code exploit on, ... an LCD panel. > > Any of these little devices, with the better part of a 1G flash and a large part of 1G DRAM, dwarfs anything Unix ever ran on. And there are more and more of them, all over the little PCB in a laptop. > > The evolution of platforms like laptops to becoming full distributed systems continues. > The wheel of reincarnation spins counter clockwise -- or sideways? About a year ago, I ran across an email written a decade or more prior on some mainframe mailing list where someone wrote something like, "wow! It just occurred to me that my Athlon machine is faster than the ES/3090-600J I used in 1989!" Some guy responded angrily, rising to the wounded honor of IBM, raving about how preposterous this was because the mainframe could handle a thousand users logged in at one time and there's no way this Linux box could ever do that. I was struck by the absurdity of that; it's such a ridiculous non-comparison. The mainframe had layers of terminal concentrators, 3270 controllers, IO controllers, etc, etc, and a software ecosystem that made heavy use of all of that, all to keep user interaction _off_ of the actual CPU (I guess freeing that up to run COBOL programs in batch mode...); it's not as though every time a mainframe user typed something into a form on their terminal it interrupted the primary CPU. Of course, the first guy was right: the AMD machine probably _was_ more capable than a 3090 in terms of CPU performance, RAM and storage capacity, and raw bandwidth between the CPU and IO subsystems. But the 3090 was really more like a distributed system than the Athlon box was, with all sorts of offload capabilities. For that matter, a thousand users probably _could_ telnet into the Athlon system. With telnet in line mode, it'd probably even be decently responsive. So often it seems to me like end-user systems are just continuing to adopt "large system" techniques. Nothing new under the sun. > I'm no longer sure the whole idea of the wheel or reincarnation is even applicable. I often feel like the wheel has fallen onto its side, and we're continually picking it up from the edge and flipping it over, ad nauseum. - Dan C. From joshnatis0 at gmail.com Thu Mar 9 06:55:46 2023 From: joshnatis0 at gmail.com (josh) Date: Wed, 8 Mar 2023 15:55:46 -0500 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: Message-ID: Hi Angelo, G. Branden Robinson, (CCed on this email) attempted a somewhat similar mission, re-typesetting the paper "Typesetting Mathematics by Kernighan and Cherry" with groff. If you look through the email thread detailing the result [1], you can see notes about aesthetic regressions from the original troff document, and Branden's attempts to fix them. Hope you don't mind me summoning you, Branden :). [1] https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html Additionally (though unrelated to roff), the Computerphile youtube channel has a video [2] you may find interesting titled "Recreating Dennis Ritchie's PhD Thesis", in which they discuss how they went about making a faithful recreation of dmr's unsubmitted PhD thesis. [2] https://www.youtube.com/watch?v=82TxNejKsng Hope this generates some interesting discussion? :) Josh On Wed, Mar 8, 2023 at 11:30 AM Angelo Papenhoff wrote: > > Something I'd like is to recreate the original troff output exactly. I > used troff from plan 9 (so same lineage as original troff) but something > causes the output to not look exactly like the original. I don't > remember what it is exactly but you can easily check by comparing my > pdfs with the scan. Line lengths, page length, something like that. > > I don't know if this is just a troff setting or if troff had changed > enough to cause this difference. Unfortunately the original troff is > lost so no way to compare. v7 (or PWB?) is the earliest version of troff > that's still around. And even then one would need CAT emulation, which I > haven't bothered with yet. > > Cheers, > Angelo > > > On 08/03/23, segaloco wrote: > > Ouch....well I'm glad I shared then, I had no idea someone had already done this....well good to know, I guess I can move on to the CB and MERT manuals then. > > > > - Matt G. > > > > ------- Original Message ------- > > On Wednesday, March 8th, 2023 at 2:02 AM, Angelo Papenhoff wrote: > > > > > > > I've done this a couple of years ago: > > > http://squoze.net/UNIX > > > > > > Cheers, > > > Angelo > > > > > > On 08/03/23, segaloco via TUHS wrote: > > > > > > > So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: > > > > > > > > https://gitlab.com/segaloco/v5man > > > > > > > > There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. > > > > > > > > I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. > > > > > > > > - Matt G. From tuhs at tuhs.org Thu Mar 9 08:21:55 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Wed, 08 Mar 2023 22:21:55 +0000 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: Message-ID: I will add the caveat that typesetting accuracy isn't my primary goal although it is a secondary one. My primary goal is easily diffable sources between versions to then facilitate version analysis. I intend to take this same approach to plenty of other documents we have lying around in scanned form to try and get a better machine-readable body of research material available, including stuff like the Documents for UNIX PWB 1.0 and Release 4.1 sets and the CB-UNIX sources we have bumping around the archive. Part of my reasoning on putting these in git archives as I go is so that if someone does want to come do some editing, corrections, etc. they're free to fork or raise a PR on my repositories. - Matt G. ------- Original Message ------- On Wednesday, March 8th, 2023 at 12:32 PM, josh wrote: > Hi Angelo, > > G. Branden Robinson, (CCed on this email) attempted a somewhat similar mission, > re-typesetting the paper "Typesetting Mathematics by Kernighan and Cherry" with > groff. If you look through the email thread detailing the result [1], you can > see notes about aesthetic regressions from the original troff document, and > Branden's attempts to fix them. Hope you don't mind me summoning you, Branden > :). > > [1] https://lists.gnu.org/archive/html/groff/2022-07/msg00000.html > > Additionally (though unrelated to roff), the Computerphile youtube channel has > a video [2] you may find interesting titled "Recreating Dennis Ritchie's PhD > Thesis", in which they discuss how they went about making a faithful recreation > of dmr's unsubmitted PhD thesis. > > [2] https://www.youtube.com/watch?v=82TxNejKsng > > Hope this generates some interesting discussion? :) > Josh > > > On Wed, Mar 8, 2023 at 11:30 AM Angelo Papenhoff aap at papnet.eu wrote: > > > Something I'd like is to recreate the original troff output exactly. I > > used troff from plan 9 (so same lineage as original troff) but something > > causes the output to not look exactly like the original. I don't > > remember what it is exactly but you can easily check by comparing my > > pdfs with the scan. Line lengths, page length, something like that. > > > > I don't know if this is just a troff setting or if troff had changed > > enough to cause this difference. Unfortunately the original troff is > > lost so no way to compare. v7 (or PWB?) is the earliest version of troff > > that's still around. And even then one would need CAT emulation, which I > > haven't bothered with yet. > > > > Cheers, > > Angelo > > > > On 08/03/23, segaloco wrote: > > > > > Ouch....well I'm glad I shared then, I had no idea someone had already done this....well good to know, I guess I can move on to the CB and MERT manuals then. > > > > > > - Matt G. > > > > > > ------- Original Message ------- > > > On Wednesday, March 8th, 2023 at 2:02 AM, Angelo Papenhoff aap at papnet.eu wrote: > > > > > > > I've done this a couple of years ago: > > > > http://squoze.net/UNIX > > > > > > > > Cheers, > > > > Angelo > > > > > > > > On 08/03/23, segaloco via TUHS wrote: > > > > > > > > > So I decided to keep the momentum and have just finished the first pass of a Fifth Edition manual restoration based on the same process I used for 3B20 4.1: > > > > > > > > > > https://gitlab.com/segaloco/v5man > > > > > > > > > > There were a few pages missing from the extant PDF scan, at least as far as pages that were in both V4 and V6 sources, so those are handled by seeing how V5 source of the few programs compares to V6. I'll note which pages required this in a second pass. > > > > > > > > > > I've set my sights on V1 and V2 next, using V3's extant roff sources as a starting point, so more to come. > > > > > > > > > > - Matt G. From clemc at ccc.com Thu Mar 9 08:44:53 2023 From: clemc at ccc.com (Clem Cole) Date: Wed, 8 Mar 2023 17:44:53 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <20230308182120.GL5993@mcvoy.com> References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> <7gRmYrV9xZLqALpbW8Y9EuB9rwaGBUKwNrgdHsepRTRVMFCHkPYaRWy68zZvwTcIpY6ZMcoFqxi2puDOS-D2Z6VUQypSYkyA2uNzDdHO8oQ=@protonmail.com> <20230308182120.GL5993@mcvoy.com> Message-ID: On Wed, Mar 8, 2023 at 1:21 PM Larry McVoy wrote: > I really miss terminal rooms. I learned so much looking over the > shoulders of more experienced people. > Amen bro.. Funny Guy Almes and I were chatting about this last week WRT to some CMU history. I've observed that the theory could be learned in lectures and reading books, but the art is taught to an apprentice by a master - carefully looking over her/his shoulder, trying it yourself, being self-critical of your work, as well as taking advice/critical observations from others -- then little by little learning to appreciate what works. That was all so much easier in a terminal room. Or as I sometimes have said to students: "Hacking is done in the privacy of your office between you and your computer terminal. Programming may start in private, but needs the public transparency of the other eyes and thoughts if you want it to be useful for a long time." ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Thu Mar 9 09:09:56 2023 From: davida at pobox.com (David Arnold) Date: Thu, 9 Mar 2023 10:09:56 +1100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: Message-ID: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> > On 9 Mar 2023, at 03:30, Angelo Papenhoff wrote: … > And even then one would need CAT emulation, which I > haven't bothered with yet. That sounds like a fun project — is there really no such beast already? d From arnold at skeeve.com Thu Mar 9 16:59:17 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 08 Mar 2023 23:59:17 -0700 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: <202303090659.3296xH8H013091@freefriends.org> David Arnold wrote: > > On 9 Mar 2023, at 03:30, Angelo Papenhoff wrote: > > > And even then one would need CAT emulation, which I > > haven't bothered with yet. > > That sounds like a fun project — is there really no such beast already? It certainly was done in the past. There were commercial and posted-to-usenet versions of such things, search the comp.sources.* and net.sources.* archives. Such things would date from the mid-80s; if you find something, you'd probably have to do some work to bring it up on a modern system, but I doubt it'd be terrible. Arnold From kennethgoodwin56 at gmail.com Thu Mar 9 18:21:19 2023 From: kennethgoodwin56 at gmail.com (Kenneth Goodwin) Date: Thu, 9 Mar 2023 03:21:19 -0500 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: I have not seen the UNIX kernel source code in quite a while, but as I recall the double indirect block algorithm did not kick in until the file exceeded a certain threshold. So it would not make sense to remove the code for performance reasons. Perhaps this is more likely due to the use of larger logical block sizes.... Is the code physically removed or IFDEF'd out for conditional compilation? Perhaps someone decided that programmers would never need to test code on large files.. On Wed, Mar 8, 2023, 8:10 AM Noel Chiappa wrote: > In PWB1, support for 'huge' files appears to have been removed. If one > compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double > indirect block" code is gone. I guess PWB didn't need very large (> > 8*256*512 > = 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it > were, though - unless PWB was generating lots of files of between 7*256*512 > and 8*256*512 bytes in length, and they wanted to avoid the overhead of the > double-indirect block? (The savings in code space are derisory - unlike in > LSX/MINI-UNIX.) Anyone know? > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsg at jsg.id.au Thu Mar 9 22:40:38 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Thu, 9 Mar 2023 23:40:38 +1100 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: removed in PWB/UNIX 1.0. ifdef'd out in the Harvard/Radcliffe Student Time-sharing System (HRSTS) parts found in tuhs/Applications/Usenix_77. h/distrib.note includes: '4. "Huge" files are not supported by our modifications. This is not necessarily a hard restriction, however we early on decided we wanted no more than one level of indirection all the way up to 1 megabyte, and had no need for larger files. The incompatibilities may be minimal, but we have not even bothered to seek them out.' On Thu, Mar 09, 2023 at 03:21:19AM -0500, Kenneth Goodwin wrote: > I have not seen the UNIX kernel source code in quite a while, but as I > recall the double indirect block algorithm did not kick in until the file > exceeded a certain threshold. So it would not make sense to remove the code > for performance reasons. > > Perhaps this is more likely due to the use of larger logical block sizes.... > > Is the code physically removed or IFDEF'd out for conditional compilation? > > Perhaps someone decided that programmers would never need to test code on > large files.. > > On Wed, Mar 8, 2023, 8:10 AM Noel Chiappa wrote: > > > In PWB1, support for 'huge' files appears to have been removed. If one > > compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double > > indirect block" code is gone. I guess PWB didn't need very large (> > > 8*256*512 > > = 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it > > were, though - unless PWB was generating lots of files of between 7*256*512 > > and 8*256*512 bytes in length, and they wanted to avoid the overhead of the > > double-indirect block? (The savings in code space are derisory - unlike in > > LSX/MINI-UNIX.) Anyone know? > > > > Noel > > From clemc at ccc.com Fri Mar 10 00:24:43 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Mar 2023 09:24:43 -0500 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: As far as I know, Tom Ferrin wrote the original in the late 1970s - it is on the original UCSF tape as part of his UNIX graphics tools. That said, Joy may have passed it along on the BSD tapes also. It's called "vcat" and converts Wang C/A/T codes to plotter strokes on a smaller (11/12in wide IIRC) Varian (originally) and small Versatec [wet / kerosene style] plotter using the 200 bpi Hershey fonts that the CMU/MIT/Stanford XGP had used. IIRC, UCB had a large format Versatec (36"/48") and the UCB version could do N pages at a time. In the Adobe 'transcript' package is a similar program (based on Tom work) but outputs using Adobe Fonts. It might take some searching "foo" to find them, but Tom's program is what most of us used back in the day before the Imagen and later Apple LaserWriter - particularly after having had access to an XGP or a Xerox Dover in college ;-) ᐧ On Wed, Mar 8, 2023 at 6:10 PM David Arnold wrote: > > On 9 Mar 2023, at 03:30, Angelo Papenhoff wrote: > > … > > > And even then one would need CAT emulation, which I > > haven't bothered with yet. > > That sounds like a fun project — is there really no such beast already? > > > > > d > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Fri Mar 10 00:42:36 2023 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 9 Mar 2023 09:42:36 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <1297BE06-BE03-477A-AC60-40A269090295@planet.nl> <73309724-1F69-49D4-B54B-63DD298CBD27@planet.nl> Message-ID: On 3/8/23, Clem Cole wrote: (regarding the issue of the definition of "workstation") > And herein lies the issue. The term was taken from the > engineering/architecture style definition of the 50s/60s - where someone > had a desk/table/bench and *area to do 'work'*. Correct. According to etymologyonline.com, the term "workstation" dates from 1950, and in the computer sense from 1972. It is a place (station) where one does one's work. In a jeweler's shop the bench where watches are cleaned and repaired could be called the workstation. Since the early 1980s when I first encountered them, I've always regarded the distinction between a workstation, a PC, and a word processor to be a matter of how the machine is used rather than the hardware itself. All three (workstation, PC, WP) are single-user computing devices. The distinction is that PCs are for non-business use and word processors are limited-function devices. A computer workstation is a single-user, general-purpose computer used for business or technical purposes. >> Would a Tek 4014 connected to a VAX count? If the VAX were only being used by one person at a time (i.e., not a timesharing system), then I would say yes. IMO the PDP-1 was often used as a workstation. -Paul W. From ron at ronnatalie.com Fri Mar 10 01:07:17 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 09 Mar 2023 15:07:17 +0000 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: In the version 6 file system, If the file was less than 4K, the four blocks in the inode refer directly to the disk blocks containing the file data. After thef ile grows past that, the large bit is set in the inode and these blocks contain the single indirect blocks, referencing 256 data blocks each, until you used up seven of these. The last one was the double indirect block that pointed to other indirect blocks. The file size was stored in 24 bits, and the block numbers were 16 bit. As Noel points out, PWB uses the same file system as V6 but with the HUGE (last double indirect) code commented out. I have no idea why and I never noticed it before. While we used a lot of stuff from the PWB distribution (notably SCCS) we had no real interest in using the PWB’s kernel because our V6 kernel had diverged sharply from the Bell versions. Version 7 came around with a different filesystem layout. File sizes were 32 bits, and the disk block indexes were 24 bits. The latter was stored as a series of bytes on the disk but expanded into longs in memeory. There was no large bit anymore. The first 8 blocks addresses in the inode were always single indirect, the next two were single indirect, and the last one was double indirect. (If my memory serves me right) At BRL, we modified our very-hacked V6 kernel to have the ability to mount either V6 or V7 filesystems. We never ran V5, but I think V5 is essentially the V6 file system without the HUGE support again. -Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Fri Mar 10 01:13:07 2023 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 09 Mar 2023 15:13:07 +0000 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: That should read eight blocks in the inode not four in the first sentence (and up to eight later). ------ Original Message ------ >From "Ron Natalie" To "Kenneth Goodwin" ; "Noel Chiappa" Cc "The Eunuchs Hysterical Society" Date 3/9/2023 10:07:17 AM Subject [TUHS] Re: 'Huge' file support removed from PWB1 >In the version 6 file system, If the file was less than 4K, the four >blocks in the inode refer directly to the disk blocks containing the >file data. >After thef ile grows past that, the large bit is set in the inode and >these blocks contain the single indirect blocks, referencing 256 data >blocks each, until you used up seven of these. >The last one was the double indirect block that pointed to other >indirect blocks. The file size was stored in 24 bits, and the block >numbers were 16 bit. > >As Noel points out, PWB uses the same file system as V6 but with the >HUGE (last double indirect) code commented out. I have no idea why and >I never noticed it before. While we used a lot of stuff from the PWB >distribution (notably SCCS) we had no real interest in using the PWB’s >kernel because our V6 kernel had diverged sharply from the Bell >versions. > >Version 7 came around with a different filesystem layout. File sizes >were 32 bits, and the disk block indexes were 24 bits. The latter was >stored as a series of bytes on the disk but expanded into longs in >memeory. >There was no large bit anymore. The first 8 blocks addresses in the >inode were always single indirect, the next two were single indirect, >and the last one was double indirect. (If my memory serves me right) > >At BRL, we modified our very-hacked V6 kernel to have the ability to >mount either V6 or V7 filesystems. > >We never ran V5, but I think V5 is essentially the V6 file system >without the HUGE support again. > >-Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Mar 10 03:01:38 2023 From: tuhs at tuhs.org (Tom Ivar Helbekkmo via TUHS) Date: Thu, 09 Mar 2023 18:01:38 +0100 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed, 8 Mar 2023 08:10:08 -0500 (EST)") References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: Noel Chiappa writes: > In PWB1, support for 'huge' files appears to have been removed. They did make various changes to the system to protect against resource exhaustion in what was a genuine production multi-user facility, and might possibly have made such a change to ensure that a runaway process couldn't write a file more than a megabyte in size. It's not mentioned in the PWB article in the special UNIX issue of the Bell System Technical Journal, though, and that article does describe various changes they'd made, explaining how and why. However: PWB grew out of Research, side by side with it, evaluating and adopting changes along the way. They aimed to stay mostly in synch, but chose to keep and maintain a number of differences. Maybe they started their work before the "huge" file support was introduced, and then simply did not include that change? It's a backward incompatible change (at least if you have at least one file that already uses the last indirect block of its inode), and they might have decided to cross that bridge if and when they ever got to it. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From arnold at skeeve.com Fri Mar 10 03:35:43 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 09 Mar 2023 10:35:43 -0700 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: <202303091735.329HZh17004192@freefriends.org> "Ron Natalie" wrote: > Version 7 came around with a different filesystem layout. File sizes > were 32 bits, and the disk block indexes were 24 bits. The latter was > stored as a series of bytes on the disk but expanded into longs in > memeory. > There was no large bit anymore. The first 8 blocks addresses in the > inode were always single indirect, the next two were single indirect, > and the last one was double indirect. (If my memory serves me right) Wasn't there a triple-indirect block as the very last one? Arnold From robpike at gmail.com Fri Mar 10 06:48:26 2023 From: robpike at gmail.com (Rob Pike) Date: Fri, 10 Mar 2023 07:48:26 +1100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: I had an idea. I asked Tom Duff, Mike Tilson, Bill Reeves to help me put together tools and font digitizations to "print" nroff output to the Versatec plotter one weekend in early 1978. Ron Baecker, their adviser, came in Monday morning furious that they had been hacking instead of working on their thesis. When he saw what we were doing, his tone changed completely and he asked if he could use it to send out a grant application he was working on. I used it for my 4th year optics thesis, which caused my prof to say I had obviously plagiarized it from somewhere, because there was otherwise no way to produce something that looked like that (Xeroxed Versatec paper). I had to work hard to convince him I had not cheated. Later that year we, mostly Bill, coupled it to troff, along with some digitized fonts, and it went out on the Toronto tapes, with our names on it. For many years I saw evidence in scientific papers of people using Bill's digitization of the Bodoni fonts. This is where it gets interesting. Berkeley took it, tweaked it some - improved it yes, but it was substantially our code - and shipped it out, with our names removed and "Copyright the Regents of the University of California" across the top. I was seriously pissed but there was really nothing I could do about it. Years later I finally asked Joy about it, and his unapologetic answer was their lawyers didn't want our names on their software so they dropped them. When Dennis Ritchie and Greg Chesson - together, yikes - were interviewing me for my job at Bell Labs, Dennis, holding my resume, asked why I had had worked on Versatec support for nroff and troff when Berkeley had already done it. I believe the force of my reply helped convince them I was worth hiring. Years later, bless him, Henry Spencer said something on Usenet explaining why the "Berkeley typesetting software" was missing the names of those who created it. He was in the lab that weekend and saw it happen. -rob On Fri, Mar 10, 2023 at 1:25 AM Clem Cole wrote: > As far as I know, Tom Ferrin wrote the original in the late 1970s - it is > on the original UCSF tape as part of his UNIX graphics tools. That said, > Joy may have passed it along on the BSD tapes also. It's called "vcat" and > converts Wang C/A/T codes to plotter strokes on a smaller (11/12in wide > IIRC) Varian (originally) and small Versatec [wet / kerosene style] plotter > using the 200 bpi Hershey fonts that the CMU/MIT/Stanford XGP had used. > IIRC, UCB had a large format Versatec (36"/48") and the UCB version could > do N pages at a time. In the Adobe 'transcript' package is a similar > program (based on Tom work) but outputs using Adobe Fonts. > > It might take some searching "foo" to find them, but Tom's program is what > most of us used back in the day before the Imagen and later Apple > LaserWriter - particularly after having had access to an XGP or a Xerox > Dover in college ;-) > ᐧ > > On Wed, Mar 8, 2023 at 6:10 PM David Arnold wrote: > >> > On 9 Mar 2023, at 03:30, Angelo Papenhoff wrote: >> >> … >> >> > And even then one would need CAT emulation, which I >> > haven't bothered with yet. >> >> That sounds like a fun project — is there really no such beast already? >> >> >> >> >> d >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Mar 10 07:04:31 2023 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 10 Mar 2023 08:04:31 +1100 (EST) Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: On Fri, 10 Mar 2023, Rob Pike wrote: > I had an idea. I asked Tom Duff, Mike Tilson, Bill Reeves to help me put > together tools and font digitizations to "print" nroff output to the > Versatec plotter one weekend in early 1978. [...] We did something like that for our LV-11; I vaguely remember italics being implemented by "sloping" the text, and bold by offsetting by a dot. Mind you, that Versatec spent most of its time plotting biorhythm charts for the operators and their GFs; well, this was the 70s, man... -- Dave From rich.salz at gmail.com Fri Mar 10 08:32:33 2023 From: rich.salz at gmail.com (Rich Salz) Date: Thu, 9 Mar 2023 17:32:33 -0500 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: > Years later I finally asked Joy about it, and his unapologetic answer was their lawyers didn't want our names on their software so they dropped them. I am *SO GLAD* that things don't work like that any more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Mar 10 09:01:30 2023 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 10 Mar 2023 00:01:30 +0100 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary Message-ID: <20230309230130.q4I-f%steffen@sdaoden.eu> I wonder if Pink Floyd's Summer68 maybe refers to this. Other than that i am addicted and could not live without it. The other (terrible) song is from 1984 (east southern US). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From tuhs at tuhs.org Fri Mar 10 09:18:07 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Thu, 09 Mar 2023 23:18:07 +0000 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230309230130.q4I-f%steffen@sdaoden.eu> References: <20230309230130.q4I-f%steffen@sdaoden.eu> Message-ID: GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs... Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do? Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs? Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right. Any alternative camps out there? - Matt G. ------- Original Message ------- On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso wrote: > I wonder if Pink Floyd's Summer68 maybe refers to this. > Other than that i am addicted and could not live without it. > The other (terrible) song is from 1984 (east southern US). > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) From imp at bsdimp.com Fri Mar 10 09:21:57 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Mar 2023 15:21:57 -0800 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> Message-ID: On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS wrote: > GOTO is one of those paradoxical things where I would only trust the most > sophisticated engineer to know when it's acceptable to use a GOTO but on > the flip side would be suspicious of anyone claiming to be an engineer that > uses any amount of GOTOs... > > Were any of the various GOTOs in languages ever meant to be any more than > providing the same level of control that branch statements in assembly do? > Was there ever some vision anyone's aware of concerning a sophisticated, > dependable use of GOTOs? Since my first days poking around learning C GOTO > has been mentally filed away as an assembly vestige for folks in > transition, not a dependable construct in its own right. Any alternative > camps out there? > In C I use it all the time to do goto err for common error recovery because C doesn't have anything better. Warner > - Matt G. > > ------- Original Message ------- > On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso < > steffen at sdaoden.eu> wrote: > > > > I wonder if Pink Floyd's Summer68 maybe refers to this. > > Other than that i am addicted and could not live without it. > > The other (terrible) song is from 1984 (east southern US). > > > > --steffen > > | > > |Der Kragenbaer, The moon bear, > > |der holt sich munter he cheerfully and one by one > > |einen nach dem anderen runter wa.ks himself off > > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emu at e-bbes.com Fri Mar 10 09:24:47 2023 From: emu at e-bbes.com (emanuel stiebler) Date: Thu, 9 Mar 2023 18:24:47 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: <7w7cvr4x36.fsf@junk.nocrew.org> References: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> <7w7cvr4x36.fsf@junk.nocrew.org> Message-ID: On 2023-03-08 00:43, Lars Brinkhoff wrote: > Noel Chiappa wrote: >>> The first frame buffers from Evans and Sutherland were at University >>> of Utah, DOD SITES and NYIT CGL as I recall. Circa 1974 to 1978. >> >> Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to >> PDP-10's; '74-'78 sounds like an interim period.) > > The Picture System from 1974 was based on a PDP-11/05. It looks like > vector graphics rather than a frame buffer though. > > http://archive.computerhistory.org/resources/text/Evans_Sutherland/EvansSutherland.3D.1974.102646288.pdf If the drawing speed is measured in inches, probably a vector screen ... From clemc at ccc.com Fri Mar 10 09:25:32 2023 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Mar 2023 18:25:32 -0500 Subject: [TUHS] 'Huge' file support removed from PWB1 In-Reply-To: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> References: <20230308131008.0C2D018C07B@mercury.lcs.mit.edu> Message-ID: I talked with John Mashey this PM and asked him about the huge file stuff and PWB1. First, he did not remember that they had done that, but ... He then emphasized that the PWB team was running the first (and for a long time the largest) "computer center" using UNIX in the Bell System in Piscataway - supporting over 1000 programmers as a front end to the mainframes. His memory is that they mostly used 88 Mbyte RP04s [remember, at the time, RK05s were only 2.5M]. Needing to support a megabyte or larger file would have been relatively rare for them. He also pointed out they needed to run their system on systems as small as 48K byte 11/40s to as large as 1M 11/70s. As he said, his team tried to track Dennis and Ken's Research system closely since the PWB team was not primarily in the system development/enhancement business -* i.e.* they tied to keep what would become PWB1 and whatever was running at Research as similar as they could [he told some stories about running to MH to get Dennis' latest compiler binary because the incremental development scheme dmr used would make someone like PWB that took snapshots at different times, end up with a compiler that could not compile itself --#1#]. But the PWB group >> was << interested in making the system they were running as reliable as possible and, more importantly, being as graceful as possible when different resources were exhausted. He said it would have made sense for them to remove the "huge file" support to help to defend against running out of space and the system having issues [V6 was extremely ungrateful about that condition]. So limiting file size became a simple quota, if you will. A runaway program was less likely to take the system out. So the process would die because the file got too large (or, to use the IBM shop term in those days -- ABEND). #1# He also regaled a bit about Ken's infamous Turning Award hack and discovering symbols in the compiler binary they could not understand ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.unix.guy at gmail.com Fri Mar 10 09:26:36 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Thu, 9 Mar 2023 18:26:36 -0500 Subject: [TUHS] Unix System V date command update Message-ID: Guys, Find attached an updated date.c for Y2K for System V IE: date 0309182123 Also works: # date +%D 03/09/23 # date +%y%m%d%H%M 2303091823 Interesting Version 7 wants: date 2303091821 Ken -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: date.c Type: text/x-csrc Size: 9210 bytes Desc: not available URL: From luther at makerlisp.com Fri Mar 10 09:31:25 2023 From: luther at makerlisp.com (Luther Johnson) Date: Thu, 9 Mar 2023 16:31:25 -0700 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> Message-ID: <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> I agree, unless I use setjmp/longjmp for that. Besides error recovery, there are occasionally other times when we want to locally "return" to a common state and start "from the top" again. I find such uses very clear in their intent, and if commented well, not hard to follow at all - as long as there is not more than one "top" :) On 03/09/2023 04:21 PM, Warner Losh wrote: > > > On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS > wrote: > > GOTO is one of those paradoxical things where I would only trust > the most sophisticated engineer to know when it's acceptable to > use a GOTO but on the flip side would be suspicious of anyone > claiming to be an engineer that uses any amount of GOTOs... > > Were any of the various GOTOs in languages ever meant to be any > more than providing the same level of control that branch > statements in assembly do? Was there ever some vision anyone's > aware of concerning a sophisticated, dependable use of GOTOs? > Since my first days poking around learning C GOTO has been > mentally filed away as an assembly vestige for folks in > transition, not a dependable construct in its own right. Any > alternative camps out there? > > > > In C I use it all the time to do goto err for common error recovery > because C doesn't have anything better. > > Warner > > - Matt G. > > ------- Original Message ------- > On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso > > wrote: > > > > I wonder if Pink Floyd's Summer68 maybe refers to this. > > Other than that i am addicted and could not live without it. > > The other (terrible) song is from 1984 (east southern US). > > > > --steffen > > | > > |Der Kragenbaer, The moon bear, > > |der holt sich munter he cheerfully and one by one > > |einen nach dem anderen runter wa.ks himself off > > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshnatis0 at gmail.com Fri Mar 10 09:44:13 2023 From: joshnatis0 at gmail.com (josh) Date: Thu, 9 Mar 2023 18:44:13 -0500 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> Message-ID: This blog post compares the clarity of a number of programs written with goto vs. with other control flow methods: https://blog.joren.ga/gotophobia-harmful Knuth’s “Structured Programming with go to Statements” argues that we eventually missed the main point of structured programming by focusing too much on goto. https://pic.plover.com/knuth-GOTO.pdf Error handling (especially in loops or when releasing resources in non-RAII languages) and implementing state machines are commonly brought up as cases where goto is more fitting than common “structured” control flow statements. I think some newer languages like Zig extend the “break” mechanism to let you break to a label, so that sort of covers the first case. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Fri Mar 10 09:51:05 2023 From: reed at reedmedia.net (Jeremy C. Reed) Date: Thu, 9 Mar 2023 23:51:05 +0000 (UTC) Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: <407644d5-1436-3c4f-cdfc-87635fcdc9df@reedmedia.net> On Fri, 10 Mar 2023, Rob Pike wrote: > Later that year we, mostly Bill, coupled it to troff, along with some > digitized fonts, and it went out on the Toronto tapes, with our names on it. > For many years I saw evidence in scientific papers of people using Bill's > digitization of the Bodoni fonts. Do you recall the name of this software or project? I tried various greps in a few of the Usenix archives but cannot tell what it is. Thanks From imp at bsdimp.com Fri Mar 10 09:54:43 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Mar 2023 15:54:43 -0800 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> Message-ID: Oh also sometimes for breaking out of multiple levels of while/for loops. The alternatives are often worse. Warner On Thu, Mar 9, 2023, 4:31 PM Luther Johnson wrote: > I agree, unless I use setjmp/longjmp for that. Besides error recovery, > there are occasionally other times when we want to locally "return" to a > common state and start "from the top" again. I find such uses very clear in > their intent, and if commented well, not hard to follow at all - as long as > there is not more than one "top" :) > On 03/09/2023 04:21 PM, Warner Losh wrote: > > > > On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS wrote: > >> GOTO is one of those paradoxical things where I would only trust the most >> sophisticated engineer to know when it's acceptable to use a GOTO but on >> the flip side would be suspicious of anyone claiming to be an engineer that >> uses any amount of GOTOs... >> >> Were any of the various GOTOs in languages ever meant to be any more than >> providing the same level of control that branch statements in assembly do? >> Was there ever some vision anyone's aware of concerning a sophisticated, >> dependable use of GOTOs? Since my first days poking around learning C GOTO >> has been mentally filed away as an assembly vestige for folks in >> transition, not a dependable construct in its own right. Any alternative >> camps out there? >> > > > In C I use it all the time to do goto err for common error recovery > because C doesn't have anything better. > > Warner > >> - Matt G. >> >> ------- Original Message ------- >> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso < >> steffen at sdaoden.eu> wrote: >> >> >> > I wonder if Pink Floyd's Summer68 maybe refers to this. >> > Other than that i am addicted and could not live without it. >> > The other (terrible) song is from 1984 (east southern US). >> > >> > --steffen >> > | >> > |Der Kragenbaer, The moon bear, >> > |der holt sich munter he cheerfully and one by one >> > |einen nach dem anderen runter wa.ks himself off >> > |(By Robert Gernhardt) >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Fri Mar 10 10:23:40 2023 From: rminnich at gmail.com (ron minnich) Date: Thu, 9 Mar 2023 16:23:40 -0800 Subject: [TUHS] scaling on TCP socket connections Message-ID: Ca. 1981, if memory serves, having even small numbers of TCP connections was not common. I was told at some point that Sun used UDP for NFS for that reason. It was a reasonably big deal when we started to move to TCP for NFS ca 1990 (my memory of the date -- I know I did it on my own for SunOS as an experiment when I worked at the SRC -- it seemed to come into general use about that time). What kind of numbers for TCP connections would be reasonable in 1980, 90, 2000, 2010? I sort of think I know, but I sort of think I'm probably wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davida at pobox.com Fri Mar 10 10:42:16 2023 From: davida at pobox.com (David Arnold) Date: Fri, 10 Mar 2023 11:42:16 +1100 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: References: Message-ID: Dan Kegel’s C10k site was 1999, wasn’t it? That’s probably a decent data point for c.2000 d > On 10 Mar 2023, at 11:24, ron minnich wrote: > >  > Ca. 1981, if memory serves, having even small numbers of TCP connections was not common. > > I was told at some point that Sun used UDP for NFS for that reason. It was a reasonably big deal when we started to move to TCP for NFS ca 1990 (my memory of the date -- I know I did it on my own for SunOS as an experiment when I worked at the SRC -- it seemed to come into general use about that time). > > What kind of numbers for TCP connections would be reasonable in 1980, 90, 2000, 2010? > > I sort of think I know, but I sort of think I'm probably wrong. From imp at bsdimp.com Fri Mar 10 10:48:16 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Mar 2023 16:48:16 -0800 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: References: Message-ID: On Thu, Mar 9, 2023, 5:23 PM ron minnich wrote: > Ca. 1981, if memory serves, having even small numbers of TCP connections > was not common. > > I was told at some point that Sun used UDP for NFS for that reason. It was > a reasonably big deal when we started to move to TCP for NFS ca 1990 (my > memory of the date -- I know I did it on my own for SunOS as an experiment > when I worked at the SRC -- it seemed to come into general use about that > time). > > What kind of numbers for TCP connections would be reasonable in 1980, 90, > 2000, 2010? > Normal systems: 10s, 100s, 1000s, 10ks. Depends on what is a reasonable system... With the high end 10x or 100x that or a bit more. These days we do 100ks of video streams at work on our high end boxes... Warner I sort of think I know, but I sort of think I'm probably wrong. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuhs at tuhs.org Fri Mar 10 10:54:48 2023 From: tuhs at tuhs.org (segaloco via TUHS) Date: Fri, 10 Mar 2023 00:54:48 +0000 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> Message-ID: I guess I hadn't considered deeply nested loops. I contort myself into a mental pretzel figuring out how to avoid GOTOs sometimes, maybe I could stand to embrace one every once in a while myself... Now doing some research, more languages support GOTO than I thought, including C#, PHP, even Rust for all its safety orientation appears to at least muster a GOTO-ish construct. If people keep doing it, it must still be wanted, needed, and useful. I stand corrected on my never-GOTO attitude. Now to slip a GOTO into a work project and see how long it takes to get chastised :) - Matt G. ------- Original Message ------- On Thursday, March 9th, 2023 at 3:54 PM, Warner Losh wrote: > Oh also sometimes for breaking out of multiple levels of while/for loops. The alternatives are often worse. > > Warner > > On Thu, Mar 9, 2023, 4:31 PM Luther Johnson wrote: > >> I agree, unless I use setjmp/longjmp for that. Besides error recovery, there are occasionally other times when we want to locally "return" to a common state and start "from the top" again. I find such uses very clear in their intent, and if commented well, not hard to follow at all - as long as there is not more than one "top" :) >> >> On 03/09/2023 04:21 PM, Warner Losh wrote: >> >>> On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS wrote: >>> >>>> GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs... >>>> >>>> Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do? Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs? Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right. Any alternative camps out there? >>> >>> In C I use it all the time to do goto err for common error recovery because C doesn't have anything better. >>> >>> Warner >>> >>>> - Matt G. >>>> >>>> ------- Original Message ------- >>>> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso wrote: >>>> >>>>> I wonder if Pink Floyd's Summer68 maybe refers to this. >>>>> Other than that i am addicted and could not live without it. >>>>> The other (terrible) song is from 1984 (east southern US). >>>>> >>>>> --steffen >>>>> | >>>>> |Der Kragenbaer, The moon bear, >>>>> |der holt sich munter he cheerfully and one by one >>>>> |einen nach dem anderen runter wa.ks himself off >>>>> |(By Robert Gernhardt) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pugs78 at gmail.com Fri Mar 10 10:59:54 2023 From: pugs78 at gmail.com (Tom Lyon) Date: Thu, 9 Mar 2023 16:59:54 -0800 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: References: Message-ID: Sun chose UDP for NFS at a point when few if any people believed TCP could go fast. I remember (early 80s) being told that one couldn't use TCP/IP in LANs because they were WAN protocols. In the late 80s, WAN people were saying you couldn't use TCP/IP because they were LAN protocols. But UDP for NFS was more attractive because it was not byte stream oriented, and didn't require copying to save for retransmissions. And there was hope we'd be able to do zero copy transmissions from the servers - also the reason for inventing Jumbo packets to match the 8K page size of Sun3 systems. I did get zero copy serving working with ND (network disk block protocol) - but it was terribly specific to particular hardware components. On Thu, Mar 9, 2023 at 4:24 PM ron minnich wrote: > Ca. 1981, if memory serves, having even small numbers of TCP connections > was not common. > > I was told at some point that Sun used UDP for NFS for that reason. It was > a reasonably big deal when we started to move to TCP for NFS ca 1990 (my > memory of the date -- I know I did it on my own for SunOS as an experiment > when I worked at the SRC -- it seemed to come into general use about that > time). > > What kind of numbers for TCP connections would be reasonable in 1980, 90, > 2000, 2010? > > I sort of think I know, but I sort of think I'm probably wrong. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Fri Mar 10 11:08:50 2023 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Mar 2023 17:08:50 -0800 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> Message-ID: On Thu, Mar 9, 2023, 5:55 PM segaloco wrote: > I guess I hadn't considered deeply nested loops. I contort myself into a > mental pretzel figuring out how to avoid GOTOs sometimes, maybe I could > stand to embrace one every once in a while myself... > Yea. I recall a proposal to add break label; and the label could only be at the end of a loop. The objection was why bloat the compiler with another goto... I developed my restricted lack of fear after a stint in Java with its multilevel break... Warner Now doing some research, more languages support GOTO than I thought, > including C#, PHP, even Rust for all its safety orientation appears to at > least muster a GOTO-ish construct. If people keep doing it, it must still > be wanted, needed, and useful. I stand corrected on my never-GOTO attitude. > Now to slip a GOTO into a work project and see how long it takes to get > chastised :) > > - Matt G. > ------- Original Message ------- > On Thursday, March 9th, 2023 at 3:54 PM, Warner Losh > wrote: > > Oh also sometimes for breaking out of multiple levels of while/for loops. > The alternatives are often worse. > > Warner > > On Thu, Mar 9, 2023, 4:31 PM Luther Johnson wrote: > >> I agree, unless I use setjmp/longjmp for that. Besides error recovery, >> there are occasionally other times when we want to locally "return" to a >> common state and start "from the top" again. I find such uses very clear in >> their intent, and if commented well, not hard to follow at all - as long as >> there is not more than one "top" :) >> On 03/09/2023 04:21 PM, Warner Losh wrote: >> >> >> >> On Thu, Mar 9, 2023, 4:18 PM segaloco via TUHS wrote: >> >>> GOTO is one of those paradoxical things where I would only trust the >>> most sophisticated engineer to know when it's acceptable to use a GOTO but >>> on the flip side would be suspicious of anyone claiming to be an engineer >>> that uses any amount of GOTOs... >>> >>> Were any of the various GOTOs in languages ever meant to be any more >>> than providing the same level of control that branch statements in assembly >>> do? Was there ever some vision anyone's aware of concerning a >>> sophisticated, dependable use of GOTOs? Since my first days poking around >>> learning C GOTO has been mentally filed away as an assembly vestige for >>> folks in transition, not a dependable construct in its own right. Any >>> alternative camps out there? >>> >> >> >> In C I use it all the time to do goto err for common error recovery >> because C doesn't have anything better. >> >> Warner >> >>> - Matt G. >>> >>> ------- Original Message ------- >>> On Thursday, March 9th, 2023 at 3:01 PM, Steffen Nurpmeso < >>> steffen at sdaoden.eu> wrote: >>> >>> >>> > I wonder if Pink Floyd's Summer68 maybe refers to this. >>> > Other than that i am addicted and could not live without it. >>> > The other (terrible) song is from 1984 (east southern US). >>> > >>> > --steffen >>> > | >>> > |Der Kragenbaer, The moon bear, >>> > |der holt sich munter he cheerfully and one by one >>> > |einen nach dem anderen runter wa.ks himself off >>> > |(By Robert Gernhardt) >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Fri Mar 10 11:24:40 2023 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 9 Mar 2023 20:24:40 -0500 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: References: Message-ID: <933FFF31-B25F-4EE1-BD03-526A3E418528@serissa.com> I have one datapoint. In late 1994 or early 1995 at Internet 1.0 startup Open Market we were working on web servers and IIRC had no trouble with 1000 (or 1024?) simultaneous clients using TCP. This was Alpha OSF/1 and probably had 256 MB or some such ungodly amount of RAM. The big change from the NCSA server was a single process model rather than one process per connection. I think there was a select(2) limit that was smaller, so perhaps there were a few processes rather than just one. I have the sources somewhere. Andy Payne was the lead engineer and I remember him slapping my fingers when I changed the way logging worked. Regarding TCP performance one story about the turning point was Van Jacobson tuning the most-likely path down to a very few vax instructions for packet receiption. That was what, Reno maybe? One of the later BSDs. -Larry > On Mar 9, 2023, at 7:59 PM, Tom Lyon wrote: > > Sun chose UDP for NFS at a point when few if any people believed TCP could go fast. > I remember (early 80s) being told that one couldn't use TCP/IP in LANs because they were WAN protocols. In the late 80s, WAN people were saying you couldn't use TCP/IP because they were LAN protocols. > > But UDP for NFS was more attractive because it was not byte stream oriented, and didn't require copying to save for retransmissions. And there was hope we'd be able to do zero copy transmissions from the servers - also the reason for inventing Jumbo packets to match the 8K page size of Sun3 systems. > > I did get zero copy serving working with ND (network disk block protocol) - but it was terribly specific to particular hardware components. > > On Thu, Mar 9, 2023 at 4:24 PM ron minnich > wrote: >> Ca. 1981, if memory serves, having even small numbers of TCP connections was not common. >> >> I was told at some point that Sun used UDP for NFS for that reason. It was a reasonably big deal when we started to move to TCP for NFS ca 1990 (my memory of the date -- I know I did it on my own for SunOS as an experiment when I worked at the SRC -- it seemed to come into general use about that time). >> >> What kind of numbers for TCP connections would be reasonable in 1980, 90, 2000, 2010? >> >> I sort of think I know, but I sort of think I'm probably wrong. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdm at cfcl.com Fri Mar 10 11:31:17 2023 From: rdm at cfcl.com (Rich Morin) Date: Thu, 9 Mar 2023 17:31:17 -0800 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> Message-ID: <3F175E13-65E1-420C-B005-24C1A1F47482@cfcl.com> > On Mar 9, 2023, at 15:18, segaloco via TUHS wrote: > > GOTO is one of those paradoxical things where I would only trust the most sophisticated engineer to know when it's acceptable to use a GOTO but on the flip side would be suspicious of anyone claiming to be an engineer that uses any amount of GOTOs... > > Were any of the various GOTOs in languages ever meant to be any more than providing the same level of control that branch statements in assembly do? Was there ever some vision anyone's aware of concerning a sophisticated, dependable use of GOTOs? Since my first days poking around learning C GOTO has been mentally filed away as an assembly vestige for folks in transition, not a dependable construct in its own right. Any alternative camps out there? COBOL's ALTER statement is kind of analogous to a computed GOTO, but it adds a dangerous aspect of "action at a distance" (i.e., monkey-patching which invisibly modifies the control flow of the original code): "The ALTER statement changes the transfer point specified in a GO TO statement" https://www.mainframebug.com/tuts/COBOL/module7/Top18_COBOL_ALTER_statement.php "The ALTER Statement" https://www.microfocus.com/documentation/visual-cobol/vc60/DevHub/HRLHLHPDF803.html The problem, IMO, is that the compile-time program flow can be invisibly altered at run time, by code anywhere else in the program. So, there is no requirement that a given branch, GOTO, or noop statement will have its compile-time semantics. If used with restraint, this be used to optimize code paths, but it can easily be overused. Just as a GOTO is a surfacing of the assembler branch instruction(s), the ALTER is analogous to an old assembly-language trick (aka hack): dynamically modifying "br*/noop foo" commands. FWIW, I didn't use either the ALTER or the trick in my own code, but I did keep them in reserve (:-). In one of my earliest COBOL projects, the code came to me with an infestation of ALTER statements: specifically, a hierarchy of IF statements with ALTER statements at various levels. This was used at startup time, to configure the remainder of the program. All very elegant, but really overkill for the task at hand. As I explained to my boss, the ALTER statements made the code really difficult to understand. With his permission, I removed the nest of ALTERs and reworked the remaining control flow as needed. I was greatly assisted in this by the fact that I could retain the DATA DIVISION as-is, and merely implement the (rather prosaic) control flow that we actually used. And no, I don't want to return to either assembler or COBOL (:-). -r From lm at mcvoy.com Fri Mar 10 11:32:16 2023 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Mar 2023 17:32:16 -0800 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: References: Message-ID: <20230310013216.GP9225@mcvoy.com> SGI made TCP go very fast on 200Mhz MIPS processors. The tricks were to mark the page copy on write on output so the driver could use the page without copying and to page flip on input. Only worked with multiples of page sized requests. SGI had very fast sequential I/O through XFS (the trick there was big I/O requests on files opened with O_DIRECT, the volume manager split the request into chunks sending each chunk to a disk controller; when you get the stupid 200Mhz processors out of the way and spin up a boat load of DMA engines, yeah, you can scale up until the bus is full). And they had fast TCP over Hippi. I showed up and asked why hasn't anyone plugged XFS into TCP? In a few weeks I wrote a user level server that demonstrated that it could work and that turned into this talk: http://mcvoy.com/lm/papers/bds.pdf If you don't go look it made O_DIRECT work on NFS and gave much faster NFS sequential I/O performance. Real NFS was 18MB/sec, my stuff was 67MB/sec for a single file, scaled to 100s of MB/sec. Everyone thought I was smart for doing that but the reality was the XFS/XLV folks and the TCP folks had done all the hard work, I just did some plumbing to connect the two fat pipes. I did eventually push it into the kernel because of stuff like the page cache coherency but even that was easy. And I found the SGI writeup of it, it has more perf numbers: http://mcvoy.com/lm/papers/bdspro.pdf If anyone cares I can post a link to the user level server code. On Thu, Mar 09, 2023 at 04:59:54PM -0800, Tom Lyon wrote: > Sun chose UDP for NFS at a point when few if any people believed TCP could > go fast. > I remember (early 80s) being told that one couldn't use TCP/IP in LANs > because they were WAN protocols. In the late 80s, WAN people were saying > you couldn't use TCP/IP because they were LAN protocols. > > But UDP for NFS was more attractive because it was not byte stream > oriented, and didn't require copying to save for retransmissions. And > there was hope we'd be able to do zero copy transmissions from the servers > - also the reason for inventing Jumbo packets to match the 8K page size of > Sun3 systems. > > I did get zero copy serving working with ND (network disk block protocol) - > but it was terribly specific to particular hardware components. > > On Thu, Mar 9, 2023 at 4:24???PM ron minnich wrote: > > > Ca. 1981, if memory serves, having even small numbers of TCP connections > > was not common. > > > > I was told at some point that Sun used UDP for NFS for that reason. It was > > a reasonably big deal when we started to move to TCP for NFS ca 1990 (my > > memory of the date -- I know I did it on my own for SunOS as an experiment > > when I worked at the SRC -- it seemed to come into general use about that > > time). > > > > What kind of numbers for TCP connections would be reasonable in 1980, 90, > > 2000, 2010? > > > > I sort of think I know, but I sort of think I'm probably wrong. > > -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From stewart at serissa.com Fri Mar 10 11:44:52 2023 From: stewart at serissa.com (Lawrence Stewart) Date: Thu, 9 Mar 2023 20:44:52 -0500 Subject: [TUHS] Origins of the frame buffer device In-Reply-To: References: <20230305185202.91B7B18C08D@mercury.lcs.mit.edu> <7w7cvr4x36.fsf@junk.nocrew.org> Message-ID: <92F13B52-ABCD-4EBD-8472-66F21A745244@serissa.com> Noel Chiappa wrote: >>>> The first frame buffers from Evans and Sutherland were at University >>>> of Utah, DOD SITES and NYIT CGL as I recall. Circa 1974 to 1978. >>> Other historical datapoints: I was at MIT ’72-’76 in the Architecture Machine Group (mostly because I was intimidated by the reception desk at LCS). There were a series of frame buffers during that time, including an 8-bit color mapped one I built in early 1976 for a senior thesis (a color printer). I don’t think anyone used them for programming or a GUI. Instead they were image output devices. Programming was mostly Imlacs or Tek or ASR33s or IBM 2741s. The weirdest display was somehow we had a wacky prototype 24-bit machine with a vector display. One of the scientists loaded a series of short vectors to turn it into a 128x128 raster display. The thing filled 3 or 4 racks. -L From robpike at gmail.com Fri Mar 10 11:58:01 2023 From: robpike at gmail.com (Rob Pike) Date: Fri, 10 Mar 2023 12:58:01 +1100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: <407644d5-1436-3c4f-cdfc-87635fcdc9df@reedmedia.net> References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> <407644d5-1436-3c4f-cdfc-87635fcdc9df@reedmedia.net> Message-ID: We just called it the Toronto typesetting software, but I don't know if it ever had a real name. As I wrote, it's on the Toronto distribution tape from the late '70s. -rob On Fri, Mar 10, 2023 at 10:51 AM Jeremy C. Reed wrote: > On Fri, 10 Mar 2023, Rob Pike wrote: > > > Later that year we, mostly Bill, coupled it to troff, along with some > > digitized fonts, and it went out on the Toronto tapes, with our names on > it. > > For many years I saw evidence in scientific papers of people using Bill's > > digitization of the Bodoni fonts. > > Do you recall the name of this software or project? I tried various > greps in a few of the Usenix archives but cannot tell what it is. > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Mar 10 12:10:38 2023 From: crossd at gmail.com (Dan Cross) Date: Thu, 9 Mar 2023 21:10:38 -0500 Subject: [TUHS] Unix System V date command update In-Reply-To: References: Message-ID: It's probably best not to attach a bunch of files to emails to TUHS; a better way might be to put these in, say, a github repository (or similar), where folks can snag them if they want them. Thanks! On Thu, Mar 9, 2023 at 6:26 PM KenUnix wrote: > > Guys, > > Find attached an updated date.c for Y2K for System V > > IE: date 0309182123 > > Also works: > # date +%D > 03/09/23 > # date +%y%m%d%H%M > 2303091823 > > Interesting Version 7 wants: date 2303091821 > > > Ken > > -- > WWL 📚 > > From usotsuki at buric.co Fri Mar 10 12:55:56 2023 From: usotsuki at buric.co (Steve Nickolas) Date: Thu, 9 Mar 2023 21:55:56 -0500 (EST) Subject: [TUHS] Unix System V date command update In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023, Dan Cross wrote: > It's probably best not to attach a bunch of files to emails to TUHS; a > better way might be to put these in, say, a github repository (or > similar), where folks can snag them if they want them. > > Thanks! > > On Thu, Mar 9, 2023 at 6:26 PM KenUnix wrote: >> >> Guys, >> >> Find attached an updated date.c for Y2K for System V >> >> IE: date 0309182123 FWIW, most of my "Strix" commands can be rolled on SVR4. I haven't yet gotten a working setup to be able to build and test for SVR3.2. Here's date: https://github.com/buricco/strix/blob/main/src/date.c -uso. From dave at horsfall.org Fri Mar 10 16:15:38 2023 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 10 Mar 2023 17:15:38 +1100 (EST) Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> Message-ID: On Thu, 9 Mar 2023, Warner Losh wrote: > In C I use it all the time to do goto err for common error recovery > because C doesn't have anything better. Me too :-) Seriously, I also use setjmp()/longjmp() for a more elegant exit from a deeply-nested loop; "break N" to break out of "N" loops, anyone? I haven't found that yet... Of course, in those days it was setexit() etc :-) -- Dave From jsg at jsg.id.au Fri Mar 10 16:33:12 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 10 Mar 2023 17:33:12 +1100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: <407644d5-1436-3c4f-cdfc-87635fcdc9df@reedmedia.net> References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> <407644d5-1436-3c4f-cdfc-87635fcdc9df@reedmedia.net> Message-ID: On Thu, Mar 09, 2023 at 11:51:05PM +0000, Jeremy C. Reed wrote: > On Fri, 10 Mar 2023, Rob Pike wrote: > > > Later that year we, mostly Bill, coupled it to troff, along with some > > digitized fonts, and it went out on the Toronto tapes, with our names on it. > > For many years I saw evidence in scientific papers of people using Bill's > > digitization of the Bodoni fonts. > > Do you recall the name of this software or project? I tried various > greps in a few of the Usenix archives but cannot tell what it is. > Thanks "This page appears twice in this issue. The first copy is the usual phototypesetter output. The second copy is the product of the Toronto typesetter simulator for the Versatec. The spacing between characters in the Versatec simulation does not appear correct due to the fact that the phototypesetter is mounted with the Sovran font and therefore the Toronto software is taking those font widths into account in calculating its spacing even though it is printing using Roman fonts." https://archive.org/details/login_november-1977/mode/2up "Bill Reeves, who also wrote vcat, a Versatec typesetter-simulator which runs as an output filter to troff. Vcat (which was used to generate this document) is available free as part of the University of Toronto distribution #3." https://archive.org/details/login_january-1980/page/n9/mode/2up I can't find the original Toronto distribution. Some documentation (no source) for a modified version with credits in: tuhs/Applications/Spencer_Tapes/del.tar.gz delaware/usgs.v7 "USGS Menlo Park Unix" U.S. Geological Survey, Menlo Park, California delaware/usgs.v7/man/chap1/trot.1 trot - troff output rotating program AUTHOR Bill Reeves, University of Toronto Martin Pensak, University of California, San Francisco delaware/usgs.v7/man/chap1/vcat.1 vcat - interpreter of troff output for Versatec AUTHORS Bill Reeves, University of Toronto Martin Pensak & Thomas Ferrin, University of California, San Francisco William Joy, University of California, Berkeley delaware/usgs.v7/man/chap5/tfonts.5 tfonts - troff versatec font usage AUTHOR Bill Reeves at University of Toronto. CSRG SCCS admin/admin/contrib/contrib has: Versatec printer/plotter support University of Toronto From jsg at jsg.id.au Fri Mar 10 17:50:51 2023 From: jsg at jsg.id.au (Jonathan Gray) Date: Fri, 10 Mar 2023 18:50:51 +1100 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: On Fri, Mar 10, 2023 at 07:48:26AM +1100, Rob Pike wrote: > > Years later, bless him, Henry Spencer said something on Usenet explaining > why the "Berkeley typesetting software" was missing the names of those who > created it. He was in the lab that weekend and saw it happen. > > -rob https://groups.google.com/g/net.unix-wizards/c/eZ1qIlRyhx0/m/UmE8cBRYbPEJ Henry Spencer in net.unix-wizards Dec 17, 1983 "The proper credits for vcat are roughly as follows: Bill Reeves most of vcat, and the font editor Tom Duff the inner loop of vcat, in pdp11 assembler Rob Pike the (unreleased) precursor to vcat (called vd) Mike Tilson miscellaneous optimizations The distributed source for vcat had Reeves, Pike, Tilson in the heading, and Duff in the lone .s file. My thanks to Rob Pike for refreshing my memory on this." From ralph at inputplus.co.uk Fri Mar 10 20:08:55 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Mar 2023 10:08:55 +0000 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> Message-ID: <20230310100855.C74931FBE4@orac.inputplus.co.uk> Hi Werner, > after a stint in Java with its multilevel break... Given sh(1)'s break takes an optional number of loops to break out of, I'm surprised C stuck with just the single-level break. -- Cheers, Ralph. From ralph at inputplus.co.uk Fri Mar 10 20:14:01 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Mar 2023 10:14:01 +0000 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: <20230310013216.GP9225@mcvoy.com> References: <20230310013216.GP9225@mcvoy.com> Message-ID: <20230310101401.CFFB51FBE4@orac.inputplus.co.uk> Hi Larry, > SGI made TCP go very fast on 200Mhz MIPS processors. The tricks were > to mark the page copy on write on output so the driver could use the > page without copying I understand that bit. > and to page flip on input. Could you expand that to a sentence or two. -- Cheers, Ralph. From tuhs at tuhs.org Fri Mar 10 20:14:49 2023 From: tuhs at tuhs.org (Paul Ruizendaal via TUHS) Date: Fri, 10 Mar 2023 11:14:49 +0100 Subject: [TUHS] scaling on TCP socket connections Message-ID: From reading a lot of papers on the origins of TCP I can confirm that people appear to have been thinking in terms of a dozen connections per machine, maybe half that on 16-bit hardware, around 1980. Maybe their expectations for PDP-10’s were higher, I have not looked into that much. > From: Tom Lyon > Sun chose UDP for NFS at a point when few if any people believed TCP could > go fast. > I remember (early 80s) being told that one couldn't use TCP/IP in LANs > because they were WAN protocols. In the late 80s, WAN people were saying > you couldn't use TCP/IP because they were LAN protocols. I’m not disputing the above, but there was a lot of focus on making TCP go fast enough for LAN usage in 1981-1984. For example see this 1981 post by Fabry/Joy in the TCP-IP mailing list: https://www.rfc-editor.org/in-notes/museum/tcp-ip-digest/tcp-ip-digest.v1n6.1 There are a few other similar messages to the list from around that time. An early issue was check-summing, with that initially taking 25% of CPU on a VAX750 when TCP was heavily used. Also ideas like having "trailing headers" (so that the data was block aligned) were driven by a search for LAN performance. Timeouts were reduced from 5s and 2s to 0.5s and 0.2s. Using a software interrupt instead of a kernel thread was another thing that made the stack more performant. It always seemed to me that the BBN-CSRG controversy over TCP code spurred both teams ahead with BBN more focussed on WAN use cases and CSRG more on LAN use cases. I would argue that no other contemporary network stack had this dual optimisation, with the possible exception of Datakit. From jnc at mercury.lcs.mit.edu Fri Mar 10 21:37:08 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Mar 2023 06:37:08 -0500 (EST) Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary Message-ID: <20230310113708.AD55518C080@mercury.lcs.mit.edu> > From: Warner Losh > In C I use it all the time to do goto err for common error recovery > because C doesn't have anything better. That's because C doesn't have 'conditions'. (Apparently, from the following posts, most people here are unfamiliar with them. Too bad, they are a great idea. OK summary here: http://gunkies.org/wiki/Condition_handler for those who are unfamiliar with the idea.) I was at one point writing a compiler using a recursive descent parser, and decided the code would be a lot simpler/cleaner if I had them. (If, for example, one discovers discovers an un-expected 'end of file', there can be an extremely large number of procedure invocations in between where that is discovered, and where it is desirable to handle it. So every possible intervening procedure would have to have an 'unexpected EOF' return value, one would have to write code in every possible intervening procedure to _handle_ an 'unexpected EOF' return value, etc.)' (Yes, I could have used setjmp/longjmp; those are effectively a limited version of condition handlers.) Since C has a stack, it was relatively easy to implement, without any compiler support: on() became a macro for 'if _on("condition_name")'; _on() was a partially-assembler procedure which i) stacked the handler (I forget where I put it; I may have created a special 'condition stack', to avoid too many changes to the main C stack), and ii) patched the calling procedure's return point to jump to some code that unstacked the handler, and iii) returned 'false'. If the condition occurred, a return from _on() was simulated, returning 'true', etc. So the code had things like: on ("unexpected EOF") { code to deal with it } With no compiler support, it added a tiny bit of overhead (stacking/unstacking conditions), but not too bad. John Wroclawski and someone implemented a very similar thing entirely in C; IIRC it was built on top of setjmp/longjmp. I don't recall how it dealt with un-stacking handlers on exit (which mine did silently). Noel From arnold at skeeve.com Fri Mar 10 21:37:39 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 10 Mar 2023 04:37:39 -0700 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230310100855.C74931FBE4@orac.inputplus.co.uk> References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> <20230310100855.C74931FBE4@orac.inputplus.co.uk> Message-ID: <202303101137.32ABbdfV003111@freefriends.org> Ralph Corderoy wrote: > Hi Werner, > > > after a stint in Java with its multilevel break... > > Given sh(1)'s break takes an optional number of loops to break out of, > I'm surprised C stuck with just the single-level break. C predates the Bourne shell by several years. Remember too that the C compiler had to fit in a small space; having multilevel or labelled breaks requires more bookkeeping. The idea of labelled loops is not at all new, Ada had them in the 80s and it wasn't new then. IIRC Go also provides them. Arnold From jnc at mercury.lcs.mit.edu Fri Mar 10 21:51:45 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Mar 2023 06:51:45 -0500 (EST) Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary Message-ID: <20230310115145.7F23118C080@mercury.lcs.mit.edu> > From: Warner Losh > for breaking out of multiple levels of while/for loops. Yeah, multi-level 'breaks' were one of the things I really missed in C. The other was BCPL's 'VALOF/RESULTIS'. Back before C compilers got good enough to do inline substitutions of small procedures (making macros with arguments less useful), it would have been nice to have, for macros that wanted to return something. Instead, one had to stand on one's head and use a '(cond ? ret1 : ret2 )' of some form. Noel From ralph at inputplus.co.uk Fri Mar 10 21:51:45 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Mar 2023 11:51:45 +0000 Subject: [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) In-Reply-To: <20230310113708.AD55518C080@mercury.lcs.mit.edu> References: <20230310113708.AD55518C080@mercury.lcs.mit.edu> Message-ID: <20230310115145.84A89212A8@orac.inputplus.co.uk> Hi Noel, > > In C I use it all the time to do goto err for common error recovery > > because C doesn't have anything better. > > That's because C doesn't have 'conditions'. (Apparently, from the following > posts, most people here are unfamiliar with them. Too bad, they are a great > idea. OK summary here: > > http://gunkies.org/wiki/Condition_handler I wasn't familiar with the term ‘condition handler’. That page starts ‘A condition handler (sometimes exception handler) refers to a mechanism in some programming languages which allows the programmer to provide code to handle the occurrence of a exception or condition (terminology varies, but the substance does not).’ Oh, exceptions. I know what they are and if you say above that most people are unfamiliar with them due to their use of goto then that's probably wrong. There are good reasons languages like Go chose not to include them. https://go.dev/doc/faq#exceptions -- Cheers, Ralph. From ralph at inputplus.co.uk Fri Mar 10 21:56:30 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Mar 2023 11:56:30 +0000 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <202303101137.32ABbdfV003111@freefriends.org> References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> <20230310100855.C74931FBE4@orac.inputplus.co.uk> <202303101137.32ABbdfV003111@freefriends.org> Message-ID: <20230310115630.7466D212A8@orac.inputplus.co.uk> Hi Arnold, > > > after a stint in Java with its multilevel break... > > > > Given sh(1)'s break takes an optional number of loops to break out of, > > I'm surprised C stuck with just the single-level break. > > C predates the Bourne shell by several years. Yes, but C was evolving. As it aged and spread in use, I agree it could change less easily. > Remember too that the C compiler had to fit in a small space; having > multilevel or labelled breaks requires more bookkeeping. Is it more bookkeeping than is already needed to handle the ends of the nested for-loops, say? -- Cheers, Ralph. From arnold at skeeve.com Fri Mar 10 21:59:21 2023 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 10 Mar 2023 04:59:21 -0700 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230310115630.7466D212A8@orac.inputplus.co.uk> References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> <20230310100855.C74931FBE4@orac.inputplus.co.uk> <202303101137.32ABbdfV003111@freefriends.org> <20230310115630.7466D212A8@orac.inputplus.co.uk> Message-ID: <202303101159.32ABxLSD007196@freefriends.org> Ralph Corderoy wrote: > > Remember too that the C compiler had to fit in a small space; having > > multilevel or labelled breaks requires more bookkeeping. > > Is it more bookkeeping than is already needed to handle the ends of the > nested for-loops, say? Yes, since you have to keep track of a label in a table somewhere that you can look up. Is it *that* much more that the PDP-11 C compiler could not have handled it? I don't know. Arnold From ralph at inputplus.co.uk Fri Mar 10 22:11:34 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Mar 2023 12:11:34 +0000 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <202303101159.32ABxLSD007196@freefriends.org> References: <20230309230130.q4I-f%steffen@sdaoden.eu> <849f8da7-8df2-619c-6080-d40d0ef6fc57@makerlisp.com> <20230310100855.C74931FBE4@orac.inputplus.co.uk> <202303101137.32ABbdfV003111@freefriends.org> <20230310115630.7466D212A8@orac.inputplus.co.uk> <202303101159.32ABxLSD007196@freefriends.org> Message-ID: <20230310121134.71C63212A8@orac.inputplus.co.uk> Hi Arnold, > > > Remember too that the C compiler had to fit in a small space; > > > having multilevel or labelled breaks requires more bookkeeping. > > > > Is it more bookkeeping than is already needed to handle the ends of > > the nested for-loops, say? > > Yes, since you have to keep track of a label in a table somewhere that > you can look up. Oh, I think our wires are crossed. I wrote: > Given sh(1)'s break takes an optional number of loops to break out of, > I'm surprised C stuck with just the single-level break. In other words, ‘break 2’ works in sh but not in C. You added labelled breaks; I wasn't asking if they upped the housekeeping, just ‘break 2’. -- Cheers, Ralph. From jnc at mercury.lcs.mit.edu Fri Mar 10 22:15:50 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Mar 2023 07:15:50 -0500 (EST) Subject: [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) Message-ID: <20230310121550.9A80718C080@mercury.lcs.mit.edu> > From: Ralph Corderoy > if you say above that most people are unfamiliar with them due to their > use of goto then that's probably wrong I didn't say that. I was just astonished that in a long thread about handling exceptional conditions, nobody had mentioned . . . exceptions. Clearly, either unfamiliarity (perhaps because not many laguages provide them - as you point out, Go does not), or not top of mind. Noel From lars at nocrew.org Fri Mar 10 23:09:25 2023 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 10 Mar 2023 13:09:25 +0000 Subject: [TUHS] Conditions, AKA exceptions. In-Reply-To: <20230310121550.9A80718C080@mercury.lcs.mit.edu> (Noel Chiappa's message of "Fri, 10 Mar 2023 07:15:50 -0500 (EST)") References: <20230310121550.9A80718C080@mercury.lcs.mit.edu> Message-ID: <7wwn3o21oa.fsf@junk.nocrew.org> Noel Chiappa writes: > I was just astonished that in a long thread about handling exceptional > conditions, nobody had mentioned . . . exceptions. Clearly, either > unfamiliarity (perhaps because not many laguages provide them - as you > point out, Go does not), or not top of mind. Seems to me exceptions are quite mainstream: CLU, C++, Java, C#, JavaScript, Python all have them. Arguably Go too, in the form of panic/recover. From clemc at ccc.com Fri Mar 10 23:11:34 2023 From: clemc at ccc.com (Clem Cole) Date: Fri, 10 Mar 2023 08:11:34 -0500 Subject: [TUHS] Fifth Edition Manual Restoration In-Reply-To: References: <944F23E0-DBB0-45E3-AE08-3CF17AE98426@pobox.com> Message-ID: I dug up the 1991 UCB source to vcat from UUNET archives I have and Rob's note about the 1983 Regents copyright. I'll keep digging - BTW there is no assembler in this version. Finding a copy of the original 't' for Toronto directory from the 1977 Harvard USENIX tape would be helpful. I spoke with Henry Spencer yesterday, like me - Henry has the '79 Toronto USENIX tape (which is what is the TUHS archives). I'll try to track down Tom Ferrin, Tom Duff, Bill and Mike later. ᐧ ᐧ ᐧ On Fri, Mar 10, 2023 at 2:50 AM Jonathan Gray wrote: > On Fri, Mar 10, 2023 at 07:48:26AM +1100, Rob Pike wrote: > > > > Years later, bless him, Henry Spencer said something on Usenet explaining > > why the "Berkeley typesetting software" was missing the names of those > who > > created it. He was in the lab that weekend and saw it happen. > > > > -rob > > https://groups.google.com/g/net.unix-wizards/c/eZ1qIlRyhx0/m/UmE8cBRYbPEJ > Henry Spencer in net.unix-wizards Dec 17, 1983 > > "The proper credits for vcat are roughly as follows: > > Bill Reeves most of vcat, and the font editor > Tom Duff the inner loop of vcat, in pdp11 assembler > Rob Pike the (unreleased) precursor to vcat (called vd) > Mike Tilson miscellaneous optimizations > > The distributed source for vcat had Reeves, Pike, Tilson in the heading, > and Duff in the lone .s file. My thanks to Rob Pike for refreshing my > memory on this." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralph at inputplus.co.uk Fri Mar 10 23:15:12 2023 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 10 Mar 2023 13:15:12 +0000 Subject: [TUHS] Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary) In-Reply-To: <20230310121550.9A80718C080@mercury.lcs.mit.edu> References: <20230310121550.9A80718C080@mercury.lcs.mit.edu> Message-ID: <20230310131512.891A8212A8@orac.inputplus.co.uk> Hi Noel, > > if you say above that most people are unfamiliar with them due to > > their use of goto then that's probably wrong > > I didn't say that. Thanks for clarifying; I did know it was a possibility. > I was just astonished that in a long thread about handling exceptional > conditions, nobody had mentioned . . . exceptions. Clearly, either > unfamiliarity (perhaps because not many laguages provide them - as you > point out, Go does not), or not top of mind. Or perhaps those happy to use gotos also tend to be those who dislike exceptions. :-) Anyway, I'm off-TUHS-pic so follow-ups set to goto COFF. -- Cheers, Ralph. From ron at ronnatalie.com Sat Mar 11 00:16:24 2023 From: ron at ronnatalie.com (Ronald Natalie) Date: Fri, 10 Mar 2023 14:16:24 +0000 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230310115145.7F23118C080@mercury.lcs.mit.edu> References: <20230310115145.7F23118C080@mercury.lcs.mit.edu> Message-ID: Multilevel breaks are as bad as goto with regard to structure violation. ------ Original Message ------ >From "Noel Chiappa" To tuhs at tuhs.org Date 3/10/2023 6:51:45 AM Subject [TUHS] Re: I can't drive 55: "GOTO considered harmful" 55th anniversary > > From: Warner Losh > > > for breaking out of multiple levels of while/for loops. > >Yeah, multi-level 'breaks' were one of the things I really missed in C. > > From cowan at ccil.org Sat Mar 11 00:39:22 2023 From: cowan at ccil.org (John Cowan) Date: Fri, 10 Mar 2023 09:39:22 -0500 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230310115145.7F23118C080@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 10, 2023 at 9:16 AM Ronald Natalie wrote: Multilevel breaks are as bad as goto with regard to structure violation. > No more so than `return` statements in arbitrary places, which nobody worries about any more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Mar 11 01:10:07 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 10 Mar 2023 07:10:07 -0800 Subject: [TUHS] scaling on TCP socket connections In-Reply-To: <20230310101401.CFFB51FBE4@orac.inputplus.co.uk> References: <20230310013216.GP9225@mcvoy.com> <20230310101401.CFFB51FBE4@orac.inputplus.co.uk> Message-ID: <20230310151007.GU9225@mcvoy.com> On Fri, Mar 10, 2023 at 10:14:01AM +0000, Ralph Corderoy wrote: > Hi Larry, > > > SGI made TCP go very fast on 200Mhz MIPS processors. The tricks were > > to mark the page copy on write on output so the driver could use the > > page without copying > > I understand that bit. > > > and to page flip on input. > > Could you expand that to a sentence or two. Sure. If you are using something like Hippi where the data size is at least as big as a page, the networking stack can arrange to send data that is a multiple of a page size. When that data works its way up the stack to where a process is waiting in a read(), if the process has asked for a read of a size that is a multiple of a page size, it can just diddle the page tables and take out the pages that the process had and give them to the kernel and put in the pages that the kernel had and give them to the process. That seems like a lot but it's basically what happens in TLB miss and that code is very small and fast. As I was thinking about this there was another thing SGI did that was new to me at the time. Interrupt coalescing. When a packet came in and the driver pulled it off the wire, the driver could look to see if there was going to be another interrupt because another packet had arrived. Then the driver grabbed that packet as well, saving all the overhead of an interrupt. MIPS cpus were not fast but SGI wall papered over that problem by being very clever when they needed to be. From ken.unix.guy at gmail.com Sat Mar 11 01:25:15 2023 From: ken.unix.guy at gmail.com (KenUnix) Date: Fri, 10 Mar 2023 10:25:15 -0500 Subject: [TUHS] simh running System V add serial (telnet) lines Message-ID: I have successfully got System V running on a PDP11 sim. I have been trying to add serial lines like on Version 7 but have had no success. What would be necessary under System V on a sim to do so. I have already tried the SIMH group but no working answers. If direct telnet is a better way please let me know. Thanks Ken -- WWL 📚 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Mar 11 01:37:02 2023 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Mar 2023 10:37:02 -0500 (EST) Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary Message-ID: <20230310153702.AFF3418C080@mercury.lcs.mit.edu> > From: "Ronald Natalie" > Multilevel breaks are as bad as goto with regard to structure violation. In a way, you are right. There isn't really much difference between: for (mumble) { for (foobar) { do some stuff break-2; } } and: for (mumble) { for (foobar) { do some stuff goto all_loops_done; } } all_loops_done: The former is basically just 'syntactic sugar' for the latter. I think the point is that goto's aren't necessarily _always_ bad, in and of themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's in a _structured_ way (oxymoronic as that sounds), to get around things that are lacking in the language's flow-control, they're probably fine. Then, of course, one gets into the usual shrubbery of 'but suppose someone uses them in a way that's _not_ structured?' There's no fixing stupid, is my response. Nested 'if/then/else' can be used to write comletely incomprehensible code (I have an amusing story about that) - but that's not an argument against nested 'if/then/else'. As I've said before, the best sculpting tools in the world won't make a great sculptor out of a ham-handed bozo. Noel From lm at mcvoy.com Sat Mar 11 01:46:02 2023 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 10 Mar 2023 07:46:02 -0800 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230310153702.AFF3418C080@mercury.lcs.mit.edu> References: <20230310153702.AFF3418C080@mercury.lcs.mit.edu> Message-ID: <20230310154602.GX9225@mcvoy.com> I've used gotos for decades but in a "structured" way. My functions have a pattern: and there are a series of labels in the deallocation section. Then while you are wandering through the allocation section, you can jump to the right spot in the deallocation section. And yes, this is a simplification because I initialize all my pointers to NULL so the deallocation is all if (p) free(p); but the idea is the same. You wind up some state and wind down some state and the gotos are used to jump to the right place to unwind. On Fri, Mar 10, 2023 at 10:37:02AM -0500, Noel Chiappa wrote: > > From: "Ronald Natalie" > > > Multilevel breaks are as bad as goto with regard to structure violation. > > In a way, you are right. There isn't really much difference between: > > for (mumble) { > for (foobar) { > do some stuff > break-2; > } > } > > and: > > for (mumble) { > for (foobar) { > do some stuff > goto all_loops_done; > } > } > all_loops_done: > > > The former is basically just 'syntactic sugar' for the latter. > > I think the point is that goto's aren't necessarily _always_ bad, in and of > themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's > in a _structured_ way (oxymoronic as that sounds), to get around things that > are lacking in the language's flow-control, they're probably fine. > > Then, of course, one gets into the usual shrubbery of 'but suppose someone > uses them in a way that's _not_ structured?' There's no fixing stupid, is my > response. Nested 'if/then/else' can be used to write comletely > incomprehensible code (I have an amusing story about that) - but that's not > an argument against nested 'if/then/else'. > > As I've said before, the best sculpting tools in the world won't make a great > sculptor out of a ham-handed bozo. > > Noel -- --- Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat From crossd at gmail.com Sat Mar 11 01:54:24 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 10 Mar 2023 10:54:24 -0500 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230310113708.AD55518C080@mercury.lcs.mit.edu> References: <20230310113708.AD55518C080@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 10, 2023 at 6:37 AM Noel Chiappa wrote: > > > From: Warner Losh > > > In C I use it all the time to do goto err for common error recovery > > because C doesn't have anything better. > > That's because C doesn't have 'conditions'. (Apparently, from the following > posts, most people here are unfamiliar with them. Too bad, they are a great > idea. OK summary here: > > http://gunkies.org/wiki/Condition_handler > > for those who are unfamiliar with the idea.) I don't know if I'd say they're a great idea. The problem with exceptions (nee conditions, though I most often associate the term "condition" with Lisp, and in particular Common Lisp's implementation has a rather different flavor in the ability to restart execution _at the point where the condition was raised_, even if the handler is conceptually much higher up in the call stack) is that they introduce non-linear control flow, which can be very difficult to reason about. This is especially challenging in code that may allocate resources and must manually deallocate them (such as C); without some notion of RAII or finalizers for arbitrary objects. It's really easy to introduce leaks in code with exceptions, and while often this is for memory, where you're ok if you're in a garbage collected language, you're gonna have a bad day when it's for something like file descriptors (which are much scarcer than memory). Unless pretty much everything is behind a stack guard, or whatever the moral equivalent in your language is, you're constrained to handling the errors at many places in the call stack, in which case, why bother? But the point about error handling and the use of `goto` in C in lieu of something better is well taken, and conditions are _a_ reasonable mechanism for dealing with the issue. I'd argue that a `Result` monad and some short-circuiting sugar used in conjunction with RAII is another that is better. For example in Rust, the result type interacts with the `?` operator so that, if a call returns a `Result`, the T will be unwrapped if the result is Ok(T), otherwise, the code will return `Err(E)`. So one can write code that has the brevity of exceptions without introducing the control-flow weirdness: fn make_request(host: &str) -> std::io::Result<()> { let req = "hi\r\n".as_bytes(); std::net::TcpStream::connect(host)?.write(req)?; Ok(()) } (Note that the TCP stream will be "dropped" after the call to `write`, and the drop impl on the TcpStream type will close the socket.) Combined with pattern matching on the error type, this is quite expressive. > I was at one point writing a compiler using a recursive descent parser, and > decided the code would be a lot simpler/cleaner if I had them. (If, for > example, one discovers discovers an un-expected 'end of file', there can be > an extremely large number of procedure invocations in between where that is > discovered, and where it is desirable to handle it. So every possible > intervening procedure would have to have an 'unexpected EOF' return value, > one would have to write code in every possible intervening procedure to > _handle_ an 'unexpected EOF' return value, etc.)' > > (Yes, I could have used setjmp/longjmp; those are effectively a limited > version of condition handlers.) > > Since C has a stack, it was relatively easy to implement, without any compiler > support: on() became a macro for 'if _on("condition_name")'; _on() was a > partially-assembler procedure which i) stacked the handler (I forget where I > put it; I may have created a special 'condition stack', to avoid too many > changes to the main C stack), and ii) patched the calling procedure's return > point to jump to some code that unstacked the handler, and iii) returned > 'false'. If the condition occurred, a return from _on() was simulated, > returning 'true', etc. > > So the code had things like: > > on ("unexpected EOF") { > code to deal with it > } > > With no compiler support, it added a tiny bit of overhead > (stacking/unstacking conditions), but not too bad. > > John Wroclawski and someone implemented a very similar thing > entirely in C; IIRC it was built on top of setjmp/longjmp. I don't > recall how it dealt with un-stacking handlers on exit (which mine > did silently). The plan9 kernel has something remarkably similar; there is a pre-process error stack containing the local equivalent of a bunch of `jmp_buf`'s. One could write, `if (waserror()) { /* handle cleanup */ }` where, `waserror` would push a jmp_buf onto the stack a la the `setjmp` equivalent. Code later on could call `error(Ewhatever)` and that would cache the error somewhere in the proc struct and invoke the `longjmp` equivalent to jump back to the label at the top of the stack, where `waserror()` would now return 1. Things would have to manually `poperror()`, to pop the stack. I'm told that the plan9 C compilers were callee-save in part to keep these state labels svelte. This got pulled into the Akaros kernel at one point, and for a while, we had someone working with us who was pretty prominent in the Linux community. What was interesting was that he was so used to the `goto err;` convention from that world that he just could not wrap his head around how the `waserror()` stuff worked; at one point there was a sequence like, char *foo; if (waserror()) { free(foo); return -1; } foo = malloc(len); something(); free(foo); return 0; ...and the guy just couldn't get how the code inside of the `waserror()` wasn't trashing the system, since obviously the malloc was done after `waserror()`, and so the pointer was meaningless at that point. It took quite a while to explain what was going on. Btw: I was once told by a reliable authority that the Go developers considered implementing exceptions, but decided against it because of the cognitive load it imposes. - Dan C. From crossd at gmail.com Sat Mar 11 02:04:19 2023 From: crossd at gmail.com (Dan Cross) Date: Fri, 10 Mar 2023 11:04:19 -0500 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: <20230310153702.AFF3418C080@mercury.lcs.mit.edu> References: <20230310153702.AFF3418C080@mercury.lcs.mit.edu> Message-ID: On Fri, Mar 10, 2023 at 10:37 AM Noel Chiappa wrote: >[snip] > I think the point is that goto's aren't necessarily _always_ bad, in and of > themselves; it's _how_, _where_ and _why_ one uses them. If one uses goto's > in a _structured_ way (oxymoronic as that sounds), to get around things that > are lacking in the language's flow-control, they're probably fine. Something that I think was likely a useful outcome of Djikstra's polemic is that people began looking at what they were using goto for and the things that were useful were extracted and codified as first-class mechanisms in lots of languages (e.g., `break` and `continue` for loops; exceptions; early function returns; multilevel-break where that's a thing in a particular language, etc). Goto is sort of like a hammer stone, it's useful for all kinds of things, but it's difficult to control without practice and patience. You can probably cut a diamond with one, but why endure the difficulty and take the risk if you have access to a jeweler's hammer? - Dan C. From phil at ultimate.com Sat Mar 11 02:30:02 2023 From: phil at ultimate.com (Phil Budne) Date: Fri, 10 Mar 2023 11:30:02 -0500 Subject: [TUHS] I can't drive 55: "GOTO considered harmful" 55th anniversary In-Reply-To: References: <20230310115145.7F23118C080@mercury.lcs.mit.edu> Message-ID: <202303101630.32AGU2OD008070@ultimate.com> ron at ronnatalie.com wrote: > Multilevel breaks are as bad as goto with regard to structure violation. Back when I was in compilers (so long ago, that it was the DEC PDP-10 FORTRAN compiler(*)) my recall is that break/continue never generated irreducible flow graphs, as goto can: https://en.wikipedia.org/wiki/Control-flow_graph#Reducibility I still remember the days when you could find C code written by PASCAL programmers, littered with condition variables on loops, and if statements to not execute the tail of the loop body if the loop condition was false. (*) The FORTRAN compiler was written in BLISS-10, which had labeled statements, and a "leave