From rich.salz at gmail.com Wed Sep 1 23:23:27 2021 From: rich.salz at gmail.com (Richard Salz) Date: Wed, 1 Sep 2021 09:23:27 -0400 Subject: [TUHS] A language question Message-ID: I hope that this does not start any kind of language flaming and that if something starts the moderator will shut it down quickly. Where did the name for abort(3) and SIGABRT come from? I believe it was derived from the IBM term ABEND, but would like to know one way or the other. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Sep 1 23:28:35 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 1 Sep 2021 09:28:35 -0400 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 9:25 AM Richard Salz wrote: > I hope that this does not start any kind of language flaming and that if > something starts the moderator will shut it down quickly. > > Where did the name for abort(3) and SIGABRT come from? I believe it was > derived from the IBM term ABEND, but would like to know one way or the > other. > Caveat that I don't know the answer to the question, but "abort" to cease doing something is pretty common in a lot of contexts; I always assumed this was picked up in the same way one would "abort the mission" or "abort the test flight" or something of that nature. As an aside, I'd always been under the impression that the "AB" in "ABEND" comes from, "abnormal"? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Sep 1 23:30:38 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 01 Sep 2021 07:30:38 -0600 Subject: [TUHS] Who said ... Message-ID: <202109011330.181DUc5v021332@freefriends.org> ... DEC Diagnositcs would run on a beached whale ? Anyone remember and/or know? (It seems to apply to other manufacturer's diagnostics as well, even today.) Thanks, Arnold From clemc at ccc.com Wed Sep 1 23:44:40 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Sep 2021 09:44:40 -0400 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 9:29 AM Dan Cross wrote: > As an aside, I'd always been under the impression that the "AB" in "ABEND" > comes from, "abnormal"? > That was what taught when I was hacking on TSS/360 (before I even saw UNIX). The term was used in the IBM batch system to say your job died or stopped with an abnormal ending (*i.e.* The job returned exit(NONZEROVALUE) to the OS in UNIX terms [or the OS killed it for some reason and forced it to exit in that manner]. As for Richard's question about abort(), no idea. I had heard the term used to kill off an errant process/job/task used in other systems before I ever came to Unix. You'd probably need some like Doug M or Knuth that goes back far enought to help you with history. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Sep 1 23:48:38 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Sep 2021 09:48:38 -0400 Subject: [TUHS] Who said ... In-Reply-To: <202109011330.181DUc5v021332@freefriends.org> References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: I believe the line was: *"running **DEC Diagnostics is like kicking a dead whale down the beach.*" As for who said it, I'm not sure, but I think it was someone like Rob Kolstad or Henry Spencer. I suspect a grep of some type on some extremely old net.noise archives of the late 1970s/early 1980s might find it. ᐧ ᐧ On Wed, Sep 1, 2021 at 9:31 AM wrote: > ... > DEC Diagnositcs would run on a beached whale > > ? > > Anyone remember and/or know? > > (It seems to apply to other manufacturer's diagnostics as well, even > today.) > > Thanks, > > Arnold > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Wed Sep 1 23:55:57 2021 From: cowan at ccil.org (John Cowan) Date: Wed, 1 Sep 2021 09:55:57 -0400 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: I heard this from my boss in the form "Mainframe programming is like moving a dead whale along the beach by kicking it" around 1985. On Wed, Sep 1, 2021 at 9:49 AM Clem Cole wrote: > I believe the line was: *"running **DEC Diagnostics is like kicking a > dead whale down the beach.*" > As for who said it, I'm not sure, but I think it was someone like Rob > Kolstad or Henry Spencer. > > I suspect a grep of some type on some extremely old net.noise archives of > the late 1970s/early 1980s might find it. > > ᐧ > ᐧ > > On Wed, Sep 1, 2021 at 9:31 AM wrote: > >> ... >> DEC Diagnositcs would run on a beached whale >> >> ? >> >> Anyone remember and/or know? >> >> (It seems to apply to other manufacturer's diagnostics as well, even >> today.) >> >> Thanks, >> >> Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Wed Sep 1 23:57:01 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 01 Sep 2021 07:57:01 -0600 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: <202109011357.181Dv1w1025209@freefriends.org> It was DMR who said Using TSO is like kicking a dead whale along a beach. My orginal quote about the diagnostics is correct, I'm pretty sure. Thanks, Arnold Clem Cole wrote: > I believe the line was: *"running **DEC Diagnostics is like kicking a dead > whale down the beach.*" > As for who said it, I'm not sure, but I think it was someone like Rob > Kolstad or Henry Spencer. > > I suspect a grep of some type on some extremely old net.noise archives of > the late 1970s/early 1980s might find it. > > ᐧ > ᐧ > > On Wed, Sep 1, 2021 at 9:31 AM wrote: > > > ... > > DEC Diagnositcs would run on a beached whale > > > > ? > > > > Anyone remember and/or know? > > > > (It seems to apply to other manufacturer's diagnostics as well, even > > today.) > > > > Thanks, > > > > Arnold > > From clemc at ccc.com Thu Sep 2 00:11:28 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Sep 2021 10:11:28 -0400 Subject: [TUHS] Who said ... In-Reply-To: <202109011357.181Dv1w1025209@freefriends.org> References: <202109011330.181DUc5v021332@freefriends.org> <202109011357.181Dv1w1025209@freefriends.org> Message-ID: On Wed, Sep 1, 2021 at 9:57 AM wrote: > It was DMR who said > > Using TSO is like kicking a dead whale along a beach. > It is quite possible. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at oclsc.org Thu Sep 2 00:16:38 2021 From: norman at oclsc.org (Norman Wilson) Date: Wed, 1 Sep 2021 10:16:38 -0400 (EDT) Subject: [TUHS] Who said ... Message-ID: <20210901141638.F064F640CC6@lignose.oclsc.org> Clem Cole: I believe the line was: *"running **DEC Diagnostics is like kicking a dead whale down the beach.*" As for who said it, I'm not sure, but I think it was someone like Rob Kolstad or Henry Spencer. ===== The nearest I can remember encountering before was a somewhat different quote, attributed to Steve Johnson: Running TSO is like kicking a dead whale down the beach. Since scj is on this list, maybe he can confirm that part. I don't remember hearing it applied to diagnostics. I can imagine someone saying it, because DEC's hardware diags were written by hardware people, not software people; they required a somewhat arcane configuration language, one that made more sense if you understood how the different pieces of hardware connected together. I learned to work with it and found it no less usable than, say, the clunky verbose command languages of DEC's operating systems; but I have always preferred to think in low levels. DEC's diags were far from perfect, but they were a hell of a lot better than the largely-nonexistent diags available for modern Intel-architecture systems. I am right now dealing with a system that has an intermittent fault, that causes the OS to crash in the middle of some device driver every so often. Other identical systems don't, so I don't think it's software. Were it a PDP-11 or a VAX I'd fire up the diagnostics for a while, and have at least a chance of spotting the problem; today, memtest is about the only such option, and a solid week of running memtest didn't shake out anything (reasonably enough, who says it's a memory problem?). Give me XXDP, not just the Blue Screen of Death. Norman Wilson Toronto ON From arnold at skeeve.com Thu Sep 2 00:23:15 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 01 Sep 2021 08:23:15 -0600 Subject: [TUHS] Who said ... In-Reply-To: <20210901141638.F064F640CC6@lignose.oclsc.org> References: <20210901141638.F064F640CC6@lignose.oclsc.org> Message-ID: <202109011423.181ENFkT029273@freefriends.org> norman at oclsc.org (Norman Wilson) wrote: > The nearest I can remember encountering before was a somewhat > different quote, attributed to Steve Johnson: > > Running TSO is like kicking a dead whale down the beach. > > Since scj is on this list, maybe he can confirm that part. I thought it was DMR, but I could be wrong. Apologies to SCJ if so. Arnold From paul.winalski at gmail.com Thu Sep 2 00:23:42 2021 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 1 Sep 2021 10:23:42 -0400 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: On 9/1/21, Dan Cross wrote: > > As an aside, I'd always been under the impression that the "AB" in "ABEND" > comes from, "abnormal"? You are correct, Dan. ABEND comes from the IBM (specifically OS/360/370) world and is short for "abnormal end". It means that application program (called the "problem program" in IBM mainframe jargon) has terminated abnormally for some reason and control has returned to the operating system. An ABEND was typically followed by a core dump to the printer. As the manual for beginning programmers at Boston College said, "Despite what your German teacher might tell you, there is no such thing as a guten ABEND." -Paul W. From henry.r.bent at gmail.com Thu Sep 2 00:26:30 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 1 Sep 2021 10:26:30 -0400 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: On Wed, 1 Sept 2021 at 09:49, Clem Cole wrote: > I believe the line was: *"running **DEC Diagnostics is like kicking a > dead whale down the beach.*" > As for who said it, I'm not sure, but I think it was someone like Rob > Kolstad or Henry Spencer. > > I suspect a grep of some type on some extremely old net.noise archives of > the late 1970s/early 1980s might find it. > This was the earliest reference I could easily find, from comp.unix.questions in Jan '87, but the author says it's an old joke. It's the last post in the thread: https://groups.google.com/g/comp.unix.questions/c/fFtkBC3TcLc/m/QphFGT7BAfsJ -Henry > ᐧ > ᐧ > > On Wed, Sep 1, 2021 at 9:31 AM wrote: > >> ... >> DEC Diagnositcs would run on a beached whale >> >> ? >> >> Anyone remember and/or know? >> >> (It seems to apply to other manufacturer's diagnostics as well, even >> today.) >> >> Thanks, >> >> Arnold >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 2 00:27:31 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Sep 2021 10:27:31 -0400 Subject: [TUHS] Who said ... In-Reply-To: <20210901141638.F064F640CC6@lignose.oclsc.org> References: <20210901141638.F064F640CC6@lignose.oclsc.org> Message-ID: On Wed, Sep 1, 2021 at 10:21 AM Norman Wilson wrote: > Running TSO is like kicking a dead whale down the beach. > I definitely stand corrected on that, now that I recall it was pot shot at IBM, not DEC. > > Since scj is on this list, maybe he can confirm that part. > Very possible -- sound a little less like a Dennis quip than others from those days. > > DEC's diags were far from perfect, but they were a hell of a > lot better than the largely-nonexistent diags available for > modern Intel-architecture systems. I agree. > Give me XXDP, not just the Blue Screen of Death. > Right. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Thu Sep 2 00:29:18 2021 From: henry.r.bent at gmail.com (Henry Bent) Date: Wed, 1 Sep 2021 10:29:18 -0400 Subject: [TUHS] Who said ... In-Reply-To: <20210901141638.F064F640CC6@lignose.oclsc.org> References: <20210901141638.F064F640CC6@lignose.oclsc.org> Message-ID: On Wed, 1 Sept 2021 at 10:21, Norman Wilson wrote: > Clem Cole: > > I believe the line was: *"running **DEC Diagnostics is like kicking a > dead > whale down the beach.*" > As for who said it, I'm not sure, but I think it was someone like Rob > Kolstad or Henry Spencer. > > ===== > > The nearest I can remember encountering before was a somewhat > different quote, attributed to Steve Johnson: > > Running TSO is like kicking a dead whale down the beach. > > Since scj is on this list, maybe he can confirm that part. > > Here's a Feb '85 net.unix thread that (eventually) attributes this to Steve: https://groups.google.com/g/net.unix/c/jq4KtffXZuI/m/2aTQBUYPyRsJ -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Sep 2 00:29:36 2021 From: cowan at ccil.org (John Cowan) Date: Wed, 1 Sep 2021 10:29:36 -0400 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: We know that SIGABRT was once SIGIOT, which was what PDP-11 Unix reported if the code executed an IOT instruction (which was all that abort() did). IOT was a trap instruction used by the aboriginal PDP-11 Paper Tape Software in order to communicate with device drivers. Later DEC OSes used EMT and Unix used TRAP, because the manual said it was for "user traps" and Unix is a user operating system. At some point it seemed stupid to someone to call the user-level routine abort() and the signal SIGIOT, and so added SIGABRT as a synonym. Not really an answer, but that's all I have. On Wed, Sep 1, 2021 at 10:24 AM Paul Winalski wrote: > On 9/1/21, Dan Cross wrote: > > > > As an aside, I'd always been under the impression that the "AB" in > "ABEND" > > comes from, "abnormal"? > > You are correct, Dan. ABEND comes from the IBM (specifically > OS/360/370) world and is short for "abnormal end". It means that > application program (called the "problem program" in IBM mainframe > jargon) has terminated abnormally for some reason and control has > returned to the operating system. An ABEND was typically followed by > a core dump to the printer. As the manual for beginning programmers > at Boston College said, "Despite what your German teacher might tell > you, there is no such thing as a guten ABEND." > > -Paul W. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Sep 2 00:32:24 2021 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Sep 2021 10:32:24 -0400 Subject: [TUHS] Who said ... In-Reply-To: References: <20210901141638.F064F640CC6@lignose.oclsc.org> Message-ID: On Wed, Sep 1, 2021 at 10:29 AM Henry Bent wrote: > Here's a Feb '85 net.unix thread that (eventually) attributes this to > Steve: > > https://groups.google.com/g/net.unix/c/jq4KtffXZuI/m/2aTQBUYPyRsJ > Thank you Henry - I knew net.noise would be the place to look ;-) ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Thu Sep 2 00:48:12 2021 From: torek at elf.torek.net (Chris Torek) Date: Wed, 1 Sep 2021 07:48:12 -0700 (PDT) Subject: [TUHS] Who said ... In-Reply-To: <20210901141638.F064F640CC6@lignose.oclsc.org> Message-ID: <202109011448.181EmCiB062091@elf.torek.net> >DEC's diags were far from perfect, but they were a hell of a >lot better than the largely-nonexistent diags available for >modern Intel-architecture systems. I am right now dealing >with a system that has an intermittent fault, that causes >the OS to crash in the middle of some device driver every >so often. Other identical systems don't, so I don't think >it's software. Could be the device itself, corrupting things. Some problems are just hard to track down. If you remember the infamous UDA50/RA81 setup, the original Unix driver was flaky somehow in that it would "lose" MSCP packets and hang. I rewrote the thing from scratch to fix that problem. But then we got an Emulex board that had a ... different problem. I hacked on our driver to find it. The problem turned out to be that the Emulex hardware (or firmware) would *drop* 16 of the 32 bits of a 32-bit field. In each MSCP packet, there was a single 32-bit field where you could store arbitrary data to be reflected back to you in a reply. The Unix driver stored `struct buf *bp` there, if I remember right, and I originally did as well. Once I figured out this was being clobbered, I replaced it with a small integer (index into "outstanding I/O table") with check bytes. I'd log the occurrence of corruption, recover the useful data from the 16 bytes that had the right data, and we would be on our merry way. There was no obvious pattern here though. Two other sort of related war stories... * We had the carry-chain timing bug on our VAX 780 at one point. It most-consistently hit on the `extzv` instruction in the kernel exit() handler, but only about 1 out of every 10 to 100 thousand occurrences. So I wrote a user-land program that would spin doing that `extzv`. If the user program crashed, the board-set installed in the backplane had the problem, and we'd have the DEC service guy cycle through them (in the usual "how many flat tires do we have today" dance). * The Ultrasparc II CPU had a similar timing bug, I think in the register forwarding logic. The BSD/OS SPARC port had a three instruction sequence for setting up the right stack on a trap (interrupt, system call, etc)., and it would randomly crash with a bizarre value, that I eventually figured out was from putting the result that should have gone into one of the %l registers, into the %sp register instead. It only happened after a pipeline flush for other purposes and I forget what I did to make it happen frequently enough to diagnose. (Re-ordering the three instructions fixed the problem.) Tying back into ZFS etc., if that was on this mailing list: :-) I had a bad DIMM in an Intel box a while back, that corrupted data in the kernel buffer pool. That one was scary, because, while the memtest86 tests found it, who knows what data they corrupted? (This is why I want ECC, even in my home systems.) Chris From andrew at humeweb.com Thu Sep 2 01:08:25 2021 From: andrew at humeweb.com (Andrew Hume) Date: Wed, 1 Sep 2021 08:08:25 -0700 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: <45E8FACF-08C1-43C3-9689-A7DB73461184@humeweb.com> of course, the dead whale joke just reminds me of that epic scene from “The Boys” tv show. never mind. andrew From ron at ronnatalie.com Thu Sep 2 02:00:24 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 01 Sep 2021 16:00:24 +0000 Subject: [TUHS] Who said ... In-Reply-To: <20210901141638.F064F640CC6@lignose.oclsc.org> References: <20210901141638.F064F640CC6@lignose.oclsc.org> Message-ID: Mike Muuss made some comment about the diagnostics being able to run on a dead whale. From ron at ronnatalie.com Thu Sep 2 01:59:08 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 01 Sep 2021 15:59:08 +0000 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: I disagree. TRAP according to the processor handbook was intended to be used for what UNIX calls system calls. EMT was the emulator trap used to simulate other operating systems on the same hardware. Oddly, for some reason, all the DEC OSes use EMT instructions for their system calls. This came in handy when JHU ported BasicPlus from RSTS to UNIX. That executable could run fine on UNIX because we caught the few EMT traps that mattered to us and simulated them. The only thing we had to do other than that was to add a "nostack()" system call that got rid of the normal UNIX-maintained stack starting at the address space (RSTS executables like many DEC OSs used a stack that started around 1000). Many of the UNIX signals come straight from PDP-11 traps: SIGFPE, SIGIOT, SIGSEGV, SIGBUS, SIGILL, SIGEMT. and those traps invoked those signals. FPE - floating point exception ILL - illegal exception (either unknown opcode or CERTAIN of the privileged instructions, others were ignored) BUS - fatal unibus timeout trap. Usually an attempt to access a memory/unibus address that doesn't respond, or to do word accesses on odd boundaries. SEGV - accessing memory not mapped to you IOT - the IOT instruction BPT - the BPT instruction TRAP, EMT - these instructions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Sep 2 02:10:26 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 01 Sep 2021 16:10:26 +0000 Subject: [TUHS] Who said ... In-Reply-To: <202109011330.181DUc5v021332@freefriends.org> References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: >... > DEC Diagnositcs would run on a beached whale > >? > >Anyone remember and/or know? > I believe this was Mike Muuss and he used the term "dead whale" in deference to the TSO comment. > From pugs at ieee.org Thu Sep 2 02:42:44 2021 From: pugs at ieee.org (Tom Lyon) Date: Wed, 1 Sep 2021 09:42:44 -0700 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: Another fun saying about TSO: "It may be slow, but it's hard to use." Not sure the origin. On Wed, Sep 1, 2021 at 9:10 AM Ron Natalie wrote: > > > >... > > DEC Diagnositcs would run on a beached whale > > > >? > > > >Anyone remember and/or know? > > > I believe this was Mike Muuss and he used the term "dead whale" in > deference to the TSO comment. > > > > > -- - Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From stewart at serissa.com Thu Sep 2 03:41:25 2021 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 1 Sep 2021 13:41:25 -0400 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> Message-ID: <52AD83E7-1E27-429B-8A4A-2B870245AC33@serissa.com> Or JCL “It’s as easy to read one file as it is to read 1000 files." > On 2021, Sep 1, at 12:42 PM, Tom Lyon via TUHS wrote: > > Another fun saying about TSO: "It may be slow, but it's hard to use." > > Not sure the origin. > > On Wed, Sep 1, 2021 at 9:10 AM Ron Natalie > wrote: > > > >... > > DEC Diagnositcs would run on a beached whale > > > >? > > > >Anyone remember and/or know? > > > I believe this was Mike Muuss and he used the term "dead whale" in > deference to the TSO comment. > > > > > > > -- > - Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Sep 2 04:09:51 2021 From: imp at bsdimp.com (Warner Losh) Date: Wed, 1 Sep 2021 12:09:51 -0600 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 10:07 AM Ron Natalie wrote: > I disagree. TRAP according to the processor handbook was intended to be > used for what UNIX calls system calls. EMT was the emulator trap used to > simulate other operating systems on the same hardware. Oddly, for some > reason, all the DEC OSes use EMT instructions for their system calls. > This came in handy when JHU ported BasicPlus from RSTS to UNIX. That > executable could run fine on UNIX because we caught the few EMT traps that > mattered to us and simulated them. The only thing we had to do other than > that was to add a "nostack()" system call that got rid of the normal > UNIX-maintained stack starting at the address space (RSTS executables like > many DEC OSs used a stack that started around 1000). > The various RT-11 emulators use variations on this theme as well, some inside the kernel, some as a signal handler (fast forward 40-odd years and I'm catching the SIGSEGV traps in executing 16-bit code to implement the unix system calls)... It's a very useful and elegant trick that's been oft-repeated. > Many of the UNIX signals come straight from PDP-11 traps: SIGFPE, SIGIOT, > SIGSEGV, SIGBUS, SIGILL, SIGEMT. and those traps invoked those signals. > Yes. They seemed to make perfect sense when I encountered them in Unix after growing up on RSTS/e and RT-11 before my first contact with Unix.... > FPE - floating point exception > ILL - illegal exception (either unknown opcode or CERTAIN of the > privileged instructions, others were ignored) > BUS - fatal unibus timeout trap. Usually an attempt to access a > memory/unibus address that doesn't respond, or to do word accesses on odd > boundaries. > SEGV - accessing memory not mapped to you > IOT - the IOT instruction > BPT - the BPT instruction > TRAP, EMT - these instructions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Thu Sep 2 04:43:06 2021 From: cowan at ccil.org (John Cowan) Date: Wed, 1 Sep 2021 14:43:06 -0400 Subject: [TUHS] A language question In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 12:07 PM Ron Natalie wrote: > I disagree. TRAP according to the processor handbook was intended to be > used for what UNIX calls system calls. EMT was the emulator trap used to > simulate other operating systems on the same hardware. > The 1969 PDP-11 Handbook < http://gordonbell.azurewebsites.net/digital/pdp%2011%20handbook%201969.pdf> says on p. 41 (PDF page 49): "[Trap] instructions provide for calls to emulators, I/O monitors, debugging packages, and user-defined interpreters", but it does not define "emulators". (The OED has several citations for this sense of "emulator", but before about 1985 the context seems to be hardware emulation only.) Nevertheless, DOS/BATCH-11 (1970-71) already uses EMT as the system call instruction, and it is clear that TRAP was for user use. At that point, the only other operating system that could be emulated would be the Paper Tape Software that I mentioned, which used IOT. (BTW, RSTS/E's hypervisor would reflect any EMT instruction to the RTS (the actual or emulated supervisor running in any given process, such as Basic-Plus, RT-11, RSX-11, or Teco), with the exception of an EMT 377, EMT 377 sequence, which was a syscall to the hypervisor itself.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Sep 2 06:00:42 2021 From: rminnich at gmail.com (ron minnich) Date: Wed, 1 Sep 2021 13:00:42 -0700 Subject: [TUHS] Who said ... In-Reply-To: <52AD83E7-1E27-429B-8A4A-2B870245AC33@serissa.com> References: <202109011330.181DUc5v021332@freefriends.org> <52AD83E7-1E27-429B-8A4A-2B870245AC33@serissa.com> Message-ID: I first heard it at usenix 1980. On Wed, Sep 1, 2021, 10:52 AM Lawrence Stewart wrote: > Or JCL “It’s as easy to read one file as it is to read 1000 files." > > On 2021, Sep 1, at 12:42 PM, Tom Lyon via TUHS > wrote: > > Another fun saying about TSO: "It may be slow, but it's hard to use." > > Not sure the origin. > > On Wed, Sep 1, 2021 at 9:10 AM Ron Natalie wrote: > >> >> >> >... >> > DEC Diagnositcs would run on a beached whale >> > >> >? >> > >> >Anyone remember and/or know? >> > >> I believe this was Mike Muuss and he used the term "dead whale" in >> deference to the TSO comment. >> >> > >> >> > > -- > - Tom > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Thu Sep 2 06:04:44 2021 From: rminnich at gmail.com (ron minnich) Date: Wed, 1 Sep 2021 13:04:44 -0700 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> <52AD83E7-1E27-429B-8A4A-2B870245AC33@serissa.com> Message-ID: It's coming back slowly. It was in response to problems with a dh11. DEC engineer:"did you run diagnostics." Response: as quoted. The other one: DEC engineer: "dh11 can run at a megabit". Response: "in a good wind. " Same person, vague memory is Mike O'Dell? Is that name right? On Wed, Sep 1, 2021, 1:00 PM ron minnich wrote: > I first heard it at usenix 1980. > > On Wed, Sep 1, 2021, 10:52 AM Lawrence Stewart > wrote: > >> Or JCL “It’s as easy to read one file as it is to read 1000 files." >> >> On 2021, Sep 1, at 12:42 PM, Tom Lyon via TUHS >> wrote: >> >> Another fun saying about TSO: "It may be slow, but it's hard to use." >> >> Not sure the origin. >> >> On Wed, Sep 1, 2021 at 9:10 AM Ron Natalie wrote: >> >>> >>> >>> >... >>> > DEC Diagnositcs would run on a beached whale >>> > >>> >? >>> > >>> >Anyone remember and/or know? >>> > >>> I believe this was Mike Muuss and he used the term "dead whale" in >>> deference to the TSO comment. >>> >>> > >>> >>> >> >> -- >> - Tom >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Thu Sep 2 07:47:27 2021 From: robpike at gmail.com (Rob Pike) Date: Thu, 2 Sep 2021 07:47:27 +1000 Subject: [TUHS] Who said ... In-Reply-To: References: <202109011330.181DUc5v021332@freefriends.org> <52AD83E7-1E27-429B-8A4A-2B870245AC33@serissa.com> Message-ID: I also remember, vividly, that it was scj's quote about TSO. Having used TSO, I think he was being kind. -rob On Thu, Sep 2, 2021 at 6:05 AM ron minnich wrote: > It's coming back slowly. It was in response to problems with a dh11. DEC > engineer:"did you run diagnostics." Response: as quoted. > > The other one: DEC engineer: "dh11 can run at a megabit". Response: "in a > good wind. " > > Same person, vague memory is Mike O'Dell? Is that name right? > > On Wed, Sep 1, 2021, 1:00 PM ron minnich wrote: > >> I first heard it at usenix 1980. >> >> On Wed, Sep 1, 2021, 10:52 AM Lawrence Stewart >> wrote: >> >>> Or JCL “It’s as easy to read one file as it is to read 1000 files." >>> >>> On 2021, Sep 1, at 12:42 PM, Tom Lyon via TUHS >>> wrote: >>> >>> Another fun saying about TSO: "It may be slow, but it's hard to use." >>> >>> Not sure the origin. >>> >>> On Wed, Sep 1, 2021 at 9:10 AM Ron Natalie wrote: >>> >>>> >>>> >>>> >... >>>> > DEC Diagnositcs would run on a beached whale >>>> > >>>> >? >>>> > >>>> >Anyone remember and/or know? >>>> > >>>> I believe this was Mike Muuss and he used the term "dead whale" in >>>> deference to the TSO comment. >>>> >>>> > >>>> >>>> >>> >>> -- >>> - Tom >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Thu Sep 2 07:58:56 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 1 Sep 2021 17:58:56 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) Message-ID: One of the things I really appreciate about participating in this community and studying Unix history (and the history of other systems) is that it gives one firm intellectual ground from which to evaluate where one is going: without understanding where one is and where one has been, it's difficult to assert that one isn't going sideways or completely backwards. Maybe either of those outcomes is appropriate at times (paradigms shift; we make mistakes; etc) but generally we want to be moving mostly forward. The danger when immersing ourselves in history, where we must consider and appreciate the set of problems that created the evolutionary paths leading to the systems we are studying, is that our thinking can become calcified in assuming that those systems continue to meet the needs of the problems of today. It is therefore always important to reevaluate our base assumptions in light of either disconfirming evidence or (in our specific case) changing environments. To that end, I found Timothy Roscoe's (ETH) joint keynote address at ATC/OSDI'21 particularly compelling. He argues that what we consider the "operating system" is only controlling a fraction of a modern computer these days, and that in many ways our models for what we consider "the computer" are outdated and incomplete, resulting in systems that are artificially constrained, insecure, and with separate components that do not consider each other and therefore frequently conflict. Further, hardware is ossifying around the need to present a system interface that can be controlled by something like Linux (used as a proxy more generally for a Unix-like operating system), simultaneously broadening the divide and making it ever more entrenched. Another theme in the presentation is that, to the limited extent the broader systems research community is actually approaching OS topics at all, it is focusing almost exclusively on Linux in lieu of new, novel systems; where non-Linux systems are featured (something like 3 accepted papers between SOSP and OSDI in the last two years out of $n$), the described systems are largely Linux-like. Here the presentation reminded me of Rob Pike's "Systems Software Research is Irrelevant" talk (slides of which are available in various places, though I know of no recording of that talk). Roscoe's challenge is that all of this should be seen as both a challenge and an opportunity for new research into operating systems specifically: what would it look like to take a holistic approach towards the hardware when architecting a new system to drive all this hardware? We have new tools that can make this tractable, so why don't we do it? Part of it is bias, but part of it is that we've lost sight of the larger picture. My own question is, have we become entrenched in the world of systems that are "good enough"? Things he does NOT mention are system interfaces to userspace software; he doesn't seem to have any quibbles with, say, the Linux system call interface, the process model, etc. He's mostly talking about taking into account the hardware. Also, in fairness, his highlighting a "small" portion of the system and saying, "that's what the OS drives!" sort of reminds me of the US voter maps that show vast tracts of largely unpopulated land colored a certain shade as having voted for a particular candidate, without normalizing for population (land doesn't vote, people do, though in the US there is a relationship between how these things impact the overall election for, say, the presidency). I'm curious about other peoples' thoughts on the talk and the overall topic? https://www.youtube.com/watch?v=36myc8wQhLo - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Thu Sep 2 18:42:21 2021 From: dot at dotat.at (Tony Finch) Date: Thu, 2 Sep 2021 09:42:21 +0100 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: Dan Cross wrote: > > I'm curious about other peoples' thoughts on the talk and the overall topic? I saw this talk yesterday and I twote some off-the-cuff thoughts (https://twitter.com/fanf/status/1433004863818960898): I wanted to hear more about the problem of closed firmware (Roscoe's research platform uses OpenBMC). I hope the gradual rise of open firmware will help to fix the problem of platform management controllers treating the OS as the enemy. The talk focuses on Linux because ~everything runs Linux, but Linux was designed for a platform that was defined by Intel and Microsoft, and the disfunctional split that Roscoe points out is exactly the split in design responsibilities between Intel and Microsoft. In the Arm world the split has been reproduced, but with Arm and the SoC manufacturers instead of Intel and the PC clones, and Linux instead of Windows. There’s also Conway’s law, “you ship your org chart”, and in this case Roscoe is talking about the organisation of the computer industry as a whole. So if someone comes up with a better OS architecture, is the implied org chart also successful under capitalism? (end paste) I suppose the historical perspective would be to ask if the way that OS and driver software was developed in the past in vertically-integratewd companies can provide insight into the hardware complexity of today's systems... Tony. -- f.anthony.n.finch https://dotat.at/ Bailey: South or southwest, becoming variable, 2 to 4. Slight. Showers. Good. From kevin.bowling at kev009.com Fri Sep 3 01:41:23 2021 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Thu, 2 Sep 2021 08:41:23 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 3:00 PM Dan Cross wrote: > > One of the things I really appreciate about participating in this community and studying Unix history (and the history of other systems) is that it gives one firm intellectual ground from which to evaluate where one is going: without understanding where one is and where one has been, it's difficult to assert that one isn't going sideways or completely backwards. Maybe either of those outcomes is appropriate at times (paradigms shift; we make mistakes; etc) but generally we want to be moving mostly forward. > > The danger when immersing ourselves in history, where we must consider and appreciate the set of problems that created the evolutionary paths leading to the systems we are studying, is that our thinking can become calcified in assuming that those systems continue to meet the needs of the problems of today. It is therefore always important to reevaluate our base assumptions in light of either disconfirming evidence or (in our specific case) changing environments. > > To that end, I found Timothy Roscoe's (ETH) joint keynote address at ATC/OSDI'21 particularly compelling. He argues that what we consider the "operating system" is only controlling a fraction of a modern computer these days, and that in many ways our models for what we consider "the computer" are outdated and incomplete, resulting in systems that are artificially constrained, insecure, and with separate components that do not consider each other and therefore frequently conflict. Further, hardware is ossifying around the need to present a system interface that can be controlled by something like Linux (used as a proxy more generally for a Unix-like operating system), simultaneously broadening the divide and making it ever more entrenched. > > Another theme in the presentation is that, to the limited extent the broader systems research community is actually approaching OS topics at all, it is focusing almost exclusively on Linux in lieu of new, novel systems; where non-Linux systems are featured (something like 3 accepted papers between SOSP and OSDI in the last two years out of $n$), the described systems are largely Linux-like. Here the presentation reminded me of Rob Pike's "Systems Software Research is Irrelevant" talk (slides of which are available in various places, though I know of no recording of that talk). > > Roscoe's challenge is that all of this should be seen as both a challenge and an opportunity for new research into operating systems specifically: what would it look like to take a holistic approach towards the hardware when architecting a new system to drive all this hardware? We have new tools that can make this tractable, so why don't we do it? Part of it is bias, but part of it is that we've lost sight of the larger picture. My own question is, have we become entrenched in the world of systems that are "good enough"? > > Things he does NOT mention are system interfaces to userspace software; he doesn't seem to have any quibbles with, say, the Linux system call interface, the process model, etc. He's mostly talking about taking into account the hardware. Also, in fairness, his highlighting a "small" portion of the system and saying, "that's what the OS drives!" sort of reminds me of the US voter maps that show vast tracts of largely unpopulated land colored a certain shade as having voted for a particular candidate, without normalizing for population (land doesn't vote, people do, though in the US there is a relationship between how these things impact the overall election for, say, the presidency). > > I'm curious about other peoples' thoughts on the talk and the overall topic? > > https://www.youtube.com/watch?v=36myc8wQhLo > > - Dan C. One thing I've realized as the unit of computing becomes more and more abundant (one off HW->mainframes->minis->micros->servers->VMs->containers) the OS increasingly becomes less visible and other software components become more important. It's an implementation detail like a language runtime and software developers are increasingly ill equipped to work at this layer. Public cloud/*aaS is a major blow to interesting general purpose OS work in commercial computing since businesses increasingly outsource more and more of their workloads. The embedded (which includes phones/Fuschia, accelerator firmware/payload, RTOS etc) and academic (i.e. Cambridge CHERI) world may have to sustain OS research for the foreseeable future. There is plenty of systems work going on but it takes place in different ways, userspace systems are completely viable and do not require switching to microkernels. Intel's DPDK/SPDK as one ecosystem, Kubernetes as another - there is a ton of rich systems work in this ecosystem with eBPF/XDP etc, and I used to dismiss it but it is no longer possible to do so rationally. I would go as far as saying Kubernetes is _the_ datacenter OS and has subsumed Linux itself as the primary system abstraction for the next while.. even Microsoft has a native implementation on Server 2022. It looks different and smells different, but being able to program compute/storage/network fabric with one abstraction is the holy grail of cluster computing and interestingly it lets you swap the lower layer implementations out with less risk but also less fanfare. Regards, Kevin From jon at fourwinds.com Fri Sep 3 01:52:23 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 02 Sep 2021 08:52:23 -0700 Subject: [TUHS] Is it time to resurrect the original dsw (delete with switches)? In-Reply-To: <71B14DD4-0F7D-4AE1-9BCE-3327C056FFD2@iitbombay.org> References: <202108292212.17TMCGow1448973@darkstar.fourwinds.com> <20210829235745.GC20021@mcvoy.com> <71B14DD4-0F7D-4AE1-9BCE-3327C056FFD2@iitbombay.org> Message-ID: <202109021552.182FqNLB3750785@darkstar.fourwinds.com> Hey, wanted to thank everybody for the good information on this topic. Was pleasantly surprised that we got through it without a flame war :-) I have a related question in case any of you have actual factual knowledge of disk drive internals. A friend who used to be in charge of reliability engineering at Seagate used to be a great resource but he's now retired. For example, years ago someone ranted at me about disk manufacturers sacrificing reliability to save a few pennies by removing the head ramp; I asked my friend who explained to me how that ramp was removed to improve reliability. So my personal setup here bucks conventional wisdom in that I don't do RAID. One reason is that I read the Google reliability studies years ago and interpreted them to say that if I bought a stack of disks on the same day I could expect them to fail at about the same time. Another reason is that 24x7 spinning disk drives is the biggest power consumer in my office. Last reason is that my big drives hold media (music/photos/video), so if one dies it's not going to be any sort of critical interruption. My strategy is to keep three (+) copies. I realized that I first came across this wisdom while learning both code and spelunking as a teenager from Carl Christensen and Heinz Lycklama in the guise of how many spare headlamps one should have when spelunking. There's the copy on my main machine, another in a fire safe, and I rsync to another copy on a duplicate machine up at my ski condo. Plus, I keep lots of old fragments of stuff on retired small (<10T) disks that are left over from past systems. And, a lot of the music part of my collection is backed up by proof-of-purchase CDs in the store room or shared with many others so it's not too hard to recover. Long intro, on to the question. Anyone know what it does to reliability to spin disks up and down. I don't really need the media disks to be constantly spinning; when whatever I'm listening to in the evening finishes the disk could spin down until morning to save energy. Likewise the video disk drive is at most used for a few hours a day. My big disks (currently 16T and 12T) bake when they're spinning which can't be great for them, but I don't know how that compares to mechanical stress from spinning up and down from a reliability standpoint. Anyone know? Jon From tytso at mit.edu Fri Sep 3 02:57:50 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 2 Sep 2021 12:57:50 -0400 Subject: [TUHS] Is it time to resurrect the original dsw (delete with switches)? In-Reply-To: <202109021552.182FqNLB3750785@darkstar.fourwinds.com> References: <202108292212.17TMCGow1448973@darkstar.fourwinds.com> <20210829235745.GC20021@mcvoy.com> <71B14DD4-0F7D-4AE1-9BCE-3327C056FFD2@iitbombay.org> <202109021552.182FqNLB3750785@darkstar.fourwinds.com> Message-ID: On Thu, Sep 02, 2021 at 08:52:23AM -0700, Jon Steinhart wrote: > Long intro, on to the question. Anyone know what it does to reliability to > spin disks up and down. I don't really need the media disks to be constantly > spinning; when whatever I'm listening to in the evening finishes the disk > could spin down until morning to save energy. Likewise the video disk drive > is at most used for a few hours a day. > > My big disks (currently 16T and 12T) bake when they're spinning which can't > be great for them, but I don't know how that compares to mechanical stress > from spinning up and down from a reliability standpoint. Anyone know? First of all, I wouldn't worry too much about big disks "baking" while they are spinning. Google runs its disks hot, in data centers where the ambient air temperatures is at least 80 degrees Fahrenheit[1], and it's not alone; Dell said in 2012 that it would honor warranties for servers running in environments as hot as 115 degrees Fahrenheit[2]. [1] https://www.google.com/about/datacenters/efficiency/ [2] https://www.datacenterknowledge.com/archives/2012/03/23/too-hot-for-humans-but-google-servers-keep-humming And of course, if the ambient *air* temperature is 80 degrees plus, you can just imagine the temperature at the hard drive. It's also true that a long time ago, disk drives had limited number of spin up/down cycles; this was in its spec sheet, and SMART would track the number of disk spinups. I had a laptop drive where I had configured the OS so it would spin down the drive after 30 seconds of idle, and I realized that after about 9 months, SMART stats had reported that I had used up almost 50% of the rated spin up/down cycles for a laptop drive. Needless to say, I backed of my agressive spindown policies. That being said, more modern HDD's have been designed for better power effiencies, with slower disk rotational speeds (which is probably fine for media disks, unless you are serving a large number of different video streams at the same time), and they are designed to allow for a much larger number of spindown cycles. Check your spec sheets, this will be listed as load/unload cycles, and it will typically be a number like 200,000, 300,000 or 600,000. If you're only spinning down the a few times a day, I suspect you'll be fine. Especially since if the disk dies due to a head crash or other head failure, it'll be a case of an obvious disk failure, not silent data corruption, and you can just pull your backups out of your fire safe. I don't personally have a lot of knowledge of how modern HDD's actually survive large numbers of load/unload cycles, because at $WORK we keep the disks spinning at all times. A disk provides value in two ways: bytes of storage, and I/O operations. And an idle disk means we're wasting part of its value it could be providing, and if the goal is to decrease the overall storage TCO, wasting IOPS is not a good thing[3]. Hence, we try to organize our data to keep all of the hard drives busy, by peanut-buttering the hot data across all of the disks in the cluster[4]. [3] https://research.google/pubs/pub44830/ [4] http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Keynote.pdf Hence, a spun-down disk is a disk which is frittering away the CapEx of the drive and a portion of the server cost to which the disk is attached. And if you can find useful work for that disk to do, it's way more valuable to keep it spun up even taking into account to the power and air-conditioning costs of the spinning drive. It should also be noted that modern HDD's now also have *write* limits[5], just like SSD's. This is especially true for technologies like HAMR --- where if you need to apply *heat* to write, that means additional thermal stress on the drive head when you write to a disk, but the write limits predate new technologies like HAMR and MAMR. [5] https://www.theregister.com/2016/05/03/when_did_hard_drives_get_workload_rate_limits/ HDD write limits has implications for systems that are using log structured storage, or other copy-on-write schemes, or systems that are moving data around to balance hot and cold data as described in the PDSW keynote. This is probably not an issue for home systems, but it's one of the things which keeps the storage space interesting. :-) - Ted P.S. I have a Synology NAS box, and I *do* let the disks spin down. Storage at the industrial scale is really different than storage at the personal scale. I do use RAID, but my backup strategy in extremis is encrypted backups uploaded to cloud storage (where I can take advantage of industrial-scale storage pricing). From marzhall.o at gmail.com Fri Sep 3 06:12:58 2021 From: marzhall.o at gmail.com (Marshall Conover) Date: Thu, 2 Sep 2021 16:12:58 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: Kevin, I think that's a great framing of why this talk actually seemed inverted in its focus for me, and a good identification of why the presenter might see OS development stalling out and ossifying around Linux. I come from the opposite side of the presenter here: my frustration as a backend dev and user has been that modern OSs still think presenting an abstraction over my resources means making it easy to use one single machine (or, as the presenter brings up, a subset of the machine). Instead, my resources are spread out among many machines and a number of remote web services, for which I'd like to have one seamless interface - both for development and use. From an OS perspective, Plan 9 and its daughter systems have come the closest I've seen to addressing this by intentionally thinking about the problem and creating an API system for representing resources that reaches across networks, and a mutable namespace for using and manipulating those APIs. Despite pulling other ideas from 9, the importance of having an opinion on the distributed nature of modern computing seems to have been missed by prominent operating systems today. As a result, their development has been relegated to what they do: be a platform for things that actually provide an abstraction for my resources. And userspace systems have filled the demand for abstracting distributed resource usage to demonstrable business success, if questionable architectural success (as in, they can still be a confusing pain in the buns and require excess work sometimes). As a dev, the systems that have come the closest to presenting one unified abstraction over my resources are the meta-services offered by Google, MS and Amazon such as Azure and AWS. I think the distributed nature of things today is also potentially why the focus of the conference is on distributed systems now, as lamented by the presenter. Granted that I'm not the sharpest bulb in the drawer, but I can't think of a way an OS taking more direct control of the internal hardware of an individual computer would impact me beyond the security issues mentioned in the talk. However, I can think of a number of ways an OS being opinionated about working with networked machines would greatly improve my situation. Boy, it would be great to just spin up a cluster of machines, install one OS on all of them, and treat them as one resource. That's the dream the k8s mentality promises, and MS and Amazon are already walking towards being this sort of one-stop shop: "want cluster computing? Press a button to spin up a cluster with ECS, and store your containers in ECR. Want to run a program or twelve somewhere on the cluster? Just tell us which one and how many. Worried about storage? Just tell us what size storage it needs. We've got you covered!" None of it is perfect, but it shows that there's heavy demand for a system where users don't have to think about how to architect and maintain arbitrary groupings of their resources as necessitated by how OSs think of their job now, and instead just want to feel as if they're writing and running programs on one big 'thing'. So I think the ossification around Linux mentioned in the talk might be that unless operating systems start doing something more than being a host for the tools that actually provide an abstraction over all my resources, there's no real reason to make them do anything else. If you're not making it easier to use my resources than k8s or Azure, why would I want you? Cheers, Marshall On Thu, Sep 2, 2021 at 11:42 AM Kevin Bowling wrote: > > On Wed, Sep 1, 2021 at 3:00 PM Dan Cross wrote: > > > > One of the things I really appreciate about participating in this community and studying Unix history (and the history of other systems) is that it gives one firm intellectual ground from which to evaluate where one is going: without understanding where one is and where one has been, it's difficult to assert that one isn't going sideways or completely backwards. Maybe either of those outcomes is appropriate at times (paradigms shift; we make mistakes; etc) but generally we want to be moving mostly forward. > > > > The danger when immersing ourselves in history, where we must consider and appreciate the set of problems that created the evolutionary paths leading to the systems we are studying, is that our thinking can become calcified in assuming that those systems continue to meet the needs of the problems of today. It is therefore always important to reevaluate our base assumptions in light of either disconfirming evidence or (in our specific case) changing environments. > > > > To that end, I found Timothy Roscoe's (ETH) joint keynote address at ATC/OSDI'21 particularly compelling. He argues that what we consider the "operating system" is only controlling a fraction of a modern computer these days, and that in many ways our models for what we consider "the computer" are outdated and incomplete, resulting in systems that are artificially constrained, insecure, and with separate components that do not consider each other and therefore frequently conflict. Further, hardware is ossifying around the need to present a system interface that can be controlled by something like Linux (used as a proxy more generally for a Unix-like operating system), simultaneously broadening the divide and making it ever more entrenched. > > > > Another theme in the presentation is that, to the limited extent the broader systems research community is actually approaching OS topics at all, it is focusing almost exclusively on Linux in lieu of new, novel systems; where non-Linux systems are featured (something like 3 accepted papers between SOSP and OSDI in the last two years out of $n$), the described systems are largely Linux-like. Here the presentation reminded me of Rob Pike's "Systems Software Research is Irrelevant" talk (slides of which are available in various places, though I know of no recording of that talk). > > > > Roscoe's challenge is that all of this should be seen as both a challenge and an opportunity for new research into operating systems specifically: what would it look like to take a holistic approach towards the hardware when architecting a new system to drive all this hardware? We have new tools that can make this tractable, so why don't we do it? Part of it is bias, but part of it is that we've lost sight of the larger picture. My own question is, have we become entrenched in the world of systems that are "good enough"? > > > > Things he does NOT mention are system interfaces to userspace software; he doesn't seem to have any quibbles with, say, the Linux system call interface, the process model, etc. He's mostly talking about taking into account the hardware. Also, in fairness, his highlighting a "small" portion of the system and saying, "that's what the OS drives!" sort of reminds me of the US voter maps that show vast tracts of largely unpopulated land colored a certain shade as having voted for a particular candidate, without normalizing for population (land doesn't vote, people do, though in the US there is a relationship between how these things impact the overall election for, say, the presidency). > > > > I'm curious about other peoples' thoughts on the talk and the overall topic? > > > > https://www.youtube.com/watch?v=36myc8wQhLo > > > > - Dan C. > > > One thing I've realized as the unit of computing becomes more and more > abundant (one off > HW->mainframes->minis->micros->servers->VMs->containers) the OS > increasingly becomes less visible and other software components become > more important. It's an implementation detail like a language runtime > and software developers are increasingly ill equipped to work at this > layer. Public cloud/*aaS is a major blow to interesting general > purpose OS work in commercial computing since businesses increasingly > outsource more and more of their workloads. The embedded (which > includes phones/Fuschia, accelerator firmware/payload, RTOS etc) and > academic (i.e. Cambridge CHERI) world may have to sustain OS research > for the foreseeable future. > > There is plenty of systems work going on but it takes place in > different ways, userspace systems are completely viable and do not > require switching to microkernels. Intel's DPDK/SPDK as one > ecosystem, Kubernetes as another - there is a ton of rich systems work > in this ecosystem with eBPF/XDP etc, and I used to dismiss it but it > is no longer possible to do so rationally. I would go as far as > saying Kubernetes is _the_ datacenter OS and has subsumed Linux itself > as the primary system abstraction for the next while.. even Microsoft > has a native implementation on Server 2022. It looks different and > smells different, but being able to program compute/storage/network > fabric with one abstraction is the holy grail of cluster computing and > interestingly it lets you swap the lower layer implementations out > with less risk but also less fanfare. > > Regards, > Kevin From cowan at ccil.org Fri Sep 3 10:19:17 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 2 Sep 2021 20:19:17 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Thu, Sep 2, 2021 at 5:01 AM Tony Finch wrote: > Linux was > designed for a platform that was defined by Intel and Microsoft, and the > disfunctional split that Roscoe points out is exactly the split in design > responsibilities between Intel and Microsoft. > As the saying has it: "What Andy giveth, Bill taketh away." -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Fri Sep 3 13:24:37 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 2 Sep 2021 23:24:37 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: I set out to write a reply, then found that Marshall had said it all, better..Alas, the crucial central principle of Plan 9 got ignored, while its ancillary contributions were absorbed into Linux, making Linux fatter but still oriented to a bygone milieu. Another entrant in the distributable computing arena is Jay Misra's "orchestrator", Orc, in which practice goes hand-in-hand with theory: https://www.cs.utexas.edu/users/misra/OrcBook.pdf. Doug On Thu, Sep 2, 2021 at 8:19 PM John Cowan wrote: > > > On Thu, Sep 2, 2021 at 5:01 AM Tony Finch wrote: > > >> Linux was >> designed for a platform that was defined by Intel and Microsoft, and the >> disfunctional split that Roscoe points out is exactly the split in design >> responsibilities between Intel and Microsoft. >> > > As the saying has it: "What Andy giveth, Bill taketh away." > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Sep 3 23:21:51 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Fri, 3 Sep 2021 09:21:51 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Thu, Sep 02, 2021 at 11:24:37PM -0400, Douglas McIlroy wrote: > I set out to write a reply, then found that Marshall had said it all, > better..Alas, the crucial central principle of Plan 9 got ignored, while > its ancillary contributions were absorbed into Linux, making Linux fatter > but still oriented to a bygone milieu. I'm really not convinced trying to build distributed computing into the OS ala Plan 9 is viable. The moment the OS has to span multiple TCB's (Trusted Computing Bases), you have to make some very opinionated decisions on a number of issues for which we do not have consensus after decades of trial and error: * What kind of directory service do you use? x.500/LDAP? Yellow Pages? Project Athena's Hesiod? * What kind of distributed authentication do you use? Kerboers? Trust on first use authentication ala ssh? .rhosts style "trust the network" style authentication? * What kind of distributed authorization service do you use? Unix-style numeric user-id/group-id's? X.500 Distinguished Names in ACL's? Windows-style Security ID's? * Do you assume that all of the machines in your distributed computation system belong to the same administrative domain? What if individuals owning their own workstations want to have system administrator privs on their system? Or is your distributed OS a niche system which only works when you have clusters of machines that are all centrally and administratively owned? * What scale should the distributed system work at? 10's of machines in a cluster? 100's of machines? 1000's of machines? Tens of thousands of machines? Distributed systems that work well on football-sized data centers may not work that well when you only have a few racks in colo facility. The "I forgot how to count that low" challenge is a real one.... There have been many, many proposals in the distributed computing arena which all try to answer these questions differently. Solaris had an answer with Yellow Pages, NFS, etc. OSF/DCE had an answer involving Kerberos, DCE/RPC, DCE/DFS, etc. More recently we have Docker's Swarm and Kubernetes, etc. None have achieved dominance, and that should tell us something. The advantage of trying push all of these questions into the OS is that you can try to provide the illusion that there is no difference between local and remote resources. But that either means that you have a toy (sorry, "research") system which ignores all of the ways in which remote computation which extends to a different node that may or may not be up, which may or may not have belong to a different administration domain, which may or may not have an adversary on the network between you and the remote node, etc. OR, you have to make access to local resources just as painful as access to remote resources. Furthermore, since supporting access remote resources is going to have more overhead, the illusion that access to local and remote resources can be the same can't be comfortably sustained in any case. When you add to that the complexities of building an OS that tries to do a really good job supporting local resources --- see all of the observations in Rob Pike's Systems Software Research is Dead slides about why this is hard --- it seems to me the solution of trying to build a hard dividing line between the Local OS and Distributed Computation infrastructure is the right one. There is a huge difference between creating a local OS that can live on a single developer's machine in their house --- and a distributed OS which requires setting up a directory server, and an authentication server, and a secure distributed time server, etc., before you set up the first useful node that can actually run user workloads. You can try to do both under a single source tree, but it's going to result in a huge amount of bloat, and a huge amount of maintenance burden to keep it all working. By keeping the local node OS and the distributed computation system separate, it can help control complexity, and that's a big part of computer science, isn't it? - Ted From imp at bsdimp.com Sat Sep 4 01:56:13 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 3 Sep 2021 09:56:13 -0600 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 4:00 PM Dan Cross wrote: > I'm curious about other peoples' thoughts on the talk and the overall > topic? > My comment is that the mental map that he presents has always been a lie. At least it's been a lie from a very early time. Even in Unibus/Qbus days, the add-in cards had some kind of processor on it from an early time. Several of the VAX boards had 68000 or similar CPUs that managed memory. Even the simpler MFM boards had buffer memory that needed to be managed before the DMA/PIO pulled it out of the card. There's always been an element of different address spaces with different degrees of visibility into those address spaces. What has changed is all of these things are now on the SoC die so you have good visibility (well, as good as the docs) into these things. The number of different things has increased, and the for cross domain knowledge has increased. The simplistic world view was even inaccurate at the start.... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From athornton at gmail.com Sat Sep 4 03:10:57 2021 From: athornton at gmail.com (Adam Thornton) Date: Fri, 3 Sep 2021 10:10:57 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: Much of the problem, I think, is that: 1) an idealized PDP-11 (I absolutely take Warner's point that that idealization never really existed) is a sufficiently simple model that a Bear Of Little Brain, such as myself, can reason about what's going to happen in response to a particular sequence of instructions, and get fairly proficient in instructing the machine to do so in a non-geological timeframe. 2) a modern CPU? Let alone SoC? Fuggedaboutit unless you're way, way smarter than I am. (I mean, I do realize that this particular venue has a lot of those people in it...but, really, those are people with extraordinary minds.) There are enough people in the world capable of doing 1 and not 2 that we can write software that usually mostly kinda works and often gets stuff done before collapsing in a puddle of nasty-smelling goo. There aren't many people at all capable of 2, and as the complexity of systems increases, that number shrinks. In short, this ends up being the same argument that comes around every so often, "why are you people still pretending that the computer is a PDP-11 when it clearly isn't?" Because, as with the keys and the streetlight, that's what we have available to us. Only a grossly oversimplified model fits into our heads. Adam On Fri, Sep 3, 2021 at 8:57 AM Warner Losh wrote: > > > On Wed, Sep 1, 2021 at 4:00 PM Dan Cross wrote: > >> I'm curious about other peoples' thoughts on the talk and the overall >> topic? >> > > My comment is that the mental map that he presents has always been a lie. > At least it's been a lie from a very early time. > > Even in Unibus/Qbus days, the add-in cards had some kind of processor > on it from an early time. Several of the VAX boards had 68000 or similar > CPUs that managed memory. Even the simpler MFM boards had buffer > memory that needed to be managed before the DMA/PIO pulled it out > of the card. There's always been an element of different address spaces > with different degrees of visibility into those address spaces. > > What has changed is all of these things are now on the SoC die so > you have good visibility (well, as good as the docs) into these things. > The number of different things has increased, and the for cross domain > knowledge has increased. > > The simplistic world view was even inaccurate at the start.... > > Warner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Sep 4 03:28:48 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 3 Sep 2021 10:28:48 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: <20210903172848.GF13471@mcvoy.com> I am exactly as Adam described, still thinking like it is a PDP-11. Such an understandable machine. For me, out of order execution kind of blew up my brain, that's when I stopped doing serious kernel work, I just couldn't get to a mental model of how you reasoned about that. Though I was talking to someone about it, maybe Clem, recently and came to the conclusion that it is fine, we already sort of had this mess with pipelines. So maybe it is fine, but out of order bugs my brain. On Fri, Sep 03, 2021 at 10:10:57AM -0700, Adam Thornton wrote: > Much of the problem, I think, is that: > > 1) an idealized PDP-11 (I absolutely take Warner's point that that > idealization never really existed) is a sufficiently simple model that a > Bear Of Little Brain, such as myself, can reason about what's going to > happen in response to a particular sequence of instructions, and get fairly > proficient in instructing the machine to do so in a non-geological > timeframe. > > 2) a modern CPU? Let alone SoC? Fuggedaboutit unless you're way, way > smarter than I am. (I mean, I do realize that this particular venue has a > lot of those people in it...but, really, those are people with > extraordinary minds.) > > There are enough people in the world capable of doing 1 and not 2 that we > can write software that usually mostly kinda works and often gets stuff > done before collapsing in a puddle of nasty-smelling goo. There aren't > many people at all capable of 2, and as the complexity of systems > increases, that number shrinks. > > In short, this ends up being the same argument that comes around every so > often, "why are you people still pretending that the computer is a PDP-11 > when it clearly isn't?" Because, as with the keys and the streetlight, > that's what we have available to us. Only a grossly oversimplified model > fits into our heads. > > Adam > > On Fri, Sep 3, 2021 at 8:57 AM Warner Losh wrote: > > > > > > > On Wed, Sep 1, 2021 at 4:00 PM Dan Cross wrote: > > > >> I'm curious about other peoples' thoughts on the talk and the overall > >> topic? > >> > > > > My comment is that the mental map that he presents has always been a lie. > > At least it's been a lie from a very early time. > > > > Even in Unibus/Qbus days, the add-in cards had some kind of processor > > on it from an early time. Several of the VAX boards had 68000 or similar > > CPUs that managed memory. Even the simpler MFM boards had buffer > > memory that needed to be managed before the DMA/PIO pulled it out > > of the card. There's always been an element of different address spaces > > with different degrees of visibility into those address spaces. > > > > What has changed is all of these things are now on the SoC die so > > you have good visibility (well, as good as the docs) into these things. > > The number of different things has increased, and the for cross domain > > knowledge has increased. > > > > The simplistic world view was even inaccurate at the start.... > > > > Warner > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jon at fourwinds.com Sat Sep 4 03:46:17 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 03 Sep 2021 10:46:17 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware [ really a comment on SoCs ] In-Reply-To: References: Message-ID: <202109031746.183HkHDL3857571@darkstar.fourwinds.com> Adam Thornton writes: > > 2) a modern CPU? Let alone SoC? Fuggedaboutit unless you're way, way Don't know how many of you are hardware/software folks as opposed to just software, but it turns out that SoCs are not immune to the problems that result from bolting disparate stuff together in the software world. A few years ago I was working on a project that included an Atmel SoC. Was having some weirdness, and contacted Atmel to ask them about timing issues between two of the DMA controllers that was unspecified in their documentation but critical to making the project work. Their initial response was "Well, we don't know, that's IP that we bought from ARM, call them and ask." I replied "I don't think that they're gonna talk to me because I'm not the one that bought that IP; you did and it's your job." Fortunately, at that time I knew someone who could escalate the issue for me, and only two months later got the timing numbers that I needed. One could be understandably think that more attention is given to bolting IP blocks together on an SoC than is given when bolting a thousand libraries onto a simple program but that turns out to not be true. Software folks need to be prepared for the fact that there may actually be nobody who knows how portions of the hardware actually work because it's not all designed at one place anymore. We have to be prepared for the SoC version of node.js. Jon From john at jfloren.net Sat Sep 4 03:42:33 2021 From: john at jfloren.net (John Floren) Date: Fri, 03 Sep 2021 17:42:33 +0000 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210903172848.GF13471@mcvoy.com> References: <20210903172848.GF13471@mcvoy.com> Message-ID: When I took Computer Architecture, "reasoning" about out-of-order execution involved 30-page worksheets where we could track the state of the Tomasulo algorithm through each iteration. It was ludicrously slow work, and wouldn't be a lot of fun even if you had a computerized tool to help step through things instead. If you're talking about a modern Intel CPU where your compiler emits CISC instructions which are actually implemented in RISC instructions in the microcode, which in turn get rewritten and reordered internally by the CPU... it's hard to fault programmers for thinking at the level of the instruction set that's presented to them, even if it looks like a PDP-11. The above should not be read as an endorsement of the CPU status quo, of course :) john ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, September 3rd, 2021 at 10:28 AM, Larry McVoy wrote: > I am exactly as Adam described, still thinking like it is a PDP-11. > > Such an understandable machine. For me, out of order execution kind > > of blew up my brain, that's when I stopped doing serious kernel work, > > I just couldn't get to a mental model of how you reasoned about that. > > Though I was talking to someone about it, maybe Clem, recently and > > came to the conclusion that it is fine, we already sort of had this > > mess with pipelines. So maybe it is fine, but out of order bugs my > > brain. > > On Fri, Sep 03, 2021 at 10:10:57AM -0700, Adam Thornton wrote: > > > Much of the problem, I think, is that: > > > > 1. an idealized PDP-11 (I absolutely take Warner's point that that > > > > idealization never really existed) is a sufficiently simple model that a > > > > Bear Of Little Brain, such as myself, can reason about what's going to > > > > happen in response to a particular sequence of instructions, and get fairly > > > > proficient in instructing the machine to do so in a non-geological > > > > timeframe. > > > > 2. a modern CPU? Let alone SoC? Fuggedaboutit unless you're way, way > > > > smarter than I am. (I mean, I do realize that this particular venue has a > > > > lot of those people in it...but, really, those are people with > > > > extraordinary minds.) > > > > > > There are enough people in the world capable of doing 1 and not 2 that we > > > > can write software that usually mostly kinda works and often gets stuff > > > > done before collapsing in a puddle of nasty-smelling goo. There aren't > > > > many people at all capable of 2, and as the complexity of systems > > > > increases, that number shrinks. > > > > In short, this ends up being the same argument that comes around every so > > > > often, "why are you people still pretending that the computer is a PDP-11 > > > > when it clearly isn't?" Because, as with the keys and the streetlight, > > > > that's what we have available to us. Only a grossly oversimplified model > > > > fits into our heads. > > > > Adam > > > > On Fri, Sep 3, 2021 at 8:57 AM Warner Losh imp at bsdimp.com wrote: > > > > > On Wed, Sep 1, 2021 at 4:00 PM Dan Cross crossd at gmail.com wrote: > > > > > > > I'm curious about other peoples' thoughts on the talk and the overall > > > > > > > > topic? > > > > > > My comment is that the mental map that he presents has always been a lie. > > > > > > At least it's been a lie from a very early time. > > > > > > Even in Unibus/Qbus days, the add-in cards had some kind of processor > > > > > > on it from an early time. Several of the VAX boards had 68000 or similar > > > > > > CPUs that managed memory. Even the simpler MFM boards had buffer > > > > > > memory that needed to be managed before the DMA/PIO pulled it out > > > > > > of the card. There's always been an element of different address spaces > > > > > > with different degrees of visibility into those address spaces. > > > > > > What has changed is all of these things are now on the SoC die so > > > > > > you have good visibility (well, as good as the docs) into these things. > > > > > > The number of different things has increased, and the for cross domain > > > > > > knowledge has increased. > > > > > > The simplistic world view was even inaccurate at the start.... > > > > > > Warner > > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From stewart at serissa.com Sat Sep 4 05:02:00 2021 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 3 Sep 2021 15:02:00 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210903172848.GF13471@mcvoy.com> References: <20210903172848.GF13471@mcvoy.com> Message-ID: <7CE6F620-FABD-4C2C-905A-02919FB0BCD5@serissa.com> I don’t really think out-of-order in hardware causes trouble for programmers that wasn’t already there when you use -O3. Compilers will already promote memory to registers and do interprocedural optimization and reorder memory references. You have to sprinkle asm volatile("" ::: "memory"); around like pixie dust to make sure the compiler does things in the order you want, nevermind the hardware. x86 has wildly complex microarchitecture, but the model for a single thread is perfectly sensible. It seems to work like it was in-order. OOO isn’t changing that model of execution at all. I mean you care about it when performance tuning, but not for correctness. Other architectures, ARM, IBM, Alpha, are far worse in this respect. The real problems are when you have multicore in a shared memory space and you have to read all the fine print in the memory ordering chapter and understand the subtle differences between LFENCE and SFENCE and MFENCE. I get that, but I also think shared memory is a failed experiment and we should have gone with distributed memory and clusters and message passing. It is possible for mortals to program those. Regular folks can make 1000 rank MPI programs work, where almost noone other than Maurice Herlihy or like that can reason about locks and threads and shared data structures. My wish for a better world is to integrate messaging into the architecture rather than have an I/O device model for communications. It is criminal that machine to machine comms are still stuck at 800 nanoseconds or so latency. It takes 200 instructions or so to send a message under the best circumstances and a similar number to receive it, plus bus, adapter, wire, and switch time. -L -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 4 05:11:28 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 3 Sep 2021 15:11:28 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210903172848.GF13471@mcvoy.com> References: <20210903172848.GF13471@mcvoy.com> Message-ID: Larry - it's the compiler (code generator) folks that I really feel bad for. They had to deal with the realities of the ISA in many ways more than we do and for them, it's getting worse and worse. BTW - there was a misstatement in a previous message. A current CISC system like the INTEL*64 is not implemented as a RISC µcode, nor are current more RISCy machines like the SPARX and Alpha much less the StrongARM and its followers. What they are internally are *data flow machines *which is why you getting a mixing of instruction ordering, scoreboarding, and all sorts of complexities that blows our mind. At least at the OS we have been used to doing things in parallel, exceptions and interrupts occurring and we have reasoned our ways through things. Butler Lampson and Leslie Lamport gave a parallel calculus to help verify things (although Butler once observed at an old SOSP talk that the problem with parallel is what does 'single step the processor mean anymore.' ). So the idea while the processor is not a PDP-10 or PDP-11 much less a 360/91 or a CDC-6600, we build a model in our heads that does simplify the machine(s) as much as possible. We ensure at least that is correct and then, build up more complexity from there. To me, the problem is that we too often do a poor job of what should be the simple stuff and we continue to make it too complicated. Not to pick on any one group/code base, but Jon's recent observation about the Linux kernel FS interface is a prime point. It's not the processor that was made complex, it's the SW wanting to be all things to all people. To me what Unix started and succeed at its time, and clearly Plan9 was attempted in its time (but failed commercially) was to mask if not toss out as much of the complexity of the HW and get to a couple of simple and common ideas and all programs could agree. Going back to the idea of the bear of the 'slittle brain and try to expose the simplest way to computation. Two of the best Unix talks/papers ever, Rob's "cat -v is a bad idea" and Tom's "All Chips that Fit" has morphed into "I have 64-bits of address space I can link anything into my framework" and "what I power and cool in my current process technology" [a SoC is not different that the board level products that some of us lived]. I recently read a suggestion that the best way to teach begging students to be "good programmers" was to "introduce them to as many frameworks as possible and teach as little theory as they need." I nearly lost my dinner. Is this what programming has come to? Framework/Access Methods/Smart Objects .... To be fair, my own employer is betting on DPC++ and believing OneAPI as the one ring to rule them all. There is a lot to be said of "small is beautiful." How did we get from Sixth Edition UNIX with K&R1 to today? One transistor and one line a code at a time. ᐧ On Fri, Sep 3, 2021 at 1:29 PM Larry McVoy wrote: > I am exactly as Adam described, still thinking like it is a PDP-11. > Such an understandable machine. For me, out of order execution kind > of blew up my brain, that's when I stopped doing serious kernel work, > I just couldn't get to a mental model of how you reasoned about that. > > Though I was talking to someone about it, maybe Clem, recently and > came to the conclusion that it is fine, we already sort of had this > mess with pipelines. So maybe it is fine, but out of order bugs my > brain. > > On Fri, Sep 03, 2021 at 10:10:57AM -0700, Adam Thornton wrote: > > Much of the problem, I think, is that: > > > > 1) an idealized PDP-11 (I absolutely take Warner's point that that > > idealization never really existed) is a sufficiently simple model that a > > Bear Of Little Brain, such as myself, can reason about what's going to > > happen in response to a particular sequence of instructions, and get > fairly > > proficient in instructing the machine to do so in a non-geological > > timeframe. > > > > 2) a modern CPU? Let alone SoC? Fuggedaboutit unless you're way, way > > smarter than I am. (I mean, I do realize that this particular venue has > a > > lot of those people in it...but, really, those are people with > > extraordinary minds.) > > > > There are enough people in the world capable of doing 1 and not 2 that we > > can write software that usually mostly kinda works and often gets stuff > > done before collapsing in a puddle of nasty-smelling goo. There aren't > > many people at all capable of 2, and as the complexity of systems > > increases, that number shrinks. > > > > In short, this ends up being the same argument that comes around every so > > often, "why are you people still pretending that the computer is a PDP-11 > > when it clearly isn't?" Because, as with the keys and the streetlight, > > that's what we have available to us. Only a grossly oversimplified model > > fits into our heads. > > > > Adam > > > > On Fri, Sep 3, 2021 at 8:57 AM Warner Losh wrote: > > > > > > > > > > > On Wed, Sep 1, 2021 at 4:00 PM Dan Cross wrote: > > > > > >> I'm curious about other peoples' thoughts on the talk and the overall > > >> topic? > > >> > > > > > > My comment is that the mental map that he presents has always been a > lie. > > > At least it's been a lie from a very early time. > > > > > > Even in Unibus/Qbus days, the add-in cards had some kind of processor > > > on it from an early time. Several of the VAX boards had 68000 or > similar > > > CPUs that managed memory. Even the simpler MFM boards had buffer > > > memory that needed to be managed before the DMA/PIO pulled it out > > > of the card. There's always been an element of different address spaces > > > with different degrees of visibility into those address spaces. > > > > > > What has changed is all of these things are now on the SoC die so > > > you have good visibility (well, as good as the docs) into these things. > > > The number of different things has increased, and the for cross domain > > > knowledge has increased. > > > > > > The simplistic world view was even inaccurate at the start.... > > > > > > Warner > > > > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at humeweb.com Wed Sep 8 18:29:13 2021 From: andrew at humeweb.com (Andrew Hume) Date: Wed, 8 Sep 2021 01:29:13 -0700 Subject: [TUHS] desiderata Message-ID: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> more garage cleaning this last weekend. i came across some memorabilia from my time at Bell Labs, including a lovely article titled The Electrical Properties of Infants Infants have long been known to grow into adults. Recent experiments show they are useful in applications such as high power circuit breakers. Not to mention a lovely article from the “Medical Aspects of Human Sexuality” (July 1991) titled “Scrotum Self-Repair”. the two items are 1) “Documents for UNIX Volume 1” by Dolotta, Olson and Petrucelli (jan 1981)” 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes the full manual (including man pages) and circuit diagrams. i’d prefer to have them go to some archival place, but send me a private email if you interested and we’ll see what we can do. andrew From dot at dotat.at Wed Sep 8 21:14:27 2021 From: dot at dotat.at (Tony Finch) Date: Wed, 8 Sep 2021 12:14:27 +0100 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: <72b1fb8c-9790-3d79-5645-fc216bb516e@dotat.at> Theodore Ts'o wrote: > > There have been many, many proposals in the distributed computing > arena which all try to answer these questions differently. Solaris > had an answer with Yellow Pages, NFS, etc. OSF/DCE had an answer > involving Kerberos, DCE/RPC, DCE/DFS, etc. More recently we have > Docker's Swarm and Kubernetes, etc. None have achieved dominance, and > that should tell us something. I think there are two different kinds of distributed computing there. Distributed authentication and administration is dominated by Microsoft Active Directory (LDAP, Kerberos, DNS, SMB, ...) which I think can reasonably be regarded as part of Windows (even if many Windows machines aren't part of an AD). That kind of distributed system doesn't try to help you stop caring that there are lots of computers. Whereas Kubernetes and Docker Swarm do automatic lifecycle management for distributed workloads. I have not yet had the pleasure (?) of working with them but I get the impression that it's difficult to set up their access control to stop giving everything root on everything else. They try much harder to make a cluster work as a single system. Tony. -- f.anthony.n.finch https://dotat.at/ St Davids Head to Great Orme Head, including St Georges Channel: Easterly or southeasterly 2 to 4, occasionally 5 at first in north, becoming variable 2 to 4 later. Smooth or slight. Showers, perhaps thundery, fog patches later. Moderate or good, occasionally very poor later. From athornton at gmail.com Thu Sep 9 03:21:39 2021 From: athornton at gmail.com (Adam Thornton) Date: Wed, 8 Sep 2021 10:21:39 -0700 Subject: [TUHS] desiderata In-Reply-To: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> References: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> Message-ID: <42A71855-B388-45A3-BC3A-F09403AF9441@gmail.com> Oh man, I remember “Scrotum Self-Repair” from alt.tasteless, back in the day. That was a classic. > On Sep 8, 2021, at 1:29 AM, Andrew Hume wrote: > > more garage cleaning this last weekend. i came across some memorabilia > from my time at Bell Labs, including a lovely article titled > > The Electrical Properties of Infants > > Infants have long been known to grow into adults. Recent experiments > show they are useful in applications such as high power circuit breakers. > > Not to mention a lovely article from the “Medical Aspects of Human Sexuality” > (July 1991) titled “Scrotum Self-Repair”. > > the two items are > 1) “Documents for UNIX Volume 1” by Dolotta, Olson and Petrucelli (jan 1981)” > 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes > the full manual (including man pages) and circuit diagrams. > > i’d prefer to have them go to some archival place, but send me a private email > if you interested and we’ll see what we can do. > > andrew From pnr at planet.nl Thu Sep 9 17:14:46 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 9 Sep 2021 09:14:46 +0200 Subject: [TUHS] desiderata Message-ID: I’d be interested in a scan of the Blit schematics, and it seems that a few others might be as well: https://minnie.tuhs.org/pipermail/tuhs/2019-December/thread.html#19652 https://github.com/aiju/fpga-blit (for clarity: I’m not ‘aiju') Paul > Message: 1 > Date: Wed, 8 Sep 2021 01:29:13 -0700 > From: Andrew Hume > To: The Eunuchs Hysterical Society > Subject: [TUHS] desiderata > Message-ID: <34E984D3-AD92-402D-9A9C-E84B6362DF77 at humeweb.com> > Content-Type: text/plain; charset=utf-8 > > more garage cleaning this last weekend. [...] > 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes > the full manual (including man pages) and circuit diagrams. > > i’d prefer to have them go to some archival place, but send me a private email > if you interested and we’ll see what we can do. > > andrew From arnold at skeeve.com Thu Sep 9 18:08:46 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 09 Sep 2021 02:08:46 -0600 Subject: [TUHS] desiderata In-Reply-To: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> References: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> Message-ID: <202109090808.18988kWS000694@freefriends.org> Bitsavers would probably be the best place. I have a copy of (1) that I photocopied myself when I did some contracting in the Bell System circa 1982. :-) The Blit manual is certainly worth preserving. My two cents, Arnold Andrew Hume wrote: > more garage cleaning this last weekend. i came across some memorabilia > from my time at Bell Labs, including a lovely article titled > > The Electrical Properties of Infants > > Infants have long been known to grow into adults. Recent experiments > show they are useful in applications such as high power circuit breakers. > > Not to mention a lovely article from the “Medical Aspects of Human Sexuality” > (July 1991) titled “Scrotum Self-Repair”. > > the two items are > 1) “Documents for UNIX Volume 1” by Dolotta, Olson and Petrucelli (jan 1981)” > 2) The complete manual for the Blit. this comes in a blue Teletype binder and includes > the full manual (including man pages) and circuit diagrams. > > i’d prefer to have them go to some archival place, but send me a private email > if you interested and we’ll see what we can do. > > andrew From aek at bitsavers.org Thu Sep 9 19:23:08 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 9 Sep 2021 02:23:08 -0700 Subject: [TUHS] desiderata In-Reply-To: <202109090808.18988kWS000694@freefriends.org> References: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> <202109090808.18988kWS000694@freefriends.org> Message-ID: <8e97e81e-3123-a1a2-117d-cb47de37807c@bitsavers.org> On 9/9/21 1:08 AM, arnold at skeeve.com wrote: > Bitsavers would probably be the best place. I have a copy of (1) > that I photocopied myself when I did some contracting in the > Bell System circa 1982. :-) > > The Blit manual is certainly worth preserving. > I sent a message asking for it. Haven't heard anything back. From web at loomcom.com Fri Sep 10 01:55:24 2021 From: web at loomcom.com (Seth Morabito) Date: Thu, 09 Sep 2021 08:55:24 -0700 Subject: [TUHS] desiderata In-Reply-To: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> References: <34E984D3-AD92-402D-9A9C-E84B6362DF77@humeweb.com> Message-ID: On Wed, Sep 8, 2021, at 1:29 AM, Andrew Hume wrote: > 2) The complete manual for the Blit. this comes in a blue Teletype > binder and includes > the full manual (including man pages) and circuit diagrams. I'm curious, is this the 68K Blit, or the DMD 5620? In either case, I do hope they get preserved and scanned. -Seth -- Seth Morabito Poulsbo, WA web at loomcom.com From douglas.mcilroy at dartmouth.edu Fri Sep 10 03:47:18 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 9 Sep 2021 13:47:18 -0400 Subject: [TUHS] desiderata Message-ID: You can check the Computer History Museum's holdings on line. If they don't have the documents already, they would probably like them. The Living Computer Museum in Seattle had a working blit on display. If they don't already have the manual, I'm sure they would love to have one. Alas, their website says they've "suspended all operations for now", a result of the double whammy of Covid and the death of their principal angel, Paul Allen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From torek at elf.torek.net Fri Sep 10 04:34:12 2021 From: torek at elf.torek.net (Chris Torek) Date: Thu, 9 Sep 2021 11:34:12 -0700 (PDT) Subject: [TUHS] desiderata In-Reply-To: Message-ID: <202109091834.189IYCqx045694@elf.torek.net> Mention of the Blit reminds me of the old Scion SuperScreen. Not sure if there were any production versions sold, but I found a price and some minimal specs on an archived page: http://bitsavers.informatik.uni-stuttgart.de/pdf/scion/Scion_Price_List_Sep1983.pdf 640k! Now where have I seen that number before... :-) The SS was indeed 68k-based; I watched one of Chuck Reiger's grad students (Richard something, cannot recall his last name) work on some assembly code for doing some of the windows on it. Chris From andrew at humeweb.com Fri Sep 10 03:50:55 2021 From: andrew at humeweb.com (Andrew Hume) Date: Thu, 9 Sep 2021 10:50:55 -0700 Subject: [TUHS] desiderata In-Reply-To: References: Message-ID: <0DF057E6-EF8B-41D1-BF76-495EF2870E45@humeweb.com> thanks, doug i’ve been collecting answers; i’m leaning towards scanning + computer museum. > On Sep 9, 2021, at 10:47 AM, Douglas McIlroy wrote: > > You can check the Computer History Museum's holdings on line. If they don't have the documents already, they would probably like them. > > The Living Computer Museum in Seattle had a working blit on display. If they don't already have the manual, I'm sure they would love to have one. Alas, their website says they've "suspended all operations for now", a result of the double whammy of Covid and the death of their principal angel, Paul Allen. From crossd at gmail.com Fri Sep 17 04:38:38 2021 From: crossd at gmail.com (Dan Cross) Date: Thu, 16 Sep 2021 14:38:38 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Wed, Sep 1, 2021 at 5:58 PM Dan Cross wrote: > [snip] > First, thank you for all of the thoughtful responses, both on-list and off. An interesting theme in many of the responses was essentially questioning whether the underlying OS still matters, since the focus on development has shifted to higher levels? E.g., we now provision components of our enormously large and complicated distributed applications with building blocks like containers, less physical machines, let alone processes etc. That is certainly a trend, but it strikes me that those containers have to run somewhere, and at some point, we've still got instructions executing on some CPU, modifying words of memory, registers, etc; presumably all of that runs under the control of an operating system. It is a worthwhile question to ask whether that operating system still matters at all: what we have works, and since it's so hidden behind layers upon layers of abstraction, do we really care what it is? But I claim that it does perhaps more than most folks realize. Certainly, there are metrics that people care about (tail latency, jitter, efficiency at the 90th, 95th, 99th percentile...) and OS effects can have outsized impacts there; Mothy's talk alludes to this when he talks about all of the hidden processing that's happening all over a modern computer, eventually some of that trickles onto the cores that are running one's containerized Node application or whatever (lookin' at you, SMM mode...). At the end of the day, the code we care about still runs in some process under some OS on some bit of physical hardware, regardless of all of the abstractions we've placed on top of those things. What that system does, and the abstractions that its interface provides to programs, still matters. Perhaps another question worth asking is, does it make sense to look at different models for those systems? My subjective impression is that, back in the 60s and 70s, there was much greater variation in system architectures than today. A common explanation for this is that we didn't know how to build systems at the time, so folks threw a lot of stuff at the wall to see what would stick. But we no longer do that...again, Mothy alludes to this in his brief survey of OSDI papers: basically, new systems aren't being presented. Rob Pike also lamented that state of affairs 20 years ago, so it's been going on for a while. Does that mean that we've come up with a recipe for systems that work and work well, and therefore we don't need to rethink those basic building blocks? Or does that mean that we're so used to our systems working well enough that we've become myopic about their architecture, and thus blind to their faults? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Sep 17 05:27:17 2021 From: crossd at gmail.com (Dan Cross) Date: Thu, 16 Sep 2021 15:27:17 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Fri, Sep 3, 2021 at 9:23 AM Theodore Ts'o wrote: > On Thu, Sep 02, 2021 at 11:24:37PM -0400, Douglas McIlroy wrote: > > I set out to write a reply, then found that Marshall had said it all, > > better..Alas, the crucial central principle of Plan 9 got ignored, while > > its ancillary contributions were absorbed into Linux, making Linux fatter > > but still oriented to a bygone milieu. > > I'm really not convinced trying to build distributed computing into > the OS ala Plan 9 is viable. It seems like plan9 itself is an existence proof that this is possible. What it did not present was an existence proof of its scalability and it wasn't successful commercially. It probably bears mentioning that that wasn't really the point of plan9, though; it was a research system. I'll try to address the plan9 specific bits below. The moment the OS has to span multiple > TCB's (Trusted Computing Bases), you have to make some very > opinionated decisions on a number of issues for which we do not have > consensus after decades of trial and error: > Interestingly, plan9 did make opinionated decisions about all of the things mentioned below. Largely, those decisions worked out pretty well. * What kind of directory service do you use? x.500/LDAP? Yellow Pages? > Project Athena's Hesiod? > In the plan9 world, the directory services were provided by the filesystem and a user-level library that consumed databases of information resident in the filesystem itself (ndb(6) -- https://9p.io/magic/man2html/6/ndb). It also provided DNS services for interacting with the larger world. The connection server was an idea that was ahead of it's time (ndb(8) -- https://9p.io/magic/man2html/8/ndb). Also, https://9p.io/sys/doc/net/net.html. * What kind of distributed authentication do you use? Kerboers? > Trust on first use authentication ala ssh? .rhosts style > "trust the network" style authentication? > Plan 9 specifically used a Kerberos-like model, but did not use the Kerberos protocol. I say "Kerberos-like" in that there was a trusted agent on the network that provided authentication services using a protocol based on shared secrets. * What kind of distributed authorization service do you use? Unix-style > numeric user-id/group-id's? X.500 Distinguished Names in ACL's? > Windows-style Security ID's? > User and group names were simple strings. There were no numeric UIDs associated with processes, though the original file server had a user<->integer mapping for directory entries. * Do you assume that all of the machines in your distributed > computation system belong to the same administrative domain? > Not necessarily, no. The model is one of resource sharing, rather than remote access. You usually pull resources into your local namespace, and those can come from anywhere you have access to take them from. They may come from a different "administrative domain". For example, towards the end of the BTL reign, there was a file server at Bell Labs that some folks had accounts on and that one could "import" into one's namespace. That was the main distribution point for the larger community. What if individuals owning their own workstations want to have > system administrator privs on their system? When a user logs into a Plan 9 terminal, they become the "host owner" of that terminal. The host owner is distinguished only in owning the hardware resources of the hosting machine; they have no other special privileges, nor is there an administrative user like `root`. It's slightly unusual, though not unheard of, for a terminal to have a local disk; the disk device is implicitly owned by the host owner. If the user puts a filesystem on that device (say, to cache a dataset locally or something), that's on them, though host owner status doesn't really give any special privileges over the permissions on the files on that filesystem, modulo them going through the raw disk device, of course. That is, the uid==0 implies you bypass all access permission checking is gone in Plan 9. CPU servers have a mechanism where a remote user can start a process on the server that becomes owned by the calling user; this is similar to remote login, except that the user brings their environment with them; the model is more of importing the CPU server's computational resources into the local environment than, say, ssh'ing into a machine. Or is your > distributed OS a niche system which only works when you have > clusters of machines that are all centrally and > administratively owned? > I'm not sure how to parse that; I mean, arguably networks of Unix machines associated with any given organization are "centrally owned and administered"? To get access to any given plan9 network, someone would have to create an account on the file and auth servers, but the system was also installable on a standalone machine with a local filesystem. If folks wanted to connect in from other types of systems, there were mechanisms for doing so: `ssh` and `telnet` servers were distributed and could be used, though the experience for an interactive user was pretty anemic. It was more typical to use a program called `drawterm` that runs as an application on e.g. a Mac or Unix machine and emulates enough of a Plan 9 terminal kernel that a user can effectively `cpu` to a plan9 CPU server. Once logged in via drawterm, one can run an environment including a window system and all the graphical stuff from there. Perhaps the aforementioned Bell Labs file server example clarifies things a bit? * What scale should the distributed system work at? 10's of machines > in a cluster? 100's of machines? 1000's of machines? > Tens of thousands of machines? This is, I think, where one gets to the crux of the problem. Plan 9 worked _really_ well for small clusters of machines (10s) and well enough for larger clusters (up to 100s or 1000s). Distributed systems that work > well on football-sized data centers may not work that well > when you only have a few racks in colo facility. The "I forgot > how to count that low" challenge is a real one... And how. Plan 9 _was_ eventually ported to football-field sized machines (the BlueGene port for DoE was on that scale); Ron can be able to speak to that in more detail, if he is so inclined. In fairness, I do think that required significant effort and it was, of course, highly specialized to HPC applications. My subjective impression was that any given plan9 network would break down at the scale of single-digit thousands of machines and, perhaps, tens of thousands of users. Growing beyond that for general use would probably require some pretty fundamental changes; for example, 9P (the file protocol) includes a client-chosen "FID" in transactions related to any open file, so that file servers must keep track of client state to associate fids to actual files, whether those file refer to disk-resident stable storage or software synthesized "files" for other things (IPC end points; process memory; whatever). There have been many, many proposals in the distributed computing > arena which all try to answer these questions differently. Solaris > had an answer with Yellow Pages, NFS, etc. OSF/DCE had an answer > involving Kerberos, DCE/RPC, DCE/DFS, etc. More recently we have > Docker's Swarm and Kubernetes, etc. None have achieved dominance, and > that should tell us something. > > The advantage of trying push all of these questions into the OS is > that you can try to provide the illusion that there is no difference > between local and remote resources. Is that the case, or is it that system designers try to provide uniform access to different classes of resources? Unix treats socket descriptors very similar to file descriptors very similar to pipes; why shouldn't named resources be handled in similar ways? But that either means that you > have a toy (sorry, "research") system which ignores all of the ways in > which remote computation which extends to a different node that may or > may not be up, which may or may not have belong to a different > administration domain, which may or may not have an adversary on the > network between you and the remote node, etc. OR, you have to make > access to local resources just as painful as access to remote > resources. Furthermore, since supporting access remote resources is > going to have more overhead, the illusion that access to local and > remote resources can be the same can't be comfortably sustained in any > case. > ...or some other way, which we'll never know about because no one thinks to ask the question, "how could we do this differently?" I think that's the crux of Mothy's point. Plan 9, as just one example, asked a lot of questions about the issues you mentioned above 30 years ago. They came up with _a_ set of answers; that set did evolve over time as things progressed. That doesn't mean that those questions were resolved definitively, just that there was a group of researchers who came up with an approach to them that worked for that group. What's changed is that we now take for granted that Linux is there, and we've stopped asking questions about anything outside of that model. When you add to that the complexities of building an OS that tries to > do a really good job supporting local resources --- see all of the > observations in Rob Pike's Systems Software Research is Dead slides > about why this is hard --- it seems to me the solution of trying to > build a hard dividing line between the Local OS and Distributed > Computation infrastructure is the right one. > > There is a huge difference between creating a local OS that can live > on a single developer's machine in their house --- and a distributed > OS which requires setting up a directory server, and an authentication > server, and a secure distributed time server, etc., before you set up > the first useful node that can actually run user workloads. You can > try to do both under a single source tree, but it's going to result in > a huge amount of bloat, and a huge amount of maintenance burden to > keep it all working. I agree with the first part of this paragraph, but then we're talking about researchers, not necessarily unaffiliated open-source developers. Hopefully researchers have some organizational and infrastructure support! By keeping the local node OS and the distributed computation system > separate, it can help control complexity, and that's a big part of > computer science, isn't it? > I don't know. It seems like this whole idea of distributed systems built on networks of loosely coupled, miniature timesharing systems has led to enormous amounts of inescapable complexity. I'll bet the Kubernetes by itself is larger than all of plan9. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Sep 17 05:34:15 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 16 Sep 2021 12:34:15 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> Dan Cross writes: > > First, thank you for all of the thoughtful responses, both on-list and off. > > An interesting theme in many of the responses was essentially questioning > whether the underlying OS still matters, since the focus on development has > shifted to higher levels? E.g., we now provision components of our > enormously large and complicated distributed applications with > building blocks like containers, less physical machines, let alone > processes etc. That is certainly a trend, but it strikes me that those > containers have to run somewhere, and at some point, we've still got > instructions executing on some CPU, modifying words of memory, registers, > etc; presumably all of that runs under the control of an operating system. > > It is a worthwhile question to ask whether that operating system still > matters at all: what we have works, and since it's so hidden behind layers > upon layers of abstraction, do we really care what it is? But I claim that > it does perhaps more than most folks realize. Certainly, there are metrics > that people care about (tail latency, jitter, efficiency at the 90th, 95th, > 99th percentile...) and OS effects can have outsized impacts there; Mothy's > talk alludes to this when he talks about all of the hidden processing > that's happening all over a modern computer, eventually some of that > trickles onto the cores that are running one's containerized Node > application or whatever (lookin' at you, SMM mode...). At the end of the > day, the code we care about still runs in some process under some OS on > some bit of physical hardware, regardless of all of the abstractions we've > placed on top of those things. What that system does, and the abstractions > that its interface provides to programs, still matters. > > Perhaps another question worth asking is, does it make sense to look at > different models for those systems? My subjective impression is that, back > in the 60s and 70s, there was much greater variation in system > architectures than today. A common explanation for this is that we didn't > know how to build systems at the time, so folks threw a lot of stuff at the > wall to see what would stick. But we no longer do that...again, Mothy > alludes to this in his brief survey of OSDI papers: basically, new systems > aren't being presented. Rob Pike also lamented that state of affairs 20 > years ago, so it's been going on for a while. Does that mean that we've > come up with a recipe for systems that work and work well, and therefore we > don't need to rethink those basic building blocks? Or does that mean that > we're so used to our systems working well enough that we've become myopic > about their architecture, and thus blind to their faults? > > - Dan C. Well, I have two different thoughts on this question. The obvious one to me is that of course it matters. I'll start by drawing a lame analogy as our 12 week deck reconstruction project just finished up an hour ago. In a conversation with the contractor he said "You're technically doing a repair so you don't have to pull a permit and bring it up to current code. But, there are some things that I recommend that you do anyway because the technology is much better than what it was when this thing was built 30 years ago." My point here is that sure, we can survive with what's there, but that doesn't mean that we should ignore new technology. I had dinner with one of the people I mentor a few weeks ago. He told me that while he was generally ok working for Google and making gobs of money that he felt sort of empty. He told me that if his project got cancelled he didn't think that the world would notice, and as a mid-20s person seeing the planet that he's living on burning up, he's thinking about changing careers to something that's more meaningful (to him). I think that there is still plenty of work to do on things like efficiency that would be easy to justify if politically energy wasn't so heavily subsidized. Think back a few decades to all of the power-saving changes that the OLPC spawned. Most felt like things were fine the way they were back then too. I think that layers upon layers is wasteful. As I've said before, I'm having difficulty distinguishing the "full stack" in full stack programming from a compost heap. It's not OK to me from a security, safety, and reliability perspective to build on a rotting foundation. It's my opinion that the whole container thing sort of started as a "we can't secure the underlying system so we'll build something secure on top" combined with "it's no fun to fix the unnecessary incompatible mess among virtually identical systems that we've made so we'll build a new fix-it layer" ideologies. How long until problems are found with containers it's decided that the way to fix it is to build "safe deposit boxes" that run in container? Is there ever an end in sight? My second train of thought is to ask the question "what is a computer?" Having started in an era where computing meant basking in the warm glow of vacuum tubes, it's easy to think that it's the hardware. But somewhere along the line microcode made an appearance, followed by nanocode and so on. I'm guessing, especially from spending time with current CS students, that to many a computer is some high-level abstraction. So the question is, below what layer is considered a computer today? From lm at mcvoy.com Fri Sep 17 05:41:03 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Sep 2021 12:41:03 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> Message-ID: <20210916194103.GK26820@mcvoy.com> On Thu, Sep 16, 2021 at 12:34:15PM -0700, Jon Steinhart wrote: > As I've said before, I'm having difficulty distinguishing the "full stack" > in full stack programming from a compost heap. It's not OK to me from a > security, safety, and reliability perspective to build on a rotting > foundation. Amen. > It's my opinion that the whole container thing sort of started as a "we > can't secure the underlying system so we'll build something secure on top" > combined with "it's no fun to fix the unnecessary incompatible mess among > virtually identical systems that we've made so we'll build a new fix-it > layer" ideologies. How long until problems are found with containers > it's decided that the way to fix it is to build "safe deposit boxes" that > run in container? Is there ever an end in sight? I think it is that the newer kids are less willing to understand stuff. So they build something on top that they understand. I agree that they will hit problems and likely build "safe deposit boxes" because the containers are "too complex". Oh, and get off my lawn! From marzhall.o at gmail.com Fri Sep 17 09:14:36 2021 From: marzhall.o at gmail.com (Marshall Conover) Date: Thu, 16 Sep 2021 19:14:36 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210916194103.GK26820@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: While I got a chuckle from this, it focuses on security, and I don't think security sold docker containers. I think what really sold containers was their ability to solve the old, hard problems of configuring and maintaining servers. Docker's use of per-process namespaces is a godsend for running different services on the same machine. I no longer run into two applications fighting over dependency versions, because both applications are running in their own world. This was somewhat possible in chroots, but as someone who tried to use chroots that way a decade ago, docker's made it trivial. Containers are also a godsend for applications that have to be deployed somewhere else. I know a container I deploy will have everything it needs wherever it goes, and will be exactly the thing I built and tested. It's hard to understate the benefits of this: when deploying, I no longer run into issues like "oh shoot, there was some configuration I forgot about on the dev server that I need for prod." I no longer have to create server configuration documentation either, as the documentation is "docker build," followed by "docker run." When we were first starting out on our current project, we built a container that runs our build system's agents. At one point the VM on which we were running those agents went down, and our stop-gap fix was to download and run a few copies of that container locally. As a result, we had builds going the entire time we worked to fix the issue. --------------- Separately, for the larger discussion, I think the abstraction-aerospace-engineering seen over the last few decades comes from the adage "necessity is the mother of invention." People writing business logic today are targeting an OS-independent platform: the browser. That's where developers need solutions, and that's where we see movement. Considering this, it's no surprise the browser has stumbled backwards from a markup language-renderer into a full platform for downloading and running applications and managing their resources, as well as providing complex abstractions for interacting with distributed systems. And it's no surprise those distributed systems have separated as much as possible from whatever's not the browser. In fact, we're seeing agreement in the browser ecosystem for problems like the directory system choice mentioned above. The OIDC workflow was born out of the internet's many-users-to-many-services issue. Now, it's such a decided approach for managing users' access to services that big names like Amazon and Google offer identity provider services using it, and I, as a service writer, can swap between any of them transparently. The services I run only care that the token they're handed is signed by the auth server they're configured to use, and that the token says the user is allowed to use the service contacted. The applications I write and use have no clue what the OS' permissions are for anything they deal with. For them, OS permissions have been made redundant. With this context, I think most of us here have learned by experience why the OS gets no more development, in every discussion they've had with management where they've said "we need to refactor some code that is wonky, but mostly works, because there will probably be errors and bugs and security issues in the future if we don't." Management - which in this case, means the world at large - demands new features, not unspecified heisen-benefits from redoing things that already work. For new features, the browser is their only recourse. And, to boot - if you change the thing under the browser, what if it breaks the browser? Cheers! Marshall On Thu, Sep 16, 2021 at 3:41 PM Larry McVoy wrote: > > On Thu, Sep 16, 2021 at 12:34:15PM -0700, Jon Steinhart wrote: > > As I've said before, I'm having difficulty distinguishing the "full stack" > > in full stack programming from a compost heap. It's not OK to me from a > > security, safety, and reliability perspective to build on a rotting > > foundation. > > Amen. > > > It's my opinion that the whole container thing sort of started as a "we > > can't secure the underlying system so we'll build something secure on top" > > combined with "it's no fun to fix the unnecessary incompatible mess among > > virtually identical systems that we've made so we'll build a new fix-it > > layer" ideologies. How long until problems are found with containers > > it's decided that the way to fix it is to build "safe deposit boxes" that > > run in container? Is there ever an end in sight? > > I think it is that the newer kids are less willing to understand stuff. > So they build something on top that they understand. I agree that they > will hit problems and likely build "safe deposit boxes" because the > containers are "too complex". > > Oh, and get off my lawn! From robpike at gmail.com Fri Sep 17 09:44:42 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 17 Sep 2021 09:44:42 +1000 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: I believe that Docker would not have been nearly as successful if shared libraries had not taken over the Unix world. Docker would have been helpful for putting together Python and Java installations, with all their ancillary bits, but less so for C binaries. Now, though, we run an OS on the machine, put a VM on that, install a container on that, and run another VM (or JVM) inside the container, then maybe we're at the level where we can execute actual code. And that misses all the extra pieces that are distributed and layered and indirected and virtualized for management, logging, security, data warehousing, ... It's a wonder any of it works at all. Here's a map to guide you: https://landscape.cncf.io/ -rob On Fri, Sep 17, 2021 at 9:15 AM Marshall Conover wrote: > While I got a chuckle from this, it focuses on security, and I don't > think security sold docker containers. I think what really sold > containers was their ability to solve the old, hard problems of > configuring and maintaining servers. > > Docker's use of per-process namespaces is a godsend for running > different services on the same machine. I no longer run into two > applications fighting over dependency versions, because both > applications are running in their own world. This was somewhat > possible in chroots, but as someone who tried to use chroots that way > a decade ago, docker's made it trivial. > > Containers are also a godsend for applications that have to be > deployed somewhere else. I know a container I deploy will have > everything it needs wherever it goes, and will be exactly the thing I > built and tested. It's hard to understate the benefits of this: when > deploying, I no longer run into issues like "oh shoot, there was some > configuration I forgot about on the dev server that I need for prod." > I no longer have to create server configuration documentation either, > as the documentation is "docker build," followed by "docker run." When > we were first starting out on our current project, we built a > container that runs our build system's agents. At one point the VM on > which we were running those agents went down, and our stop-gap fix was > to download and run a few copies of that container locally. As a > result, we had builds going the entire time we worked to fix the > issue. > > --------------- > > Separately, for the larger discussion, I think the > abstraction-aerospace-engineering seen over the last few decades comes > from the adage "necessity is the mother of invention." People writing > business logic today are targeting an OS-independent platform: the > browser. That's where developers need solutions, and that's where we > see movement. Considering this, it's no surprise the browser has > stumbled backwards from a markup language-renderer into a full > platform for downloading and running applications and managing their > resources, as well as providing complex abstractions for interacting > with distributed systems. And it's no surprise those distributed > systems have separated as much as possible from whatever's not the > browser. > > In fact, we're seeing agreement in the browser ecosystem for problems > like the directory system choice mentioned above. The OIDC workflow > was born out of the internet's many-users-to-many-services issue. Now, > it's such a decided approach for managing users' access to services > that big names like Amazon and Google offer identity provider services > using it, and I, as a service writer, can swap between any of them > transparently. The services I run only care that the token they're > handed is signed by the auth server they're configured to use, and > that the token says the user is allowed to use the service contacted. > The applications I write and use have no clue what the OS' permissions > are for anything they deal with. For them, OS permissions have been > made redundant. > > With this context, I think most of us here have learned by experience > why the OS gets no more development, in every discussion they've had > with management where they've said "we need to refactor some code that > is wonky, but mostly works, because there will probably be errors and > bugs and security issues in the future if we don't." Management - > which in this case, means the world at large - demands new features, > not unspecified heisen-benefits from redoing things that already work. > For new features, the browser is their only recourse. > > And, to boot - if you change the thing under the browser, what if it > breaks the browser? > > Cheers! > > Marshall > > > > > > > > > > > On Thu, Sep 16, 2021 at 3:41 PM Larry McVoy wrote: > > > > On Thu, Sep 16, 2021 at 12:34:15PM -0700, Jon Steinhart wrote: > > > As I've said before, I'm having difficulty distinguishing the "full > stack" > > > in full stack programming from a compost heap. It's not OK to me from > a > > > security, safety, and reliability perspective to build on a rotting > > > foundation. > > > > Amen. > > > > > It's my opinion that the whole container thing sort of started as a "we > > > can't secure the underlying system so we'll build something secure on > top" > > > combined with "it's no fun to fix the unnecessary incompatible mess > among > > > virtually identical systems that we've made so we'll build a new fix-it > > > layer" ideologies. How long until problems are found with containers > > > it's decided that the way to fix it is to build "safe deposit boxes" > that > > > run in container? Is there ever an end in sight? > > > > I think it is that the newer kids are less willing to understand stuff. > > So they build something on top that they understand. I agree that they > > will hit problems and likely build "safe deposit boxes" because the > > containers are "too complex". > > > > Oh, and get off my lawn! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Sep 17 09:45:15 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 16 Sep 2021 16:45:15 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210916194103.GK26820@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> Larry McVoy writes: > I think it is that the newer kids are less willing to understand stuff. > So they build something on top that they understand. I agree that they > will hit problems and likely build "safe deposit boxes" because the > containers are "too complex". Like usual, we agree on this sort of stuff. A conundrum for me is that this stuff that "they understand" is in my opinion way more complicated than understanding computer hardware and/or an operating system. So I'm not sure where the win is. Jon From davida at pobox.com Fri Sep 17 09:54:26 2021 From: davida at pobox.com (David Arnold) Date: Fri, 17 Sep 2021 09:54:26 +1000 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210916194103.GK26820@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> > On 17 Sep 2021, at 05:41, Larry McVoy wrote: <…> > I think it is that the newer kids are less willing to understand stuff. > So they build something on top that they understand. I agree that they > will hit problems and likely build "safe deposit boxes" because the > containers are "too complex”. Writing a new OS in the 70s or even early 80s meant that you had to replace or port a compiler toolchain, an editor, an email client, a news reader, an IRC client, a couple of simple games, and whatever applications your university/research lab needed to justify its grant money. It was a chunk of work, but it was surmountable by a small team or even a dedicated individual. It was demonstrably possible to build your own machine from CPU upward within a reasonable timeframe (eg. Wirth’s Oberon). It’s still possible (and perhaps even easier) to do that today, but no-one’s really happy with an OS that only provides a handful of applications. In particular, as has been widely stated, a modern web browser is orders of magnitude more work than an OS. But expectations for every type of application have moved on, and a modern editor, chat/messaging app, or game is also likely orders of magnitude more complex and feature-rich than what was once acceptable. For a while, it was possible to have a “POSIX emulation” module/layer/whatever (was Mach the first to go this route?) as a shortcut to this but the breadth of the APIs needed to run, eg. Chrome/ium is again orders of magnitude more work than what was needed to port vi/emacs/rn/etc. And it’s not just those applications: to have your new OS be useful, you need to support a dozen languages, a hundred protocols, thousands of libraries … a vast range of stuff that would take years, perhaps decades, to port over or reinvent in your new paradigm. The idea that you’d turn your back on the accumulated value of 50 years of countless people’s work because your set of system calls is slightly better than the one you’ve got now … that’s a very, very big call. So I think the notion that “the kids” are less willing to understand, or to drill deep, is doing them a disservice. They do understand, and they (mostly) make the choice to leverage that body of work rather than embark on the futility of starting afresh. d From aek at bitsavers.org Fri Sep 17 10:06:01 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 16 Sep 2021 17:06:01 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> Message-ID: <9f97cbbe-3346-68d6-93e8-dd64100b8920@bitsavers.org> On 9/16/21 4:45 PM, Jon Steinhart wrote: > A conundrum for me is that > this stuff that "they understand" is in my opinion way more complicated > than understanding computer hardware and/or an operating system. When a young'un says something like this to snapshot the data in a structure, I'm convinced my title at CHM should be "20th Century Software Curator" because it took me an hour to figure out what that sentence even meant. "You specialize some template for the structures you want to be able to save, and use a concept for a visitor to register members." From lm at mcvoy.com Fri Sep 17 10:32:57 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Sep 2021 17:32:57 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> Message-ID: <20210917003257.GA18465@mcvoy.com> On Thu, Sep 16, 2021 at 04:45:15PM -0700, Jon Steinhart wrote: > Larry McVoy writes: > > I think it is that the newer kids are less willing to understand stuff. > > So they build something on top that they understand. I agree that they > > will hit problems and likely build "safe deposit boxes" because the > > containers are "too complex". > > Like usual, we agree on this sort of stuff. A conundrum for me is that > this stuff that "they understand" is in my opinion way more complicated > than understanding computer hardware and/or an operating system. So I'm > not sure where the win is. Someone, sorry, I suck at names, I think he is in aerospace or similar, had a pretty rational view on why docker made things easier. It was today so should be easy to find. The part that I don't understand is why it seems so hard to deploy stuff today. We supported the same application, a pretty complicated one, 636K lines of code, on every Unix variant, Linux {32,64} {every arch including IBM 360}, MacOS {PPC, x86, and I'm working on M1}, Windows {XP..} and it wasn't that hard. Granted, of the core team, I'm the least intelligent so I hired well, but still. From tytso at mit.edu Fri Sep 17 10:34:52 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 16 Sep 2021 20:34:52 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Thu, Sep 16, 2021 at 03:27:17PM -0400, Dan Cross wrote: > > > > I'm really not convinced trying to build distributed computing into > > the OS ala Plan 9 is viable. > > It seems like plan9 itself is an existence proof that this is possible. > What it did not present was an existence proof of its scalability and it > wasn't successful commercially. It probably bears mentioning that that > wasn't really the point of plan9, though; it was a research system. I should have been more clear. I'm not realliy convinced that building distributed computing into the OS ala Plan 9 is viable from the perspective of commercial success. Of course, Plan 9 did it; but it did it as a research system. The problem is that if a particular company is convinced that they want to use Yellow Pages as their directory service --- or maybe X.509 certificates as their authentication system, or maybe Apollo RPC is the only RPC system for a particularly opinionated site administrator --- and these prior biases disagree with the choices made by a particular OS that had distributed computing services built in as a core part of its functionality, that might be a reason for a particular customer *not* to deploy a particular distributed OS. Of course, this doesn't matter if you don't care if anyone uses it after the paper(s) about said OS has been published. > Plan 9, as just one example, asked a lot of questions about the issues you > mentioned above 30 years ago. They came up with _a_ set of answers; that > set did evolve over time as things progressed. That doesn't mean that those > questions were resolved definitively, just that there was a group of > researchers who came up with an approach to them that worked for that group. There's nothing stopping researchers from creating other research OS's that try to answer that question. However, creating an entire new local node OS from scratch is challenging[1], and then if you then have to recreate new versions of Kerberos, an LDAP directory server, etc., so they all of these functions can be tightly integrated into a single distributed OS ala Plan 9, that seems to be a huge amount of work, requiring a lot of graduate students to pull off. [1] http://doc.cat-v.org/bell_labs/utah2000/ (Page 14, Standards) > What's changed is that we now take for granted that Linux is there, and > we've stopped asking questions about anything outside of that model. It's unclear to me that Linux is blamed as the reason why researchers have stopped asking questions outside of that model. Why should Linux have this effect when the presence of Unix didn't? Or is the argument that it's Linux's fault that Plan 9 has apparently failed to compete with it in the marketplace of ideas? And arguably, Plan 9 failed to make headway against Unix (and OSF/DCE, and Sun NFS, etc.) in the early to mid 90's, which is well before Linux's became popular, so that argument doesn't really make sense, either. - Ted From lm at mcvoy.com Fri Sep 17 10:37:33 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Sep 2021 17:37:33 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: <20210917003733.GB18465@mcvoy.com> On Fri, Sep 17, 2021 at 09:44:42AM +1000, Rob Pike wrote: > Now, though, we run an OS on the machine, put a VM on that, install a > container on that, and run another VM (or JVM) inside the container, then > maybe we're at the level where we can execute actual code. And that misses > all the extra pieces that are distributed and layered and indirected and > virtualized for management, logging, security, data warehousing, ... > > It's a wonder any of it works at all. I think a huge part of why it works is Pugs exporting the IOMMU to user space. If I understand that work correctly, it really doesn't matter how many layers you have, if the layers use what he did, then the layers don't matter for I/O and I/O is usually where things get slow. Rob, that link you sent makes my head spin. Which was probably your intent. --lm From lm at mcvoy.com Fri Sep 17 10:44:25 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Sep 2021 17:44:25 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: <20210917004425.GC18465@mcvoy.com> On Thu, Sep 16, 2021 at 08:34:52PM -0400, Theodore Ts'o wrote: > > What's changed is that we now take for granted that Linux is there, and > > we've stopped asking questions about anything outside of that model. > > It's unclear to me that Linux is blamed as the reason why researchers > have stopped asking questions outside of that model. Why should Linux > have this effect when the presence of Unix didn't? Linux runs on _everything_. From your phone to the top 500 HPC clusters. Unix, for all that it did, never had that level of success. I credit Unix for a lot, including showing Linux what it should be, but Linux took that model and ran with it. Plan 9 is very cool but I am channeling my inner Clem, Plan 9 didn't meet Clem's law. It was never compelling enough to make the masses love it. Linux was good enough. We can argue about if that is a good thing or not, I've watched Linux become more complex and seen docker et al react to that. From jon at fourwinds.com Fri Sep 17 11:10:11 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 16 Sep 2021 18:10:11 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> Message-ID: <202109170110.18H1ABL63319807@darkstar.fourwinds.com> David Arnold writes: > And it’s not just those applications: to have your new OS be useful, > you need to support a dozen languages, a hundred protocols, thousands of > libraries … a vast range of stuff that would take years, perhaps decades, > to port over or reinvent in your new paradigm. > > The idea that you’d turn your back on the accumulated value of 50 years > of countless people’s work because your set of system calls is slightly > better than the one you’ve got now … that’s a very, very big call. > > So I think the notion that “the kids” are less willing to understand, > or to drill deep, is doing them a disservice. They do understand, and > they (mostly) make the choice to leverage that body of work rather than > embark on the futility of starting afresh. I have to respectfully disagree which is a challenge because being disagreeable comes more naturally than being respectful :-) We already have this. I kind of wonder what actual value could have been created with the resources that went into supporting the dozen languages, hundred protocols, and so on. Is there value to me that a library exists that lets me to something in python that is identical to the library that lets me do that same thing in perl or the one that lets me do it in php or the one that lets me do it in ...? No. You made a big assumption that I was suggesting tossing prior work and API specs which I wasn't. Would you have wanted to have the 32 bit system call API frozen because it worked and not wanted 64 bit versions? History shows plenty of good work going into compatibility when the underlying technology evolves. Don't know how much time you spend with "the kids" these days. I make it a point to do so when I can; SIGCOVID has cut into that unfortunately. One can get a CS degree without ever taking an OS course at many respectable institutions. Many are not so much making a choice as doing what they can which is inadequate in my opinion. Was discussing this with someone the other day. I'm glad that I have an engineering degree instead of a computer science degree. And I'm also glad that I prevailed with one of my mentees to double major in EE and CS when he wanted to bail on the EE. While it's a generalization, as an engineeer I was educated on how the universe worked - chemistry, physics, and so on. It was up to me to figure out how to apply that knowledge - I wasn't taught how to lay out a circuit board or to use a CAD package or to write an app. A modern CS degree at many institutions is vocational training in programming. It's not the same thing. Jon From lm at mcvoy.com Fri Sep 17 11:28:47 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Sep 2021 18:28:47 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109170110.18H1ABL63319807@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109170110.18H1ABL63319807@darkstar.fourwinds.com> Message-ID: <20210917012847.GD18465@mcvoy.com> On Thu, Sep 16, 2021 at 06:10:11PM -0700, Jon Steinhart wrote: > Was discussing this with someone the other day. I'm glad that I have an > engineering degree instead of a computer science degree. I have and BS and MS in computer science, with most of a minor in systems arch from the EE department (but not all, I did it for fun, I should have finished it). That said, when people ask me what I am, I say I'm an engineer. And proud of it, I love being an engineer, to me it just means you are someone who figures stuff out. From crossd at gmail.com Fri Sep 17 11:33:02 2021 From: crossd at gmail.com (Dan Cross) Date: Thu, 16 Sep 2021 21:33:02 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: Message-ID: On Thu, Sep 16, 2021 at 8:34 PM Theodore Ts'o wrote: > On Thu, Sep 16, 2021 at 03:27:17PM -0400, Dan Cross wrote: > > > > > > I'm really not convinced trying to build distributed computing into > > > the OS ala Plan 9 is viable. > > > > It seems like plan9 itself is an existence proof that this is possible. > > What it did not present was an existence proof of its scalability and it > > wasn't successful commercially. It probably bears mentioning that that > > wasn't really the point of plan9, though; it was a research system. > > I should have been more clear. I'm not realliy convinced that > building distributed computing into the OS ala Plan 9 is viable from > the perspective of commercial success. Of course, Plan 9 did it; but > it did it as a research system. > > The problem is that if a particular company is convinced that they > want to use Yellow Pages as their directory service --- or maybe X.509 > certificates as their authentication system, or maybe Apollo RPC is > the only RPC system for a particularly opinionated site administrator > --- and these prior biases disagree with the choices made by a > particular OS that had distributed computing services built in as a > core part of its functionality, that might be a reason for a > particular customer *not* to deploy a particular distributed OS. > Ah, I take your meaning. Yes, I can see that being a problem. But we've had similar problems before: "we only buy IBM", or, "does it integrate into our VAXcluster?" Put another way, _every_ system has opinions about how to do things. I suppose the distinction you're making is that we can paper over so many of those by building abstractions on top of the "node" OS. But the node OS is already forcing a shape onto our solutions. Folks working on the Go runtime have told me painful stories about detection of blocking system calls using timers and signals: wouldn't it be easier if the system provided real asynchronous abstractions? But the system call model in Unix/Linux/plan9 etc is highly synchronous. If `open` takes a while for whatever reason (say, blocking on reading directory entries looking up a name?) there's no async IO interface for that, hence shenanigans. But that's what the local node gives me; c'est la vie. Of course, this doesn't matter if you don't care if anyone uses it > after the paper(s) about said OS has been published. > I suspect most researchers don't expect the actual research artifacts to make it directly into products, but that the ideas will hopefully have some impact. Interestingly, Unix seems to have been an exception to this in that Unix itself did make it into industry. > Plan 9, as just one example, asked a lot of questions about the issues you > > mentioned above 30 years ago. They came up with _a_ set of answers; that > > set did evolve over time as things progressed. That doesn't mean that > those > > questions were resolved definitively, just that there was a group of > > researchers who came up with an approach to them that worked for that > group. > > There's nothing stopping researchers from creating other research OS's > that try to answer that question. True, but they aren't. I suspect there are a number of confounding factors at play here; certainly, the breadth and size of the standards they have to implement is an issue, but so is lack of documentation. No one is seriously looking at new system architectures, though. > However, creating an entire new > local node OS from scratch is challenging[1], and then if you then > have to recreate new versions of Kerberos, an LDAP directory server, > etc., so they all of these functions can be tightly integrated into a > single distributed OS ala Plan 9, that seems to be a huge amount of > work, requiring a lot of graduate students to pull off. > > [1] http://doc.cat-v.org/bell_labs/utah2000/ (Page 14, Standards) > Yup. That is the presentation I meant when I mentioned Rob Pike lamenting the situation 20 years ago in the previous message and earlier in the thread. An interesting thing here is that we assume that we have to redo _all_ of that, though. A lot of the software out there is just code that does something interesting, but actually touches the system in a pretty small way. gvisor is an interesting example of this; it provides something that looks an awful lot like Linux to an application, and a lot of stuff can run under it. But the number of system calls _it_ in turn makes to the underlying system is much smaller. > What's changed is that we now take for granted that Linux is there, and > > we've stopped asking questions about anything outside of that model. > > It's unclear to me that Linux is blamed as the reason why researchers > have stopped asking questions outside of that model. Why should Linux > have this effect when the presence of Unix didn't? > a) There's a lot more Linux in the world than there ever was Unix. b) There are more computers now than there were when Unix was popular. c) computers are significantly more complex now than they were when Unix was written. But to be clear, I don't think this trend started with Linux; I get the impression that by the 1980s, a lot of research focused on a Unix-like model to the exclusion of other architectures. The PDP-10 was basically dead by 1981, and we haven't seen a system like TOPS-20 since the 70s. Or is the argument that it's Linux's fault that Plan 9 has apparently > failed to compete with it in the marketplace of ideas? It's hard to make that argument when Linux borrowed so many of plan9's ideas: /proc, per-process namespaces, etc. > And arguably, > Plan 9 failed to make headway against Unix (and OSF/DCE, and Sun NFS, > etc.) in the early to mid 90's, which is well before Linux's became > popular, so that argument doesn't really make sense, either. > That wasn't the argument. There are a number of reasons why plan9 failed to achieve commercial success relative to Unix; most of them have little to do with technology. In many ways, AT&T strangled the baby by holding it too tightly to its chest, fearful of losing control the way they "lost" control of Unix (ironically, something that allowed Unix to flourish and become wildly successful). Incompatibility with the rest of the world was likely an issue, but inaccessibility and overly restrictive licensing in the early 90s practically made it a foregone conclusion. Also, it's a little bit of an aside, but I think we often undercount the impact of individual preference on systems. In so many ways, Linux succeeded because, simply put, people liked working on Linux more than they liked working on other systems. You've mentioned yourself that it was more fun to hack on Linux without having to appease some of the big personalities in the BSD world. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Fri Sep 17 11:38:21 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 16 Sep 2021 18:38:21 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: <202109170138.18H1cL7I3320784@darkstar.fourwinds.com> Marshall Conover writes: > > Separately, for the larger discussion, I think the > abstraction-aerospace-engineering seen over the last few decades comes > from the adage "necessity is the mother of invention." People writing > business logic today are targeting an OS-independent platform: the > browser. Wow. I think that it would be more accurate to say that people writing business logic today are targeting the browser because other people are going through the trouble of porting it to different platforms. Doesn't seem to me the best use of resources given that browsers are more complex than operating systems. And I've had many an experience with things that are not portable among browsers. Of course, given that firefox is trying to die by regularly alienating users and that to a first approximation much everything else is chrome or chrome based, you're effectively saying that people are targeting a single operating system even though we don't call a brower an OS. And while there's no going back, I think that browsers suck. Doesn't seem that anybody had the foresight in the early days to realize that they were really building a virtual machine, so the one that we have ended up with is a Rube Goldberg contraption. CSS is one of the brower components that I find especially appalling. I understand its genesis and all that. Would be lovely to be able to make stuff just work without having to "program". Despite revision after revision it's still impossible to lay out things as desired without reverting to JavaScript. While it didn't start that way, at this point there are so many properties with twisty and often undocumented interactions that it would be better to toss it and just write programs. Of course, programming is "hard" and it's supposedly easier to pore though online forums looking for answers to questions like "I think that this can be done but I have no idea how so can someone please share an incantation with me. I personally prefer a language that has a small number of primitives that can be combined in an understandable manner than a huge number of poorly documented primitives that no one person fully understands. And don't tell me that JavaScript is the answer; while it has some good, it suffers from being the dumping ground for people who were never able to get their favorite feature into other languages; it's an incoherent mess. I know that Larry and Clem and I agree on the value of past work. I was a proofreader for Alan Wirf-Brock's 20 years of JavaScript article. I was busy with other stuff when JavaScript began so wasn't familiar with some of the history. Kind of shook my head reading about Eich's big week-long sprint to get the parser up and running. Though to myself that it would have only been a half-day sprint at most had he used existing tools such as lex and yacc, and had he done so we wouldn't still be suffering from the optional semicolon problem 20 years later. Don't mean to offend anybody here, all just my opinion. Jon From jon at fourwinds.com Fri Sep 17 11:40:47 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 16 Sep 2021 18:40:47 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210917012847.GD18465@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109170110.18H1ABL63319807@darkstar.fourwinds.com> <20210917012847.GD18465@mcvoy.com> Message-ID: <202109170140.18H1elie3320978@darkstar.fourwinds.com> Larry McVoy writes: > On Thu, Sep 16, 2021 at 06:10:11PM -0700, Jon Steinhart wrote: > > Was discussing this with someone the other day. I'm glad that I have an > > engineering degree instead of a computer science degree. > > I have and BS and MS in computer science, with most of a minor in > systems arch from the EE department (but not all, I did it for fun, > I should have finished it). > > That said, when people ask me what I am, I say I'm an engineer. And > proud of it, I love being an engineer, to me it just means you are > someone who figures stuff out. I'm the opposite. Would have double-majored in EE and CS but my school wouldn't allow double majoring unless you stayed for 9 semesters. I finished my EE in 7 semesters and was 2 classes shy of the CS degree and couldn't justify another year just for 2 classes. In hindsight I'm not sure that that was the correct choice because I would have partied my ass off. From lm at mcvoy.com Fri Sep 17 12:04:17 2021 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 16 Sep 2021 19:04:17 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109170140.18H1elie3320978@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109170110.18H1ABL63319807@darkstar.fourwinds.com> <20210917012847.GD18465@mcvoy.com> <202109170140.18H1elie3320978@darkstar.fourwinds.com> Message-ID: <20210917020417.GE18465@mcvoy.com> On Thu, Sep 16, 2021 at 06:40:47PM -0700, Jon Steinhart wrote: > Larry McVoy writes: > > On Thu, Sep 16, 2021 at 06:10:11PM -0700, Jon Steinhart wrote: > > > Was discussing this with someone the other day. I'm glad that I have an > > > engineering degree instead of a computer science degree. > > > > I have and BS and MS in computer science, with most of a minor in > > systems arch from the EE department (but not all, I did it for fun, > > I should have finished it). > > > > That said, when people ask me what I am, I say I'm an engineer. And > > proud of it, I love being an engineer, to me it just means you are > > someone who figures stuff out. > > I'm the opposite. Would have double-majored in EE and CS but my school > wouldn't allow double majoring unless you stayed for 9 semesters. I > finished my EE in 7 semesters and was 2 classes shy of the CS degree > and couldn't justify another year just for 2 classes. In hindsight > I'm not sure that that was the correct choice because I would have > partied my ass off. You do you, I had undiagnosed ADD so partys in college were just an awkward cringe fest for me. Looking backwards, now that I've figured that out, yeah, I can see it, sort of, if I knew then what I know now. I was pretty committed to learning in college. I'm not trying to judge or anything, it was just such a fun focussed time for me, I'd happily give up a party (where I was gonna get nothing) for a few hours on slovax where the BSD source was. Details aside, I think we both self identify as engineers and love it. From jon at fourwinds.com Fri Sep 17 12:21:26 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 16 Sep 2021 19:21:26 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210917020417.GE18465@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109170110.18H1ABL63319807@darkstar.fourwinds.com> <20210917012847.GD18465@mcvoy.com> <202109170140.18H1elie3320978@darkstar.fourwinds.com> <20210917020417.GE18465@mcvoy.com> Message-ID: <202109170221.18H2LQ583323080@darkstar.fourwinds.com> Larry McVoy writes: > > You do you, I had undiagnosed ADD so partys in college were just an > awkward cringe fest for me. Looking backwards, now that I've figured > that out, yeah, I can see it, sort of, if I knew then what I know now. > > I was pretty committed to learning in college. I'm not trying to judge > or anything, it was just such a fun focussed time for me, I'd happily > give up a party (where I was gonna get nothing) for a few hours on slovax > where the BSD source was. > > Details aside, I think we both self identify as engineers and love it. OK, we're getting pretty far afield from UNIX. Probably wasn't using the word "party" in the traditional sense - of the drugs, sex, and rock-n-roll college was consumed by the last two. BSD wasn't a thing when I was in school; I do have a memory of coming in to work at BTL after dinner one evening when Ken was walking out the door with mag tapes under his arm on his way to Berkeley for sabbatical. I got to play with computers and UNIX at BTL, college was building and operating radio stations. Jon From tytso at mit.edu Fri Sep 17 12:48:32 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 16 Sep 2021 22:48:32 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109170110.18H1ABL63319807@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109170110.18H1ABL63319807@darkstar.fourwinds.com> Message-ID: On Thu, Sep 16, 2021 at 06:10:11PM -0700, Jon Steinhart wrote: > > You made a big assumption that I was suggesting tossing prior work and API > specs which I wasn't. Would you have wanted to have the 32 bit system call > API frozen because it worked and not wanted 64 bit versions? History shows > plenty of good work going into compatibility when the underlying technology > evolves. Unfortunately, Implementing all of the old API specs is not easy if you're starting from scratch as you create your new OS. As David wrote in an earlier paragraph: > For a while, it was possible to have a “POSIX emulation” > module/layer/whatever (was Mach the first to go this route?) as a > shortcut to this but the breadth of the APIs needed to run, > eg. Chrome/ium is again orders of magnitude more work than what was > needed to port vi/emacs/rn/etc. And this is the same observation Rob Pike made in his cri du coeur in 2000: * To be a viable computer system, one must honor a huge list of large, and often changing, standards: TCP/IP, HTTP, HTML, XML, CORBA, Unicode, POSIX, NFS, SMB, MIME, POP, IMAP, X, ... * A huge amount of work, but if you don't honor the standards, you're marginalized. * I estimate that 90-95% of the work in Plan 9 was directly or indirectly to honor externally imposed standards. > Don't know how much time you spend with "the kids" these days. I make it a > point to do so when I can; SIGCOVID has cut into that unfortunately. One > can get a CS degree without ever taking an OS course at many respectable > institutions. Many are not so much making a choice as doing what they can > which is inadequate in my opinion. > > Was discussing this with someone the other day. I'm glad that I have an > engineering degree instead of a computer science degree. And I'm also glad > that I prevailed with one of my mentees to double major in EE and CS when > he wanted to bail on the EE. While it's a generalization, as an engineeer I > was educated on how the universe worked - chemistry, physics, and so on. It > was up to me to figure out how to apply that knowledge - I wasn't taught how > to lay out a circuit board or to use a CAD package or to write an app. A > modern CS degree at many institutions is vocational training in programming. > It's not the same thing. When I studied CS in the late 80's, MIT's EE/CS department required all EE's and CS's to take 2 foundational CS classes, and 2 foundational EE classes. This meant that CS folks needed to understand how to build op-amps from transitors (6.002) and descrete and continuous FFT's (6.003). And EE folks needed to be able understand Lambda calculus (6.001), and to build stack and general register computers using 74XX TTL chips on a breadbroad (6.004). Furthermore, CS students needed to take an OS course and/or a compiler course, so by the time you graduated, you understood computers from a "full stack" perspective --- from transitors, to AND/OR gates, to CPU design, to compilers, to OS's, to systems issues around desining big systems like Multics and the SABRE Airline Reservations systems. These days, at MIT, one of things students are taught is how figure out what an under-documented abstraction (implemented in Python), partially by reading the code (but it's way too complex), so it's mostly by deducing the abstraction by running experiments on the Python Library code in question. Given how complex computers have gotten, that's probably more realistic anticipation of what students will need once they graduate, but yeah, it does seem a bit like "vocational training in programming". And that's quite a change. When I was an undergraduate, MIT was proud of the fact that they didn't teach CS students the C language; after all, that would be *way* too practical/vocational. The assumption was after you learned Scheme and CLU, you'd be able pick up other languages on the fly. (And they didn't really *teach* Scheme per se; the first lecture in 6.001 was about the Lambda calculus, and if you couldn't figure out Scheme syntax from the reference manual so you could do the first problem set, well, the EE/CS department was heavily over-subscribed anyway, and it was a good way of filtering out the less committed undergraduates. :-) - Ted From cowan at ccil.org Fri Sep 17 13:54:01 2021 From: cowan at ccil.org (John Cowan) Date: Thu, 16 Sep 2021 23:54:01 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> Message-ID: On Thu, Sep 16, 2021 at 7:15 PM Marshall Conover wrote: > I know a container I deploy will have > everything it needs wherever it goes, and will be exactly the thing I > built and tested. Up to a point, Minister. You can mount a scratch monkey, but you can't mount a scratch Internet or a scratch AWS or a scratch Google. > At one point the VM on > which we were running those agents went down, and our stop-gap fix was > to download and run a few copies of that container locally. > That's true if the container isn't too vulgar big. I can run $EMPLOYER's whole application on my laptop in the root environment, but running it in Docker is too costly even though that's how it's deployed on AWS. > from the adage "necessity is the mother of invention." People writing > business logic today are targeting an OS-independent platform: the > browser. Most actual business logic is still in the back end, at least at my part of the coal face. The browser is more of a programmable platform as time goes by, but it's still a Blit even if no longer just a 3270. > Management - > which in this case, means the world at large - demands new features, > not unspecified heisen-benefits from redoing things that already work. > There is a pressure toward that. But when $CLIENTS (who are a lot bigger than $EMPLOYER) start to complain about how often the application they are paying $$$$$$$ for falls over due to lack of robustness, things change. Not everything can be startup-grade. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cowan at ccil.org Fri Sep 17 14:06:57 2021 From: cowan at ccil.org (John Cowan) Date: Fri, 17 Sep 2021 00:06:57 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <9f97cbbe-3346-68d6-93e8-dd64100b8920@bitsavers.org> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> <9f97cbbe-3346-68d6-93e8-dd64100b8920@bitsavers.org> Message-ID: On Thu, Sep 16, 2021 at 8:13 PM Al Kossow wrote: > When a young'un says something like this to snapshot the data in a > structure, > I'm convinced my title at CHM should be "20th Century Software Curator" > because it > took me an hour to figure out what that sentence even meant. > > "You specialize some template for the structures you want to be able to > save, and use a concept for a visitor to register members." > Y'know, the guy who invented that jargon is a younker of 70 (and from the Labs at that). -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Fri Sep 17 14:18:56 2021 From: aek at bitsavers.org (Al Kossow) Date: Thu, 16 Sep 2021 21:18:56 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <202109162345.18GNjFGn3316576@darkstar.fourwinds.com> <9f97cbbe-3346-68d6-93e8-dd64100b8920@bitsavers.org> Message-ID: On 9/16/21 9:06 PM, John Cowan wrote: > Y'know, the guy who invented that jargon is a younker of 70 (and from the Labs at that). and we had a version of "Talking Moose" called "Talking Barney" at Apple in the late 80's making fun of him and his language. The tuft of hair on top would pop up when he said something exceptional. I've not been able to find a copy of it on my backups, sadly. From meillo at marmaro.de Fri Sep 17 18:52:00 2021 From: meillo at marmaro.de (markus schnalke) Date: Fri, 17 Sep 2021 10:52:00 +0200 Subject: [TUHS] RegExp decision for meta characters: Circumflex Message-ID: <1mR9bE-8RG-00@marmaro.de> Hoi, I'm interested in the early design decisions for meta characters in REs, mainly regarding Ken's RE implementation in ed. Two questions: 1) Circumflex As far as I see, the circumflex (^) is the only meta character that has two different special meanings in REs: First being the beginning of line anchor and second inverting a character class. Why was it chosen for the second one? Why not the exclamation mark in that case? (Sure, C didn't exist by then, but the bang probably was used to negate in other languages of the time, I think.) 2) Symbol for the end of line anchor What is the reason that the beginning of line and end of line anchors are different symbols? Is there a reason why not only one symbol, say the circumflex, was chosen to represent both? I currently see no disadvantages of such a design. (Circumflexes aren't likely to end lines of text, neither.) I would appreciate if you could help me understand these design decisions better. Maybe there existed RE notations that were simply copied ... meillo From robpike at gmail.com Fri Sep 17 19:32:00 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 17 Sep 2021 19:32:00 +1000 Subject: [TUHS] RegExp decision for meta characters: Circumflex In-Reply-To: <1mR9bE-8RG-00@marmaro.de> References: <1mR9bE-8RG-00@marmaro.de> Message-ID: You'd have to ask ken why he chose the characters he did, but I can answer the second question. The beginning and end of line are the same. If you make ^ mean both beginning and end of line, what does this ed command do: s/^/x/ Which end gets the x? -rob On Fri, Sep 17, 2021 at 7:00 PM markus schnalke wrote: > Hoi, > > I'm interested in the early design decisions for meta characters > in REs, mainly regarding Ken's RE implementation in ed. > > Two questions: > > 1) Circumflex > > As far as I see, the circumflex (^) is the only meta character that > has two different special meanings in REs: First being the > beginning of line anchor and second inverting a character class. > Why was it chosen for the second one? Why not the exclamation mark > in that case? (Sure, C didn't exist by then, but the bang probably > was used to negate in other languages of the time, I think.) > > 2) Symbol for the end of line anchor > > What is the reason that the beginning of line and end of line > anchors are different symbols? Is there a reason why not only one > symbol, say the circumflex, was chosen to represent both? I > currently see no disadvantages of such a design. (Circumflexes > aren't likely to end lines of text, neither.) > > I would appreciate if you could help me understand these design > decisions better. Maybe there existed RE notations that were simply > copied ... > > > meillo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robpike at gmail.com Fri Sep 17 19:32:28 2021 From: robpike at gmail.com (Rob Pike) Date: Fri, 17 Sep 2021 19:32:28 +1000 Subject: [TUHS] RegExp decision for meta characters: Circumflex In-Reply-To: References: <1mR9bE-8RG-00@marmaro.de> Message-ID: *NOT* the same. Sorry.... I hope the example explains better than my prose. -rob On Fri, Sep 17, 2021 at 7:32 PM Rob Pike wrote: > You'd have to ask ken why he chose the characters he did, but I can answer > the second question. The beginning and end of line are the same. If you > make ^ mean both beginning and end of line, what does this ed command do: > > s/^/x/ > > Which end gets the x? > > -rob > > > On Fri, Sep 17, 2021 at 7:00 PM markus schnalke wrote: > >> Hoi, >> >> I'm interested in the early design decisions for meta characters >> in REs, mainly regarding Ken's RE implementation in ed. >> >> Two questions: >> >> 1) Circumflex >> >> As far as I see, the circumflex (^) is the only meta character that >> has two different special meanings in REs: First being the >> beginning of line anchor and second inverting a character class. >> Why was it chosen for the second one? Why not the exclamation mark >> in that case? (Sure, C didn't exist by then, but the bang probably >> was used to negate in other languages of the time, I think.) >> >> 2) Symbol for the end of line anchor >> >> What is the reason that the beginning of line and end of line >> anchors are different symbols? Is there a reason why not only one >> symbol, say the circumflex, was chosen to represent both? I >> currently see no disadvantages of such a design. (Circumflexes >> aren't likely to end lines of text, neither.) >> >> I would appreciate if you could help me understand these design >> decisions better. Maybe there existed RE notations that were simply >> copied ... >> >> >> meillo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From meillo at marmaro.de Fri Sep 17 20:10:28 2021 From: meillo at marmaro.de (markus schnalke) Date: Fri, 17 Sep 2021 12:10:28 +0200 Subject: [TUHS] RegExp decision for meta characters: Circumflex In-Reply-To: References: <1mR9bE-8RG-00@marmaro.de> Message-ID: <1mRApA-0wG-00@marmaro.de> Hoi. [2021-09-17 11:32] Rob Pike > > You'd have to ask ken why he chose the characters he did, but I can answer the > second question. The beginning and end of line are the same. If you make ^ mean > both beginning and end of line, what does this ed command do: > > s/^/x/ > > Which end gets the x? Perfect answer! I just never thought about replacing. *oops* Now that's obvious. ;-) meillo From roelof_klaas at yahoo.com Sat Sep 18 00:09:23 2021 From: roelof_klaas at yahoo.com (Roland) Date: Fri, 17 Sep 2021 14:09:23 +0000 (UTC) Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> Message-ID: <2007825471.713023.1631887763341@mail.yahoo.com> Hello Unix fanatics, I have a PDP11/20 and I would love to run an early Unix version on it. I've been working on the hardware for a while and I'm getting more and more of the pieces back online again. The configuration will be two RK05 hard disks, TU56H tape, PC11 paper tape reader/puncher and a RX01 floppy drive. Unfortunately I don't have a MMU or paging option. But it seems that the earliest versions of Unix do not need the extra memory. Does anyone have RK05 disk images for these early Unix versions? That would be a great help. Otherwise it would be great to have some input about how to create a bootable Unix pack for this machine. A bit about the hardware restoring is on the vcfed forum:https://www.vcfed.org/forum/forum/genres/dec/78961-rk05-disk-drive-versionshttps://www.vcfed.org/forum/forum/genres/dec/80723-pdp11-20-restoring Booting RT11 from RK05https://youtu.be/k0tiUcRBPQATU56H tape drive back onlinehttps://youtu.be/_ZJK3QP9gRA Thanks in advance!Roland Huisman   -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Sep 18 00:33:53 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Sep 2021 08:33:53 -0600 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: <2007825471.713023.1631887763341@mail.yahoo.com> References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> Message-ID: On Fri, Sep 17, 2021 at 8:10 AM Roland via TUHS wrote: > Hello Unix fanatics, > > I have a PDP11/20 and I would love to run an early Unix version on it. > I've been working on the hardware for a while and I'm getting more and more > of the pieces back online again. The configuration will be two RK05 hard > disks, TU56H tape, PC11 paper tape reader/puncher and a RX01 floppy drive. > Unfortunately I don't have a MMU or paging option. But it seems that the > earliest versions of Unix do not need the extra memory. > > Does anyone have RK05 disk images for these early Unix versions? That > would be a great help. Otherwise it would be great to have some input about > how to create a bootable Unix pack for this machine. > V5 is the earliest Unix we have contemporary images from. We have fragments from everything else earlier, including files scavenged/recovered from early DECtapes and some code recovered from kernel listings from a Unix course that was put together by Bell Labs... The Unix 1972 project that some TUHS members did. I think it's in the TUHS distribution archive, but also on github. I think Warren Toomey's repo is the canonical one https://github.com/DoctorWkt/unix-jun72 but https://github.com/c3x04/Unix-1st-Edition-jun72 has a couple of newer fixes for a docker file to contain the simh simulator. I'm unsure what hardware that's supported, though. The machine file suggests: rk03/rk11 177400 disk RK dc11 174000 tty? (not supp?) tc11/tu56 177340 dec tape DTn (not showing up in simh?) rf11/rs11 177460 fixed head disk RF kw11-l 177546 clock CLK pc11 177550 paper tape PTR/PTP asr-33 177560 tty? TTI, TTO which has an RK03, not sure how close that is to an RK05, so some tweaks may be needed. Warner > A bit about the hardware restoring is on the vcfed forum: > https://www.vcfed.org/forum/forum/genres/dec/78961-rk05-disk-drive-versions > https://www.vcfed.org/forum/forum/genres/dec/80723-pdp11-20-restoring > > Booting RT11 from RK05 > https://youtu.be/k0tiUcRBPQA > TU56H tape drive back online > https://youtu.be/_ZJK3QP9gRA > > Thanks in advance! > Roland Huisman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 18 01:32:10 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Sep 2021 11:32:10 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> Message-ID: FYI: The KS11 MMU for the 11/20 was built by CSS and was not on the product list as it were. To my knowledge, no hardware or prints of it survive. I've been told it was much more similar to the MMU in the KA10 than the scheme eventually done for the 11/45/55/70 and the 11/40 class systems - but I think Noel has done more investigation than I have. So if others have more info, please chime in. As Warner points out the oldest code base we have is Fifth Edition. I'm not sure if the KS11 code is still there. I did not think so. I thought it ran on 11/40 and 11/45. The V1 work was for a PDP-7 and is before the first 11/20 was secured. The point is that I think there is a hole in the the SW we have. As for RK03 vs. RK05 -- *I think I can help a little*. RK02/RK03 used an RK-11C. I'm fairly sure that the RK05, used the RK11-D controller. The '72 peripherals' handbook describes the former and the '76 the later. But if you believe the handbook, both supported 203 cylinders and 2.45M bytes/disk with 512 byte sectors. The difference seems to have been in drive performance. On Fri, Sep 17, 2021 at 10:34 AM Warner Losh wrote: > > > On Fri, Sep 17, 2021 at 8:10 AM Roland via TUHS > wrote: > >> Hello Unix fanatics, >> >> I have a PDP11/20 and I would love to run an early Unix version on it. >> I've been working on the hardware for a while and I'm getting more and more >> of the pieces back online again. The configuration will be two RK05 hard >> disks, TU56H tape, PC11 paper tape reader/puncher and a RX01 floppy drive. >> Unfortunately I don't have a MMU or paging option. But it seems that the >> earliest versions of Unix do not need the extra memory. >> >> Does anyone have RK05 disk images for these early Unix versions? That >> would be a great help. Otherwise it would be great to have some input about >> how to create a bootable Unix pack for this machine. >> > > V5 is the earliest Unix we have contemporary images from. We have > fragments from everything else earlier, including files scavenged/recovered > from early DECtapes and some code recovered from kernel listings from a > Unix course that was put together by Bell Labs... > > The Unix 1972 project that some TUHS members did. I think it's in the TUHS > distribution archive, but also on github. I think Warren Toomey's repo is > the canonical one https://github.com/DoctorWkt/unix-jun72 but > https://github.com/c3x04/Unix-1st-Edition-jun72 has a couple of newer > fixes for a docker file to contain the simh simulator. I'm unsure what > hardware that's supported, though. The machine file suggests: > > rk03/rk11 177400 disk RK > dc11 174000 tty? (not supp?) > tc11/tu56 177340 dec tape DTn (not showing up in simh?) > rf11/rs11 177460 fixed head disk RF > kw11-l 177546 clock CLK > pc11 177550 paper tape PTR/PTP > asr-33 177560 tty? TTI, TTO > > which has an RK03, not sure how close that is to an RK05, so some tweaks > may be needed. > > Warner > > >> A bit about the hardware restoring is on the vcfed forum: >> >> https://www.vcfed.org/forum/forum/genres/dec/78961-rk05-disk-drive-versions >> https://www.vcfed.org/forum/forum/genres/dec/80723-pdp11-20-restoring >> >> Booting RT11 from RK05 >> https://youtu.be/k0tiUcRBPQA >> TU56H tape drive back online >> https://youtu.be/_ZJK3QP9gRA >> >> Thanks in advance! >> Roland Huisman >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Sep 18 01:35:23 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 17 Sep 2021 11:35:23 -0400 (EDT) Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option Message-ID: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> > From: Roland Huisman > I have a PDP11/20 and I would love to run an early Unix version on > it. ... But it seems that the earliest versions of Unix do not need the > extra memory. Does anyone have RK05 disk images for these early Unix > versions? Although the _kernel_ source for V1 is available: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V1 most of the rest is missing; only 'init' and 'sh' are available. So one would have to write almost _everything_ else. Some commands are available in PDP-11 assembler in later versions, and might be movable without _too_ much work - but one would have to start with the assembler itself, which is luckily in assembler. If I were trying to run 'UNIX' on an -11/20, I think the only reasonable choice would be MINI-UNIX: https://gunkies.org/wiki/MINI-UNIX It's basically V6 UNIX with all use of the PDP-11 memory management removed. The advantage of going MINI-UNIX is that almost all V6 source (applications, drivers, etc) will run on it 'as is'. It does need ~56KB of main memory. If you don't have that much on the -11/20, LSX (links in the above) would be an option; it's very similar to MINI-UNIX, but is trimmed down some, to allow its use on systems with less main memory. I'm not sure if MINI-UNIX has been run on the -11/20, but it _should_ run there; it runs on the -11/05, and the only differences between the /20 and the /05 are that the /20 does not have the RTT instruction (and I just checked, and MINI-UNIX doesn't use RTT), and SWAB doesn't clear the V condition code bit. (There are other minor differences, such as OP Rn, (Rn)+ are different on the -11/20, but that shouldn't be an issue.) Step 1 would be to get MINI-UNIX running on an -11/20 under a simulator; links in the above to get you there. Noel From bakul at iitbombay.org Sat Sep 18 01:56:13 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 17 Sep 2021 08:56:13 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> Message-ID: <8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org> On Sep 16, 2021, at 12:34 PM, Jon Steinhart wrote: > > It's my opinion that the whole container thing sort of started as a "we > can't secure the underlying system so we'll build something secure on top" > combined with "it's no fun to fix the unnecessary incompatible mess among > virtually identical systems that we've made so we'll build a new fix-it > layer" ideologies. How long until problems are found with containers > it's decided that the way to fix it is to build "safe deposit boxes" that > run in container? Is there ever an end in sight? Recall that previously sysadmins used programs such as ghost to image a system. A completely operational system with all the required software could be created fairly quickly with minimum configuration. If your h/w crashed, you can get up and running fairly quickly on a new machine (provided your unique bits were backed up & restored). The same thing could be done for server machines. By minimizing differences you can apply security patches or put new machines in service quickly. A server machine needs much more than the main service program before it can be put in real service but machines providing the same service need pretty much the same things. When VMs and containers started getting used, the same model could be used for provisioning them. The docker folks simplified this further. Now you can spin up new servers almost trivially (even if later tooling via Kubernetes and such got quite complicated). Seems to me, this provisioning of whole systems is what users of technologies such as jail never quite got it. A couple of points on this: 1) I think this can be simplified even further if one can rely on a fast control plane connection by basically lazily pulling in the contents of each container. 2) If the underlying system provides a capability architecture, you can probably achieve the exact same functionality without containers as the required "many worlds" functionality is already built in. -- Bakul From roelof_klaas at yahoo.com Sat Sep 18 02:04:12 2021 From: roelof_klaas at yahoo.com (Roland) Date: Fri, 17 Sep 2021 16:04:12 +0000 (UTC) Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> Message-ID: <1359803079.736350.1631894652157@mail.yahoo.com> Hi Clem, FYI:  The KS11 MMU for the 11/20 was built by CSS and was not on the product list as it were. To my knowledge, no hardware or prints of it survive.    I've been told it was much more similar to the MMU in the KA10 than the scheme eventually done for the 11/45/55/70 and the 11/40 class systems - but I think Noel has done more investigation than I have.  So if others have more info, please chime in. There is a KT11B paging option that makes the PDP11/20 a 18 bit machine. It looks a bit like the TC11 DECtape controller. I've got the schematics from the internet. But I have no idea how it compares to the later MMU units from the software perspective. As Warner points out the oldest code base we have is Fifth Edition.    I'm not sure if the KS11 code is still there.  I did not think so.  I thought it ran on 11/40 and 11/45. Yes, that is what I found too. V5 expects an 11/40 with at least 18 bits memory address space. The V1 work was for a PDP-7 and is before the first 11/20 was secured.  The point is that I think there is a hole in the the SW we have. Too bad, but you never know what is still hidden in some attics... As for RK03 vs. RK05  -- I think I can help a little.  RK02/RK03 used an RK-11C.  I'm fairly sure that the RK05,  used the RK11-D controller.   The '72 peripherals' handbook describes the former and the '76 the later.  But if you believe the handbook, both supported 203 cylinders and 2.45M bytes/disk with 512 byte sectors.  The difference seems to have been in drive performance. Yes the RK03 was the Diablo 31 with a DEC label on it. 100% compatible with RK11D and RK05. You can swap the packs between these drives as well... So I'm hoping for a disk image for such a drive... 😊 Regards, Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From roelof_klaas at yahoo.com Sat Sep 18 02:05:04 2021 From: roelof_klaas at yahoo.com (Roland) Date: Fri, 17 Sep 2021 16:05:04 +0000 (UTC) Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> Message-ID: <205429669.748473.1631894704660@mail.yahoo.com> Hi Warner, Thanks for your reply! V5 is the earliest Unix we have contemporary images from. We have fragments from everything else earlier, including files scavenged/recovered from early DECtapes and some code recovered from kernel listings from a Unix course that was put together by Bell Labs... What I foundon Wikipedia about Unix V5 is that is needs an MMU. " 5th Edition Targetedthe PDP-11/40 and other 11 models with 18 bit addresses." Because it uses18 bit address space it probably expects 248K of memory. My machine does nothave a paging option or mmu. So I think that means that I can't use V5 unfortunately... The Unix 1972 project that some TUHS members did. I think it's in the TUHS distribution archive, but also on github. I think Warren Toomey's repo is the canonical one https://github.com/DoctorWkt/unix-jun72 but https://github.com/c3x04/Unix-1st-Edition-jun72 has a couple of newer fixes for a docker file to contain the simh simulator. I'm unsure what hardware that's supported, though.  The machine file suggests: rk03/rk11   177400     disk             RK dc11        174000     tty?             (not supp?) tc11/tu56   177340     dec tape         DTn (not showing up in simh?) rf11/rs11   177460     fixed head disk  RF kw11-l      177546     clock            CLK pc11        177550     paper tape       PTR/PTP asr-33      177560     tty?             TTI, TTO which has an RK03, not sure how close that is to an RK05, so some tweaks may be needed. That RK03 isa Diablo 31. It uses the same packs and same interface as the RK05 and is 100%compatible. The RK05 was build by Digital itself and not by Diablo any more. I have the TC11/TU56, PC11, asr33 tty and KW11-L line clock as well. So that is almost the complete list of devices you showed here... So if it is possible to generate a RK03/RK05 disk image from that simulator then I think I can put that on a real RK05 disk pack. But I'm completely new in this old Unix era... So if anyone could help to generate such an image then it would be a great help! Regards, Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Sep 18 02:13:05 2021 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Sep 2021 10:13:05 -0600 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> Message-ID: On Fri, Sep 17, 2021 at 9:32 AM Clem Cole wrote: > FYI: The KS11 MMU for the 11/20 was built by CSS and was not on the > product list as it were. To my knowledge, no hardware or prints of it > survive. I've been told it was much more similar to the MMU in the KA10 > than the scheme eventually done for the 11/45/55/70 and the 11/40 class > systems - but I think Noel has done more investigation than I have. So if > others have more info, please chime in. > > As Warner points out the oldest code base we have is Fifth Edition. > I'm not sure if the KS11 code is still there. I did not think so. I > thought it ran on 11/40 and 11/45. > > The V1 work was for a PDP-7 and is before the first 11/20 was secured. > The point is that I think there is a hole in the the SW we have. > V0 was for the pdp-7/pdp-9. V1 was the first port to the 11/20. V2 still supports the 11/20, but V3 and V4 move heavily to the 11/40s and 11/45s. We have printouts for V0. And the kernel for V1 with bits and pieces in the V2 to V3 timeframe that folded into the Unix-Jun72 efforts. Warner > As for RK03 vs. RK05 -- *I think I can help a little*. RK02/RK03 used > an RK-11C. I'm fairly sure that the RK05, used the RK11-D controller. > The '72 peripherals' handbook describes the former and the '76 the later. > But if you believe the handbook, both supported 203 cylinders and 2.45M > bytes/disk with 512 byte sectors. The difference seems to have been in > drive performance. > > On Fri, Sep 17, 2021 at 10:34 AM Warner Losh wrote: > >> >> >> On Fri, Sep 17, 2021 at 8:10 AM Roland via TUHS >> wrote: >> >>> Hello Unix fanatics, >>> >>> I have a PDP11/20 and I would love to run an early Unix version on it. >>> I've been working on the hardware for a while and I'm getting more and more >>> of the pieces back online again. The configuration will be two RK05 hard >>> disks, TU56H tape, PC11 paper tape reader/puncher and a RX01 floppy drive. >>> Unfortunately I don't have a MMU or paging option. But it seems that the >>> earliest versions of Unix do not need the extra memory. >>> >>> Does anyone have RK05 disk images for these early Unix versions? That >>> would be a great help. Otherwise it would be great to have some input about >>> how to create a bootable Unix pack for this machine. >>> >> >> V5 is the earliest Unix we have contemporary images from. We have >> fragments from everything else earlier, including files scavenged/recovered >> from early DECtapes and some code recovered from kernel listings from a >> Unix course that was put together by Bell Labs... >> >> The Unix 1972 project that some TUHS members did. I think it's in the >> TUHS distribution archive, but also on github. I think Warren Toomey's repo >> is the canonical one https://github.com/DoctorWkt/unix-jun72 but >> https://github.com/c3x04/Unix-1st-Edition-jun72 has a couple of newer >> fixes for a docker file to contain the simh simulator. I'm unsure what >> hardware that's supported, though. The machine file suggests: >> >> rk03/rk11 177400 disk RK >> dc11 174000 tty? (not supp?) >> tc11/tu56 177340 dec tape DTn (not showing up in simh?) >> rf11/rs11 177460 fixed head disk RF >> kw11-l 177546 clock CLK >> pc11 177550 paper tape PTR/PTP >> asr-33 177560 tty? TTI, TTO >> >> which has an RK03, not sure how close that is to an RK05, so some tweaks >> may be needed. >> >> Warner >> >> >>> A bit about the hardware restoring is on the vcfed forum: >>> >>> https://www.vcfed.org/forum/forum/genres/dec/78961-rk05-disk-drive-versions >>> https://www.vcfed.org/forum/forum/genres/dec/80723-pdp11-20-restoring >>> >>> Booting RT11 from RK05 >>> https://youtu.be/k0tiUcRBPQA >>> TU56H tape drive back online >>> https://youtu.be/_ZJK3QP9gRA >>> >>> Thanks in advance! >>> Roland Huisman >>> >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 18 02:14:54 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Sep 2021 12:14:54 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: <1359803079.736350.1631894652157@mail.yahoo.com> References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> <1359803079.736350.1631894652157@mail.yahoo.com> Message-ID: On Fri, Sep 17, 2021 at 12:04 PM Roland via TUHS wrote: > > There is a KT11B paging option that makes the PDP11/20 a 18 bit machine. > It looks a bit like the TC11 DECtape controller. I've got the schematics > from the internet. But I have no idea how it compares to the later MMU > units from the software perspective. > Love to see them and if you know where you found them. > The V1 work was for a PDP-7 and is before the first 11/20 was secured. > The point is that I think there is a hole in the the SW we have. > I just looked again at what Warren has -- it is the 11/20 assembler code that Dennis scanned. I have forgotten that we still had that. I wonder if it had the KS-11 stuff in it. I'll have to peek ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Sep 18 02:17:23 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Sep 2021 12:17:23 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> Message-ID: On Fri, Sep 17, 2021 at 12:13 PM Warner Losh wrote: > > We have printouts for V0. And the kernel for V1 with bits and pieces in > the V2 to V3 timeframe that folded into the Unix-Jun72 efforts. > Right. Need to look to see if the KS11 support was in there. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From douglas.mcilroy at dartmouth.edu Sat Sep 18 02:40:43 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Fri, 17 Sep 2021 12:40:43 -0400 Subject: [TUHS] RegExp decision for meta characters: Circumflex Message-ID: > Maybe there existed RE notations that were simply copied ... Ed was derived from Ken's earlier qed. Qed's descendant in Multics was described in a 1969 GE document: http://www.bitsavers.org/pdf/honeywell/multics/swenson/6906.multics-condensed-guide.pdf. Unfortunately it describes regular expressions only sketchily by example. However, alternation, symbolized by | with grouping by parentheses, was supported in qed, whereas alternation was omitted from ed. The GE document does not mention character classes; an example shows how to use alternation for the same purpose. Beginning-of-line is specified by a logical-negation symbol. In apparent contradiction, the v1 manual says the meanings of [ and ^ are the same in ed and (an unspecified version of) qed. My guess about the discrepancies is no better than yours. (I am amused by the title "condensed guide" for a manual in which each qed request gets a full page of explanation. It exemplifies how Unix split from Multics in matters of taste.) Doug From roelof_klaas at yahoo.com Sat Sep 18 02:44:42 2021 From: roelof_klaas at yahoo.com (Roland) Date: Fri, 17 Sep 2021 16:44:42 +0000 (UTC) Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <2007825471.713023.1631887763341.ref@mail.yahoo.com> <2007825471.713023.1631887763341@mail.yahoo.com> <1359803079.736350.1631894652157@mail.yahoo.com> Message-ID: <1053956686.747705.1631897082211@mail.yahoo.com> There is a KT11B paging option that makes the PDP11/20 a 18 bit machine. It looks a bit like the TC11 DECtape controller. I've got the schematics from the internet. But I have no idea how it compares to the later MMU units from the software perspective.Love to see them and if you know where you found them.  Al has put them online once. http://bitsavers.trailing-edge.com/pdf/dec/pdp11/1120/KT11-B_EngrDrws_Feb72.pdfhttp://bitsavers.trailing-edge.com/pdf/dec/pdp11/1120/KT11-B_OD_Apr71.pdf The V1 work was for a PDP-7 and is before the first 11/20 was secured.  The point is that I think there is a hole in the the SW we have. I just looked again at what Warren has -- it is the 11/20 assembler code that Dennis scanned.  I have forgotten that we still had that.   I wonder if it had the KS-11 stuff in it.   I'll have to peek  I wonder is there is some compatibility with the KT11-B Regards, Roland rrrjj -------------- next part -------------- An HTML attachment was scrubbed... URL: From bakul at iitbombay.org Sat Sep 18 03:07:11 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 17 Sep 2021 10:07:11 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210917004425.GC18465@mcvoy.com> References: <20210917004425.GC18465@mcvoy.com> Message-ID: <5A1F2D0B-9A1B-4E6D-9032-F0FCCE58D1E3@iitbombay.org> On Sep 16, 2021, at 5:44 PM, Larry McVoy wrote: > > On Thu, Sep 16, 2021 at 08:34:52PM -0400, Theodore Ts'o wrote: >>> What's changed is that we now take for granted that Linux is there, and >>> we've stopped asking questions about anything outside of that model. >> >> It's unclear to me that Linux is blamed as the reason why researchers >> have stopped asking questions outside of that model. Why should Linux >> have this effect when the presence of Unix didn't? > > Linux runs on _everything_. From your phone to the top 500 HPC clusters. > > Unix, for all that it did, never had that level of success. I credit > Unix for a lot, including showing Linux what it should be, but Linux > took that model and ran with it. > > Plan 9 is very cool but I am channeling my inner Clem, Plan 9 didn't meet > Clem's law. It was never compelling enough to make the masses love it. > Linux was good enough. Things might have been different if Plan9 was open sourced in the same time frame as 386BSD and early Linux. Back then Linux was not good enough. plan9 was not all that different from unix and simpler to understand and use. > We can argue about if that is a good thing or not, I've watched Linux > become more complex and seen docker et al react to that. As Marshall Conover (& later I) said, containers & docker filled a genuine need. Not much to do with the complexity of Linux. Plan9 could've provided a much simpler and cleaner platform than linux but that was not to be. [plan has a couple of global names spaces that might have needed changing. Specifically the process id and '#' driver spaces] -- Bakul From bakul at iitbombay.org Sat Sep 18 03:39:52 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 17 Sep 2021 10:39:52 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> Message-ID: On Sep 16, 2021, at 4:54 PM, David Arnold wrote: > > And it’s not just those applications: to have your new OS be useful, you need to support a dozen languages, a hundred protocols, thousands of libraries … a vast range of stuff that would take years, perhaps decades, to port over or reinvent in your new paradigm. > > The idea that you’d turn your back on the accumulated value of 50 years of countless people’s work because your set of system calls is slightly better than the one you’ve got now … that’s a very, very big call. > > So I think the notion that “the kids” are less willing to understand, or to drill deep, is doing them a disservice. They do understand, and they (mostly) make the choice to leverage that body of work rather than embark on the futility of starting afresh. I have mixed feelings about this. Unix didn't "throw away" the mainframe world of computing. It simply created a new ecosystem, more suited for the microprocessor age. For IBM it was perhaps the classic Innovator's Dilemma. Similarly now we have (mostly) the Linux ecosystem, while the actual hardware has diverged a lot from the C memory model. There are security issues. There is firmware running on these system about which the OS knows nothing. We have processors like Esperanto Tech's 1088 64 bit Risc-V cores, each with its own vector/tensor unit, 160MB onchip sram and 23.8B transistors but can take only limited advantage of it. We have super performant GPUs but programming them is vendor dependent and a pain. If someone can see a clear path through all this, and create a new software system, they will simply generate a new ecosystem and not worry about 50 years worth of work. From jon at fourwinds.com Sat Sep 18 03:51:38 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 17 Sep 2021 10:51:38 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> Message-ID: <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> Bakul Shah writes: > I have mixed feelings about this. Unix didn't "throw away" > the mainframe world of computing. It simply created a new > ecosystem, more suited for the microprocessor age. For IBM it > was perhaps the classic Innovator's Dilemma. Similarly now we > have (mostly) the Linux ecosystem, while the actual hardware > has diverged a lot from the C memory model. There are > security issues. There is firmware running on these system > about which the OS knows nothing. We have processors like > Esperanto Tech's 1088 64 bit Risc-V cores, each with its own > vector/tensor unit, 160MB onchip sram and 23.8B transistors > but can take only limited advantage of it. We have super > performant GPUs but programming them is vendor dependent and > a pain. If someone can see a clear path through all this, > and create a new software system, they will simply generate a > new ecosystem and not worry about 50 years worth of work. You're kind of reminding me of the HEP (heterogeneous element processor) talk that I saw at I think Usenix in Santa Monica. My opinion is that it was a "kitchen sink" project - let's throw in a few of these and a few of those and so on. Also analogous to what I saw in the housing market up here when people started cashing in their California huts for Oregon mansions - when we lived in California we could afford two columns out front but now we can afford 6 columns, 8 poticos, 6 dormers, 4 turrets, and so on. Just because you can built it doesn't keep it from being an ugly mess. So my question on many of these processors is, has anybody given any thought to system architecture? Most likely all of us have had to suffer with some piece of spiffy hardware that was pretty much unprogrammable. Do the performance numbers mean anything if they can't be achieved in an actual system configuration? Jon From lm at mcvoy.com Sat Sep 18 04:07:10 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Sep 2021 11:07:10 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> Message-ID: <20210917180710.GH18465@mcvoy.com> On Fri, Sep 17, 2021 at 10:51:38AM -0700, Jon Steinhart wrote: > So my question on many of these processors is, has anybody > given any thought to system architecture? Most likely all > of us have had to suffer with some piece of spiffy hardware > that was pretty much unprogrammable. Do the performance > numbers mean anything if they can't be achieved in an actual > system configuration? Apple, much to my surprise, has been thinking about this stuff. The M1 is one of the better thought out chips in a long time. I especially liked the idea of slow (and low battery draw) processors for some apps, and fast ones for apps that need fast. It's an obvious idea in retrospect but I hadn't thought to do it that way. Clever. From rminnich at gmail.com Sat Sep 18 04:24:42 2021 From: rminnich at gmail.com (ron minnich) Date: Fri, 17 Sep 2021 11:24:42 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <8A83BD02-E014-4282-A67D-FDD928AF35DE@iitbombay.org> Message-ID: As a student weekend operator at Dupont, I saw the last 2 weeks of the 705 vacuum tube machine that ran payroll and then, over two years: the 7080 that ran the 705 in emulation; the 360 that ran the 7080 that ran the 705; the 370 that ran the 360 that ran the 7800 that ran the 705. The 370 sacrificed ASCII support so it could emulate a 360 (IBM ran out of bits in the PSW, so ASCII had to go). The Blue Gene compute node kernel (CNK) started out supporting the "most commonly used" 80 or so linux system calls; that grew by about 1 system call a month. As CNK became asymptotic to Linux, some sites threw in the towel and ran linux. Frequently, emulation is not enough. Linux itself supported SCO for a time; freebsd has a good linux subsystem; one could argue that Linux emulates Linux, given its binary compatibility guarantee. Unix had a JCL command through v5 and still has a GECOS field in the password. The x86 allocates 1/256 of its gigantic opcode space to the DAA instruction nobody uses. A multi-hundred core server can still boot CP/M and DOS 1.0 RISC-V started as clean-ish break with the past, and has followed the standard evilutionary path to x86-inspired 4k page sizes; big-endian support; and runtime BIOS. Successful systems rarely come as a complete break with the past. People frequently expect that the Unix "clean break" experience can be repeated, but. if anything, the history of Unix shows why that experience is unlikely to be repeated. But if you're going to do a new kernel, and you want broad usage, you're going to provide a VM to run Linux or something like it, or you're going to fail. Or target something invisible, like a security token, then you are free to do what you will -- the Google Open Titan security token runs a kernel written in Rust. Nobody knows about it so nobody cares. ron p.s. I remember the person who finally ported payroll from the 705 binary. "There's a bug in there, maybe, but i can't find it" -- 2 weeks later, in a not-to-be-repeated occurence, the paycheck of all us weekend students was 2x normal. We couldn't figure out who to report it to so we let it slide. p.p.s. The 7080 was the last mainframe I worked with that smelled of machine oil. On Fri, Sep 17, 2021 at 8:57 AM Bakul Shah wrote: > > On Sep 16, 2021, at 12:34 PM, Jon Steinhart wrote: > > > > It's my opinion that the whole container thing sort of started as a "we > > can't secure the underlying system so we'll build something secure on top" > > combined with "it's no fun to fix the unnecessary incompatible mess among > > virtually identical systems that we've made so we'll build a new fix-it > > layer" ideologies. How long until problems are found with containers > > it's decided that the way to fix it is to build "safe deposit boxes" that > > run in container? Is there ever an end in sight? > > Recall that previously sysadmins used programs such as ghost to image a > system. A completely operational system with all the required software > could be created fairly quickly with minimum configuration. If your > h/w crashed, you can get up and running fairly quickly on a new machine > (provided your unique bits were backed up & restored). The same thing > could be done for server machines. By minimizing differences you can > apply security patches or put new machines in service quickly. A server > machine needs much more than the main service program before it can > be put in real service but machines providing the same service need > pretty much the same things. > > When VMs and containers started getting used, the same model could > be used for provisioning them. The docker folks simplified this > further. Now you can spin up new servers almost trivially (even if > later tooling via Kubernetes and such got quite complicated). Seems > to me, this provisioning of whole systems is what users of technologies > such as jail never quite got it. > > A couple of points on this: 1) I think this can be simplified even > further if one can rely on a fast control plane connection by basically > lazily pulling in the contents of each container. 2) If the underlying > system provides a capability architecture, you can probably achieve the > exact same functionality without containers as the required "many worlds" > functionality is already built in. > > -- Bakul From bakul at iitbombay.org Sat Sep 18 04:34:07 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 17 Sep 2021 11:34:07 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> Message-ID: <242A20E1-3A22-4C98-8D96-02C3662724D4@iitbombay.org> On Sep 17, 2021, at 10:51 AM, Jon Steinhart wrote: > > Bakul Shah writes: >> I have mixed feelings about this. Unix didn't "throw away" >> the mainframe world of computing. It simply created a new >> ecosystem, more suited for the microprocessor age. For IBM it >> was perhaps the classic Innovator's Dilemma. Similarly now we >> have (mostly) the Linux ecosystem, while the actual hardware >> has diverged a lot from the C memory model. There are >> security issues. There is firmware running on these system >> about which the OS knows nothing. We have processors like >> Esperanto Tech's 1088 64 bit Risc-V cores, each with its own >> vector/tensor unit, 160MB onchip sram and 23.8B transistors >> but can take only limited advantage of it. We have super >> performant GPUs but programming them is vendor dependent and >> a pain. If someone can see a clear path through all this, >> and create a new software system, they will simply generate a >> new ecosystem and not worry about 50 years worth of work. > > You're kind of reminding me of the HEP (heterogeneous element > processor) talk that I saw at I think Usenix in Santa Monica. > My opinion is that it was a "kitchen sink" project - let's > throw in a few of these and a few of those and so on. Also > analogous to what I saw in the housing market up here when > people started cashing in their California huts for Oregon > mansions - when we lived in California we could afford two > columns out front but now we can afford 6 columns, 8 poticos, > 6 dormers, 4 turrets, and so on. Just because you can built > it doesn't keep it from being an ugly mess. > > So my question on many of these processors is, has anybody > given any thought to system architecture? Most likely all > of us have had to suffer with some piece of spiffy hardware > that was pretty much unprogrammable. Do the performance > numbers mean anything if they can't be achieved in an actual > system configuration? If you look at the chip architecture, it is pretty regular. https://www.esperanto.ai/technology/ and very low power (0.01W/core as opposed to 7W/core on X86-64) https://www.servethehome.com/esperanto-et-soc-1-1092-risc-v-ai-accelerator-solution-at-hot-chips-33/ The equivalent of turrets and porticos and columns and dormers are IO ports like USB, ethernet, and various GPIOs etc. but they use only a small portion of the available gates. IMHO the real issue is that the software folks are *not* providing and *can no*t provide any sort of guidance for general purpose computing, as the memory underlying modern programming languages is so far removed from reality. The situation is sorta like what happens with people with newly acquired incredible wealth but no background in how to spend or manage it wisely (and I don't mean *investing* to get more wealth). At least in that case there are people who can help you and a tremendous need. Here we can put billions and billions of gates on a chip and even do wafer scale integration but these gates are not fungible like money. From phil at ultimate.com Sat Sep 18 04:28:44 2021 From: phil at ultimate.com (Phil Budne) Date: Fri, 17 Sep 2021 14:28:44 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> References: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> Message-ID: <202109171828.18HISiR5057486@ultimate.com> The earliest Unix running on the 11/20 requires not only the custom MMU, but also a fixed-head disk (the genesis of the tiny root partition?), so I agree with Noel that MINI-UNIX and LSX, while not "historically correct" for your hardware are a good fit, and that building a working system on simulated hardware would likely be the easiest route. Phil From jon at fourwinds.com Sat Sep 18 04:56:58 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 17 Sep 2021 11:56:58 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <242A20E1-3A22-4C98-8D96-02C3662724D4@iitbombay.org> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> <242A20E1-3A22-4C98-8D96-02C3662724D4@iitbombay.org> Message-ID: <202109171856.18HIuw5g3403957@darkstar.fourwinds.com> Bakul Shah writes: > > IMHO the real issue is that the software folks are *not* providing > and *can no*t provide any sort of guidance for general purpose > computing, as the memory underlying modern programming languages > is so far removed from reality. The situation is sorta like what > happens with people with newly acquired incredible wealth but no > background in how to spend or manage it wisely (and I don't mean > *investing* to get more wealth). At least in that case there are > people who can help you and a tremendous need. Here we can put > billions and billions of gates on a chip and even do wafer scale > integration but these gates are not fungible like money. Are you sure about this? Or is it just that the hardware folks got to work without ever asking software/systems people for input? Reminds me of a UNIX workstation project that I was working on at a startup in the mid-1980s. The graphics hardware guy came from DEC and had his designs well under way before I was hired. I looked at his specs and asked WTF? He had put a lot of work, for example, into blazingly fast frame-buffer clears. I asked him why and he told me that that was a very important thing to DECs customers. He was crestfallen when I told him that I would never use that hunk of hardware because we were building a windowing system and not a standalone graphics terminal. So yeah, he built useless hardware because he never asked for system design help. It's not just compute hardware. Was working on a project in the 1990s that you might be connected to if you're ever in the emergency room. After I hired on, I looked over the schematics for the device and kept asking "What's this for?" Answer was consistently "Thought that it would be useful for you software folks." My response was "Hey, we're trying to build a low-cost device here. We don't need it, take it out." The common thread here, which I don't know if it applies to your example, is that hardware has traditionally had a longer lead time than software so commonly a hardware team is assembled and busy designing long before any software/systems types are brought on board. Sometimes it makes sense. I'll never forget a day that I expected to be walked to the door at a company but to my surprise management backed me up. A big failing of the company was that the lead chip designer was also a founder and on the board so was hard to hold to account. This person could always find a better way to do something that had already been done, so perpetual chip redesigns meant that the chip never happened. I was in a weekly status meeting where the hardware team presented its status and schedule. When it was question time, I asked something like "So, if I look at your schedule this has 2 weeks to go and this has 5 and so on, meaning that there's 20 weeks of work left. Does that mean that we're not gonna tape out next week like it says on the schedule?" I got reamed up and down for not showing respect for the ever so hard working hardware team. I think that what saved my butt was pointing out that I was not criticizing the hardware team, but that we had a big hiring plan for the software team once the hardware was on its way, and only so much money in the bank, and maybe we shouldn't be spending that money quite yet. Jon From bakul at iitbombay.org Sat Sep 18 05:16:56 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 17 Sep 2021 12:16:56 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <202109171856.18HIuw5g3403957@darkstar.fourwinds.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> <242A20E1-3A22-4C98-8D96-02C3662724D4@iitbombay.org> <202109171856.18HIuw5g3403957@darkstar.fourwinds.com> Message-ID: <86F5F16F-EB3F-4AB8-9821-94CAE94465DB@iitbombay.org> On Sep 17, 2021, at 11:56 AM, Jon Steinhart wrote: > > Bakul Shah writes: >> >> IMHO the real issue is that the software folks are *not* providing >> and *can no*t provide any sort of guidance for general purpose >> computing, as the memory underlying modern programming languages >> is so far removed from reality. The situation is sorta like what >> happens with people with newly acquired incredible wealth but no >> background in how to spend or manage it wisely (and I don't mean >> *investing* to get more wealth). At least in that case there are >> people who can help you and a tremendous need. Here we can put >> billions and billions of gates on a chip and even do wafer scale >> integration but these gates are not fungible like money. > > Are you sure about this? Or is it just that the hardware folks got to > work without ever asking software/systems people for input? Let me ask you. You have a budget of 24 Billion transistors (& a much more limited power budget). How would you spend it to maximize general purpose computing? Note that Esperanto Tech. was founded by Dave Ditzel, not exactly a h/w newbie. [EE/CS, worked with Dave Patterson, CTO @ Sun, Transmeta founder etc. etc.]. Now it is entirely possible that Esperanto folks are building such processors for special purpose applications like Machine learning but the fact is we simply have an incredible riches of transistors that we don't how to spend wisely, [My opinion, of course] From jon at fourwinds.com Sat Sep 18 05:35:00 2021 From: jon at fourwinds.com (Jon Steinhart) Date: Fri, 17 Sep 2021 12:35:00 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <86F5F16F-EB3F-4AB8-9821-94CAE94465DB@iitbombay.org> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> <242A20E1-3A22-4C98-8D96-02C3662724D4@iitbombay.org> <202109171856.18HIuw5g3403957@darkstar.fourwinds.com> <86F5F16F-EB3F-4AB8-9821-94CAE94465DB@iitbombay.org> Message-ID: <202109171935.18HJZ0Xg3405315@darkstar.fourwinds.com> Bakul Shah writes: > On Sep 17, 2021, at 11:56 AM, Jon Steinhart wrote: > > > > Bakul Shah writes: > >> > >> IMHO the real issue is that the software folks are *not* providing > >> and *can no*t provide any sort of guidance for general purpose > >> computing, as the memory underlying modern programming languages > >> is so far removed from reality. The situation is sorta like what > >> happens with people with newly acquired incredible wealth but no > >> background in how to spend or manage it wisely (and I don't mean > >> *investing* to get more wealth). At least in that case there are > >> people who can help you and a tremendous need. Here we can put > >> billions and billions of gates on a chip and even do wafer scale > >> integration but these gates are not fungible like money. > > > > Are you sure about this? Or is it just that the hardware folks got to > > work without ever asking software/systems people for input? > > Let me ask you. > > You have a budget of 24 Billion transistors (& a much more limited > power budget). How would you spend it to maximize general purpose > computing? > > Note that Esperanto Tech. was founded by Dave Ditzel, not exactly a > h/w newbie. [EE/CS, worked with Dave Patterson, CTO @ Sun, Transmeta > founder etc. etc.]. Now it is entirely possible that Esperanto folks > are building such processors for special purpose applications like > Machine learning but the fact is we simply have an incredible riches > of transistors that we don't how to spend wisely, [My opinion, of course] Tough question to answer. I would say that maybe we're getting to the point where a dream of mine could happen, which is eliminating the traditional multi-tasking operating system and just having one processor per process. One could even call it "hardware containers". Gak! Big unsolved problem the incompatibility between the processes for this sort of stuff and DRAM processes. Had hoped that some of the 3D stuff that I saw Dave D. talk about a few years ago would have panned out by now. So just because I've never heard anybody else say this, and because we have named laws like Cole's law, I have Steinhart's law. It states that a bad investment to give money to people who have had successful startup companies. My opinion is that people are lucky to get it right once, and very few get it right more than once, so I wouldn't bet on a company founded by people who have already done successful companies. A corollary is that to find a successful startup, look for someone who has been perfecting an idea over a handful of failed startup companies. In many respects, Apple fits that model; they let other people invent stuff and then they "do it right". The more interesting question that you raise is, why would you expect better stuff because we can now do tens of billions of transistors? >From the software side, we have a mind-boggling about of memory, at least for those of us who began with 4K or less, and I can't see that it's used wisely. I've had people tell me that I was wasting my time being efficient because memory was cheaper than my time. Which I guess was true until you multiplied it by the number of systems. As an EE/CS guy, I don't really expect the HW people to be any different than the SW people now that designing HW is just writing SW. Jon From clemc at ccc.com Sat Sep 18 05:43:38 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Sep 2021 15:43:38 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: <202109171828.18HISiR5057486@ultimate.com> References: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> <202109171828.18HISiR5057486@ultimate.com> Message-ID: On Fri, Sep 17, 2021 at 2:51 PM Phil Budne wrote: > The earliest Unix running on the 11/20 requires not only the custom MMU, > but also a fixed-head disk Right, a 4Mbyte RF11/RS11 which Ken refers to as /dev/drum in this code. That lived for a pretty long time - at least thru the Sixth edition, IIRC. > (the genesis of the tiny root partition?), I thought the original system just swapped to it, no mounted FS on it, but unless someone knows for sure, it means staring at Ken's assembler listings for V1 that Warner mentioned earlier. > so I agree with Noel that MINI-UNIX and LSX, while not "historically > correct" for your hardware are a good fit, and that > building a working system on simulated hardware would likely be the easiest > route. > > Phil > ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantley at coraid.com Sat Sep 18 05:51:49 2021 From: brantley at coraid.com (Brantley Coile) Date: Fri, 17 Sep 2021 19:51:49 +0000 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> <202109171828.18HISiR5057486@ultimate.com> Message-ID: swplo was past the root file system. > On Sep 17, 2021, at 3:43 PM, Clem Cole wrote: > > (the genesis of the tiny root partition?), > I thought the original system just swapped to it, no mounted FS on it, but unless someone knows for sure, it means staring at Ken's assembler listings for V1 that Warner mentioned earlier. > From clemc at ccc.com Sat Sep 18 06:07:08 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Sep 2021 16:07:08 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> <202109171828.18HISiR5057486@ultimate.com> Message-ID: On Fri, Sep 17, 2021 at 3:51 PM Brantley Coile wrote: > swplo was past the root file system. > That is v5 and v6 for sure, but I'm not so sure about that the earlier systems. I did a quick peek earlier today and in the v1 code, it seems to be hardcoded but I can say I sat and read it in detail. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Sat Sep 18 06:18:47 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 17 Sep 2021 16:18:47 -0400 (EDT) Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option Message-ID: <20210917201847.AB60018C0A6@mercury.lcs.mit.edu> > From: Clem Cole > The KS11 MMU for the 11/20 was built by CSS ... I think Noel has done > more investigation than I have. I got a very rough description of how it worked, but that was about it. > I'm not sure if the KS11 code is still there. I did not think so. No, the KS11 was long gone by later Vn. Also,I think not all of the -11/20 UNIX machines had it, just some. > The V1 work was for a PDP-7 Actually, there is a PDP-11 version prior to V2, canonically called V1. The PDP-7 version seems to be called 'PDP-7 UNIX' or 'V0'. > I'm fairly sure that the RK05, used the RK11-D controller. Normally, yes. I have the impression that one could finagle RK03's to work on the RK11-D, and vice versa for RK05's on the RK11-C, but I don't recall the details. The main difference between the RK11-C and -D (other then the implementation) was that i) the RK11-C used one line per drive for drive selection (the -D used binary encoding on 3 lines), and ii) it had the 'maintenance' capability and register (al omitted from the -D). > The difference seems to have been in drive performance. Yes, but it wasn't major. They both did 1500RPM, so since they used the same pack format, the rotational delay, transfer rate, etc were identical. The one peformance difference was in seeks; the average on the RK01 was quoted as 70 msec, and 50 msec on the RK05. > Love to see the {KT11-B prints] and if you know where you found them. They were sold on eBait along with an -11/20 that allegedly had a KT11-B. (It didn't; it was an RK11-C.) I managed to get them scanned, and they and the minimal manual are now in Bitsavers. I started working on a Tech Manual for it, but gave up with it about half-way done. > I wonder if [our V1 source] had the KS-11 stuff in it. No; I had that idea a while back, looked carefully, our V1 listings pre-date the KS11. > From: Roland Huisman > There is a KT11B paging option that makes the PDP11/20 a 18 bit > machine. Well, it allows 2^18 bytes of main memory, but the address space of the CPU is still2^16 bytes. > It looks a bit like the TC11 DECtape controller. IITC, it's two backplanes high, the TC11 is one. So more like the RK11-C... :-) > I have no idea how it compares to the later MMU units from the > software perspective. Totally different; it's real paging (with page tables stored in masin memory). The KT11-B provides up to 128 pages of 512 bytes each, in both Exec and User mode. The KT11-C, -D etc are all segmentation, with all the info stored in registers in the unit. > I wonder is there is some compatibility with the KT11-B [from the KS11] I got the impression that the KS11 was more a 'base and bounds' kind of thing. Noel From torek at elf.torek.net Sat Sep 18 06:40:25 2021 From: torek at elf.torek.net (Chris Torek) Date: Fri, 17 Sep 2021 13:40:25 -0700 (PDT) Subject: [TUHS] RegExp decision for meta characters: Circumflex In-Reply-To: Message-ID: <202109172040.18HKePMD009565@elf.torek.net> Also worth noting, though the precise history predates my own experience: it's common in grammar theory to use `$` as the end symbol. Was this from REs using `$` as an end symbol as well, or did REs adopt `$` from here, or ...? Chris From clemc at ccc.com Sat Sep 18 06:47:40 2021 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Sep 2021 16:47:40 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: <20210917201847.AB60018C0A6@mercury.lcs.mit.edu> References: <20210917201847.AB60018C0A6@mercury.lcs.mit.edu> Message-ID: On Fri, Sep 17, 2021 at 4:19 PM Noel Chiappa wrote: > I got the impression that the KS11 was more a 'base and bounds' kind of > thing. > Ditto. I was under the impression it was modeled after the KA10 scheme. I don't remember who told me that, probably somebody from CSS, but I have no idea whom. As I think you remember when you asked about it a while ago, I sent some probes to a few of folks from the 11 group but all of them disavowed any knowledge of it. One of the questions I always had was since M[TF]P[IDS] instructions were not created until the 40 and 45 class processors, how did Ken get the information to/fr the other address space. I >>think<< the KT has a funky memory window (that I never really looked into in any detail), I assume the KS must have done something similar. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Sat Sep 18 07:03:42 2021 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Fri, 17 Sep 2021 22:03:42 +0100 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210917180710.GH18465@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> <20210917180710.GH18465@mcvoy.com> Message-ID: On Fri, Sep 17, 2021 at 11:07:10AM -0700, Larry McVoy wrote: > > Apple, much to my surprise, has been thinking about this stuff. > The M1 is one of the better thought out chips in a long time. > I especially liked the idea of slow (and low battery draw) > processors for some apps, and fast ones for apps that need > fast. It's an obvious idea in retrospect but I hadn't thought > to do it that way. Clever. I'd suggest that is not Apple, but ARM. That was sort of the whole point of their BIG.little architecture with performance and efficiency cores. DF From phil at ultimate.com Sat Sep 18 07:21:47 2021 From: phil at ultimate.com (Phil Budne) Date: Fri, 17 Sep 2021 17:21:47 -0400 Subject: [TUHS] Unix for PDP11/20 w/o mmu or paging option In-Reply-To: References: <20210917153523.96CC618C0A6@mercury.lcs.mit.edu> <202109171828.18HISiR5057486@ultimate.com> Message-ID: <202109172121.18HLLlB8061859@ultimate.com> I was commenting based on the Boot Procedures man page on pg 5 of the pdf at: https://www.bell-labs.com/usr/dmr/www/pdfs/man71.pdf on dmr's "Unix Manual, first edition" page: https://www.bell-labs.com/usr/dmr/www/1stEdman.html which makes no reference to the rk disk, but does talk about loading up initial files. The page for init (pdf p.11) mentions that the usr directory is mounted from the rk disk. The rf0 page (pdf p3) at https://www.bell-labs.com/usr/dmr/www/pdfs/man41.pdf says "writing is inherently very dangerous since a file system resides there" The description of seek on the special files really slapped me in the face for the first time! The tty page in the man41 file ever so slightly advances my theory that the interrupt character on the PDP-7 console (0176 or rather 0376) could have been generated by the "ALT MODE" key on the console Teletype. But regarding memory management, I foolishly put my foot in the gopher hole of assumption that the earliest kernel on hand required the mystery MMU, without verifying by reading the code, and forgetting that "editions" refer to dates the manual was published, and that the fragmentary fossil record that is the earliest surviving code (which was in a constant state of evolution) doesn't align with the manuals. Mea culpa, for adding any confusion! From lm at mcvoy.com Sat Sep 18 08:11:49 2021 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Sep 2021 15:11:49 -0700 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> <20210917180710.GH18465@mcvoy.com> Message-ID: <20210917221149.GC3365@mcvoy.com> On Fri, Sep 17, 2021 at 10:03:42PM +0100, Derek Fawcus wrote: > On Fri, Sep 17, 2021 at 11:07:10AM -0700, Larry McVoy wrote: > > > > Apple, much to my surprise, has been thinking about this stuff. > > The M1 is one of the better thought out chips in a long time. > > > I especially liked the idea of slow (and low battery draw) > > processors for some apps, and fast ones for apps that need > > fast. It's an obvious idea in retrospect but I hadn't thought > > to do it that way. Clever. > > I'd suggest that is not Apple, but ARM. That was sort of the whole > point of their BIG.little architecture with performance and efficiency > cores. Credit to ARM, but M1 was where I saw it first. The M1 performance is pretty impressive as well. Reminds me of LED bulbs: "Wait, these are brighter, use less power, and cost less? How is that a thing?" From grog at lemis.com Sat Sep 18 11:03:52 2021 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sat, 18 Sep 2021 11:03:52 +1000 Subject: [TUHS] RegExp decision for meta characters: Circumflex In-Reply-To: <202109172040.18HKePMD009565@elf.torek.net> References: <202109172040.18HKePMD009565@elf.torek.net> Message-ID: <20210918010352.GR59580@eureka.lemis.com> On Friday, 17 September 2021 at 13:40:25 -0700, Chris Torek wrote: > Also worth noting, though the precise history predates my own > experience: it's common in grammar theory to use `$` as the end > symbol. Was this from REs using `$` as an end symbol as well, > or did REs adopt `$` from here, or ...? Weren't there programming languages that used $ as a statement terminator instead of ;? Greg -- Sent from my desktop computer. Finger grog at lemis.com for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA.php -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From bakul at iitbombay.org Sat Sep 18 11:23:59 2021 From: bakul at iitbombay.org (Bakul Shah) Date: Fri, 17 Sep 2021 18:23:59 -0700 Subject: [TUHS] RegExp decision for meta characters: Circumflex In-Reply-To: <20210918010352.GR59580@eureka.lemis.com> References: <202109172040.18HKePMD009565@elf.torek.net> <20210918010352.GR59580@eureka.lemis.com> Message-ID: <1038880F-A0D6-4A51-A0F1-8434ED49C71A@iitbombay.org> On Sep 17, 2021, at 6:03 PM, Greg 'groggy' Lehey wrote: > > On Friday, 17 September 2021 at 13:40:25 -0700, Chris Torek wrote: >> Also worth noting, though the precise history predates my own >> experience: it's common in grammar theory to use `$` as the end >> symbol. Was this from REs using `$` as an end symbol as well, >> or did REs adopt `$` from here, or ...? > > Weren't there programming languages that used $ as a statement > terminator instead of ;? IIRC Macsyma used ; as well as $ as statement terminators. ; if you wanted to print the output of an expresion, $ if you wanted to suppress the output. But I suspect it is not related to this. From tytso at mit.edu Sun Sep 19 14:05:25 2021 From: tytso at mit.edu (Theodore Ts'o) Date: Sun, 19 Sep 2021 00:05:25 -0400 Subject: [TUHS] ATC/OSDI'21 joint keynote: It's Time for Operating Systems to Rediscover Hardware (Timothy Roscoe) In-Reply-To: <20210917221149.GC3365@mcvoy.com> References: <202109161934.18GJYFsl881498@darkstar.fourwinds.com> <20210916194103.GK26820@mcvoy.com> <58BCBB10-A303-41C0-8620-992B107786BB@pobox.com> <202109171751.18HHpcAf3401326@darkstar.fourwinds.com> <20210917180710.GH18465@mcvoy.com> <20210917221149.GC3365@mcvoy.com> Message-ID: On Fri, Sep 17, 2021 at 03:11:49PM -0700, Larry McVoy wrote: > > I'd suggest that is not Apple, but ARM. That was sort of the whole > > point of their BIG.little architecture with performance and efficiency > > cores. > > Credit to ARM, but M1 was where I saw it first. The M1 performance is > pretty impressive as well. Reminds me of LED bulbs: "Wait, these are > brighter, use less power, and cost less? How is that a thing?" ARM's BIG.little architecture dates back to 2011. Of course, they didn't *tell* anyone that they were doing this when before the chip was released, lest it get copied by their competitors. So they released a hacked-up version of the Linux kernel that supported their chip. And successive versions of BIG.little implemented by different ARM vendors had their own vendor-specific tweaks, with "board support kernels" that were heavily hacked up Linux kernels in code that was never sent upstream, since by the time vendors had released that chip, their kernel team was moved to working on a new project, where they would fork the current kernel version, and add completely different hacks for the next year's version of their System on a Chip (SOC). Proper support for differntly sized/powered cores didn't land in theb ppstream Linux until 2019, when Linux 5.0 finally acquired support for "Energy Aware Scheduling". So not only does hardware engineering take longer, but it's done in Sekrit, by software teams employed by chip manufacturers who often don't have any long-time attachment to the OS, and who will get reassigned to work the next year's SOC as soon as the current year's SOC is released. :-( Things have gotten a bit better in the last five years, but that's a pretty low bar, considering how horrible things were before that! - Ted From arnold at skeeve.com Mon Sep 20 01:46:34 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 19 Sep 2021 09:46:34 -0600 Subject: [TUHS] Thompson trojan put into practice Message-ID: <202109191546.18JFkY8h012460@freefriends.org> This is FYI. No comment on whether it was a good idea or not. :-) Arnold > From: Niklas Rosencrantz > Date: Sun, 19 Sep 2021 17:10:24 +0200 > To: tinycc-devel at nongnu.org > Subject: Re: [Tinycc-devel] Can tcc compile itself with Apple M1? > > > Hello! > > For demonstration purpose I put my experiment with a compiler backdoor in a > public repository > https://github.com/montao/ddc-tinyc/blob/857d927363e9c9aaa713bb20adbe99ded76ac615/tcc-evil/tinycc/libtcc.c#L989 > > It's part of my academic project to work on provable compiler security. > I tried to do it according to the "Reflections on Trusting Trust" by Ken > Thompson, not only to show a compiler Trojan horse but also to prove that > we can discover it. > What it does is inject arbitrary code to the next version of the compiler > and so on. > > Regards \n From aek at bitsavers.org Mon Sep 20 01:58:54 2021 From: aek at bitsavers.org (Al Kossow) Date: Sun, 19 Sep 2021 08:58:54 -0700 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: <202109191546.18JFkY8h012460@freefriends.org> References: <202109191546.18JFkY8h012460@freefriends.org> Message-ID: >> For demonstration purpose I put my experiment with a compiler backdoor in a >> public repository >> It's part of my academic project to work on provable compiler security. Sounds like excellent grounds for expulsion. Whatever happened to the people who were submitting poison pull requests at U-Minnesota? From john at jfloren.net Mon Sep 20 02:10:06 2021 From: john at jfloren.net (John Floren) Date: Sun, 19 Sep 2021 16:10:06 +0000 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: References: <202109191546.18JFkY8h012460@freefriends.org> Message-ID: -------- Original Message -------- On Sep 19, 2021, 8:58 AM, Al Kossow < aek at bitsavers.org> wrote: >> For demonstration purpose I put my experiment with a compiler backdoor in a >> public repository >> It's part of my academic project to work on provable compiler security. Sounds like excellent grounds for expulsion. Whatever happened to the people who were submitting poison pull requests at U-Minnesota? It's in his own fork, in a directory called tcc-evil. He's not exactly sneaking it into the distribution. Calling it expulsion-worthy reminds me of the time a guy phoned the FBI because of an article he read in the NYT: Sandia Labs was running botnets in a virtualized environment! (Could the cluster route to the Internet? No, but he didn't know that, and he didn't care; only bad people have botnets) john -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 20 02:02:55 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sun, 19 Sep 2021 10:02:55 -0600 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: References: <202109191546.18JFkY8h012460@freefriends.org> Message-ID: <202109191602.18JG2t5l014358@freefriends.org> Al Kossow wrote: > >> For demonstration purpose I put my experiment with a compiler backdoor in a > >> public repository > > >> It's part of my academic project to work on provable compiler security. > > Sounds like excellent grounds for expulsion. > > Whatever happened to the people who were submitting poison pull requests at U-Minnesota? > Supposedly he's able to show that the compiler has been hacked. From douglas.mcilroy at dartmouth.edu Mon Sep 20 12:39:25 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Sun, 19 Sep 2021 22:39:25 -0400 Subject: [TUHS] Thompson trojan put into practice Message-ID: > It's part of my academic project to work on provable compiler security. > I tried to do it according to the "Reflections on Trusting Trust" by Ken > Thompson, not only to show a compiler Trojan horse but also to prove that > we can discover it. Of course it can be discovered if you look for it. What was impressive about the folks who got Thompson's compiler at PWB is that they found the horse even though they weren't looking for it. Then there was the first time Jim Reeds and I turned on integrity control in IX, our multilevel-security version of Research Unix. When it reported a security violation during startup we were sure it was a bug. But no, it had snagged Tom Duff's virus in the act of replication. It surprised Tom as much as it did us, because he thought he'd eradicated it. Doug From lm at mcvoy.com Mon Sep 20 12:50:35 2021 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 19 Sep 2021 19:50:35 -0700 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: References: Message-ID: <20210920025035.GI7551@mcvoy.com> On Sun, Sep 19, 2021 at 10:39:25PM -0400, Douglas McIlroy wrote: > > It's part of my academic project to work on provable compiler security. > > I tried to do it according to the "Reflections on Trusting Trust" by Ken > > Thompson, not only to show a compiler Trojan horse but also to prove that > > we can discover it. > > Of course it can be discovered if you look for it. What was impressive about > the folks who got Thompson's compiler at PWB is that they found the horse > even though they weren't looking for it. > > Then there was the first time Jim Reeds and I turned on integrity control in > IX, our multilevel-security version of Research Unix. When it reported > a security > violation during startup we were sure it was a bug. But no, it had snagged Tom > Duff's virus in the act of replication. It surprised Tom as much as it did us, > because he thought he'd eradicated it. > > Doug This is the first I've heard of Tom Duff's virus, what was that? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jnc at mercury.lcs.mit.edu Mon Sep 20 13:04:11 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 19 Sep 2021 23:04:11 -0400 (EDT) Subject: [TUHS] Thompson trojan put into practice Message-ID: <20210920030411.3325418C08A@mercury.lcs.mit.edu> https://googlethatforyou.com/?q=Tom%20Duff%20Virus Noel From davida at pobox.com Mon Sep 20 13:21:05 2021 From: davida at pobox.com (David Arnold) Date: Mon, 20 Sep 2021 13:21:05 +1000 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: <20210920030411.3325418C08A@mercury.lcs.mit.edu> References: <20210920030411.3325418C08A@mercury.lcs.mit.edu> Message-ID: <08446368-BA93-4EE0-B7B7-294FC31D1CA2@pobox.com> I think that’s the first time I’ve seen Gerrold’s When H.A.R.L.I.E was One cited alongside Shockwave Rider as anticipating computer viruses. Since we’re saving each other searching today, here’s a link to the author’s page for anyone else who, like me, hasn’t read it and wants to. https://www.gerrold.com/book/when-harlie-was-one/ d > On 20 Sep 2021, at 13:05, jnc at mercury.lcs.mit.edu wrote: > > https://googlethatforyou.com/?q=Tom%20Duff%20Virus > > Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Mon Sep 20 14:35:36 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Mon, 20 Sep 2021 00:35:36 -0400 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: <08446368-BA93-4EE0-B7B7-294FC31D1CA2@pobox.com> References: <08446368-BA93-4EE0-B7B7-294FC31D1CA2@pobox.com> Message-ID: <45A5502B-2158-4936-A435-6E3F3D7192C9@gmail.com> FYI that’s the 2nd modified version. The first version ends much differently. See tha author note as to the background. Earl Sent from my iPhone > On Sep 19, 2021, at 11:30 PM, David Arnold wrote: > > I think that’s the first time I’ve seen Gerrold’s When H.A.R.L.I.E was One cited alongside Shockwave Rider as anticipating computer viruses. > > Since we’re saving each other searching today, here’s a link to the author’s page for anyone else who, like me, hasn’t read it and wants to. > > https://www.gerrold.com/book/when-harlie-was-one/ > > > > > d > >>> On 20 Sep 2021, at 13:05, jnc at mercury.lcs.mit.edu wrote: >>> >> https://googlethatforyou.com/?q=Tom%20Duff%20Virus >> >> Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From earl.baugh at gmail.com Mon Sep 20 14:36:16 2021 From: earl.baugh at gmail.com (Earl Baugh) Date: Mon, 20 Sep 2021 00:36:16 -0400 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: <08446368-BA93-4EE0-B7B7-294FC31D1CA2@pobox.com> References: <08446368-BA93-4EE0-B7B7-294FC31D1CA2@pobox.com> Message-ID: <726635EB-D60F-4749-81AA-8CDC8E17BD54@gmail.com> Btw he also wrote the famous Star Trek episode - The Trouble with Tribbles. Earl Sent from my iPhone > On Sep 19, 2021, at 11:30 PM, David Arnold wrote: > > I think that’s the first time I’ve seen Gerrold’s When H.A.R.L.I.E was One cited alongside Shockwave Rider as anticipating computer viruses. > > Since we’re saving each other searching today, here’s a link to the author’s page for anyone else who, like me, hasn’t read it and wants to. > > https://www.gerrold.com/book/when-harlie-was-one/ > > > > > d > >>> On 20 Sep 2021, at 13:05, jnc at mercury.lcs.mit.edu wrote: >>> >> https://googlethatforyou.com/?q=Tom%20Duff%20Virus >> >> Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Sep 20 17:12:27 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Sep 2021 01:12:27 -0600 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: References: Message-ID: <202109200712.18K7CRBo000544@freefriends.org> Douglas McIlroy wrote: > > It's part of my academic project to work on provable compiler security. > > I tried to do it according to the "Reflections on Trusting Trust" by Ken > > Thompson, not only to show a compiler Trojan horse but also to prove that > > we can discover it. > > Of course it can be discovered if you look for it. What was impressive about > the folks who got Thompson's compiler at PWB is that they found the horse > even though they weren't looking for it. I had not heard this story. Can you elaborate, please? My impression from having read the paper (a long time ago now) is that Ken did the experiment locally only. Thanks, Arnold From douglas.mcilroy at dartmouth.edu Mon Sep 20 21:57:02 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Mon, 20 Sep 2021 07:57:02 -0400 Subject: [TUHS] Thompson trojan put into practice Message-ID: >> > It's part of my academic project to work on provable compiler security. >> > I tried to do it according to the "Reflections on Trusting Trust" by Ken >> > Thompson, not only to show a compiler Trojan horse but also to prove that >> > we can discover it. >> >> Of course it can be discovered if you look for it. What was impressive about >> the folks who got Thompson's compiler at PWB is that they found the horse >> even though they weren't looking for it. > I had not heard this story. Can you elaborate, please? My impression from having > read the paper (a long time ago now) is that Ken did the experiment locally only. Ken did it locally, but a vigilant person at PWB noticed there was an experimental compiler on the research machine and grabbed it. While they weren't looking for hidden stuff, they probably were trying to find what was new in the compiler. Ken may know details about what they had in the way of source and binary. Doug From kenbob at gmail.com Mon Sep 20 23:51:40 2021 From: kenbob at gmail.com (Ken Thompson) Date: Mon, 20 Sep 2021 06:51:40 -0700 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: References: Message-ID: pwb recompiled the compiler and it got 1 byte larger. again, another byte. after that they played with it until they broke the quine part. i am not sure that if they ever realized what was going on. the extra byte was my bug. On Mon, Sep 20, 2021 at 4:58 AM Douglas McIlroy < douglas.mcilroy at dartmouth.edu> wrote: > >> > It's part of my academic project to work on provable compiler > security. > >> > I tried to do it according to the "Reflections on Trusting Trust" by > Ken > >> > Thompson, not only to show a compiler Trojan horse but also to prove > that > >> > we can discover it. > >> > >> Of course it can be discovered if you look for it. What was impressive > about > >> the folks who got Thompson's compiler at PWB is that they found the > horse > >> even though they weren't looking for it. > > > I had not heard this story. Can you elaborate, please? My impression > from having > > read the paper (a long time ago now) is that Ken did the experiment > locally only. > > Ken did it locally, but a vigilant person at PWB noticed there was an > experimental > compiler on the research machine and grabbed it. While they weren't > looking for > hidden stuff, they probably were trying to find what was new in the > compiler. Ken > may know details about what they had in the way of source and binary. > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpl.jpl at gmail.com Tue Sep 21 00:35:50 2021 From: jpl.jpl at gmail.com (John P. Linderman) Date: Mon, 20 Sep 2021 10:35:50 -0400 Subject: [TUHS] Thompson trojan put into practice In-Reply-To: References: Message-ID: My recollection is that Larry Wehr ran nm on the compiler, possibly in response to the extra-byte quirk, and found a subroutine reference with no appearance in the source. If Ken hadn't kept the code so modular, they might never have noticed. On Mon, Sep 20, 2021 at 9:53 AM Ken Thompson wrote: > > pwb recompiled the compiler and it got 1 byte larger. > again, another byte. after that they played with it > until they broke the quine part. i am not sure that > if they ever realized what was going on. > > the extra byte was my bug. > > > On Mon, Sep 20, 2021 at 4:58 AM Douglas McIlroy < > douglas.mcilroy at dartmouth.edu> wrote: > >> >> > It's part of my academic project to work on provable compiler >> security. >> >> > I tried to do it according to the "Reflections on Trusting Trust" by >> Ken >> >> > Thompson, not only to show a compiler Trojan horse but also to prove >> that >> >> > we can discover it. >> >> >> >> Of course it can be discovered if you look for it. What was impressive >> about >> >> the folks who got Thompson's compiler at PWB is that they found the >> horse >> >> even though they weren't looking for it. >> >> > I had not heard this story. Can you elaborate, please? My impression >> from having >> > read the paper (a long time ago now) is that Ken did the experiment >> locally only. >> >> Ken did it locally, but a vigilant person at PWB noticed there was an >> experimental >> compiler on the research machine and grabbed it. While they weren't >> looking for >> hidden stuff, they probably were trying to find what was new in the >> compiler. Ken >> may know details about what they had in the way of source and binary. >> >> Doug >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Sep 21 00:48:25 2021 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 20 Sep 2021 14:48:25 +0000 Subject: [TUHS] On UNIX Trojans In-Reply-To: References: Message-ID: I have to say my experience in UNIX systems programming was due to the discovery of a trojan. It also shaped my research into security on UNIX and other systems over the coming decades. At the time, the UNIX system at Johns Hopkins University (there was only one) in the EE department was run by an undergraduate activity called the "University Computing Society." This bunch, headed by Mike Muuss and another covered all aspects of running the computer: programming, operations, hardware, and documentation support. I was just a loose hangar on at the time, writing my first C programs and the like. A couple of student operators managed to get access to what would be the installed copy of /lib/crt0.o (the small snippet inserted at the beginning of all C programs). They inserted a couple of bytes that did an exec of a file "^V" (current directory) and then waited. Most of the time, this is a harmless change as there is no ^V file in the current directory. Then, one day they hit the jackpot and a setuid root program got rebuilt and now they had a way of getting a root shell easily. This went largely undetected as they used it for quasi-productive uses for a while. One day one of the other programmers was rebuilding a program and noticed the few byte increase in size (back then we were running the system on a grand total of 8.5MB so every byte was precious). Subsequent analysis of what changed revealed the trojan. This led to an upheaval in the department and the end of the UCS. They did decide to keep the cheap student labor however, and since I had kept my nose clean and had some extensive, albeit, non-UNIX programming experience, I was brought on board. I spent the next three and a half years looking for and plugging security holes. I went on (after a brief stint at Martin Marietta) to work for Mike at Aberdeen Proving Ground and continued doing random security work including being put on the Army's initial tiger team effort. Also, there used to be a discussion in the security groups about what a "hacker with a Cray" could do for things about brute forcing decryption. I was given use of the new X/MP the Army bought to see if that was a feasibility. I later got to purchase a $25 million Cray 2, but left BRL for Rutgers before that was delivered. From woods at robohack.ca Wed Sep 29 03:46:25 2021 From: woods at robohack.ca (Greg A. Woods) Date: Tue, 28 Sep 2021 10:46:25 -0700 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> Message-ID: [[ I'm digging through old mail -- my summer has been preoccupied by things that kept me from most everything else, including computing. ]] At Sun, 1 Aug 2021 18:13:18 -0600, Andrew Warkentin wrote: Subject: Re: [TUHS] Systematic approach to command-line interfaces > > There's a third kind of primitive that is superior to either spawn() > or fork() IMO, specifically one that creates a completely empty child > process and returns a context that lets the parent set up the child's > state using normal APIs. That's actually what fork(2) is, effectively -- it sets up a new process that then effectively has control over its own destiny, but only by using code supplied by the parent process, and thus it is also working within the limits of the Unix security model. The fact that fork() happens to also do some of the general setup useful in a unix-like system is really just a merely a convenience -- you almost always want all those things to be done anyway. I agree there is some messiness introduced in more modern environments, especially w.r.t. threads, but there is now general consensus on how to handle such things. I'll also note here instead of in a separate message that Ted's followup questions about the API design and security issues with having the parent process have to do all the setup from its own context are exactly the problems that fork() solves -- the elegance of fork() is incredible! You just have to look at it the right way around, and with the Unix security model firmly in mind. I personally find spawn() to be the spawn of the devil, worse by a million times than any alternative, including the Multics process model (which could have made very good use of threads to increase concurrency in handling data pipelines, for example -- it was even proposed at the time). Spawn() is narrow-minded, inelegant, and an antique by design. I struggled for a very long time as an undergrad to understand the Multics process model, but now that I know more about hypervisors (i.e. the likes of Xen) it makes perfect sense to me. I now struggle with liking the the Unix concept of "everything is a file" -- especially with respect to actual data files. Multics also got it right to use single-level storage -- that's the right abstraction for almost everything, i.e. except some forms of communications (for which Multics I/O was a very clever and elegant design). The "unix" nod to single level storage by way of mmap() suffers from horribly bad design and neglect. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From lm at mcvoy.com Wed Sep 29 04:10:16 2021 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 28 Sep 2021 11:10:16 -0700 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> Message-ID: <20210928181016.GN18305@mcvoy.com> On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote: > The "unix" nod to > single level storage by way of mmap() suffers from horribly bad design > and neglect. I supported Xerox PARC when they were redoing their OS as a user space application on SunOS 4.x. They used mmap() and protections to take user level page faults. Yeah, there were bugs but that was ~30 years ago. In more recent times, BitKeeper used mmap() and protections to take the same page faults (we implemented a compressed, XORed file storage that filled in "pages" on demand, it was a crazy performance improvement) and that worked on pretty much every Unix we tried it on. Certainly worked on Linux first try. So what is it about mmap you don't like? From jnc at mercury.lcs.mit.edu Wed Sep 29 04:15:34 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 28 Sep 2021 14:15:34 -0400 (EDT) Subject: [TUHS] Systematic approach to command-line interfaces Message-ID: <20210928181534.F37BC18C0B7@mercury.lcs.mit.edu> > From: "Greg A. Woods" > the elegance of fork() is incredible! That's because in PDP-11 Unix, they didn't have the _room_ to create a huge mess. Try reading the exec() code in V6 or so. (I'm in a bit of a foul mood today; my laptop sorta locked up when a _single_ Edge browser window process grew to almost _2GB_ in size. Are you effing kidding me? If I had any idea what today would look like, back when I was 20 - especially the massive excrement pile that the Internet has turned into - I never would have gone into computers - cabinetwork, or something, would have been an infinitely superior career choice.) > I now struggle with liking the the Unix concept of "everything is a > file" -- especially with respect to actual data files. Multics also got > it right to use single-level storage -- that's the right abstraction Well, files a la Unix, instead of the SLS, are OK for a _lot_ of data storage - pretty much everything except less-common cases like concurrent access to a shared database, etc. Where the SLS really shines is _code_ - being able to just do a subroutine call to interact with something else has incredible bang/buck ratio - although I concede doing it all securely is hard (although they did make a lot of progress there). Noel From woods at robohack.ca Thu Sep 30 02:40:23 2021 From: woods at robohack.ca (Greg A. Woods) Date: Wed, 29 Sep 2021 09:40:23 -0700 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: <20210928181016.GN18305@mcvoy.com> References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> <20210928181016.GN18305@mcvoy.com> Message-ID: At Tue, 28 Sep 2021 11:10:16 -0700, Larry McVoy wrote: Subject: Re: [TUHS] Systematic approach to command-line interfaces > > On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote: > > The "unix" nod to > > single level storage by way of mmap() suffers from horribly bad design > > and neglect. > > So what is it about mmap you don't like? Mmap() as we have it today almost completely ignores the bigger picture and the lessons that came before it. It was an add-on hack that basically said only "Oh, Yeah, we can do that too! Look at this." -- and nobody bothered to look for decades. For one it has no easy direct language support (though it is possible in C to pretend to use it directly, though the syntax often gets cumbersome). Single-level-storage was obviously designed into Multics from the beginning and from the ground up, and it was easily used in the main languages supported on Multics -- but it was just an add-on hack in Unix (that, if memory serves me correctly, was initially only poorly used in another extremely badly designed add-on hack that didn't pay any attention whatsoever to past lessons, i.e. dynamic linking. which to this day is a horror show of inefficiencies and bad hacks). I think perhaps the problem was that mmap() came too soon in a narrow sub-set of the Unix implementations that were around at the time, when many couldn't support it well (especially on 32-bit systems -- it really only becomes universally useful with either segments or 64-bit and larger address spaces). The fracturing of "unix" standards at the time didn't help either. Perhaps these "add-on hack" problems are the reason so many people think fondly of the good old Unix versions where everything was still coming from a few good minds that could work together to build a cohesive design. The add-ons were poorly done, not widely implemented, and usually incompatible with each other when they were adopted by additional implementations. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP Digital Signature URL: From lm at mcvoy.com Thu Sep 30 02:57:15 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Sep 2021 09:57:15 -0700 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> <20210928181016.GN18305@mcvoy.com> Message-ID: <20210929165715.GN18305@mcvoy.com> On Wed, Sep 29, 2021 at 09:40:23AM -0700, Greg A. Woods wrote: > At Tue, 28 Sep 2021 11:10:16 -0700, Larry McVoy wrote: > Subject: Re: [TUHS] Systematic approach to command-line interfaces > > > > On Tue, Sep 28, 2021 at 10:46:25AM -0700, Greg A. Woods wrote: > > > The "unix" nod to > > > single level storage by way of mmap() suffers from horribly bad design > > > and neglect. > > > > So what is it about mmap you don't like? > > Mmap() as we have it today almost completely ignores the bigger picture > and the lessons that came before it. > > It was an add-on hack that basically said only "Oh, Yeah, we can do that > too! Look at this." -- and nobody bothered to look for decades. > > For one it has no easy direct language support (though it is possible in > C to pretend to use it directly, though the syntax often gets cumbersome). > > Single-level-storage was obviously designed into Multics from the > beginning and from the ground up, and it was easily used in the main > languages supported on Multics -- but it was just an add-on hack in Unix > (that, if memory serves me correctly, was initially only poorly used in > another extremely badly designed add-on hack that didn't pay any > attention whatsoever to past lessons, i.e. dynamic linking. which to > this day is a horror show of inefficiencies and bad hacks). > > I think perhaps the problem was that mmap() came too soon in a narrow > sub-set of the Unix implementations that were around at the time, when > many couldn't support it well (especially on 32-bit systems -- it really > only becomes universally useful with either segments or 64-bit and > larger address spaces). The fracturing of "unix" standards at the time > didn't help either. I think you didn't use SunOS 4.x. mmap() was implemented correctly there, the 4.x VM system mostly got rid of the buffer cache (the buffer cache was used only for reading directories and inodes, there was no regular file data there). If you read(2) a page and mmap()ed it and then did a write(2) to the page, the mapped page is the same physical memory as the write()ed page. Zero coherency issues. This was not true in other systems, they copied the page from the buffer cache and had all sorts of coherency problems. It took about a decade for other Unix implementations to catch up and I think that's what you are hung up on. SunOS 4.x got it right. You can read about it, I have all the papers cached at http://mcvoy.com/lm/papers ZFS screwed it all up again, ZFS has it's own cache because they weren't smart enough to know how to make compressed file systems use the page cache (we did it in BitKeeper so I have an existance proof that it is possible). I was deeply disapointed to hear that ZFS screwed up that badly, the Sun I was part of would have NEVER even entertained such an idea, they worked so hard to get a unified page cache. It's just sad. From jnc at mercury.lcs.mit.edu Thu Sep 30 04:07:42 2021 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Sep 2021 14:07:42 -0400 (EDT) Subject: [TUHS] Systematic approach to command-line interfaces Message-ID: <20210929180742.4E63218C0BE@mercury.lcs.mit.edu> > From: Larry McVoy > If you read(2) a page and mmap()ed it and then did a write(2) to the > page, the mapped page is the same physical memory as the write()ed > page. Zero coherency issues. Now I'm confused; read() and write() semantically include a copy operation (so there are then two copies of that data chunk, and possible consistency issues between them), and the copied item is not necessarily page-sized (so you can't ensure consistency between the original+copy by mapping it in). So when one does a read(file, &buffer, 1), one gets a _copy of just that byte_ in the process' address space (and similar for write()). Yes, there's no coherency issue between the contents of an mmap()'d page, and the system's idea of what's in that page of the file, but that's a _different_ coherency issue. Or am I confused? PS: > From: "Greg A. Woods" > I now struggle with liking the the Unix concept of "everything is a > file" -- especially with respect to actual data files. Multics also got > it right to use single-level storage -- that's the right abstraction Oh, one other thing that SLS breaks, for data files, is the whole Unix 'pipe' abstraction, which is at the heart of the whole Unix tools paradigm. So no more 'cmd | wc' et al. And since SLS doesn't have the 'make a copy' semantics of pipe output, it would be hard to trivially work around it. Yes, one could build up a similar framework, but each command would have to specify an input file and an output file (no more 'standard in' and 'out'), and then the command interpreter would have to i) take command A's output file and feed it to command B, and ii) delete A's output file when the whole works was done. Yes, the user could do it manually, but compare: cmd aaa | wc and cmd aaa bbb wc bbb rm bbb If bbb is huge, one might run out of room, but with today's 'light my cigar with disk blocks' life, not a problem - but it would involve more disk traffic, as bbb would have to be written out in its entirety, not just have a mall piece kept in the disk cache as with a pipe. Noel From crossd at gmail.com Thu Sep 30 05:04:23 2021 From: crossd at gmail.com (Dan Cross) Date: Wed, 29 Sep 2021 15:04:23 -0400 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: <20210929180742.4E63218C0BE@mercury.lcs.mit.edu> References: <20210929180742.4E63218C0BE@mercury.lcs.mit.edu> Message-ID: On Wed, Sep 29, 2021 at 2:08 PM Noel Chiappa wrote: > > From: Larry McVoy > > > If you read(2) a page and mmap()ed it and then did a write(2) to the > > page, the mapped page is the same physical memory as the write()ed > > page. Zero coherency issues. > > Now I'm confused; read() and write() semantically include a copy operation > (so there are then two copies of that data chunk, and possible consistency > issues between them), and the copied item is not necessarily page-sized (so > you can't ensure consistency between the original+copy by mapping it in). > So > when one does a read(file, &buffer, 1), one gets a _copy of just that byte_ > in the process' address space (and similar for write()). > > Yes, there's no coherency issue between the contents of an mmap()'d page, > and > the system's idea of what's in that page of the file, but that's a > _different_ coherency issue. > > Or am I confused? > I think that mention of `read` here is a bit of a red-herring; presumably Larry only mentioned it so that the reader would assume that the read blocks are in the buffer cache when discussing the write vs mmap coherency issue with respect to unmerged page and buffer caches (e.g., `*p = 1;` modifies some page in the VM cache, but not the relevant block in the buffer cache, so a subsequent `read` on the mmap'd file descriptor won't necessarily reflect the store). I don't think that is strictly necessary, though; presumably the same problem exists even if the file data isn't in block cache yet. PS: > > From: "Greg A. Woods" > > > I now struggle with liking the the Unix concept of "everything is a > > file" -- especially with respect to actual data files. Multics also > got > > it right to use single-level storage -- that's the right abstraction > > Oh, one other thing that SLS breaks, for data files, is the whole Unix > 'pipe' > abstraction, which is at the heart of the whole Unix tools paradigm. So no > more 'cmd | wc' et al. And since SLS doesn't have the 'make a copy' > semantics of pipe output, it would be hard to trivially work around it. > I don't know about that. One could still model a pipe as an IO device; Multics supported tapes, printers and terminals, after all. It even had pipes! https://web.mit.edu/multics-history/source/Multics/doc/info_segments/pipes.gi.info Yes, one could build up a similar framework, but each command would have to > specify an input file and an output file (no more 'standard in' and 'out'), Why? To continue with the Multics example, it supported `sysin` and `sysprint` from PL/1, referring to the terminal by default. > and then the command interpreter would have to i) take command A's output > file > and feed it to command B, and ii) delete A's output file when the whole > works > was done. Yes, the user could do it manually, but compare: > > cmd aaa | wc > > and > > cmd aaa bbb > wc bbb > rm bbb > > If bbb is huge, one might run out of room, but with today's 'light my cigar > with disk blocks' life, not a problem - but it would involve more disk > traffic, as bbb would have to be written out in its entirety, not just > have a > mall piece kept in the disk cache as with a pipe. > It feels like all you need is a stream abstraction and programs written to use it, which doesn't seem incompatible with SLS. Perhaps the argument is that in a SLS system one wouldn't be motivated to write programs that way, whereas in a program with a Unix-style IO mechanism it's more natural? - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Sep 30 05:12:18 2021 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 29 Sep 2021 12:12:18 -0700 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: <20210929180742.4E63218C0BE@mercury.lcs.mit.edu> References: <20210929180742.4E63218C0BE@mercury.lcs.mit.edu> Message-ID: <20210929191218.GR18305@mcvoy.com> On Wed, Sep 29, 2021 at 02:07:42PM -0400, Noel Chiappa wrote: > > From: Larry McVoy > > > If you read(2) a page and mmap()ed it and then did a write(2) to the > > page, the mapped page is the same physical memory as the write()ed > > page. Zero coherency issues. > > Now I'm confused; read() and write() semantically include a copy operation > (so there are then two copies of that data chunk, and possible consistency > issues between them), and the copied item is not necessarily page-sized (so > you can't ensure consistency between the original+copy by mapping it in). So > when one does a read(file, &buffer, 1), one gets a _copy of just that byte_ > in the process' address space (and similar for write()). > > Yes, there's no coherency issue between the contents of an mmap()'d page, and > the system's idea of what's in that page of the file, but that's a > _different_ coherency issue. That "different" coherency issue is the one I was talking about. SunOS got rid of it, when HP-UX etc grudgingly implemented mmap() they did not have a unified page cache, they had pages that were mmapped but the data was copied from the buffer cache. It was a mess for years and years. From phil at ultimate.com Thu Sep 30 09:10:33 2021 From: phil at ultimate.com (Phil Budne) Date: Wed, 29 Sep 2021 19:10:33 -0400 Subject: [TUHS] Systematic approach to command-line interfaces In-Reply-To: References: <20210731142533.69caf929@moon> <40763c2d-52ad-eb01-8bf8-85acf6fee700@case.edu> Message-ID: <202109292310.18TNAXQp031140@ultimate.com> Greg A. Woods wrote: > [[ I'm digging through old mail -- my summer has been preoccupied by > things that kept me from most everything else, including computing. ]] > > At Sun, 1 Aug 2021 18:13:18 -0600, Andrew Warkentin wrote: > Subject: Re: [TUHS] Systematic approach to command-line interfaces > > > > There's a third kind of primitive that is superior to either spawn() > > or fork() IMO, specifically one that creates a completely empty child > > process and returns a context that lets the parent set up the child's > > state using normal APIs. > > That's actually what fork(2) is, effectively -- it sets up a new process > that then effectively has control over its own destiny, but only by > using code supplied by the parent process, and thus it is also working > within the limits of the Unix security model. The original post above made me think of the TENEX (later TOPS-20) primatives for fork (a noun, aka process) control: SFORK -- create an empty fork/process (halted) GET -- map executable SFORK -- start fork HFORK -- halt a running fork KFORK -- kill a fork SPJFN -- set primary file job file numbers (stdin/stdout) SPLFK -- splice a fork into tree TENEX, like UNIX was created with with knowledge of the Berkeley Timesharing System (SDS 940) and MULTICS. Like MULTICS, TENEX was designed from square one as a VM system, and I believe the 4.2BSD specified mmap call was inspired by the TENEX PMAP call (which can map file pages into a process AND map process pages into a file, and map process pages from another process). The "halted" process state was also used when a user typed CTRL/C. A halted process could be debugged (either in-process, entering a newly mapped debugger, or one already linked in, or out-of-process by splicing a debugger into the process tree). Threads were easily implemented by mapping (selected pages of) the parent process (leaving others copy-on-write, or zero-fill for thread-local stoage). Starting on small machines (an 8KW PDP-7, and a (28KW?) PDP-11) UNIX placed a premium on maximum usefulness in the minimum space. The PDP-7 source we have implements fork (implemented, as on the PDP-11 by swapping out the forking process) but not exec! The Plan9 rfork unbundles traditional Unix descriptor and memory inheritance behaviors. For all the VM generality, a sore place (for me) in TENEX/TOPS-20, a single file descriptor (job file number) was shared by all processes in a login session ("job"). "Primary" input and output streams were however per-process, but, ISTR there was nothing to stop another process from closing a stream another process was using. And like MULTICS, TENEX had byte-stream I/O, implemented day-one for disk files (I'd have to look, but system code may well have implemented it by issuing PMAP calls (monitor call code could invoke monitor calls)), and most simple user programs used it, since it was simpler to program than file mapping. refs: https://opost.com/tenex/tenex72.txt https://www.opennet.ru/docs/BSD/design-44bsd-eng/x312.html http://www.bitsavers.org/pdf/dec/pdp10/TOPS20/AA-4166E-TM_TOPS-20_Monitor_Calls_Reference_Ver_5_Dec82.pdf P.S. And on the ORIGINAL topic, TOPS-20 started with code from the TENEX EXEC (shell) that implemented command completion and incremental, and made it the COMND system call (tho it could well have been a shared library, since almost all of the COMND code called other system calls to do the work). From pnr at planet.nl Thu Sep 30 19:01:50 2021 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 30 Sep 2021 11:01:50 +0200 Subject: [TUHS] mmap origin (was Systematic approach to command-line interfaces) Message-ID: On Wed, Sep 29, 2021 at 09:40:23AM -0700, Greg A. Woods wrote: > I think perhaps the problem was that mmap() came too soon in a narrow > sub-set of the Unix implementations that were around at the time, when > many couldn't support it well (especially on 32-bit systems -- it really > only becomes universally useful with either segments or 64-bit and > larger address spaces). The fracturing of "unix" standards at the time > didn't help either. > > Perhaps these "add-on hack" problems are the reason so many people think > fondly of the good old Unix versions where everything was still coming > from a few good minds that could work together to build a cohesive > design. The add-ons were poorly done, not widely implemented, and > usually incompatible with each other when they were adopted by > additional implementations. mmap() did come from those days and minds. The first appearance of mmap() was in 32V R3, done by John Reiser in 1981. This is the version of 32V with full demand paging; it implemented a unified buffer cache. According to John, that version of mmap() already had the modern 6 argument API. John added mmap() because he worked with Tenex a lot during his PhD days and missed PMAP. He needed some 6 months to design, implement and debug this version of 32V as a skunkworks project. I am trying to revert early VAX SVr1/r2 code to get a better view of what 32V R3 looked like, but unfortunately I did not have much time for this effort in last couple of months. It would seem that 32V R3 assumed that disk blocks and memory pages were the same size (true on a 1980 VAX) and with that assumption a unified buffer cache comes natural in this code base. For 4.2BSD initially Joy cs. had a different approach to memory mapped files in mind (see the 1981 tech report #4 from CSRG). By the time of 4.2BSD’s release the manual defined a mmap() system call, but it was not implemented and it appears to have been largely forgotten until SunOS 4 and dynamic libraries six years later. In the SysV lineage it is less clear. For sure mmap() is not there, but the first implementation of the shmem IPC feature might derive from the 32V R3 code. On the inside, SVr2 virtual memory appears to implement the segments (now called regions) that Joy envisaged for 4.2BSD but did not implement. CB Unix had a precursor to shmem as well, where a portion of system core was reserved for shared memory purposes and could be accessed either via the /dev/mem device or could be mapped into the PDP-11 address space (using 1 of the 8 segment registers for each map). Here too the device and the map were unified. So far, I have not come across any shared library implementations or precursors in early Unix prior to SunOS 4. Paul From arnold at skeeve.com Thu Sep 30 20:39:29 2021 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 30 Sep 2021 04:39:29 -0600 Subject: [TUHS] Early shared library implementations In-Reply-To: References: Message-ID: <202109301039.18UAdT0F026748@freefriends.org> Paul Ruizendaal via TUHS wrote: > So far, I have not come across any shared library implementations or > precursors in early Unix prior to SunOS 4. In more or less the same time frame, the AT&T UnixPC / 3B1, which was OEM'ed from Convergent, had shared libraries. This was ~ 1986. I don't know the details of how it worked and how one built the shared libraries; I am sure that it was an independent implementation from Sun's. This was done on top of a System V Release 2 kernel. Later versions of the OS had some bits of the SVR3 user land, but the kernel remained SVR2 based. There is a 3B1 emulator and disk images for it available for anyone who really wants to go back to a system with short filenames and no job control. :-) Arnold From douglas.mcilroy at dartmouth.edu Thu Sep 30 21:41:33 2021 From: douglas.mcilroy at dartmouth.edu (Douglas McIlroy) Date: Thu, 30 Sep 2021 07:41:33 -0400 Subject: [TUHS] Systematic approach to command-line interfaces Message-ID: > one other thing that SLS breaks, for data files, is the whole Unix 'pipe' > abstraction, which is at the heart of the whole Unix tools paradigm. Multics had an IO system with an inherent notion of redirectable data streams. Pipes could have--and eventually did (circa 1987)--fit into that framework. I presume a pipe DIM (device interface manager) was not hard to build once it was proposed and accepted. Doug From halbert at halwitz.org Thu Sep 30 22:56:28 2021 From: halbert at halwitz.org (Dan Halbert) Date: Thu, 30 Sep 2021 08:56:28 -0400 Subject: [TUHS] mmap origin (was Systematic approach to command-line interfaces) In-Reply-To: References: Message-ID: <3078f9ad-0c1b-52b7-4d76-973ff3fde7f4@halwitz.org> On 9/30/21 5:01 AM, Paul Ruizendaal via TUHS wrote: > For 4.2BSD initially Joy cs. had a different approach to memory mapped files in mind (see the 1981 tech report #4 from CSRG). By the time of 4.2BSD’s release the manual defined a mmap() system call, but it was not implemented and it appears to have been largely forgotten until SunOS 4 and dynamic libraries six years later. > 3BSD and I think 4.1BSD had vread() and vwrite(), which looked like regular read() and write() but accessed pages only on demand. I was a grad student at Berkeley at the time and remember their genesis. Bill and I were eating lunch from Top Dog on the Etcheverry Hall plaza, and were talking about memory-mapped I/O. I remember suggesting the actual names, perhaps as a parallel to vfork(). I had used both TENEX and Multics, which both had page mapping. Multics' memory-mapped segments were quite fundamental, of course. I think we were looking for something vaguely upward compatible from the existing system calls. We did not leap to an mmap() right away just because it would have been a more radical shift than continuing the stream orientation of UNIX. I did not implement any of this: it was just a brainstorming session. Dan H