From steffen at sdaoden.eu Fri Dec 1 01:44:04 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 30 Nov 2017 16:44:04 +0100 Subject: [TUHS] RIP J.F.Ossanna In-Reply-To: <20171130024816.GI16794@mcvoy.com> References: <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com> <20171128001543.GG3430@mcvoy.com> <20171129190055.9ZFVf%steffen@sdaoden.eu> <20171130024816.GI16794@mcvoy.com> Message-ID: <20171130154404.-Z1KH%steffen@sdaoden.eu> Larry McVoy wrote: |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote: |> Larry McVoy wrote: |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote: |>|> 1977 marks my entry into the world of UNIX. I've always stated \ |>|> there was |>|> only one person who truly understood nroff and he was dead. |>|> I mourn the fact that of all the UNIX greats I've met, I missed out on |>|> Ossanna. |> |>|I think one could argue that James Clark has a pretty good handle on |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc). |> |> And Werner Lemberg, who carried the torch for the last almost two |> decades. He brought in some really great improvements, like |> arguments for strings, which allows to write pretty much TeX like |> a.k.a. inline if you want to (as in "this is \*[I talic] text"). | |Yep. James exited stage left and Werner stepped in. I mean no disrespect |to anyone, I was just saying that James has a really good handle on roff, |he redid it all. I admire him for doing so (even though I curse the fact |that he did it in C++). The original source was no free code back then, so he did it for the free and open software world. Thankfully. And i do not know, i mean C++ was in 1989-1992, when he did most of the work as far as i can tell from a shallow look, a class, later template extension layer for plain C, not that overly huge stands-by-itself monster that i call it now. I am absolutely in favour and a of classes and objects, the encapsulation they provide, the method-on-object rather than object-on-function that you have with C. (Multiple) Inheritance including automatic upcasts (to the given parent). Virtual function pointer tables, automatically managed. And "simple" templates. For example, myself, in the process of creating my own fork, can write (globbering the global namespace) color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){ m_scheme = scheme_rgb; return set_red(r).set_green(g).set_blue(b); } color &set_red(rf_ui32 c){ rf_ASSERT(scheme() == scheme_rgb); m_comps[0] = rf_min(c, max_val); return *this; } ... instead of rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){ self->c_scheme = rf_COLOR_SCHEME_RGB; self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL); ... return self; } and programming all that out over and over again. (Or using macros with side-effects. Or relying on inline functions.) And that is a simple object with a short name. References are unfortunate in my opinion, but you will not see any light if you try doing C++ without them because they are omnipresent for core functionality like standard copy constructors etc. Like many other things, including the complete departure from an underlaying C standard. C++03/C99 or so i would have appreciated. But as long as -fno-rtti -fno-exceptions is possible i can somehow live with it. (Let aside the fact that i have to live with it no matter what bloat the C++ standard introduces next.) And then C is not what it was no more, too, and unfortunately the usage-makes-fun guideline from what Plan9 documents and extends onto ISO C89 was not what the ISO C people looked at when they did. Well. Maybe if he would have known what C++ ends up as he would have used C instead? That would be an interesting question. Myself i currently appreciate coming back to a C++ codebase, however, because thinking in objects is my personal way of dealing with programming, that is how i really got used to it, anyway. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From noel.hunt at gmail.com Fri Dec 1 06:43:51 2017 From: noel.hunt at gmail.com (Noel Hunt) Date: Fri, 1 Dec 2017 07:43:51 +1100 Subject: [TUHS] RIP J.F.Ossanna In-Reply-To: <20171130154404.-Z1KH%steffen@sdaoden.eu> References: <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com> <20171128001543.GG3430@mcvoy.com> <20171129190055.9ZFVf%steffen@sdaoden.eu> <20171130024816.GI16794@mcvoy.com> <20171130154404.-Z1KH%steffen@sdaoden.eu> Message-ID: If you want to see a nice use of a restricted subset of C++, that is, code written in the early days before the accretion of hideous excrescences, I highly recommend Tom Cargill's 'pads'. You will find it in the 10th Edition distributions. It is a typical blit-style program, with a 'terminal' and 'host' portion, the 'host' portion being written in the said restricted, earlier form of C++. The 'terminal' part is in C (this is the graphics front-end) but written for the blit. There was an OpenLook port by Dave Kowolski, and I have a version that runs under Plan9 (via Russ Cox's plan9port)---there is a straight-forward mapping of blit graphics operations to the Plan9 model. Noel Hunt On Fri, Dec 1, 2017 at 2:44 AM, Steffen Nurpmeso wrote: > Larry McVoy wrote: > |On Wed, Nov 29, 2017 at 08:00:55PM +0100, Steffen Nurpmeso wrote: > |> Larry McVoy wrote: > |>|On Mon, Nov 27, 2017 at 07:06:51PM -0500, Ron Natalie wrote: > |>|> 1977 marks my entry into the world of UNIX. I've always stated \ > |>|> there was > |>|> only one person who truly understood nroff and he was dead. > |>|> I mourn the fact that of all the UNIX greats I've met, I missed out > on > |>|> Ossanna. > |> > |>|I think one could argue that James Clark has a pretty good handle on > |>|roff (having written the GNU version of nroff/troff/tbl/eqn/pic etc). > |> > |> And Werner Lemberg, who carried the torch for the last almost two > |> decades. He brought in some really great improvements, like > |> arguments for strings, which allows to write pretty much TeX like > |> a.k.a. inline if you want to (as in "this is \*[I talic] text"). > | > |Yep. James exited stage left and Werner stepped in. I mean no > disrespect > |to anyone, I was just saying that James has a really good handle on roff, > |he redid it all. I admire him for doing so (even though I curse the fact > |that he did it in C++). > > The original source was no free code back then, so he did it for > the free and open software world. Thankfully. And i do not know, > i mean C++ was in 1989-1992, when he did most of the work as far > as i can tell from a shallow look, a class, later template > extension layer for plain C, not that overly huge stands-by-itself > monster that i call it now. > > I am absolutely in favour and a of classes and objects, the > encapsulation they provide, the method-on-object rather than > object-on-function that you have with C. (Multiple) Inheritance > including automatic upcasts (to the given parent). Virtual > function pointer tables, automatically managed. And "simple" > templates. For example, myself, in the process of creating my own > fork, can write (globbering the global namespace) > > color &assign_rgb(rf_ui32 r, rf_ui32 g, rf_ui32 b){ > m_scheme = scheme_rgb; > return set_red(r).set_green(g).set_blue(b); > } > color &set_red(rf_ui32 c){ > rf_ASSERT(scheme() == scheme_rgb); > m_comps[0] = rf_min(c, max_val); > return *this; > } > ... > > instead of > > rf_color *rf_color_assign_rgb(rf_color *self, rf_ui32 r, ....){ > self->c_scheme = rf_COLOR_SCHEME_RGB; > self->c_comps[0] = rf_MIN(r, rf_COLOR_MAX_VAL); > ... > return self; > } > > and programming all that out over and over again. (Or using > macros with side-effects. Or relying on inline functions.) > And that is a simple object with a short name. > References are unfortunate in my opinion, but you will not see any > light if you try doing C++ without them because they are > omnipresent for core functionality like standard copy constructors > etc. Like many other things, including the complete departure > from an underlaying C standard. C++03/C99 or so i would have > appreciated. But as long as -fno-rtti -fno-exceptions is possible > i can somehow live with it. (Let aside the fact that i have to > live with it no matter what bloat the C++ standard introduces > next.) And then C is not what it was no more, too, and > unfortunately the usage-makes-fun guideline from what Plan9 > documents and extends onto ISO C89 was not what the ISO C people > looked at when they did. Well. > > Maybe if he would have known what C++ ends up as he would have > used C instead? That would be an interesting question. Myself > i currently appreciate coming back to a C++ codebase, however, > because thinking in objects is my personal way of dealing with > programming, that is how i really got used to it, anyway. > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Fri Dec 1 08:36:51 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 30 Nov 2017 23:36:51 +0100 Subject: [TUHS] RIP J.F.Ossanna In-Reply-To: References: <003d01d367dc$cd3e8910$67bb9b30$@ronnatalie.com> <20171128001543.GG3430@mcvoy.com> <20171129190055.9ZFVf%steffen@sdaoden.eu> <20171130024816.GI16794@mcvoy.com> <20171130154404.-Z1KH%steffen@sdaoden.eu> Message-ID: <20171130223651.gSX4i%steffen@sdaoden.eu> Noel Hunt wrote: |If you want to see a nice use of a restricted subset of C++, |that is, code written in the early days before the accretion |of hideous excrescences, I highly recommend Tom Cargill's |'pads'. You will find it in the 10th Edition distributions. I downloaded it from [1] [1] http://www.softwarepreservation.org/projects/c_plus_plus/application/application/pi_pads_libj.tgz |It is a typical blit-style program, with a 'terminal' and |'host' portion, the 'host' portion being written in the said |restricted, earlier form of C++. Yes, that package looks good. Two nice things in 5 minutes: if( !this ) return 0; I would like to read "references are needless" into that. // C++ bug (Action) Yes! That is exactly my gut feeling, too! Interestingly it seems that it has been possible to apply access policies on file level, even for preprocessor things etc.: >pri #define PADS_VERSION 0x851021 /* YYMMDD */ #define CARTE 0x80 #define NUMERIC 1 > That i never had seen before. Quite a lot of C++ in this package.. |The 'terminal' part is in C (this is the graphics front-end) |but written for the blit. There was an OpenLook port by Dave |Kowolski, and I have a version that runs under Plan9 (via |Russ Cox's plan9port)---there is a straight-forward mapping |of blit graphics operations to the Plan9 model. | |Noel Hunt In V10 there are the sources of cfront, and also troff, pic etc. I would wish i had more time to look through that. Most code from these laboratories and universities is just casual, this is what i like so much. I mean, really. Most of the elder code goes like about LayerReshaped(); MOUSEServe(); KBDServe(); RCVServe(); and is done with it When i started, as well as today, notational things for namespace and (get, set) functions were in use for at least libraries, and then i found C++ preferable over C due to "using NAME" directives etc., whereas in C you go for g_mount_tracker_find_by_mount_spec() and woe if the argument is "a subclass". And pi is really a debugger!? I detest debuggers! But he instrumented most of it with trace() and VOK by hand in order to debug that thing. That is fantastic. I dislike so much that today shipout code of even the smallest utility is compiled with stack canaries enabled, the assembly looks infested, all that should be kept in debug code, in my opinion. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From lm at mcvoy.com Sat Dec 2 01:44:48 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Dec 2017 07:44:48 -0800 Subject: [TUHS] signals and blocked in I/O Message-ID: <20171201154448.GL3924@mcvoy.com> Does anyone remember the reason that processes blocked in I/O don't catch signals? When did that become a thing, was that part of the original design or did that happen in BSD? I'm asking because I'm banging on FreeBSD and I can wedge it hard, to the point that it won't recover, by just beating on tons of memory. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From crossd at gmail.com Sat Dec 2 01:53:58 2017 From: crossd at gmail.com (Dan Cross) Date: Fri, 1 Dec 2017 10:53:58 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201154448.GL3924@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> Message-ID: On Fri, Dec 1, 2017 at 10:44 AM, Larry McVoy wrote: > Does anyone remember the reason that processes blocked in I/O don't catch > signals? When did that become a thing, was that part of the original > design or did that happen in BSD? > > I'm asking because I'm banging on FreeBSD and I can wedge it hard, to > the point that it won't recover, by just beating on tons of memory. My understanding was that signal delivery only happens when the process is *running* in the kernel. If the process is sleeping on IO then it's not running, so the signal isn't delivered. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Dec 2 02:01:32 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 2 Dec 2017 03:01:32 +1100 (EST) Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201154448.GL3924@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> Message-ID: On Fri, 1 Dec 2017, Larry McVoy wrote: > Does anyone remember the reason that processes blocked in I/O don't > catch signals? When did that become a thing, was that part of the > original design or did that happen in BSD? Something to do with pending DMA transfers? > I'm asking because I'm banging on FreeBSD and I can wedge it hard, to > the point that it won't recover, by just beating on tons of memory. That happens on my MacBook a lot :-) It "only" has 4GB memory, the most it will ever take. In the meantime, my FreeBSD server, pretty much running only Sendmail and Apache (and BIND), gets along just fine with just 512MB (yes, really; it does not run X or anything). Sigh... Sometimes I miss my old 11/40 with 124kw of memory and a handful of users, the biggest memory hog probably being NROFF (we didn't have VI, but used EM)... Hey, anyone remember Editor for Mortals? The author ought to be shot for naming something just one keystroke away from "rm file"... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Sat Dec 2 02:11:56 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 1 Dec 2017 11:11:56 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201154448.GL3924@mcvoy.com> Message-ID: Right... that's one of the reasons we created AST's and tried to get them in the POSIX spec and an alternative to signals. Instead of trying to 'fix' them, we decided to inject a new scheme with better semantics (like being queued, prioritized, guaranteed to be delivered). They were *.4 for a while and got replaced with sigqueue which sort helps but does not solve the issues. I'm always torn, do you add a new interface and risk bloat, or try to extend the old. We never did it in RTU, but talked about it for Stellix (and never did it there either), but we toyed with making AST's the kernel primitive and then trying to build signals from them in a user space library -> which at the time, we thought you can do. Although there are some strange side effects of signals that you would have really think through. They have been extended again with POSIX and SVR4 so I'm not so sure, It's hard because if I/O (like DMA) is in progress, what are the proper semantics to exit/roll back? When do you stop the transfer and what happens. When doing direct to/from disk (like a in a real-time system), this can get tricky. Traditional UNIX semantics were that when a DMA was started, the process is blocked at high priority until the I/O completes. Which is fine in the standard case, but begs the question of what happens when things go south. signals match an easy implementation of the V6 kernel. BSD did try to fix them a little, but we all know that caused as many issues as it solved. Clem On Fri, Dec 1, 2017 at 10:53 AM, Dan Cross wrote: > On Fri, Dec 1, 2017 at 10:44 AM, Larry McVoy wrote: > >> Does anyone remember the reason that processes blocked in I/O don't catch >> signals? When did that become a thing, was that part of the original >> design or did that happen in BSD? >> >> I'm asking because I'm banging on FreeBSD and I can wedge it hard, to >> the point that it won't recover, by just beating on tons of memory. > > > My understanding was that signal delivery only happens when the process is > *running* in the kernel. If the process is sleeping on IO then it's not > running, so the signal isn't delivered. > > - Dan C. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Dec 2 02:18:10 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Dec 2017 08:18:10 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201154448.GL3924@mcvoy.com> Message-ID: <20171201161810.GM3924@mcvoy.com> On Fri, Dec 01, 2017 at 11:11:56AM -0500, Clem Cole wrote: > It's hard because if I/O (like DMA) is in progress, what are the proper > semantics to exit/roll back? When do you stop the transfer and what > happens. When doing direct to/from disk (like a in a real-time system), > this can get tricky. So at first blush, what it seems like is you need a barrier to starting more DMA's. You take the signal, the signal changes state to say to the I/O system "finish what you are doing but then no more". Or what you do is kill the process, tear down all of the pages except those that are locked for I/O, leave those in the process and wait for the I/O to get done. That might be simpler. From imp at bsdimp.com Sat Dec 2 02:24:06 2017 From: imp at bsdimp.com (Warner Losh) Date: Fri, 1 Dec 2017 09:24:06 -0700 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201154448.GL3924@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> Message-ID: On Fri, Dec 1, 2017 at 8:44 AM, Larry McVoy wrote: > Does anyone remember the reason that processes blocked in I/O don't catch > signals? When did that become a thing, was that part of the original > design or did that happen in BSD? > > I'm asking because I'm banging on FreeBSD and I can wedge it hard, to > the point that it won't recover, by just beating on tons of memory. > It depends on the I/O, really, if the signal will work. If we're waiting for I/O to arrive at a character device, for example, you can signal all day long (the TTY driver depends on this, for example). In old-school BSD, processes in disk wait state were blocked in the filesystem layer (typically) waiting for an I/O to complete. I don't know which came first, but I know the code is quite dependent on the I/O not returning half-baked. There's no way cancel the I/O once it's started. And the I/O can also be decoupled from the original process if it's being done by one of the system threads, so you could be waiting on an I/O to complete so a page is valid that may have been started by someone else. Tracking back which process to signal in such circumstances is tricky. The filesystem code assumes the buffer cache actually caches the page, so the pages are invalid while the I/O is in progress. Plus pages are wired for the I/O, and generally marked as invalid so any access on them faults. Processes receiving signals in that state may need to exit, but couldn't until those pages are unwired, so even SIGKILL there would be useless until the I/O completed. But I think your issues aren't so much I/O as free pages. You need free pages in order to make progress in running your process. W/o them, you bog down badly. The root cause is poor page laundering behavior: the system isn't able to clean enough pages to keep up with the demand. I'm not so sure it's signals, per se... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Sat Dec 2 02:33:49 2017 From: imp at bsdimp.com (Warner Losh) Date: Fri, 1 Dec 2017 09:33:49 -0700 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201161810.GM3924@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> Message-ID: On Fri, Dec 1, 2017 at 9:18 AM, Larry McVoy wrote: > On Fri, Dec 01, 2017 at 11:11:56AM -0500, Clem Cole wrote: > > It's hard because if I/O (like DMA) is in progress, what are the proper > > semantics to exit/roll back? When do you stop the transfer and what > > happens. When doing direct to/from disk (like a in a real-time system), > > this can get tricky. > > So at first blush, what it seems like is you need a barrier to starting > more > DMA's. You take the signal, the signal changes state to say to the I/O > system "finish what you are doing but then no more". > The I/O subsystem is great at knowing disks, pages and buffers. Lousy at knowing processes. It has no hooks into, well, anything apart from FOOstrategy (and if you are lucky first open and last close). And FOOstrategy is far removed from anything that the process knows about. It knows about vmpages and open file descriptors. You'd need to plumb something into the vnode code that could take a request for a signal. Then that signal would need to go down to the driver somehow. And you'd need to know what I/O was pending for pages that are in that process, and somehow have an ID to cancel just those requests. With the layering involved, it would be extremely tricky. Many of the io completion routines cause more I/O to happen, especially when swapping. Plus, modern disks have a hardware queue depth. There is no way to do say 'finish this and do no more' because there's stuff in the hardware queue. SCSI is sensible and you may be able to selectively cancel I/O transactions, but ATA is not sensible: you cancel the whole queue and cope with the fallout (usually by rescheduling the I/Os). > Or what you do is kill the process, tear down all of the pages except those > that are locked for I/O, leave those in the process and wait for the I/O to > get done. That might be simpler. > Perhaps. Even that may have issues with cleanup because you may also need other pages to complete the I/O processing since I think that things like aio allocate a tiny bit of memory associated with the requesting process and need that memory to finish the I/O. It's certainly not a requirement that all I/O initiated by userland have no extra state stored in the process' address space associated with it. Since the unwinding happens at a layer higher than the disk driver, who knows what those guys do, eh? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Dec 2 03:26:03 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Dec 2017 09:26:03 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> Message-ID: <20171201172603.GO3924@mcvoy.com> On Fri, Dec 01, 2017 at 09:33:49AM -0700, Warner Losh wrote: > > Or what you do is kill the process, tear down all of the pages except those > > that are locked for I/O, leave those in the process and wait for the I/O to > > get done. That might be simpler. > > Perhaps. Even that may have issues with cleanup because you may also need > other pages to complete the I/O processing since I think that things like > aio allocate a tiny bit of memory associated with the requesting process > and need that memory to finish the I/O. It's certainly not a requirement > that all I/O initiated by userland have no extra state stored in the > process' address space associated with it. Since the unwinding happens at a > layer higher than the disk driver, who knows what those guys do, eh? Yeah, it's not an easy fix but the problem we are having right now is that the system is thrashing. Why the OOM code isn't fixing it I don't know. It just feels busted. From torek at torek.net Sat Dec 2 05:10:25 2017 From: torek at torek.net (Chris Torek) Date: Fri, 01 Dec 2017 11:10:25 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: Your message of "Fri, 01 Dec 2017 09:26:03 -0800." <20171201172603.GO3924@mcvoy.com> Message-ID: <201712011910.vB1JAPVD068905@elf.torek.net> FYI, the way signals actually work is that they are delivered only by crossing through the user/kernel boundary. (That mostly even includes those that kill a process entirely, except that there's some optimizations there for some cases. If the CPU is running in user space for some *other* process, we have to arrange for the signalled process to be scheduled to run, or if it's on another CPU, take an interrupt so as to get into the kernel and hence cross that boundary.) This part is natural, since signal delivery means "run a function in user space, with user privileges". If you're currently *in* the kernel on behalf of some user process, that means you have to get *out* of it in that same process. This is why signals interrupt system calls, making them return with EINTR. To avoid having system calls that haven't really started -- have not done anything yet -- from returning EINTR, the BSD and POSIX SA_RESTART options work by just making the "resume" program counter address point back to the "make system call" instruction. Essentially: frame->pc -= instruction_size; This can't be done if the system call has actually done something, so read() or write() on a slow device like a tty will return a short count (not -1 and EINTR). The BSD implementation these days is to call the various *sleep kernel functions (msleep, tsleep, etc) with PCATCH "or"-ed into the priority to indicate that it is OK to have a signal interrupt the sleep. If so, the sleep call returns ERESTART (a special error code that the syscall handler notices and does the "subtract from frame->pc" trick). In the old days, PCATCH was implied by the sleep priority; all we did was make it an explicit flag, and do manual unwinding (the V6 kernel used the equivalent of longjmp to get to the EINTR-returner so that the main line code path did not have to check). The I/O subsystem generally calls *sleep without PCATCH, though. Chris From bakul at bitblocks.com Sat Dec 2 07:33:46 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 1 Dec 2017 13:33:46 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201172603.GO3924@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> Message-ID: On Dec 1, 2017, at 9:26 AM, Larry McVoy wrote: > > On Fri, Dec 01, 2017 at 09:33:49AM -0700, Warner Losh wrote: >>> Or what you do is kill the process, tear down all of the pages except those >>> that are locked for I/O, leave those in the process and wait for the I/O to >>> get done. That might be simpler. >> >> Perhaps. Even that may have issues with cleanup because you may also need >> other pages to complete the I/O processing since I think that things like >> aio allocate a tiny bit of memory associated with the requesting process >> and need that memory to finish the I/O. It's certainly not a requirement >> that all I/O initiated by userland have no extra state stored in the >> process' address space associated with it. Since the unwinding happens at a >> layer higher than the disk driver, who knows what those guys do, eh? > > Yeah, it's not an easy fix but the problem we are having right now is that > the system is thrashing. Why the OOM code isn't fixing it I don't know. > It just feels busted. So OOM code kills a (random) process in hopes of freeing up some pages but if this process is stuck in diskIO, nothing can be freed and everything grinds to a halt. Is this right? If so, one work around is to kill a process that is *not* sleeping at an uninterruptable priority :-)/2 This is separate from any policy of how to choose a victim. If the queue of dirty pages is growing longer and longer as the page washer can't keep up, this is analogous to the bufferbloat problem in networking. You have to test if this is what is going on. If so, may be you can figure out how to keep the queues short. But before any fixes, I would strongly suggest instrumenting the code to understand what is going on and then instrument the code further to test out various hypotheses. Once a clear mental model is in place, the fix will be obvious! From lm at mcvoy.com Sat Dec 2 08:38:59 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Dec 2017 14:38:59 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> Message-ID: <20171201223859.GX3924@mcvoy.com> On Fri, Dec 01, 2017 at 01:33:46PM -0800, Bakul Shah wrote: > > Yeah, it's not an easy fix but the problem we are having right now is that > > the system is thrashing. Why the OOM code isn't fixing it I don't know. > > It just feels busted. > > So OOM code kills a (random) process in hopes of freeing up > some pages but if this process is stuck in diskIO, nothing > can be freed and everything grinds to a halt. Is this right? Yep, exactly. From ralph at inputplus.co.uk Sat Dec 2 09:03:02 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Fri, 01 Dec 2017 23:03:02 +0000 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201223859.GX3924@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> Message-ID: <20171201230302.0DC351FA41@orac.inputplus.co.uk> Hi Larry, > > So OOM code kills a (random) process in hopes of freeing up some > > pages but if this process is stuck in diskIO, nothing can be freed > > and everything grinds to a halt. > > Yep, exactly. Is that because the pages have been dirty for so long they've reached the VM-writeback timeout even though there's no pressure to use them for something else? Or has that been lengthened because you don't fear power loss wiping volatile RAM? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From lm at mcvoy.com Sat Dec 2 09:09:34 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Dec 2017 15:09:34 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201230302.0DC351FA41@orac.inputplus.co.uk> References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> Message-ID: <20171201230934.GA24335@mcvoy.com> On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote: > Hi Larry, > > > > So OOM code kills a (random) process in hopes of freeing up some > > > pages but if this process is stuck in diskIO, nothing can be freed > > > and everything grinds to a halt. > > > > Yep, exactly. > > Is that because the pages have been dirty for so long they've reached > the VM-writeback timeout even though there's no pressure to use them for > something else? Or has that been lengthened because you don't fear > power loss wiping volatile RAM? I'm tinkering with the pageout daemon so I'm trying to apply memory pressure. I have 10 25GB processes (25GB malloced) and the processes just walk the memory over and over. This is on a 256GB main memory machine (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix). It's the old "10 pounds of shit in a 5 pound bag" problem, same old stuff, just a bigger bag. The problem is that OOM can't kill the processes that are the problem, they are stuck in disk wait. That's why I started asking why can't you kill a process that's in the middle of I/O. From dave at horsfall.org Sat Dec 2 09:21:23 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 2 Dec 2017 10:21:23 +1100 (EST) Subject: [TUHS] signals and blocked in I/O In-Reply-To: <201712011910.vB1JAPVD068905@elf.torek.net> References: <201712011910.vB1JAPVD068905@elf.torek.net> Message-ID: On Fri, 1 Dec 2017, Chris Torek wrote: [...] > This part is natural, since signal delivery means "run a function in > user space, with user privileges". If you're currently *in* the kernel > on behalf of some user process, that means you have to get *out* of it > in that same process. Which leads to the classic comment (it's right up there with the famous "line 2238") along the lines of "we ask a process to do something to itself". -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From bakul at bitblocks.com Sat Dec 2 09:42:15 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 01 Dec 2017 15:42:15 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: Your message of "Fri, 01 Dec 2017 15:09:34 -0800." <20171201230934.GA24335@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> Message-ID: <20171201234230.F33D4156E523@mail.bitblocks.com> On Fri, 01 Dec 2017 15:09:34 -0800 Larry McVoy wrote: Larry McVoy writes: > On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote: > > Hi Larry, > > > > > > So OOM code kills a (random) process in hopes of freeing up some > > > > pages but if this process is stuck in diskIO, nothing can be freed > > > > and everything grinds to a halt. > > > > > > Yep, exactly. > > > > Is that because the pages have been dirty for so long they've reached > > the VM-writeback timeout even though there's no pressure to use them for > > something else? Or has that been lengthened because you don't fear > > power loss wiping volatile RAM? > > I'm tinkering with the pageout daemon so I'm trying to apply memory > pressure. I have 10 25GB processes (25GB malloced) and the processes just > walk the memory over and over. This is on a 256GB main memory machine > (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix). How many times do processes walk their memory before this condition occurs? So what may be happening is that a process references a page, it page faults, the kernel finds its phys page has been paged out, so it looks for a free page and once a free page is found, the process will block on page in. Or if there is no free page, it has to wait until some other dirty page is paged out (but this would be a different wait queue). As more and more processes do this, the system runs out of all free pages. Can you find out how many processes are waiting under what conditions, how long they wait and how these queue lengths are changing over time? You can use a ring buffer to capture last 2^N measurements and dump them in the debugger when everything grinds to a halt. > It's the old "10 pounds of shit in a 5 pound bag" problem, same old stuff, > just a bigger bag. > > The problem is that OOM can't kill the processes that are the problem, > they are stuck in disk wait. That's why I started asking why can't you > kill a process that's in the middle of I/O. The OS equivalent of RED (random early drop) would be if a process kills itself. e.g. when some critical metric crosses a highwater mark. Another option would be to return with an EFAULT and the process can either kill itself or free up the page or something. [I have used EFAULT to dyanmically allocate *more* pages but no reason why the same can be used to free up memory!] From lm at mcvoy.com Sat Dec 2 10:48:50 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 1 Dec 2017 16:48:50 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201234230.F33D4156E523@mail.bitblocks.com> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> Message-ID: <20171202004850.GB24335@mcvoy.com> On Fri, Dec 01, 2017 at 03:42:15PM -0800, Bakul Shah wrote: > On Fri, 01 Dec 2017 15:09:34 -0800 Larry McVoy wrote: > Larry McVoy writes: > > On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote: > > > Hi Larry, > > > > > > > > So OOM code kills a (random) process in hopes of freeing up some > > > > > pages but if this process is stuck in diskIO, nothing can be freed > > > > > and everything grinds to a halt. > > > > > > > > Yep, exactly. > > > > > > Is that because the pages have been dirty for so long they've reached > > > the VM-writeback timeout even though there's no pressure to use them for > > > something else? Or has that been lengthened because you don't fear > > > power loss wiping volatile RAM? > > > > I'm tinkering with the pageout daemon so I'm trying to apply memory > > pressure. I have 10 25GB processes (25GB malloced) and the processes just > > walk the memory over and over. This is on a 256GB main memory machine > > (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix). > > How many times do processes walk their memory before this condition > occurs? Until free memory goes to ~0. That's the point, I'm trying to improve things when there is too much pressure on memory. > So what may be happening is that a process references a page, > it page faults, the kernel finds its phys page has been paged > out, so it looks for a free page and once a free page is > found, the process will block on page in. Or if there is no > free page, it has to wait until some other dirty page is paged > out (but this would be a different wait queue). As more and > more processes do this, the system runs out of all free pages. Yeah. > Can you find out how many processes are waiting under what > conditions, how long they wait and how these queue lengths are > changing over time? So I have 10 processes, they all run until the system starts to thrash, then they are all in wait mode for memory but there isn't any (and there is no swap configured). The fundamental problem is that they are sleeping waiting for memory to be freed. They are NOT in I/O mode, there is no DMA happening, this is main memory, it is not backed by swap, there is no swap. So they are sleeping waiting for the pageout daemon to free some memory. It's not going to free their memory because there is no place to stash (no swap). So it's trying to free other memory. The real question is where did they go to sleep and why did they sleep without PCATCH on? If I can find that place where they are trying to alloc a page and failed and they go to sleep there, I could either a) commit seppuku because we are out of memory and I'm part of the problem b) go into a sleep / wakeup / check signals loop I am reminded by you all that we ask the process to do it to itself but there does seem to be a way to sleep and respect signals, the tty stuff does that. So if I can find this place, determine that I'm just asking for memory, not I/O, and sleep with PCATCH on then I might be golden. Where "golden" means I can kill the process and the OOM thread could do it for me. Thoughts? From bakul at bitblocks.com Sat Dec 2 11:40:32 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Fri, 01 Dec 2017 17:40:32 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: Your message of "Fri, 01 Dec 2017 16:48:50 -0800." <20171202004850.GB24335@mcvoy.com> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> Message-ID: <20171202014047.E5E0C156E523@mail.bitblocks.com> On Fri, 01 Dec 2017 16:48:50 -0800 Larry McVoy wrote: Larry McVoy writes: > On Fri, Dec 01, 2017 at 03:42:15PM -0800, Bakul Shah wrote: > > On Fri, 01 Dec 2017 15:09:34 -0800 Larry McVoy wrote: > > Larry McVoy writes: > > > On Fri, Dec 01, 2017 at 11:03:02PM +0000, Ralph Corderoy wrote: > > > > Hi Larry, > > > > > > > > > > So OOM code kills a (random) process in hopes of freeing up some > > > > > > pages but if this process is stuck in diskIO, nothing can be freed > > > > > > and everything grinds to a halt. > > > > > > > > > > Yep, exactly. > > > > > > > > Is that because the pages have been dirty for so long they've reached > > > > the VM-writeback timeout even though there's no pressure to use them fo > r > > > > something else? Or has that been lengthened because you don't fear > > > > power loss wiping volatile RAM? > > > > > > I'm tinkering with the pageout daemon so I'm trying to apply memory > > > pressure. I have 10 25GB processes (25GB malloced) and the processes jus > t > > > walk the memory over and over. This is on a 256GB main memory machine > > > (2 socket haswell, 28 cpus, 28 1TB SSDs, on loan from Netflix). > > > > How many times do processes walk their memory before this condition > > occurs? > > Until free memory goes to ~0. That's the point, I'm trying to > improve things when there is too much pressure on memory. You said 10x25GB but you have 256GB. So there is still 6GB left... > > > So what may be happening is that a process references a page, > > it page faults, the kernel finds its phys page has been paged > > out, so it looks for a free page and once a free page is > > found, the process will block on page in. Or if there is no > > free page, it has to wait until some other dirty page is paged > > out (but this would be a different wait queue). As more and > > more processes do this, the system runs out of all free pages. > > Yeah. > > > Can you find out how many processes are waiting under what > > conditions, how long they wait and how these queue lengths are > > changing over time? > > So I have 10 processes, they all run until the system starts to > thrash, then they are all in wait mode for memory but there isn't > any (and there is no swap configured). > > The fundamental problem is that they are sleeping waiting for memory to > be freed. They are NOT in I/O mode, there is no DMA happening, this is > main memory, it is not backed by swap, there is no swap. So they are > sleeping waiting for the pageout daemon to free some memory. It's not > going to free their memory because there is no place to stash (no swap). > So it's trying to free other memory. This confuses me. Before I make more false assumptions, can you show the code? > The real question is where did they go to sleep and why did they sleep > without PCATCH on? If I can find that place where they are trying to > alloc a page and failed and they go to sleep there, I could either Can you use kgdb to find out where they sleep? > a) commit seppuku because we are out of memory and I'm part of the problem > b) go into a sleep / wakeup / check signals loop > > I am reminded by you all that we ask the process to do it to itself but > there does seem to be a way to sleep and respect signals, the tty stuff > does that. So if I can find this place, determine that I'm just asking > for memory, not I/O, and sleep with PCATCH on then I might be golden. Won't kgdb tell you? Or you can insert printfs. You should also print something in your program as it walks a few pages and see if this happens at almost the same time (when all pages are used up). tty code probably assumes memory shortfall is a short term issue (which is likely). Not the case with your test (unless I misguessed). > Where "golden" means I can kill the process and the OOM thread could do > it for me. > > Thoughts? Now I am starting to think this happens as soon as all the phys pages are used up. But looking at your program would help. [removd cc: TUHS] From tytso at mit.edu Sun Dec 3 00:59:52 2017 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 2 Dec 2017 09:59:52 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171201230934.GA24335@mcvoy.com> References: <20171201154448.GL3924@mcvoy.com> <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> Message-ID: <20171202145952.m4v76unuz5vbw4e5@thunk.org> On Fri, Dec 01, 2017 at 03:09:34PM -0800, Larry McVoy wrote: > > It's the old "10 pounds of shit in a 5 pound bag" problem, same old stuff, > just a bigger bag. > > The problem is that OOM can't kill the processes that are the problem, > they are stuck in disk wait. That's why I started asking why can't you > kill a process that's in the middle of I/O. You may need to solve the problem much earlier, by write throttling the process which is generating so many dirty pages in the first place. At one point Linux would press-gang the badly behaved process which was generating lots of dirty pages into helping to deactivate and clean pages; it doesn't do this any more, but stopping processes which are being badly behaved until the writeback daemons can catch up is certainly kinder than OOM-killing the bad process. Are you using ZFS? It does have a write throttling knob, apparently. - Ted From ralph at inputplus.co.uk Sun Dec 3 23:50:18 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sun, 03 Dec 2017 13:50:18 +0000 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171202004850.GB24335@mcvoy.com> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> Message-ID: <20171203135018.D01CA1F977@orac.inputplus.co.uk> Hi Larry, > The fundamental problem is that they are sleeping waiting for memory > to be freed. They are NOT in I/O mode, there is no DMA happening, > this is main memory, it is not backed by swap, there is no swap. So > they are sleeping waiting for the pageout daemon to free some memory. > It's not going to free their memory because there is no place to stash > (no swap). So it's trying to free other memory. Right. > The real question is where did they go to sleep Reading through from vm_fault(), is it vm_waitpfault()? http://fxr.watson.org/fxr/source/vm/vm_page.c?im=3?v=FREEBSD55#L2749 Or, chase down where some of sysctl(3)'s CTL_VM constants are used to see how their behaviour is effected? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From arnold at skeeve.com Tue Dec 5 02:36:15 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 04 Dec 2017 09:36:15 -0700 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <20171202004850.GB24335@mcvoy.com> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> Message-ID: <201712041636.vB4GaFEp017803@freefriends.org> Larry McVoy wrote: > So I have 10 processes, they all run until the system starts to > thrash, then they are all in wait mode for memory but there isn't > any (and there is no swap configured). Um, pardon me for asking the obvious question, but why not just configure a few gigs of swap to give the OS some breathing room? Most modern systems let you use a regular old file in the filesystem for swap space, instead of having to repartition your disk and using a dedicated partition. I'd be suprised if your *BSD box didn't let you do that too. It's a little slower, but a gazillion times more convenient. Just a thought, Arnold From krewat at kilonet.net Tue Dec 5 02:58:20 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 4 Dec 2017 11:58:20 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <201712041636.vB4GaFEp017803@freefriends.org> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> Message-ID: <1348e3ef-9bb3-ad85-6a84-ad8bec0f887f@kilonet.net> I've had some strange experiences with Solaris 11, where if I didn't have enough swap, I'd get OOM issues with Oracle databases (SGA) on startup and other various things. While Oracle docs say it's OK to have a small swap area if you have plenty of RAM, I've experienced the exact opposite. If the ZFS arc is large (and it always is), and something needs memory, if there isn't enough swap to "guarantee" the allocation, the allocation will fail. (Disregarding the fact that the ZFS arc can be tuned, and now Solaris 11.3 has an even better setting, user_reserve_hint_pct). It won't wait to flush out ZFS arc to make room, it'll just fail outright. With a huge swap area that's at least half the size of RAM (in boxes that range from 96GB to 256GB), even though it'll never touch the swap, it works just fine. Now, I understand your issue is with BSD, but if it's ZFS, perhaps there's something not-so-different about the two environments. $.02 On 12/4/2017 11:36 AM, arnold at skeeve.com wrote: > Larry McVoy wrote: > >> So I have 10 processes, they all run until the system starts to >> thrash, then they are all in wait mode for memory but there isn't >> any (and there is no swap configured). > Um, pardon me for asking the obvious question, but why not just configure > a few gigs of swap to give the OS some breathing room? > > Most modern systems let you use a regular old file in the filesystem > for swap space, instead of having to repartition your disk and using a > dedicated partition. I'd be suprised if your *BSD box didn't let you do > that too. It's a little slower, but a gazillion times more convenient. > > Just a thought, > > Arnold > From imp at bsdimp.com Tue Dec 5 03:19:19 2017 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Dec 2017 10:19:19 -0700 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <201712041636.vB4GaFEp017803@freefriends.org> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> Message-ID: On Mon, Dec 4, 2017 at 9:36 AM, wrote: > Larry McVoy wrote: > > > So I have 10 processes, they all run until the system starts to > > thrash, then they are all in wait mode for memory but there isn't > > any (and there is no swap configured). > > Um, pardon me for asking the obvious question, but why not just configure > a few gigs of swap to give the OS some breathing room? > > Most modern systems let you use a regular old file in the filesystem > for swap space, instead of having to repartition your disk and using a > dedicated partition. I'd be suprised if your *BSD box didn't let you do > that too. It's a little slower, but a gazillion times more convenient. > The deployed systems in the field have swap space configured. But if we're not careful we can still run out. Larry's tests are at the extreme limits, to be sure, and not having swap exacerbates the bad behavior at the limit. If he's trying to ameliorate bad effects, doing it on worst case scenario certainly helps. The BSD box allows for it, and it's not that much slower, but it kinda misses the point of the exercise. Also, the systems in questions often operate at the limits of the disk subsystem, so additional write traffic is undesirable. They are also SSDs, so doubly undesirable where avoidable. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Dec 5 08:07:13 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 5 Dec 2017 09:07:13 +1100 (EST) Subject: [TUHS] signals and blocked in I/O In-Reply-To: <201712041636.vB4GaFEp017803@freefriends.org> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> Message-ID: On Mon, 4 Dec 2017, arnold at skeeve.com wrote: > Most modern systems let you use a regular old file in the filesystem for > swap space, instead of having to repartition your disk and using a > dedicated partition. I'd be suprised if your *BSD box didn't let you do > that too. It's a little slower, but a gazillion times more convenient. Doesn't it have to be a contiguous file (for DMA), or is scatter/gather now supported? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ron at ronnatalie.com Tue Dec 5 08:54:15 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Mon, 4 Dec 2017 17:54:15 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> Message-ID: <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> Nothing says a page has to be loaded in one DMA. The swap file isn't allocated any different than any other file on the LINUX systems. About the only thing you have to do is make sure that all the blocks are populated. UNIX normally allocates the files as sparse and the swap code doesn't want to have to worry about allocating blocks when it comes to paging out. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave Horsfall Sent: Monday, December 4, 2017 5:07 PM To: The Eunuchs Hysterical Society Subject: Re: [TUHS] signals and blocked in I/O On Mon, 4 Dec 2017, arnold at skeeve.com wrote: > Most modern systems let you use a regular old file in the filesystem > for swap space, instead of having to repartition your disk and using a > dedicated partition. I'd be suprised if your *BSD box didn't let you > do that too. It's a little slower, but a gazillion times more convenient. Doesn't it have to be a contiguous file (for DMA), or is scatter/gather now supported? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Tue Dec 5 08:56:22 2017 From: imp at bsdimp.com (Warner Losh) Date: Mon, 4 Dec 2017 15:56:22 -0700 Subject: [TUHS] signals and blocked in I/O In-Reply-To: <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> Message-ID: Pages are pages. The filesystem handles the details for the offset of each one. There's no contiguous on disk requirement. Warner On Mon, Dec 4, 2017 at 3:54 PM, Ron Natalie wrote: > Nothing says a page has to be loaded in one DMA. The swap file isn't > allocated any different than any other file on the LINUX systems. About > the only thing you have to do is make > sure that all the blocks are populated. UNIX normally allocates the > files > as sparse and the swap code doesn't want to have to worry about allocating > blocks when it comes to paging out. > > > > -----Original Message----- > From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave > Horsfall > Sent: Monday, December 4, 2017 5:07 PM > To: The Eunuchs Hysterical Society > Subject: Re: [TUHS] signals and blocked in I/O > > On Mon, 4 Dec 2017, arnold at skeeve.com wrote: > > > Most modern systems let you use a regular old file in the filesystem > > for swap space, instead of having to repartition your disk and using a > > dedicated partition. I'd be suprised if your *BSD box didn't let you > > do that too. It's a little slower, but a gazillion times more > convenient. > > Doesn't it have to be a contiguous file (for DMA), or is scatter/gather now > supported? > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will > suffer." > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Tue Dec 5 09:06:23 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 5 Dec 2017 10:06:23 +1100 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: The ARPAnet reached four nodes on this day in 1969 (anyone know which?); at least one "history" site reckoned the third node was connected in 1977 (and I'm still waiting for a reply to my correction). Well, I can believe that perhaps there were only three left by then... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From nobozo at gmail.com Tue Dec 5 09:14:29 2017 From: nobozo at gmail.com (Jon Forrest) Date: Mon, 4 Dec 2017 15:14:29 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: <6ea322da-80e0-01b1-5fc4-1b78b740125a@gmail.com> On 12/4/2017 3:06 PM, Dave Horsfall wrote: > The ARPAnet reached four nodes on this day in 1969 (anyone know which?); > at least one "history" site reckoned the third node was connected in > 1977 (and I'm still waiting for a reply to my correction).  Well, I can > believe that perhaps there were only three left by then... One of the original 4 was my Alma Mater, UC Santa Barbara. I can say that even though it was one of the first four, its presence wasn't well known and nobody outside a select few in EE knew it was there. Jon Forrest From jnc at mercury.lcs.mit.edu Tue Dec 5 09:42:39 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Dec 2017 18:42:39 -0500 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: <20171204234239.8542A18C087@mercury.lcs.mit.edu> > From: Dave Horsfall > The ARPAnet reached four nodes on this day in 1969 (anyone know which?) SRI, UCSD, UCLA, Utah: http://www.chiappa.net/~jnc/tech/arpageo.html All West Coast, plus Utah. Next was BBN; if you look at the IMP numbers, in HOSTS.TXT, they were assigned in order of installation. > at least one "history" site reckoned the third node was connected in > 1977 ... Well, I can believe that perhaps there were only three left by > then... No: http://www.chiappa.net/~jnc/tech/arpalog.html 1977 was not too many years before the peak in size (with the MILNET split coming in October, 1983). Per: http://www.chiappa.net/~jnc/tech/arpanet.html "Prior to the split, in 1983, there were 113 IMPs in the ARPANET; after the ARPANET/MILNET split, the MILNET consisted of 65 nodes, leaving the ARPANET with 68 nodes." Noel From jnc at mercury.lcs.mit.edu Tue Dec 5 09:44:49 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Dec 2017 18:44:49 -0500 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: <20171204234449.D210618C087@mercury.lcs.mit.edu> > SRI, UCSD, UCLA, Utah: Ooops, typo: UCS_B_. Noel From dscherrer at solar.stanford.edu Tue Dec 5 09:18:14 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 4 Dec 2017 15:18:14 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <6ea322da-80e0-01b1-5fc4-1b78b740125a@gmail.com> References: <6ea322da-80e0-01b1-5fc4-1b78b740125a@gmail.com> Message-ID: <7e135409-58d1-5e0e-1e75-8e195e88554f@solar.stanford.edu> Don't know about nodes, but the initial research on the arpanet was done at Lawrence Berkeley Lab. The primary goal of the project was for scientists to share data. But, alas, the scientists didn't want to share data. And, there were so many data formats that nobody could read each other's anyway. So we ranked the arpanet as a failure for that item. However, we found that it seemed to be incredibly useful for communications amongst people, i.e. email... Debbie On 12/4/17 3:14 PM, Jon Forrest wrote: > > > On 12/4/2017 3:06 PM, Dave Horsfall wrote: >> The ARPAnet reached four nodes on this day in 1969 (anyone know >> which?); at least one "history" site reckoned the third node was >> connected in 1977 (and I'm still waiting for a reply to my >> correction). Well, I can believe that perhaps there were only three >> left by then... > > One of the original 4 was my Alma Mater, UC Santa Barbara. I can > say that even though it was one of the first four, its presence wasn't > well known and nobody outside a select few in EE knew it was there. > > Jon Forrest > From dave at horsfall.org Tue Dec 5 10:49:28 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 5 Dec 2017 11:49:28 +1100 (EST) Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> Message-ID: On Mon, 4 Dec 2017, Warner Losh wrote: [ Swap files ] > Pages are pages. The filesystem handles the details for the offset of > each one. There's no contiguous on disk requirement. I've used at least one *ix OS that required it be both contiguous and pre-allocated; Slowaris? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From krewat at kilonet.net Tue Dec 5 10:58:54 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 4 Dec 2017 19:58:54 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> Message-ID: <7c7b34b5-0a5c-3080-6cd0-ff451c2f162d@kilonet.net> On 12/4/2017 7:49 PM, Dave Horsfall wrote: > On Mon, 4 Dec 2017, Warner Losh wrote: > > [ Swap files ] > >> Pages are pages. The filesystem handles the details for the offset of >> each one. There's no contiguous on disk requirement. > > I've used at least one *ix OS that required it be both contiguous and > pre-allocated; Slowaris? > Nope, unless mkfile is is guaranteed to give you contiguous space: # uname -a SunOS vmsol8 5.8 Generic_108529-05 i86pc i386 i86pc # mkfile 100m a.a # swap -a /a.a # swap -l swapfile             dev  swaplo blocks   free /dev/dsk/c0d0s1     102,1       8 1048936 1048896 /a.a                  -        8 204792 204792 From doug at cs.dartmouth.edu Tue Dec 5 11:01:32 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 05 Dec 2017 01:01:32 -0000 Subject: [TUHS] 80 columns Message-ID: <201711082329.vA8NTcNP026158@coolidge.cs.Dartmouth.EDU> > I do recall 80 column monitors, but I started on 132 column decwriter > IIs and hence have never had sympathy for 80 columns. It's weird that so Interesting. I wonder if that's where the 132 column (alternative) standard came from. No. IBM's printers were 132 columns even before stored-program computers. From jnc at mercury.lcs.mit.edu Tue Dec 5 11:05:20 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Dec 2017 20:05:20 -0500 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: <20171205010520.2C91C18C087@mercury.lcs.mit.edu> > From: Deborah Scherrer > the initial research on the arpanet was done at Lawrence Berkeley Lab I was interested to find out more about this: I looked in Hafner, "Where Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET) but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did have Lawrence Livermore); there were a couple of 'Californa, University of (at Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet" (the first half of which covers the ARPANET), nothing under any of 'Lawrence Berkeley', 'LBL', 'Berkeley' or 'California'. In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA history, which has extensive coverage of the ARPANET project), there was one entry for 'Californa, University (Berkeley)', which might be about the work you refer to: "IPTO issued a contract for a 'network' project at the Berkeley campus of the University of California ... because of the presence at Berkeley of specialists in programming languages and heuristic programming". But there's nothing about what was produced. Is there anything you can point me at that provides more detail? Thanks! Noel From nobozo at gmail.com Tue Dec 5 11:38:00 2017 From: nobozo at gmail.com (Jon Forrest) Date: Mon, 4 Dec 2017 17:38:00 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <20171205010520.2C91C18C087@mercury.lcs.mit.edu> References: <20171205010520.2C91C18C087@mercury.lcs.mit.edu> Message-ID: <8596f8bf-a1ba-7ed8-dd32-8c6e5c97b666@gmail.com> On 12/4/2017 5:05 PM, Noel Chiappa wrote: > > From: Deborah Scherrer > > > the initial research on the arpanet was done at Lawrence Berkeley Lab I'm also skeptical about this claim, although it could depend on what "initial research" means. I believe LBL did work on early TCP implementations, the conversion from NCP to TCP, and the early "software tools" movement. (I was there for a year in 1988 and had the office next to Cliff Stoll when he was doing the Cookoo's Egg work, but that's another story). Jon From dscherrer at solar.stanford.edu Tue Dec 5 11:13:20 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 4 Dec 2017 17:13:20 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <20171205010520.2C91C18C087@mercury.lcs.mit.edu> References: <20171205010520.2C91C18C087@mercury.lcs.mit.edu> Message-ID: <1afac5da-82db-489d-320f-e3eb74f67216@solar.stanford.edu> LBL was part of UC Berkeley. We were funded by DOE, who was working with DARPA. But we were UC employees. LBL had a contract with DOE/DARPA to evaluate an early version of the the arpanet. I was just getting started at that time, so only slightly involved. The people I remember were Dennis Hall, Joe Sventek, Carl Quong & several other guys in EE. A lot of the TCP/IP development was done at the Lab. We also worked heavily with the CS people on campus. I think this was before Kirk McKusick, Bill Joy, et al. Debbie On 12/4/17 5:05 PM, Noel Chiappa wrote: > > From: Deborah Scherrer > > > the initial research on the arpanet was done at Lawrence Berkeley Lab > > I was interested to find out more about this: I looked in Hafner, "Where > Wizards Stay Up Late" (the popular, but well-researched, book on the ARPANET) > but couldn't find 'Lawrence Berkeley' or 'LBL' in the index (although it did > have Lawrence Livermore); there were a couple of 'Californa, University of (at > Berkeley' listings, but none covered this. In Abbate, "Inventing the Internet" > (the first half of which covers the ARPANET), nothing under any of 'Lawrence > Berkeley', 'LBL', 'Berkeley' or 'California'. > > In Norberg/O'Neill, "Transforming Computer Technology" (the standard ARPA > history, which has extensive coverage of the ARPANET project), there was one > entry for 'Californa, University (Berkeley)', which might be about the work > you refer to: > > "IPTO issued a contract for a 'network' project at the Berkeley campus of > the University of California ... because of the presence at Berkeley of > specialists in programming languages and heuristic programming". > > But there's nothing about what was produced. Is there anything you can point > me at that provides more detail? Thanks! > > Noel From dscherrer at solar.stanford.edu Tue Dec 5 11:56:58 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 4 Dec 2017 17:56:58 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <8596f8bf-a1ba-7ed8-dd32-8c6e5c97b666@gmail.com> References: <20171205010520.2C91C18C087@mercury.lcs.mit.edu> <8596f8bf-a1ba-7ed8-dd32-8c6e5c97b666@gmail.com> Message-ID: <7f65ef5a-c198-d252-596b-07ce79f8983e@solar.stanford.edu> This was looooong before Cliff Stoll. I worked at LBL for 14 years, in the Computer Science & Applied Math (CSAM) group. Don't remember the exact dates this was happening, but something like late 60s - early 70s. I remember discussing with Dennis Hall the report back to DARPA that emphasized no value for data transfer but high value for communications. (Unfortunately, Dennis is gone now.) We even had a "demonstration" for DARPA. However, the nodes we needed in a couple places weren't in those places yet, so we "simulated" a response by having something in, say, San Francisco receive an internet request, read it with their eyes, then type in a response. ;-) At least DARPA folks were told this was a simulation. Deborah On 12/4/17 5:38 PM, Jon Forrest wrote: > > > On 12/4/2017 5:05 PM, Noel Chiappa wrote: >> > From: Deborah Scherrer >> >> > the initial research on the arpanet was done at Lawrence >> Berkeley Lab > > I'm also skeptical about this claim, although it could depend on > what "initial research" means. I believe LBL did work on early TCP > implementations, the conversion from NCP to TCP, and the early "software > tools" movement. (I was there for a year in 1988 and had the office next > to Cliff Stoll when he was doing the Cookoo's Egg work, but that's > another story). > > Jon > From bakul at bitblocks.com Tue Dec 5 12:12:12 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 04 Dec 2017 18:12:12 -0800 Subject: [TUHS] signals and blocked in I/O In-Reply-To: Your message of "Mon, 04 Dec 2017 10:19:19 -0700." References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> Message-ID: <20171205021228.189EA156E523@mail.bitblocks.com> On Mon, 04 Dec 2017 10:19:19 -0700 Warner Losh wrote: Warner Losh writes: > > On Mon, Dec 4, 2017 at 9:36 AM, wrote: > > > Larry McVoy wrote: > > > > > So I have 10 processes, they all run until the system starts to > > > thrash, then they are all in wait mode for memory but there isn't > > > any (and there is no swap configured). > > > > Um, pardon me for asking the obvious question, but why not just configure > > a few gigs of swap to give the OS some breathing room? > > > > Most modern systems let you use a regular old file in the filesystem > > for swap space, instead of having to repartition your disk and using a > > dedicated partition. I'd be suprised if your *BSD box didn't let you do > > that too. It's a little slower, but a gazillion times more convenient. > > The deployed systems in the field have swap space configured. But if we're > not careful we can still run out. Larry's tests are at the extreme limits, > to be sure, and not having swap exacerbates the bad behavior at the limit. Conceptually they are somewhat different cases. 1) In the no-swap case *no* pages will be available once all the phys pages are used up. To recover, the kernel must free up space by killing some process. 2) In the swap case pages will eventually be available. The paging rate becomes the bottleneck but no need to kill any process. In case 1) there may be other disk traffic to confuse things. But eventually that should die down. However I am not sure FreeBSD has a clean way to indicate there are no free pages. It calls OOM logic as a last resort. In case 2) OOM should never be called. I think the issue is that the kernel is unable to kill a process that is waiting for a free page. Since all of them are doing the same thing, the system hangs. I think this wait has to be made interruptable to be able to kill a process. Of course that may break something else.... May be better to avoid the whole issue in the first place for a service latency sensitive production machine. By providing a way for a process to ask that there is enough backing store for any mmaped pages (and thus avoid swapping or running out of memory). Not sure if originally BSD did provide such a guarantee... > If he's trying to ameliorate bad effects, doing it on worst case scenario > certainly helps. The BSD box allows for it, and it's not that much slower, > but it kinda misses the point of the exercise. > Also, the systems in questions often operate at the limits of the disk > subsystem, so additional write traffic is undesirable. They are also SSDs, > so doubly undesirable where avoidable. This can be tested by writing some custom logic: instead of writing out a page, compress it and stash in memory (or ramdisk). The test can write highly compressable patterns. From dave at horsfall.org Tue Dec 5 12:15:00 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 5 Dec 2017 13:15:00 +1100 (EST) Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> Message-ID: On Tue, 5 Dec 2017, Dave Horsfall wrote: > I've used at least one *ix OS that required it be both contiguous and > pre-allocated; Slowaris? OK, likely not, but I've used literally dozens of systems[*] over the last 40 years or so; this one was definitely Unix-ish (otherwise I wouldn't've used it) and it definitely required a contiguous file for ease of DMA. Wish I could remember it, but the ol' memory is one of the first things to go when in your 60s, and I never could remember what comes afterwards... [*] Pretty much AIX to Xenix (when you pronounce it with a "Z"). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jnc at mercury.lcs.mit.edu Tue Dec 5 12:52:39 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Dec 2017 21:52:39 -0500 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: <20171205025239.F02E418C087@mercury.lcs.mit.edu> > From: Deborah Scherrer > A lot of the TCP/IP development was done at the Lab. I think this is incorrect. The "Birth of the Internet" plaque: http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg mentions a number of organizations, but not UCB. Also, if you look at early TCP/IP Meeting Notes, which list all the meeting attendees, e.g.: http://www.postel.org/ien/txt/ien3.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien134.txt http://www.postel.org/ien/txt/ien121.txt http://www.postel.org/ien/txt/ien160.txt http://www.postel.org/ien/txt/ien175.txt (plus a bunch more only available in PDF form here: http://www.postel.org/ien/pdf which I couldn't be bothered to look at, since they are huge scans which take a while to download - see the IEN Index for the numbers) you won't find anyone from UCB listed in any of them. Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but it had nothing to do with the "development" of TCP/IP. Noel From clemc at ccc.com Tue Dec 5 12:54:21 2017 From: clemc at ccc.com (Clem cole) Date: Mon, 4 Dec 2017 21:54:21 -0500 Subject: [TUHS] signals and blocked in I/O In-Reply-To: References: <20171201161810.GM3924@mcvoy.com> <20171201172603.GO3924@mcvoy.com> <20171201223859.GX3924@mcvoy.com> <20171201230302.0DC351FA41@orac.inputplus.co.uk> <20171201230934.GA24335@mcvoy.com> <20171201234230.F33D4156E523@mail.bitblocks.com> <20171202004850.GB24335@mcvoy.com> <201712041636.vB4GaFEp017803@freefriends.org> <01db01d36d52$cffe9430$6ffbbc90$@ronnatalie.com> Message-ID: I can not speak for others but both Masscomp’s Real Time Unix and Stellar’s Stellix supported contiguous files and could swap to them. And yes they were preallocated at creat(2) time. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 4, 2017, at 9:15 PM, Dave Horsfall wrote: > >> On Tue, 5 Dec 2017, Dave Horsfall wrote: >> >> I've used at least one *ix OS that required it be both contiguous and pre-allocated; Slowaris? > > OK, likely not, but I've used literally dozens of systems[*] over the last 40 years or so; this one was definitely Unix-ish (otherwise I wouldn't've used it) and it definitely required a contiguous file for ease of DMA. > > Wish I could remember it, but the ol' memory is one of the first things to go when in your 60s, and I never could remember what comes afterwards... > > [*] > Pretty much AIX to Xenix (when you pronounce it with a "Z"). > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dscherrer at solar.stanford.edu Tue Dec 5 13:10:27 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 4 Dec 2017 19:10:27 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <20171205025239.F02E418C087@mercury.lcs.mit.edu> References: <20171205025239.F02E418C087@mercury.lcs.mit.edu> Message-ID: <95a27cf3-a26c-b070-765e-665f54d02117@solar.stanford.edu> I don't know about the historical record. But everything I said is true, based on my own personal experience. Why would I misrepresent? I was there, this happened. If people didn't write it down, I don't know why. D On 12/4/17 6:52 PM, Noel Chiappa wrote: > > From: Deborah Scherrer > > > A lot of the TCP/IP development was done at the Lab. > > I think this is incorrect. The "Birth of the Internet" plaque: > > http://ana-3.lcs.mit.edu/~jnc/history/BirthInternetL.jpg > > mentions a number of organizations, but not UCB. > > Also, if you look at early TCP/IP Meeting Notes, which list all the meeting > attendees, e.g.: > > http://www.postel.org/ien/txt/ien3.txt > http://www.postel.org/ien/txt/ien121.txt > http://www.postel.org/ien/txt/ien134.txt > http://www.postel.org/ien/txt/ien121.txt > http://www.postel.org/ien/txt/ien160.txt > http://www.postel.org/ien/txt/ien175.txt > > (plus a bunch more only available in PDF form here: > > http://www.postel.org/ien/pdf > > which I couldn't be bothered to look at, since they are huge scans which take > a while to download - see the IEN Index for the numbers) you won't find anyone > from UCB listed in any of them. > > Berkeley did produce a now-common _implementation_ of TCP/IP, it's true, but > it had nothing to do with the "development" of TCP/IP. > > Noel From jnc at mercury.lcs.mit.edu Tue Dec 5 13:43:49 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Dec 2017 22:43:49 -0500 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: <20171205034349.1D3F518C087@mercury.lcs.mit.edu> > From: Deborah Scherrer > I don't know about the historical record. But everything I said is true, > based on my own personal experience. ... I was there, this happened. If > people didn't write it down, I don't know why. FWIW, I was actually at many of those meetings. (You can find my name in a lot of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved - and the Meeting Notes (which, you will note, are quite detailed) indicate the same thing. (Later on, of course, Van Jacobson of LBL did some imporant work on TCP congestion control, but that was in '87 or so - I can't instantly lay my hands on my copy of Van's famous e-mail, to get a more exact date - some years after the full-scale deployment of TCP/IP in January, 1983.) > Why would I misrepresent? Perhaps you are conflating several different things in your memory? Human memory is very fallible, which is why historians prefer contemporary documents (and even those sometimes have errors). Here: http://www.chiappa.net/~jnc/nontech/tmlotus.html is a mildly amusing example (from a completely different arena) of all that. Noel From dscherrer at solar.stanford.edu Tue Dec 5 13:46:21 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 4 Dec 2017 19:46:21 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <20171205034349.1D3F518C087@mercury.lcs.mit.edu> References: <20171205034349.1D3F518C087@mercury.lcs.mit.edu> Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70@solar.stanford.edu> Yes, Van Jacobson was involved. Great guy. So sorry you feel the need to think I am lying. Why would I make up this stuff? I was a teeny tiny piece of it. Doesn't affect my career one way or other. I don't care what you believe, but this really did happen. D On 12/4/17 7:43 PM, Noel Chiappa wrote: > > From: Deborah Scherrer > > > I don't know about the historical record. But everything I said is true, > > based on my own personal experience. ... I was there, this happened. If > > people didn't write it down, I don't know why. > > FWIW, I was actually at many of those meetings. (You can find my name in a lot > of those Meeting Notes.) Nobody from LBL, or UCB in general, was involved - > and the Meeting Notes (which, you will note, are quite detailed) indicate the > same thing. > > (Later on, of course, Van Jacobson of LBL did some imporant work on TCP > congestion control, but that was in '87 or so - I can't instantly lay my hands > on my copy of Van's famous e-mail, to get a more exact date - some years after > the full-scale deployment of TCP/IP in January, 1983.) > > > Why would I misrepresent? > > Perhaps you are conflating several different things in your memory? Human > memory is very fallible, which is why historians prefer contemporary documents > (and even those sometimes have errors). Here: > > http://www.chiappa.net/~jnc/nontech/tmlotus.html > > is a mildly amusing example (from a completely different arena) of all that. > > Noel From crossd at gmail.com Tue Dec 5 13:49:14 2017 From: crossd at gmail.com (Dan Cross) Date: Mon, 4 Dec 2017 22:49:14 -0500 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <8254fc85-12e6-4730-8f14-faf060ad6a70@solar.stanford.edu> References: <20171205034349.1D3F518C087@mercury.lcs.mit.edu> <8254fc85-12e6-4730-8f14-faf060ad6a70@solar.stanford.edu> Message-ID: On Mon, Dec 4, 2017 at 10:46 PM, Deborah Scherrer < dscherrer at solar.stanford.edu> wrote: > [...] So sorry you feel the need to think I am lying. [...] I don't think anyone is suggesting that anyone else is lying. People can make mistakes (one way or another) without it being a lie. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Tue Dec 5 18:14:29 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 5 Dec 2017 09:14:29 +0100 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: <3AE304EA-6742-4558-A98A-3E2C1601BE67@planet.nl> I don’t think anybody was thinking you wilfully misrepresented things, it is always interesting to hear about strands of history that might have been missed earlier. It would be helpful to better understand the time period, people involved and the scope of work. I’m a bit confused as to what time period you are referring to: I think you are referring to the initial development of Arpanet, i.e. the second half of the sixties. Is that correct? There is a page here with some info on events in that period and it may have missed some interesting development work done at LBL: https://www.livinginternet.com/i/ii_roberts.htm Paul > > Message: 7 > Date: Mon, 4 Dec 2017 19:46:21 -0800 > From: Deborah Scherrer > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] ARPAnet now 4 nodes > Message-ID: <8254fc85-12e6-4730-8f14-faf060ad6a70 at solar.stanford.edu> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Yes, Van Jacobson was involved. Great guy. So sorry you feel the need > to think I am lying. Why would I make up this stuff? I was a > teeny tiny piece of it. Doesn't affect my career one way or other. I > don't care what you believe, but this really did happen. > > D From pnr at planet.nl Tue Dec 5 18:24:30 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 5 Dec 2017 09:24:30 +0100 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl> This page: http://www2.lbl.gov/Publications/75th/files/exhibit.html mentions 3 links between LBL and Arpanet: - In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor. - In 1986, when the Internet was on the verge of collapse from congestion, a Berkeley Lab researcher, Van Jacobson, co-developed the congestion control algorithms that allowed the Internet to keep growing. - In 1995, Jacobson and Steven McCanne developed MBone, the first successful software for multiparty audio and video conferencing over the Internet. From steffen at sdaoden.eu Tue Dec 5 23:22:11 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 05 Dec 2017 14:22:11 +0100 Subject: [TUHS] Dash options In-Reply-To: <20171204215701.l9Pvr%steffen@sdaoden.eu> References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com> <20171128062845.GB5277@eureka.lemis.com> <20171129191643.XPHH3%steffen@sdaoden.eu> <20171204054651.GA17671@eureka.lemis.com> <20171204215701.l9Pvr%steffen@sdaoden.eu> Message-ID: <20171205132211.gYVHH%steffen@sdaoden.eu> Hello. ||On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote: ||> Greg 'groggy' Lehey wrote: ||>> On Monday, 27 November 2017 at 21:51:13 -0800, Jon Steinhart wrote: ||>>> Does anybody know the history of dash options? Were they ||>>> a UNIX thing or did UNIX borrow them from something earlier? ||>> ||>> If you mean specificall the dash, I can't help much. But there were ||>> similar ideas elsewhere. UNIVAC EXEC-8 (for the 1108, late 1960s) had ||>> options that followed the command with a comma, like: ||>> ||>> @RUN,G GOPU,STANDARD,STANDARD ||>> @ADD,PL ASGDMS . ASSIGNIERT DATENBASIS ||> ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS" ... ||>> @ASG,A PF. . PF IST PROGRAMM-FILE MIT GOPU ||> ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so. ... I have apologised for this brusque and rude tone in private. Unfortunately Greg Lehey was the one who took up that thread. Puh; he is also right correcting my statements, it should have been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU" instead of what i falsely claimed. |The question that should have been asked with mild interest and |very kind should have been "Why has German been used to comment |this code?" at first, i am afraid to realize. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From nobozo at gmail.com Wed Dec 6 00:46:01 2017 From: nobozo at gmail.com (Jon Forrest) Date: Tue, 5 Dec 2017 06:46:01 -0800 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl> References: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl> Message-ID: Another clarification - LBL has never been part of UC Berkeley. It's (always?) been a Department of Energy laboratory managed by the Univ. of California. On the other hand, many people, due the close proximity of LBL to UC Berkeley, have appointments at both places so it can be hard to recognize which place somebody was working at when certain research was done. For example, both Van Jacobson and Steve McCanne had affiliations with LBL and UC Berkeley. Jon From ches at cheswick.com Wed Dec 6 00:52:17 2017 From: ches at cheswick.com (William Cheswick) Date: Tue, 5 Dec 2017 09:52:17 -0500 Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl> References: <5DC50DA3-0165-4139-AA3A-30FCA569C2FD@planet.nl> Message-ID: I really wonder how the CDC link worked. The channels were electrically strange, and certainly not easily amenable to communicating with anything other than CDC controllers or perhaps a serial line through one of the front ends. I did hear of a proposal at NADC around 1977 to try to hook into telnet and ftp from a CDC using some hack of the serial stuff. The idea didn’t impress me: it would have taken a lot of hacking to get a kludge working. It always took a lot to make CDC hardware play well with others. > On 5Dec 2017, at 3:24 AM, Paul Ruizendaal wrote: > > - In 1974, the Lab’s CDC 6600 became the first online supercomputer when it was connected to ARPANET, the Internet’s predecessor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 6 01:22:27 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Dec 2017 10:22:27 -0500 (EST) Subject: [TUHS] ARPAnet now 4 nodes Message-ID: <20171205152227.91A6218C08D@mercury.lcs.mit.edu> > From: Jon Forrest > LBL has never been part of UC Berkeley. It's (always?) been a > Department of Energy laboratory managed by the Univ. Actually, I think if you go back far enough (1930's), it was part of UCB, back when Lawrence first started it. And of course the DoE didn't exist until 1977, so during the early ARPANET era if would have been under the AEC, and then I assume the Energy Research and Development Administration after 1974 (I assume it didn't go with the NRC when the AEC was split up). Noel From wkt at tuhs.org Wed Dec 6 08:21:13 2017 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 6 Dec 2017 08:21:13 +1000 Subject: [TUHS] What UNIX Artifacts Are Still Missing? Message-ID: <20171205222113.GA32070@minnie.tuhs.org> All, it's time to nudge the conversation away from debugging 2017 OOM issues and the pre-UNIX history of the Arpanet. We've been able to recover quite a deal of UNIX artifacts in the past two decades, but what artifacts (in your opinion) are still out there that we should try and unearth? Remember that the 50th anniversary is coming up in 2019. Here's my list: - more PDP-7 source code: the shell, the rest of the utilities - more 1st Edition source code: the rest of the utilities - ditto the missing bits of 3rd, 4th and 5th Editions - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?) - more details on who was Ted Bashkow, and the story behind his (+ others?) analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf - a firm date on the day that Ken added pipes to the kernel :) What else should be we looking for? What physical artifacts (drawings, artwork etc.) have we missed that should be sought after? Cheers, Warren From rmswierczek at gmail.com Wed Dec 6 08:38:43 2017 From: rmswierczek at gmail.com (Robert Swierczek) Date: Tue, 5 Dec 2017 17:38:43 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org> References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: I would add the B and NB (New B) compilers and applications. We have the man pages and some tantalizing fragments of the run-time but nothing else including not a single non-trivial application! (that I am aware of) On Tue, Dec 5, 2017 at 5:21 PM, Warren Toomey wrote: > All, it's time to nudge the conversation away from debugging 2017 OOM issues > and the pre-UNIX history of the Arpanet. > > We've been able to recover quite a deal of UNIX artifacts in the past two > decades, but what artifacts (in your opinion) are still out there that > we should try and unearth? Remember that the 50th anniversary is coming up > in 2019. > > Here's my list: > - more PDP-7 source code: the shell, the rest of the utilities > - more 1st Edition source code: the rest of the utilities > - ditto the missing bits of 3rd, 4th and 5th Editions > - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?) > - more details on who was Ted Bashkow, and the story behind his (+ others?) > analysis of the 1st Edition kernel at > http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf > - a firm date on the day that Ken added pipes to the kernel :) > > What else should be we looking for? What physical artifacts (drawings, > artwork etc.) have we missed that should be sought after? > > Cheers, Warren From beebe at math.utah.edu Wed Dec 6 08:45:47 2017 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 5 Dec 2017 15:45:47 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? Message-ID: Warren Toomey asks on Wed, 6 Dec 2017 08:21:13 +1000: >> - more details on who was Ted Bashkow, and the story behind his (+ others?) I found a short obituary at http://engineering.columbia.edu/web/newsletter/spring_2010/memoriam which is, in full: >> ... >> Theodore R. Bashkow Dr. Theodore R. Bashkow, professor emeritus of >> electricial engineering and computer science, died Dec. 23, 2009, at >> his home in Katonah, N.Y. See PDF version >> >> He was born in St. Louis, Mo., and attended Washington University, >> where he received his BS degree in mechanical engineering. He went on >> to receive his master’s and doctorate degrees at Stanford >> University. He served in the U.S. Air Force as a first lieutenant >> during World War II from 1943 to 1945. >> >> While in the Air Force, he served as maintenance officer and helped to >> stage the Enola Gay. In the 1950s, while at Bell Labs, Professor >> Bashkow became well known for his development of a new method for >> analyzing linear electrical networks, Professor Bashkow’s A matrix. He >> also became involved with digital computers. He joined the faculty of >> the Columbia Electrical Engineering Department in 1958 and helped >> transform the Electrical Engineering Department into the Department of >> Electrical Engineering and Computer Science. >> >> When, in 1979, this department was divided into the Electrical >> Engineering and Computer Science departments, Bashkow became one of >> the founding faculty members of Computer Science. He taught courses in >> digital logic, computer organization, and computer programming. He did >> research on parallel processing. In collaboration with Herbert >> Sullivan, he pioneered a new approach to that subject through the >> development of CHoPP, Columbia Homogeneous Parallel Processor, a >> large-scale, homogeneous, fully distributed parallel machine. A number >> of Columbia graduate students and a junior faculty member, David >> Klappholz, were also involved at various stages. >> >> In 1980, the Computer Science Department instituted an annual award in >> his honor, the Theodore R. Bashkow Award. Among his many affiliations, >> Professor Bashkow was an active member of IEEE, ACM, and Sigma Xi >> organizations. >> ... He is apparently not in Wikipedia. I then searched our local bibliography archives and found this publication-title summary (Bashkow is an uncommon name, so I didn't attempt to disambiguate the reported articles): MariaDB [bibtex]> select filename, label, substr(title,1,80) from bibtab where (author like '%Bashkow%') order by year, filename; +-------------------------+--------------------+----------------------------------------------------------------------------------+ | filename | label | substr(title,1,80) | +-------------------------+--------------------+----------------------------------------------------------------------------------+ | jacm.bib | Bashkow:1958:CPR | A ``Curve Plotting'' Routine for the Inverse Laplace Transform of Rational Funct | | ieeetranscomput.bib | Bashkow:1963:RDA | R63-106 The D 825 Automatic Operating and Scheduling Program | | ieeetranscomput.bib | Bashkow:1963:C | Contributors | | ieeetranscomput.bib | Bashkow:1963:PSD | A Programming System for Detection and Diagnosis of Machine Malfunctions | | ieeetranscomput.bib | Bashkow:1964:SCA | A Sequential Circuit for Algebraic Statement Translation | | fortran1.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput.bib | Bashkow:1967:SDF | System Design of a FORTRAN Machine | | ieeetranscomput1970.bib | Bashkow:1971:BSS | B71-6 System Structure in Data, Programs, and Computers | | ieeetranscomput1970.bib | Bashkow:1971:BIC | B71-2 Introduction to Computer Organization | | ieeetranscomput1970.bib | Bashkow:1973:CRO | Comment on Review of Operating Systems Survey | | ovr.bib | Sullivan77b | A Large Scale, Homogeneous, Fully Distributed Parallel Machine | | ovr.bib | Sullivan77a | A Large Scale Homogeneous Fully Distributed Parallel Machine | | sigarch.bib | Sullivan:1977:LSHb | A Large Scale, Homogenous, Fully Distributed Parallel Machine, II | | sigarch.bib | Sullivan:1977:LSHa | A large scale, homogeneous, fully distributed parallel machine, I | | ieeetranscomput1980.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | super.bib | Ghafoor:1989:BFT | Bisectional Fault-Tolerant Communication Architecture for Supercomputer Systems | | ieeetranscomput1990.bib | Ghafoor:1991:SOG | A study of odd graphs as fault-tolerant interconnection networks | +-------------------------+--------------------+----------------------------------------------------------------------------------+ 17 rows in set (2.67 sec) ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From aap at papnet.eu Wed Dec 6 08:55:39 2017 From: aap at papnet.eu (Angelo Papenhoff) Date: Tue, 5 Dec 2017 23:55:39 +0100 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org> References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: <20171205225539.GA48162@indra.papnet.eu> On 06/12/17, Warren Toomey wrote: > All, it's time to nudge the conversation away from debugging 2017 OOM issues > and the pre-UNIX history of the Arpanet. > > We've been able to recover quite a deal of UNIX artifacts in the past two > decades, but what artifacts (in your opinion) are still out there that > we should try and unearth? Remember that the 50th anniversary is coming up > in 2019. > > Here's my list: > - more PDP-7 source code: the shell, the rest of the utilities > - more 1st Edition source code: the rest of the utilities > - ditto the missing bits of 3rd, 4th and 5th Editions > - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any ideas?) > - more details on who was Ted Bashkow, and the story behind his (+ others?) > analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/Distributions/Research/Dennis_v1/PreliminaryUnixImplementationDocument_Jun72.pdf > - a firm date on the day that Ken added pipes to the kernel :) > > What else should be we looking for? What physical artifacts (drawings, > artwork etc.) have we missed that should be sought after? > > Cheers, Warren (Replied off list accidentally, sorry Warren) I totally agree that having more of V2-V4 would be great. Recently, I've become interested in the UNIX development at AT&T. There is SysIII for PDP-11 and VAX and both work in simh. With SysVR1 I only found the PDP-11 version, would be cool to have the VAX version too. But turning to older stuff...there is not much info about the UNICES that were to become SysIII. I'm talking PWB (there is PWB/1.0 in the archive that I will try to get running soon, but I understand there were more versions), CB UNIX (only scans of it it seems) and the elusive UNIX/TS in various versions. I'm aware that these were not released under the ancient UNIX license, however the web source view on TUHS has the source code for SysIII and SysV and most of it can be found on archive.org as well, so the fact that they're not part of the public TUHS archive is a bit weird. BTW, I'm currently putting together installation instructions for various old UNICES on http://a.papnet.eu/UNIX/. And I also ported aiju's blit emulator to Unix recently (ran on plan 9 originally): https://github.com/aap/blit So have fun running v8 with this. aap From dave at horsfall.org Wed Dec 6 09:03:34 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 6 Dec 2017 10:03:34 +1100 (EST) Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org> References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: Is the source (and/or hardware description) for Belle available anywhere? I know that the box itself is at the Smithsonian. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Wed Dec 6 09:06:46 2017 From: imp at bsdimp.com (Warner Losh) Date: Tue, 5 Dec 2017 16:06:46 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171205225539.GA48162@indra.papnet.eu> References: <20171205222113.GA32070@minnie.tuhs.org> <20171205225539.GA48162@indra.papnet.eu> Message-ID: Venix/86 and Venix/86R might be interesting... I have impure versions of both... Warner On Tue, Dec 5, 2017 at 3:55 PM, Angelo Papenhoff wrote: > On 06/12/17, Warren Toomey wrote: > > All, it's time to nudge the conversation away from debugging 2017 OOM > issues > > and the pre-UNIX history of the Arpanet. > > > > We've been able to recover quite a deal of UNIX artifacts in the past two > > decades, but what artifacts (in your opinion) are still out there that > > we should try and unearth? Remember that the 50th anniversary is coming > up > > in 2019. > > > > Here's my list: > > - more PDP-7 source code: the shell, the rest of the utilities > > - more 1st Edition source code: the rest of the utilities > > - ditto the missing bits of 3rd, 4th and 5th Editions > > - the Phil Foglio artwork that became a Usenix t-shirt (Armando, any > ideas?) > > - more details on who was Ted Bashkow, and the story behind his (+ > others?) > > analysis of the 1st Edition kernel at http://www.tuhs.org/Archive/ > Distributions/Research/Dennis_v1/PreliminaryUnixImplementationD > ocument_Jun72.pdf > > - a firm date on the day that Ken added pipes to the kernel :) > > > > What else should be we looking for? What physical artifacts (drawings, > > artwork etc.) have we missed that should be sought after? > > > > Cheers, Warren > > (Replied off list accidentally, sorry Warren) > > I totally agree that having more of V2-V4 would be great. > > Recently, I've become interested in the UNIX development at AT&T. > There is SysIII for PDP-11 and VAX and both work in simh. > With SysVR1 I only found the PDP-11 version, would be cool to have the > VAX version too. But turning to older stuff...there is not much info > about the UNICES that were to become SysIII. I'm talking PWB (there is > PWB/1.0 in the archive that I will try to get running soon, but I > understand there were more versions), CB UNIX (only scans of it it > seems) and the elusive UNIX/TS in various versions. > I'm aware that these were not released under the ancient UNIX license, > however the web source view on TUHS has the source code for SysIII and > SysV and most of it can be found on archive.org as well, so the fact > that they're not part of the public TUHS archive is a bit weird. > > BTW, I'm currently putting together installation instructions for > various > old UNICES on http://a.papnet.eu/UNIX/. And I also ported aiju's blit > emulator to Unix recently (ran on plan 9 originally): > https://github.com/aap/blit So have fun running v8 with this. > > aap > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmswierczek at gmail.com Wed Dec 6 10:00:24 2017 From: rmswierczek at gmail.com (Robert Swierczek) Date: Tue, 5 Dec 2017 19:00:24 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org> References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: I am also interested in the early development of networked GUI's that led to the X Window System. According to Wikipedia there was a W Window System that predated X. Early research on networked GUI's was done on the V Operating System which included a Virtual Graphics Terminal Service (VGTS) providing a modular window system for local and remote clients (which led to W, which led to X.) I suppose they are not on the main-line of UNIX artifacts, but they definitely influenced the modern UNIX experience (the workstation era onward to the present.) None of my Google searching has yielded any scrap of those early efforts. From gtaylor at tnetconsulting.net Wed Dec 6 10:08:38 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 5 Dec 2017 17:08:38 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: <4109b4aa-2eed-0b83-9f4a-678f71150746@spamtrap.tnetconsulting.net> On 12/05/2017 05:00 PM, Robert Swierczek wrote: > I am also interested in the early development of networked GUI's that > led to the X Window System. +1 for information on W. > I suppose they are not on the main-line of UNIX artifacts, but they > definitely influenced the modern UNIX experience (the workstation era > onward to the present.) If such is appropriate. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From imp at bsdimp.com Wed Dec 6 10:33:02 2017 From: imp at bsdimp.com (Warner Losh) Date: Tue, 5 Dec 2017 17:33:02 -0700 Subject: [TUHS] V7 Addendem Message-ID: >From the tuhs web site: "This is a set of addenda to Seventh Edition Unix, possibly put out by the Labs." and "The identity of the person who donated them is unknown." Two questions: Was this put out by the Labs? Second: There was recently a discussion about a tape found at some public location during an early Unix user group meeting. Is this that tape? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Dec 6 11:07:36 2017 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 6 Dec 2017 11:07:36 +1000 Subject: [TUHS] V7 Addendem In-Reply-To: References: Message-ID: <20171206010736.GA16514@minnie.tuhs.org> On Tue, Dec 05, 2017 at 05:33:02PM -0700, Warner Losh wrote: > From the tuhs web site: > "This is a set of addenda to Seventh Edition Unix, possibly put out by > the Labs." > and > "The identity of the person who donated them is unknown." > Two questions: Was this put out by the Labs? > Second: There was recently a discussion about a tape found at some > public location during an early Unix user group meeting. Is this that > tape? > Warner No. I had to search my own archives. From this list in 2002: The mythical `50 bugs' tape, described in Peter Salus' book `A Quarter Century of UNIX' has been found lurking in the Unix Archive. You can find it in Applications/Spencer_Tapes/unsw3.tar.gz as the file usr/sys/v6unix/unix_changes. And here is the relevant paragraphs from QCU: Lou Katz’s version is a bit different: A large number of bug fixes was collected, and rather than issue them one at a time, a collection tape (”The 50 fixes”) was put together by Ken. Some of the fixes were quite important, though I don't remember any in particular. I suspect that a significant fraction of the fixes were actually done by non-Bell people. Ken tried to send it out, but the lawyers kept stalling and stalling and stalling. Finally, in complete disgust, someone "found a tape on Mountain Avenue” which had the fixes. [The address of Bell Labs is 600 Mountain Avenue, Murray Hill, NJ.] When the lawyers found out about it, they called every licensee and threatened them with dire consequences if they didn’t destroy the tape, after trying to find out how they got the tape. I would guess that no one would actually tell them how they came by the tape (I didn’t). Cheers, Warren From ggm at algebras.org Wed Dec 6 11:22:52 2017 From: ggm at algebras.org (George Michaelson) Date: Wed, 6 Dec 2017 11:22:52 +1000 Subject: [TUHS] shell PS1/PS2 which survive cut-paste Message-ID: I tried a long time ago to set PS1 and PS2 to character sequences which would permit cut-paste to work. I failed, but I didn't try very hard. The choice of "# " and "> " interests me. Because roots prompt of "hash" has a side effect of making a cut-paste over it a comment in most shells. But.. it predates being *able* to cut-paste so it has to be a side-effect, not a design choice. "> " is more dangerous in cut-paste. Which again feels like a side-effect both by anachronistic time effects, and intent: nobody would be that suicidally mad to make cut-paste invoke shell pre-forming the command sequence which neccessarily zeros out the > targets before executing the cmd... -G From usotsuki at buric.co Wed Dec 6 11:30:44 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 5 Dec 2017 20:30:44 -0500 (EST) Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: On Wed, 6 Dec 2017, George Michaelson wrote: > I tried a long time ago to set PS1 and PS2 to character sequences > which would permit cut-paste to work. I failed, but I didn't try very > hard. > > The choice of "# " and "> " interests me. Because roots prompt of > "hash" has a side effect of making a cut-paste over it a comment in > most shells. > > But.. it predates being *able* to cut-paste so it has to be a > side-effect, not a design choice. > > "> " is more dangerous in cut-paste. Which again feels like a > side-effect both by anachronistic time effects, and intent: nobody > would be that suicidally mad to make cut-paste invoke shell > pre-forming the command sequence which neccessarily zeros out the > > targets before executing the cmd... > > -G > I think this is why rc used a ";" ? Maybe use "; " for PS1 and " " for PS2? -uso. From khm at sciops.net Wed Dec 6 11:28:24 2017 From: khm at sciops.net (Kurt H Maier) Date: Tue, 5 Dec 2017 17:28:24 -0800 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: <20171206012824.GA20970@wopr> On Wed, Dec 06, 2017 at 11:22:52AM +1000, George Michaelson wrote: > I tried a long time ago to set PS1 and PS2 to character sequences > which would permit cut-paste to work. I failed, but I didn't try very > hard. I've used :; and ::; to good effect. Since : is a no-op, it just inserts noise into the history. khm From lyndon at orthanc.ca Wed Dec 6 12:26:05 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 5 Dec 2017 18:26:05 -0800 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: <20171206012824.GA20970@wopr> References: <20171206012824.GA20970@wopr> Message-ID: > On Dec 5, 2017, at 5:28 PM, Kurt H Maier wrote: > > I've used :; and ::; to good effect. Since : is a no-op, it just inserts > noise into the history. This fragment lives in my ${HOME}/.env on pretty much every machine I log in to. If you 'export ENV=${HOME}/.env' in .profile, then configure sudo/doas to pass ENV through unmolested, this will follow you as you switch uids. _hostname=$(hostname | sed -e 's/\.hushmail\(inc\)*\.com$//') awd=$(which awd 2>/dev/null) if [ "${awd}" == "" ] ; then awd=':' fi setprompt () { PS1=": $(id -un)@$_hostname:$(pwd); " ; } cd () { command cd "$@" && setprompt && ${awd} ; } setprompt It works with pretty much every Bourne/Korn shell variant I've stumbled across. Adjust the _hostname bit to match the domains of the systems you regularly log in to, and drop the awd bits if you don't use plan9port. --lyndon From gtaylor at tnetconsulting.net Wed Dec 6 13:45:44 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 5 Dec 2017 20:45:44 -0700 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: On 12/05/2017 06:22 PM, George Michaelson wrote: > I tried a long time ago to set PS1 and PS2 to character sequences > which would permit cut-paste to work. I failed, but I didn't try very > hard. What do you mean by "permit cut (and) paste to work"? Do you want to be able to cut (triple click the entire line in Xterm) and then paste it (middle click a new line) and have it execute? Or do you mean that you want it to not execute as a safety measure? Or are you wanting to go one step further and have something that toggles input interpretation off until a character sequence is provided, possibly by the prompt? Ideally so that you would not accidentally copy & paste swaths of screen output and have it executed. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From arnold at skeeve.com Wed Dec 6 15:53:15 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 05 Dec 2017 22:53:15 -0700 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: <201712060553.vB65rFa3002734@freefriends.org> George Michaelson wrote: > The choice of "# " and "> " interests me. Because roots prompt of > "hash" has a side effect of making a cut-paste over it a comment in > most shells. "#" as the root prompt predates # as the comment in the Bourne shell, not to mention predating copy/paste entirely. (My understanding is that the do-nothing command, ":" was used for comments. Talk about minimalist!) Same point for ">", since copy/paste didn't exist in the late 70s when Bourne was doing the shell, it wasn't an issue. Arnold From arnold at skeeve.com Wed Dec 6 15:54:32 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 05 Dec 2017 22:54:32 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171205222113.GA32070@minnie.tuhs.org> References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: <201712060554.vB65sWLV002765@freefriends.org> Warren Toomey wrote: > What else should be we looking for? What physical artifacts (drawings, > artwork etc.) have we missed that should be sought after? Schematics for the original Blit? Any actual original Blits? Arnold From ggm at algebras.org Wed Dec 6 16:01:01 2017 From: ggm at algebras.org (George Michaelson) Date: Wed, 6 Dec 2017 16:01:01 +1000 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: <201712060553.vB65rFa3002734@freefriends.org> References: <201712060553.vB65rFa3002734@freefriends.org> Message-ID: So.. arnold.. you never used the ! command in ex or vi? because it will treat a range command as the bounding set of lines to feed into the command.. if you specify sh or /path/to/shell then its functionally a cut-paste-exec sequence isn't it? emacs has the same functionality (in some syntactic suger) I used fmt all the time in vi, to get <72 for mail in MH. which led me to find other things you can pipe the editor lines through... -G From dave at horsfall.org Wed Dec 6 16:19:01 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 6 Dec 2017 17:19:01 +1100 (EST) Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: <201712060553.vB65rFa3002734@freefriends.org> References: <201712060553.vB65rFa3002734@freefriends.org> Message-ID: On Tue, 5 Dec 2017, arnold at skeeve.com wrote: > "#" as the root prompt predates # as the comment in the Bourne shell, > not to mention predating copy/paste entirely. (My understanding is that > the do-nothing command, ":" was used for comments. Talk about > minimalist!) And as a label for the dreaded "goto" command; it was a while before I realised that ":" in and of itself did bugger-all... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From arnold at skeeve.com Wed Dec 6 18:00:58 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 06 Dec 2017 01:00:58 -0700 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: <201712060553.vB65rFa3002734@freefriends.org> Message-ID: <201712060800.vB680wXG013646@freefriends.org> Dave Horsfall wrote: > On Tue, 5 Dec 2017, arnold at skeeve.com wrote: > > > "#" as the root prompt predates # as the comment in the Bourne shell, > > not to mention predating copy/paste entirely. (My understanding is that > > the do-nothing command, ":" was used for comments. Talk about > > minimalist!) > > And as a label for the dreaded "goto" command; it was a while before I > realised that ":" in and of itself did bugger-all... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." "goto" was in the V6 shell, I think (next to no experience with the V6 shell, and it was a LONG time ago anyway). But there never was a goto in the V7 shell. From pnr at planet.nl Wed Dec 6 21:02:25 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 6 Dec 2017 12:02:25 +0100 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: >> The choice of "# " and "> " interests me. Because roots prompt of >> "hash" has a side effect of making a cut-paste over it a comment in >> most shells. > > "#" as the root prompt predates # as the comment in the Bourne shell, > not to mention predating copy/paste entirely. (My understanding is that > the do-nothing command, ":" was used for comments. Talk about minimalist!) > > Same point for ">", since copy/paste didn't exist in the late 70s when > Bourne was doing the shell, it wasn't an issue. As early as V5 the (thompson) shell prompts were “#” and “%”, and “:” for a label. As the goto command exists in V4 (there is a man page for it), I would assume that those characters were used in V4 as well. So it would seem to go back to 1974. In the V7 (bourne) shell the default non-root prompt is “$”. Goto is dropped at this point. Don’t know when or where “>” was first used on Unix as a prompt character (on my boxes it still is “$”). Paul From pnr at planet.nl Wed Dec 6 21:22:39 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 6 Dec 2017 12:22:39 +0100 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: Message-ID: <2C3508CE-5B20-4EEC-ABA6-FB02C5FCBA39@planet.nl> > We've been able to recover quite a deal of UNIX artifacts in the past two > decades, but what artifacts (in your opinion) are still out there that > we should try and unearth? Remember that the 50th anniversary is coming up > in 2019. I’d be interested in anything on Spider/Datakit networking in V4-V7. (at them moment the trail starts at V8, with just a few hints in earlier source materials, and the bits that Noel found). My thinking is that there were two main lines of early networking development on Unix (and I realise that this gross simplification excludes many other worthy projects): 1. The “sockets” lineage from UoI NCP Unix -> BBN NCP Unix -> BBN TCP Unix -> 4.1a BSD -> 4.2 BSD 2. The “device” lineage from Spider -> Datakit -> UUCP -> streams -> STREAMS In the first lineage there is much material available, in the second very little. This is probably because Datakit was AT&T confidential at the time. From pnr at planet.nl Wed Dec 6 21:25:27 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 6 Dec 2017 12:25:27 +0100 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: Message-ID: > Venix/86 and Venix/86R might be interesting... I have impure versions of > both... +1 Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could go together with Idris and Minix as examples of early PC Unix. From arnold at skeeve.com Wed Dec 6 22:00:18 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 06 Dec 2017 05:00:18 -0700 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: <201712061200.vB6C0Inu006737@freefriends.org> Paul Ruizendaal wrote: > Don’t know when or where “>” was first used on Unix as a prompt character > (on my boxes it still is “$”). The V7 shell uses it as the secondary prompt, for when a construct isn't complete: $ echo 'abc > def' abc def Arnold From mutiny.mutiny at rediffmail.com Wed Dec 6 22:58:37 2017 From: mutiny.mutiny at rediffmail.com (Mutiny ) Date: 6 Dec 2017 12:58:37 -0000 Subject: [TUHS] =?utf-8?q?What_UNIX_Artifacts_Are_Still_Missing=3F?= In-Reply-To: Message-ID: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> >Venix/86 is the first Unix to run on PC hardware that I’m aware of. It couldgo together with Idris and Minix as examples of early PC Unix.'A working version of Venix for the IBM PC XT was demoed at Comdex in May 1983. 'https://en.wikipedia.org/wiki/VenixXenix Initial release 1980;https://en.wikipedia.org/wiki/XenixMore on Microsoft Short-lived Love Affair with Unix:'Microsoft licensed UNIX from AT&T in 1979.'http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Dec 6 23:36:22 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 06 Dec 2017 08:36:22 -0500 Subject: [TUHS] V7 Addendem Message-ID: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU> > Was this [v7 addenda] put out by the Labs? It is definitely Research code from the Labs. How it From clemc at ccc.com Thu Dec 7 00:29:42 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Dec 2017 09:29:42 -0500 Subject: [TUHS] V7 Addendem In-Reply-To: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU> References: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU> Message-ID: An observation ... in reading the last few days emails, I fear there may be some confusion - there were two different tapes. The infamous 'patch tape' that Lou was discussing was patches to the *Sixth Edition* which I want to say '76 or 77 timeframe (should be able to be dated by when Chesson graduated from UofI and Ken was on his way to UCB for a sabbatical). I can date this because we had a copy of the patch tape at CMU at least by I think late '77/early '78 when I was hacking full-time for the EE Dept. CS had switched from the Fifth Edition on their systems, which was my introduction. I would eventually bring up 6th on an original 11/34 (not a 34A). The 11/34 did not 'just work' due to some small differences between the 11/40 and the 11/34 and remember having to do it from first principles borrowing a hacked CS system (11/40e), that had CSR/CRET stuff in their compiler, so I went back to just booting Ken's original tape, hacking until both 11/34 and the 11/40 boot and then having to reapplied the patches, because I wanted to make sure I did get polluted with the 11/40e stuff. The V7 addendum was obviously post Seventh Edition. The Seventh Edition was released in 1979 for general availability**; although it's direct predecessor (UNIX/TS) which was not officially released made its way to number of places such as MIT and CMU via OYOCs and summer students as Noel and I have pointed out in the past. Noel (MIT) and I (CMU) both had heavily hacked systems that were combo's of V6, PWB [1.0], UNIX/TS plus local additions. UNIX/TS had a newer kernel, updated FS and the compiler that was released with troff - a.k.a. 'Typesetter C' [Historical note - this was the system Ted with a small amount of help from me, used to create fsck]. If I recall the V7 'addendum' is in reference to the later (post 1980) V7 distribution tapes, that had one more file on it with some additions/corrections from Research as Doug mentioned. IIRC: The first V7 tapes that went out in '79 (such as the ones I recieved at CMU and then Tektronix) did not have that file and the copy said tape I have home is missing it (I just checked the label). Clem **V7 GA was in Feb '79 I think, I can not find my copy of Al Arm's letter to the licensees announcing it, I seem to have lost it - any other pack rat/old f*rt please check your files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Dec 7 00:33:17 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 6 Dec 2017 15:33:17 +0100 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: That is a good point: early Xenix is still missing. It would make an excellent public relations move for Microsoft if they would make early Xenix available to celebrate 50 years of Unix. Although Xenix predates Venix, I'm not sure it predates it on PC hardware. It would seem to me that there both Venix and PC/IX preceded it: http://seefigure1.com/2014/04/15/xenixtime.html https://en.wikipedia.org/wiki/Interactive_Systems_Corporation If Xenix 3.0 had an integrated source code base, it would be an excellent example of the portability of early Unix across a wide range of architectures. Paul On 6 Dec 2017, at 13:58 , Mutiny wrote: > > >Venix/86 is the first Unix to run on PC hardware that I’m aware of. It could > go together with Idris and Minix as examples of early PC Unix. > > 'A working version of Venix for the IBM PC XT was demoed at Comdex in May 1983. ' > https://en.wikipedia.org/wiki/Venix > > Xenix Initial release 1980; > https://en.wikipedia.org/wiki/Xenix > > More on Microsoft Short-lived Love Affair with Unix: > 'Microsoft licensed UNIX from AT&T in 1979.' > http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml From arnold at skeeve.com Thu Dec 7 00:23:24 2017 From: arnold at skeeve.com (Aharon Robbins) Date: Wed, 06 Dec 2017 16:23:24 +0200 Subject: [TUHS] V10 spell vs. spell.old? Message-ID: <201712061423.vB6ENOZZ011903@skeeve.com> Hi. What's the difference between spell.old and spell in the V10 sources? I'm guessing spell.old is the original version for the small-address-space PDP-11 and that plain spell takes better advantage of the roomier vax... Thanks, Arnold From clemc at ccc.com Thu Dec 7 00:45:15 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Dec 2017 09:45:15 -0500 Subject: [TUHS] V7 Addendem In-Reply-To: References: <201712061336.vB6DaMqQ032571@coolidge.cs.Dartmouth.EDU> Message-ID: s/did get polluted/didn't get polluted/ --- sigh On Wed, Dec 6, 2017 at 9:29 AM, Clem Cole wrote: > An observation ... in reading the last few days emails, I fear there may > be some confusion - there were two different tapes. The infamous 'patch > tape' that Lou was discussing was patches to the *Sixth Edition* which I > want to say '76 or 77 timeframe (should be able to be dated by when Chesson > graduated from UofI and Ken was on his way to UCB for a sabbatical). > > I can date this because we had a copy of the patch tape at CMU at least by > I think late '77/early '78 when I was hacking full-time for the EE Dept. > CS had switched from the Fifth Edition on their systems, which was my > introduction. I would eventually bring up 6th on an original 11/34 (not a > 34A). The 11/34 did not 'just work' due to some small differences between > the 11/40 and the 11/34 and remember having to do it from first principles > borrowing a hacked CS system (11/40e), that had CSR/CRET stuff in their > compiler, so I went back to just booting Ken's original tape, hacking until > both 11/34 and the 11/40 boot and then having to reapplied the patches, > because I wanted to make sure I did get polluted with the 11/40e stuff. > > The V7 addendum was obviously post Seventh Edition. The Seventh Edition > was released in 1979 for general availability**; although it's direct > predecessor (UNIX/TS) which was not officially released made its way to > number of places such as MIT and CMU via OYOCs and summer students as Noel > and I have pointed out in the past. Noel (MIT) and I (CMU) both had > heavily hacked systems that were combo's of V6, PWB [1.0], UNIX/TS plus > local additions. UNIX/TS had a newer kernel, updated FS and the compiler > that was released with troff - a.k.a. 'Typesetter C' [Historical note - > this was the system Ted with a small amount of help from me, used to create > fsck]. > > If I recall the V7 'addendum' is in reference to the later (post 1980) V7 > distribution tapes, that had one more file on it with some > additions/corrections from Research as Doug mentioned. IIRC: The first V7 > tapes that went out in '79 (such as the ones I recieved at CMU and then > Tektronix) did not have that file and the copy said tape I have home is > missing it (I just checked the label). > > Clem > > > **V7 GA was in Feb '79 I think, I can not find my copy of Al Arm's letter > to the licensees announcing it, I seem to have lost it - any other pack > rat/old f*rt please check your files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From itz at very.loosely.org Thu Dec 7 01:14:49 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Wed, 6 Dec 2017 07:14:49 -0800 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: <201712060553.vB65rFa3002734@freefriends.org> Message-ID: <20171206151449.oc2qsqkdp5jzxotl@matica.foolinux.mooo.com> On 2017-12-06 16:01, George Michaelson wrote: > I used fmt all the time in vi, to get <72 for mail in MH. which led me > to find other things you can pipe the editor lines through... Exactly! Just put a trivial script in front of the /bin/sh in the pipe to strip the undesirable stuff like prompts. I do this for browsing URLs in mail bodies which may be split across multiple lines or otherwise mangled. With emacs, you don't even need an extra process, because the demangling can be programmed in lisp. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From clemc at ccc.com Thu Dec 7 01:23:02 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Dec 2017 10:23:02 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <20171205222113.GA32070@minnie.tuhs.org> Message-ID: On Tue, Dec 5, 2017 at 7:00 PM, Robert Swierczek wrote: > I am also interested in the early development of networked GUI's that > led to the X Window System. According to Wikipedia there was a W > Window System that predated X. W which was done at Stanford and is definitely related to (direct parent of) X Windows. Cheriton of course is the place to start, although I've lost track of him. He's in the valley somewhere, he made billions funding Google ;-) V Kernel and the Stanford University Network (SUN) terminals were all developed around the same time as W. FWIW: Gettys & Schiefler might have of the W ​sources squirreled away - as they started with them at MIT; but rejected it as the base for a set of reasons which I forget now; but did take a number of the ideas. Jim showed me a demo of early X and W side-by-side a long time ago. IIRC the basic site protocol and the approach where the 'server' was on the local system and the 'client' was remote came from W. [I'll try to ask Gettys what he has off-line]. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Thu Dec 7 02:11:11 2017 From: random832 at fastmail.com (Random832) Date: Wed, 06 Dec 2017 11:11:11 -0500 Subject: [TUHS] V7 Addendem In-Reply-To: <20171206010736.GA16514@minnie.tuhs.org> References: <20171206010736.GA16514@minnie.tuhs.org> Message-ID: <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> On Tue, Dec 5, 2017, at 20:07, Warren Toomey wrote: > Ken tried to send it out, but the lawyers kept > stalling and stalling and stalling. > > When the lawyers found out about it, they called every > licensee and threatened them with dire consequences if they > didn’t destroy the tape, after trying to find out how they got > the tape. I would guess that no one would actually tell them > how they came by the tape (I didn’t). I have a question, if anyone has any idea... is there any recorded knowledge about *who was driving*? That is, beyond "the lawyers", who on the business side of AT&T was making the policy decisions that led to the various sometimes bizarre legal actions that caused problems for the Unix world, and to what end (was there some way they expected to profit? liability concerns?) In other words, what was the basis of the legal department's mandate to try to shut these things down? (This question is also something I've wondered for some non-Unix stuff like the E911 document, but that's not relevant to this list) From jon at fourwinds.com Thu Dec 7 02:15:20 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 06 Dec 2017 08:15:20 -0800 Subject: [TUHS] V7 Addendem In-Reply-To: <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> Message-ID: <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> Random832 writes: > On Tue, Dec 5, 2017, at 20:07, Warren Toomey wrote: > > Ken tried to send it out, but the lawyers kept > > stalling and stalling and stalling. > > > > When the lawyers found out about it, they called every > > licensee and threatened them with dire consequences if they > > didn’t destroy the tape, after trying to find out how they got > > the tape. I would guess that no one would actually tell them > > how they came by the tape (I didn’t). > > I have a question, if anyone has any idea... is there any recorded > knowledge about *who was driving*? That is, beyond "the lawyers", who on > the business side of AT&T was making the policy decisions that led to > the various sometimes bizarre legal actions that caused problems for the > Unix world, and to what end (was there some way they expected to profit? > liability concerns?) > > In other words, what was the basis of the legal department's mandate to > try to shut these things down? (This question is also something I've > wondered for some non-Unix stuff like the E911 document, but that's not > relevant to this list) Can't answer your question directly, but I think that some of this was the result of the prior consent decree banning them from being in the data business. I seem to recall that it was technically illegal for them to sell SW and don't know how giving it away would have been viewed. From clemc at ccc.com Thu Dec 7 03:13:36 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Dec 2017 12:13:36 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On Wed, Dec 6, 2017 at 9:33 AM, Paul Ruizendaal wrote: > > ​A​ > lthough Xenix predates Venix, I'm not sure it predates it on PC hardware. ​It really depends how you count. I was there at time when AT&T was negotiating the replacement for the V7 license with 10 of us (the 10 firms included Microsoft - the only time I can say I was in the room with Willy G. - but that's another story)​. This work would become the System III license. ​Xenix, which was V7 based originally, was target for the generic 8086 systems (as well as PDP-11, 68K and Z8000) but the Intel support was generic so it included the PC. The bigger problem is that it really wanted a hard disk, which made its target a 'high end' computer in those days. Running on a floppy was sort of possible (besides slow, it tended to wear out the oxide in the center of the disk where the superblock and i-list was storied from all r/w - I used to have an 8" floppy sans case hanging in my office). But that said, the V7 based license was terrible for a 'small value system' and I'm not sure Microsoft shipped much against it. That was the primary reason they wanted to a new license [Gate's line at the time: 'You guys don't get it. The only thing that matters is volume.']. So until the System III license, which is what Xenix 2.0 and later shipped, I don't think Microsoft really had much presence. But at that time, Microsoft [via Bob Greenburg a founder and the only one of Gates roommates at Harvard to graduate btw] was trying to a UNIX porting house, similar to HCR. That had been the original vision of Xenix, they would OEM the SW to other firms that build HW, just like they did for BASIC and were beginning to do for FORTRAN and COBOL. As you point out, other firms such as ISC, HCR and Locus appeared on the scene as more UNIX knowledgeable. I also think IBM already had placed big bets on Microsoft for DOS and BASIC, so they wanted to spread the risk a little which is why ISC got the original UNIX for the PC HW deal. Once Microsoft had Xenix stable, IBM was already their customer so selling Xenix on IBM was a secondary issue. For a little more on the history front; my former boss, Phill Shevrin, who would later switch from ISC to Locus where I worked for him, pulled what I always thought was one of the great tricks of salesmanship in the UNIX business. When he was at ISC, he sold for $1.5M a 'port' to the 386 of System III to each of IBM, AT&T and Intel. He got paid three times for same work and got to sell the result as their own product when they were done. Also, from a historical standpoint, I hope we do have the ISC 386 code base - that was the first of the 32-bit linear UNIX ports for the x86 systems. The other thing that we should try to find is the Phoenix Tech VP/IX code base and the Locus Merge Code base. These were the first VM/hypervisors. They ran in PC/IX 386 and allowed Windows to run under it, long before VMware existed. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From imp at bsdimp.com Thu Dec 7 03:55:30 2017 From: imp at bsdimp.com (Warner Losh) Date: Wed, 6 Dec 2017 10:55:30 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: Message-ID: On Wed, Dec 6, 2017 at 4:25 AM, Paul Ruizendaal wrote: > > > Venix/86 and Venix/86R might be interesting... I have impure versions of > > both... > > +1 > > Venix/86 is the first Unix to run on PC hardware that I’m aware of. It > could > go together with Idris and Minix as examples of early PC Unix. > I have a set of both the original Venix/86R disks (From Venturicom) as well as the Boston Software Works modifications (which made it usable, honestly). I also have ported the v7 date code to this and fixed the y2k bug in it. Is any of that interesting to TUHS? I have a low-priority project that I'm working on towards the 40th anniversary of V7: I'd like to reconstruct the complete sources to the version of Venix that I have and have it running on my DEC Rainbow 100B in time based on sources I've compiled from scratch. It looks like about 90% of the system is there unmodified.... I also had a crazy pipe dream of getting Ultrix-11M ported over once I had the machine dependent files from Venix... But the lack of any network cards (at least available network cards) for my Rainbow has put a bit of a damper on my enthusiasm for that (since the 11M port was basically V7 + bug fixes - packet interface + sockets). Then again, someone else mentioned hypervisors... I was looking at hacking FreeBSD's BHYVE to emulate the old hardware so I can run things faster (but there's issues with timing loops in the old software that I'm sure will bedevil any such road). If only my body could execute fast enough on the things my brain thinks would be cool to do... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Thu Dec 7 03:59:16 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 7 Dec 2017 00:59:16 +0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? Message-ID: Regarding Theodore Bashkow I found a reference in this article http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.880&rep=rep1&type=pdf "[Jain 90a], N. Jain, M. Schwartz and T. R. Bashkov, "Transport Protocol Processing at GBPS Rates.", Computer Communications Review, Vol. 20 (4), 1990, pp. 188-199." No idea if this 'bashkov' is the 'bashkow' in the 'what's missing' discussion. Cheers, rudi From clemc at ccc.com Thu Dec 7 04:39:03 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Dec 2017 13:39:03 -0500 Subject: [TUHS] V7 Addendem In-Reply-To: <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> Message-ID: On Wed, Dec 6, 2017 at 11:15 AM, Jon Steinhart wrote: > Random832 writes: > > On Tue, Dec 5, 2017, at 20:07, Warren Toomey wrote: > > > Ken tried to send it out, but the lawyers kept > > > stalling and stalling and stalling. > > > > > > When the lawyers found out about it, they called every > > > licensee and threatened them with dire consequences if they > > > didn’t destroy the tape, after trying to find out how they got > > > the tape. I would guess that no one would actually tell them > > > how they came by the tape (I didn’t). > > > > I have a question, if anyone has any idea... is there any recorded > > knowledge about *who was driving*? That is, beyond "the lawyers", who on > > the business side of AT&T was making the policy decisions that led to > > the various sometimes bizarre legal actions that caused problems for the > > Unix world, and to what end (was there some way they expected to profit? > > liability concerns?) > > > > In other words, what was the basis of the legal department's mandate to > > try to shut these things down? (This question is also something I've > > wondered for some non-Unix stuff like the E911 document, but that's not > > relevant to this list) > > Can't answer your question directly, but I think that some of this was > the result of the prior consent decree banning them from being in the > data business. I seem to recall that it was technically illegal for > them to sell SW and don't know how giving it away would have been viewed. > ​I really think Jon is correct here. The behavior was all left over from the 1956 consent decree, which settled the 1949 anti-trust case against AT&T. As the recipients of the AT&T IP, we used to refer the behavior as "UNIX was abandoned on your doorstep." Throughout the 60s and 70s, the AT&T sr management from the CEO on down, were terrified of another anti-trust case. And of course they got one and we all know what judge Green did to resolve that in 1980. I described the activities/actions in detail in my paper: *"**UNIX: A View from the Field as We Played the Game" *which I gave last fall in Paris​. The proceeding are supposed to go on line at some point. Send me email if you want the details and I'll send you a PDF. I'm holding off cutting and pasting here for reasons of brevity. For an legal analysis I also recommend: *“AT&T Divestiture & the Telecommunications Market”,* John Pinheiro, Berkeley Technical Law Journal, 303, September 1987, Volume 2, Issue 2, Article 5 which I cite in my paper. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Dec 7 04:49:11 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 06 Dec 2017 10:49:11 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> Message-ID: <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Clem Cole writes: > On Wed, Dec 6, 2017 at 11:15 AM, Jon Steinhart wrote: > > Can't answer your question directly, but I think that some of this was > > the result of the prior consent decree banning them from being in the > > data business.  I seem to recall that it was technically illegal for > > them to sell SW and don't know how giving it away would have been viewed. > > I really think Jon is correct here.  The behavior was all left over from the > 1956 consent decree, which settled the 1949 anti-trust case against AT&T. > > As the recipients of the AT&T IP, we used to refer the behavior as "UNIX was > abandoned on your doorstep."  Throughout the 60s and 70s, the AT&T sr > management from the CEO on down, were terrified of another anti-trust case.  > And of course they got one and we all know what judge Green did to resolve that > in 1980. > > I described the activities/actions in detail in my paper: "UNIX: A View from > the Field as We Played the Game" which I gave last fall in Paris.  The > proceeding are supposed to go on line at some point.  Send me email if you want > the details and I'll send you a PDF.   I'm holding off cutting and pasting here > for reasons of brevity.  For an legal analysis I also recommend: “AT&T > Divestiture & the Telecommunications Market”, John Pinheiro, Berkeley Technical > Law Journal, 303, September 1987, Volume 2, Issue 2, Article 5 which I cite in > my paper. > > Clem There's another aspect of this that I think that many people misunderstand which is that Judge Green gave AT&T exactly what they wanted. AT&T knew that in the future the money was in data and were willing to trade their monopoly for that business. From their perspective, it worked. For the rest of us, not so good. Some of us remember the days in which phones were reliable and you could understand the person on the other end. Or when your phone lasted 60+ years. Or the current debate about whether it's ok to eliminate exchange powered phones that work in an emergency. During the primaries when Ted Cruz would stand up and hold a dial phone and say "this is what government regulation got you" I always thought "Yeah, give me more of that. It's 60 years old, still works better than what you can get today, and if you hurl it across the room it'll still work which is more than you can say for anything made post-split." Not to mention it ended one of the best research labs in history. Jon From imp at bsdimp.com Thu Dec 7 04:53:11 2017 From: imp at bsdimp.com (Warner Losh) Date: Wed, 6 Dec 2017 11:53:11 -0700 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: On Wed, Dec 6, 2017 at 11:49 AM, Jon Steinhart wrote: > > During the primaries when Ted Cruz would stand up and hold a dial phone > and say "this is what government regulation got you" I always thought > "Yeah, give me more of that. It's 60 years old, still works better than > what you can get today, and if you hurl it across the room it'll still > work which is more than you can say for anything made post-split." > We traded reliability for cat videos and any kind of porn you'd ever want (and sever you wouldn't!) Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 7 04:54:44 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 6 Dec 2017 13:54:44 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: On Wed, Dec 6, 2017 at 1:49 PM, Jon Steinhart wrote: > > There's another aspect of this that I think that many people misunderstand > which is that Judge Green gave AT&T exactly what they wanted. AT&T knew > that in the future the money was in data and were willing to trade their > monopoly for that business. From their perspective, it worked. For the > rest of us, not so good. > > Some of us remember the days in which phones were reliable and you could > understand the person on the other end. Or when your phone lasted 60+ > years. Or the current debate about whether it's ok to eliminate exchange > powered phones that work in an emergency. > > During the primaries when Ted Cruz would stand up and hold a dial phone > and say "this is what government regulation got you" I always thought > "Yeah, give me more of that. It's 60 years old, still works better than > what you can get today, and if you hurl it across the room it'll still > work which is more than you can say for anything made post-split." > > Not to mention it ended one of the best research labs in history. ​Amen brother Jon....​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Dec 7 04:58:38 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 06 Dec 2017 10:58:38 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: <201712061858.vB6IwcB8032748@darkstar.fourwinds.com> Warner Losh writes: > On Wed, Dec 6, 2017 at 11:49 AM, Jon Steinhart wrote: > > > > During the primaries when Ted Cruz would stand up and hold a dial phone > > and say "this is what government regulation got you" I always thought > > "Yeah, give me more of that. It's 60 years old, still works better than > > what you can get today, and if you hurl it across the room it'll still > > work which is more than you can say for anything made post-split." > > > > We traded reliability for cat videos and any kind of porn you'd ever want > (and sever you wouldn't!) > > Warner Exactly. I remember Dick Hause (?) doing a nice graphical demo on the Glance G that showed how the phone system routed around faults and was able to because of the "there shall be a minimum of three paths out of any exchange" rule. A while back my long distance went out because someone hit a phone pole 40 miles away. Couldn't even call to report it because support was in Seattle and there was no path there from here; that was the only route. Something to keep in mind with the internet. While TCP/IP is great for routing around trouble it can only do so when there are alternate routes. Seem to be fewer and fewer of these. Jon From web at loomcom.com Thu Dec 7 05:00:51 2017 From: web at loomcom.com (Seth Morabito) Date: Wed, 6 Dec 2017 11:00:51 -0800 Subject: [TUHS] AT&T 3B2/400 Emulator Message-ID: <20171206190051.GA15028@xenon.retronet.net> Hello everyone, A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator into the main SIMH source tree, and I realized that I should mention it here, where there may be particular interest. The 3B2 and 3B5 were main porting platforms for AT&T System V Release 3, and when I realized how scarce the equipment has become to find, I set out to write an emulator for the 3B2. It was rough going at points due to lack of documentation, but I was able to reverse engineer quite a bit of the system through reading the SVR3 source code, and of course strapping my own 3B2/310 to a logic analyzer. The emulator is fairly complete. It certainly works well as a standalone, single-user UNIX system. Support for multiple terminals is coming very soon (as soon as I find the time, that is) so it will soon be possible to allow multiple users to telnet into virtual terminals, similar to how the SIMH PDP-11 and VAX emulators work. For now, information about the emulator lives here: https://loomcom.com/3b2/emulator/ Best Wishes, -Seth -- Seth Morabito web at loomcom.com From pechter at gmail.com Thu Dec 7 05:20:46 2017 From: pechter at gmail.com (William Pechter) Date: Wed, 6 Dec 2017 14:20:46 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: <7a457110-994a-4a08-c47b-9e17ff369d41@gmail.com> Clem Cole wrote: > > > On Wed, Dec 6, 2017 at 1:49 PM, Jon Steinhart > wrote: > > > There's another aspect of this that I think that many people > misunderstand > which is that Judge Green gave AT&T exactly what they wanted. > AT&T knew > that in the future the money was in data and were willing to trade > their > monopoly for that business. From their perspective, it worked. > For the > rest of us, not so good. > For AT&T (which no longer is a company since the current AT&T is really AT&T in name only. SBC Communications bought AT&T Corp. on November 18, 2005, and changed its name to AT&T Inc. (The real AT&T is no longer...) > Some of us remember the days in which phones were reliable and you > could > understand the person on the other end. Or when your phone lasted 60+ > years. Or the current debate about whether it's ok to eliminate > exchange > powered phones that work in an emergency. > > During the primaries when Ted Cruz would stand up and hold a dial > phone > and say "this is what government regulation got you" I always thought > "Yeah, give me more of that. It's 60 years old, still works > better than > what you can get today, and if you hurl it across the room it'll still > work which is more than you can say for anything made post-split." > > Not to mention it ended one of the best research labs in history. > > ​Amen brother Jon....​ > > And it also helped cause the end of a number of computer companies, including NCR, DEC, Pyramid Technologies... The bad decisions AT&T made once they got into the computer hardware business were legendary. They had product support problems (replaced a significant quantity of 6300 motherboards on their PC for an MS-DOS clock problem they introduced by clearing the seconds in the RTC chip at each boot)... They had issues with their Field Service techs being unwilling to work on Pyramid OS/x boxes under Unix (AT&T System 7000) because that was system software and they were only willing to work with a (nonexistant on Pyramid) offline diagnostics set. An AT&T Union tech walkout from Pyramid classes was averted on that one... They were not too successful selling Alliant FX/1 and FX/8 boxes as AT&T machines as well. I worked for both computer companies in service and training and saw this first hand.AT&T was to hand AT&T Business cards to Alliant Service personnel to handle the customers. They tried to sell the 3b20 simplex box against the Vax into scientific markets only to find that although the integer performance was superior... Scientific use really needs hardware floating point. The later 3b line got much better but the first entry was frightenening Unfortunately, half of Pyramid's sales were through OEM's (Siemens-Nixdorf and AQT&T mostly) so the ton of business dropped immediately once the NCR deal took hold. It happened just as Pyramid moved to DCOS/x (Their SVR4 port to MIPS). This killed a ton of growth and the deal to move the US Internal Revenue from System III based Zilog Zeus boxes to Pyramid... Sometimes you can't always get what you want. Sometimes when you get it you screw yourself into the ground. AT&T, I was told, couldn't figure out how MCI could undercut them in long distance. The experts said -- we have the network in place and paid for and there's no way we could do it for under 10c per minute... They didn't figure MCI (later LDDS) could cook the books to make the numbers look better. Back in '84 DEC was to train me as a Unix admin and act as the outsource contractor supplier to AT&T. This would've had one source of service and support for all their Vaxes and eliminated the large collection of Sysadmin and Operator suppliers. Pre-IBM Global Services type stuff. The wife was at the Labs at the time and they supposedly announced it. Rumor says a DEC and AT&T merger about the same time fell apart. Perhaps the history is buried in the DEC Archives now in the Computer Museuum. I was told I was in on the deal in Oct/Nov 1983 or 84 and it fell apart the next January or so. Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Dec 7 05:21:33 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 6 Dec 2017 14:21:33 -0500 Subject: [TUHS] AT&T 3B2/400 Emulator In-Reply-To: <20171206190051.GA15028@xenon.retronet.net> References: <20171206190051.GA15028@xenon.retronet.net> Message-ID: <7b56851f-9de4-fccc-455f-3e733385de60@kilonet.net> On 12/6/2017 2:00 PM, Seth Morabito wrote: > A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator > into the main SIMH source tree, and I realized that I should mention > it here, where there may be particular interest. > > The 3B2 and 3B5 were main porting platforms for AT&T System V Release > 3, and when I realized how scarce the equipment has become to find, I > set out to write an emulator for the 3B2. It was rough going at points > due to lack of documentation, but I was able to reverse engineer quite > a bit of the system through reading the SVR3 source code, and of > course strapping my own 3B2/310 to a logic analyzer. > > The emulator is fairly complete. It certainly works well as a > standalone, single-user UNIX system. Support for multiple terminals is > coming very soon (as soon as I find the time, that is) so it will soon > be possible to allow multiple users to telnet into virtual terminals, > similar to how the SIMH PDP-11 and VAX emulators work. > Nice work! The KS10 emulation also has telnet-to-DZ11 support as well (cough cough). (Ok, Bob did rewrite the DZ11 emulation after I stuffed someone else's version into the KS10, but still...) ;) From wlc at jctaylor.com Thu Dec 7 05:23:00 2017 From: wlc at jctaylor.com (William Corcoran) Date: Wed, 6 Dec 2017 19:23:00 +0000 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> , <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: Well, sure in 1963 the T1 carrier was a huge pipe. It was a huge pipe in 1970. It was also a huge pipe in 1980 for business. (Not so for the telcos, as ATT had Metrobus in the 80’s and the telcos had SONET in the 90’s—-completely inaccessible but to the largest corporations) However, today, I have Fios with nearly 1 Gigabit up and down for a small fee. Thank you Judge Greene! (Let’s not forget, I now have access to a working v7 for free where the license previously cost $28,000.) Bill Corcoran On Dec 6, 2017, at 1:49 PM, Jon Steinhart > wrote: Clem Cole writes: On Wed, Dec 6, 2017 at 11:15 AM, Jon Steinhart > wrote: Can't answer your question directly, but I think that some of this was the result of the prior consent decree banning them from being in the data business. I seem to recall that it was technically illegal for them to sell SW and don't know how giving it away would have been viewed. I really think Jon is correct here. The behavior was all left over from the 1956 consent decree, which settled the 1949 anti-trust case against AT&T. As the recipients of the AT&T IP, we used to refer the behavior as "UNIX was abandoned on your doorstep." Throughout the 60s and 70s, the AT&T sr management from the CEO on down, were terrified of another anti-trust case. And of course they got one and we all know what judge Green did to resolve that in 1980. I described the activities/actions in detail in my paper: "UNIX: A View from the Field as We Played the Game" which I gave last fall in Paris. The proceeding are supposed to go on line at some point. Send me email if you want the details and I'll send you a PDF. I'm holding off cutting and pasting here for reasons of brevity. For an legal analysis I also recommend: “AT&T Divestiture & the Telecommunications Market”, John Pinheiro, Berkeley Technical Law Journal, 303, September 1987, Volume 2, Issue 2, Article 5 which I cite in my paper. Clem There's another aspect of this that I think that many people misunderstand which is that Judge Green gave AT&T exactly what they wanted. AT&T knew that in the future the money was in data and were willing to trade their monopoly for that business. From their perspective, it worked. For the rest of us, not so good. Some of us remember the days in which phones were reliable and you could understand the person on the other end. Or when your phone lasted 60+ years. Or the current debate about whether it's ok to eliminate exchange powered phones that work in an emergency. During the primaries when Ted Cruz would stand up and hold a dial phone and say "this is what government regulation got you" I always thought "Yeah, give me more of that. It's 60 years old, still works better than what you can get today, and if you hurl it across the room it'll still work which is more than you can say for anything made post-split." Not to mention it ended one of the best research labs in history. Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Dec 7 05:27:57 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 6 Dec 2017 20:27:57 +0100 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: > On 6 Dec 2017, at 18:13, Clem Cole wrote: > > On Wed, Dec 6, 2017 at 9:33 AM, Paul Ruizendaal wrote: > ​A​lthough Xenix predates Venix, I'm not sure it predates it on PC hardware. > ​It really depends how you count. I was there at time when AT&T was negotiating the replacement for the V7 license with 10 of us (the 10 firms included Microsoft - the only time I can say I was in the room with Willy G. - but that's another story)​. This work would become the System III license. > > ​Xenix, which was V7 based originally, was target for the generic 8086 systems (as well as PDP-11, 68K and Z8000) but the Intel support was generic so it included the PC. [...] Yes, you are correct: In november 1981 Xenix ran on the Altos 8600. Once you run on one 8086 machine, the next is minor step. https://en.wikipedia.org/wiki/Altos_Computer_Systems#ACS_8600 Your insights about licensing match with the chart on the ‘seefigure1’ website, and help explain some things about it. Paul From khm at sciops.net Thu Dec 7 06:30:57 2017 From: khm at sciops.net (Kurt H Maier) Date: Wed, 6 Dec 2017 12:30:57 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: <20171206203057.GA72441@wopr> On Wed, Dec 06, 2017 at 07:23:00PM +0000, William Corcoran wrote: > Well, sure in 1963 the T1 carrier was a huge pipe. It was a huge pipe in 1970. It was also a huge pipe in 1980 for business. (Not so for the telcos, as ATT had Metrobus in the 80’s and the telcos had SONET in the 90’s—-completely inaccessible but to the largest corporations) > > However, today, I have Fios with nearly 1 Gigabit up and down for a small fee. > > Thank you Judge Greene! > > (Let’s not forget, I now have access to a working v7 for free where the license previously cost $28,000.) But that was the flip side of being allowed to maintain a monopoly -- you could get phone service damn near anywhere, while getting FiOS service is possible only in geographic regions small enough to be a rounding error compared to POTS penetration. Near-universal service was the burden AT&T was required to bear. Now, nobody is bearing it. The current state of bandwidth is great if you're in the right place at the right time. For everyone else in the US nothing is getting better. Even 100mbit service is unavailable to the majority of the nation, let alone laughably bizarre requests like "reliability." khm From dave at horsfall.org Thu Dec 7 08:32:33 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 7 Dec 2017 09:32:33 +1100 (EST) Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On Wed, 6 Dec 2017, Paul Ruizendaal wrote: > That is a good point: early Xenix is still missing. It would make an > excellent public relations move for Microsoft if they would make early > Xenix available to celebrate 50 years of Unix. Call me a cynical old bastard (which I am), but I can't see M$ raising a flag for Unix... Wasn't it Billy Gates who reportedly said that any PC running Linux is one not running Windoze, and did his best to discredit it? I still have horrible memories of porting Unify (an early RDBMS) to Xenix, and getting tangled up in the poxy small/large memory models on the equally-poxy 286 (no, not the 386). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Thu Dec 7 09:57:58 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 7 Dec 2017 10:57:58 +1100 (EST) Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: <201712060800.vB680wXG013646@freefriends.org> References: <201712060553.vB65rFa3002734@freefriends.org> <201712060800.vB680wXG013646@freefriends.org> Message-ID: On Wed, 6 Dec 2017, arnold at skeeve.com wrote: > "goto" was in the V6 shell, I think (next to no experience with the V6 > shell, and it was a LONG time ago anyway). But there never was a goto > in the V7 shell. Never got to use the V7 shell; we were stuck with 11/40s[*] :-( It was certainly in the V6 shell, hence by bafflement at why labels were of the form ": blah" instead of the sensible "blah: "... [*] Although I did shove as much of the V7 kernel into V6 as I could (such as XON/XOFF), thereby earning me the sobriquet "Mr Unix 6.5" or something; having the AUSAM buffer scheme helped a lot. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ggm at algebras.org Thu Dec 7 09:59:17 2017 From: ggm at algebras.org (George Michaelson) Date: Thu, 7 Dec 2017 09:59:17 +1000 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <20171206203057.GA72441@wopr> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> <20171206203057.GA72441@wopr> Message-ID: The capital investment regime changed. AT&T like all the other telcos used utility scale funding options, to buy asset with a 50+ year life and then reaped the benefits against the long tail of payment on the investment funding to make it. Fast forward to the 1970s and people decided they'd rather sweat an asset fast, make a huge Return on Investment, and let dumb schmucks from their parents generation dig holes to earn low interest income for 50 years. Who wants to live forever! Cocaine on aisle three, Junk bond finance, speculation, deregulation... Pretty much everything we're using right now, right down the food chain comes from that decision. My laptop is in a three year depreciation cycle. My ISP is desperately trying not to have to spend money every 5-10 years re-engineering the switching and routing logic behind my fibre-to-the-home. The glass in the ground will last 50 years, but the government expects funding to complete its capital cost debt return inside 5. (insane) Admittedly, given the rate of change in technology, I think there was some coupling. If you had just invested in a strowger exchange and somebody showed you a transistor, if you were smart your heart was sinking: Kid was in meccano, not in mechanical switching any more... On Thu, Dec 7, 2017 at 6:30 AM, Kurt H Maier wrote: > On Wed, Dec 06, 2017 at 07:23:00PM +0000, William Corcoran wrote: >> Well, sure in 1963 the T1 carrier was a huge pipe. It was a huge pipe in 1970. It was also a huge pipe in 1980 for business. (Not so for the telcos, as ATT had Metrobus in the 80’s and the telcos had SONET in the 90’s—-completely inaccessible but to the largest corporations) >> >> However, today, I have Fios with nearly 1 Gigabit up and down for a small fee. >> >> Thank you Judge Greene! >> >> (Let’s not forget, I now have access to a working v7 for free where the license previously cost $28,000.) > > But that was the flip side of being allowed to maintain a monopoly -- > you could get phone service damn near anywhere, while getting FiOS > service is possible only in geographic regions small enough to be a > rounding error compared to POTS penetration. Near-universal service was > the burden AT&T was required to bear. Now, nobody is bearing it. > > The current state of bandwidth is great if you're in the right place at > the right time. For everyone else in the US nothing is getting better. > Even 100mbit service is unavailable to the majority of the nation, let > alone laughably bizarre requests like "reliability." > > khm From rminnich at gmail.com Thu Dec 7 10:06:54 2017 From: rminnich at gmail.com (ron minnich) Date: Thu, 07 Dec 2017 00:06:54 +0000 Subject: [TUHS] looking for a quote Message-ID: A long time ago, dmr wrote about something that IIRC BSD had done he did not like: unlimited length identifiers in C, maybe? His argument was that being too general was not a good thing. Can't quite find the quote, anyone remember it? Would have been ca. 1980. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Dec 7 10:34:39 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 6 Dec 2017 16:34:39 -0800 Subject: [TUHS] looking for a quote In-Reply-To: References: Message-ID: <20171207003439.GB24409@mcvoy.com> Could it have been having a structure field namespace per struct type? I feel like he and I talked about that, I know that that has always been a pet peeve of mine, I *much* prefer sbuf.st_size than whatever.size, the former is instantly a stat structure, the later is a "whatever". Yeah, I get it, it wasn't scalable, but I wish that there was a way to encourage that all structure fields be uniquely named, it's awesome for code readability. If the kernel and common libraries could have done that, so much better. On Thu, Dec 07, 2017 at 12:06:54AM +0000, ron minnich wrote: > A long time ago, dmr wrote about something that IIRC BSD had done he did > not like: unlimited length identifiers in C, maybe? His argument was that > being too general was not a good thing. > > Can't quite find the quote, anyone remember it? Would have been ca. 1980. > > ron -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From dscherrer at solar.stanford.edu Thu Dec 7 10:39:03 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Wed, 6 Dec 2017 16:39:03 -0800 Subject: [TUHS] how do I unsubscribe Message-ID: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> Could someone please tell me how to get off this list? I was rather appalled at the rudeness in the previous conversation... Deborah From lm at mcvoy.com Thu Dec 7 10:39:41 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 6 Dec 2017 16:39:41 -0800 Subject: [TUHS] standard types Message-ID: <20171207003941.GA27244@mcvoy.com> I have my own types.h that I carry around that has stuff like typedef unsigned char u8; typedef unsigned short u16; typedef unsigned int u32; typedef unsigned long long u64; typedef signed char i8; typedef signed short i16; typedef signed int i32; typedef signed long long i64; and I wonder why the original Unix authors didn't make something similar? Instead we have uint64_t and I don't see the added value of more chars. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Thu Dec 7 10:41:25 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 6 Dec 2017 16:41:25 -0800 Subject: [TUHS] how do I unsubscribe In-Reply-To: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> Message-ID: <20171207004125.GB27244@mcvoy.com> Deborah, I'm pretty sure I know the conversation (and I don't believe I was a part of it, just read it) and I'm 100% sure nobody intended to be rude, they were just trying to get at an accurate history of what happened. I can see how you could take offense but I don't think any was intended and it would be a loss if you left. Please reconsider. --lm On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: > Could someone please tell me how to get off this list? I was rather > appalled at the rudeness in the previous conversation... > > Deborah From doug at cs.dartmouth.edu Thu Dec 7 10:45:17 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 06 Dec 2017 19:45:17 -0500 Subject: [TUHS] [groff] [UTROFF] references, summary, index Message-ID: <201712070045.vB70jHKP004480@coolidge.cs.Dartmouth.EDU> Ralph, > > On unjustified text, fmt (which uses an algorithm purported to be like > > Knuth-Plass) > > I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness > that I've seen for a while but never got around to investigating? > > $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q You threw it something of a curve ball--an infinite paragraph. At some point I suppose it chokes, and tries its best to make a semiparagraph of equal-length lines. (Since the real paragraph is not yet complete, it would be wrong to make the last line of the semiparagraph short.) Equilibrating apparently led to the split between 69- and 71-letter lines. Whether the alternation of 11 of one and 16 of the other is an infinite pattern or a subpattern is not clear. It could be part of a continued-fraction approximation, related to the staircse appearance of a bitmap "straight line". Doug From dscherrer at solar.stanford.edu Thu Dec 7 10:55:39 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Wed, 6 Dec 2017 16:55:39 -0800 Subject: [TUHS] how do I unsubscribe In-Reply-To: <20171207004125.GB27244@mcvoy.com> References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207004125.GB27244@mcvoy.com> Message-ID: In the "good old days" of Unix, the community succeeded because we all shared and treated each other with respect. Each listened to the other. Sure, there were disagreements about technical issues, as well there should have been, but they were rarely made personal. That's what made that community great. I liked those times, and loved the people in them. What happened to lose those aspects? I don't think I want to be part of the new community where egos seem to run rampant... Deborah On 12/6/17 4:41 PM, Larry McVoy wrote: > Deborah, > > I'm pretty sure I know the conversation (and I don't believe I was a > part of it, just read it) and I'm 100% sure nobody intended to be > rude, they were just trying to get at an accurate history of what > happened. > > I can see how you could take offense but I don't think any was intended > and it would be a loss if you left. Please reconsider. > > --lm > > On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: >> Could someone please tell me how to get off this list? I was rather >> appalled at the rudeness in the previous conversation... >> >> Deborah From ggm at algebras.org Thu Dec 7 11:17:06 2017 From: ggm at algebras.org (George Michaelson) Date: Thu, 7 Dec 2017 11:17:06 +1000 Subject: [TUHS] [groff] [UTROFF] references, summary, index In-Reply-To: <201712070045.vB70jHKP004480@coolidge.cs.Dartmouth.EDU> References: <201712070045.vB70jHKP004480@coolidge.cs.Dartmouth.EDU> Message-ID: In email. We used to talk about how many nested >>> it made sense to need in a conversation. fmt was usually cited as the arbiter, because you had to give it args to get outside of its limits, which meant you were staring down the barrel of 6-8 >>>>>>>> deep nests for a naieve user. I think, it even came up as a beer conversation of the rule-of-seven. on FreeBSD, its around 64/65 by default. Also MacOSX. Thats a 10+ deep nested conversation of he-said-she-said-they-said-we-all-said mind you, we also argued about top posting. which I am doing. So there. -G On Thu, Dec 7, 2017 at 10:45 AM, Doug McIlroy wrote: > Ralph, > >> > On unjustified text, fmt (which uses an algorithm purported to be like >> > Knuth-Plass) >> >> I wonder if that accounts for modern, coreutils 8.28-1, fmt's weirdness >> that I've seen for a while but never got around to investigating? >> >> $ yes x | fmt | awk '{print length, $0}' | uniq -c | sed 5q > > You threw it something of a curve ball--an infinite paragraph. > At some point I suppose it chokes, and tries its best to make > a semiparagraph of equal-length lines. (Since the real paragraph > is not yet complete, it would be wrong to make the last line of > the semiparagraph short.) > > Equilibrating apparently led to the split between 69- and 71-letter lines. > Whether the alternation of 11 of one and 16 of the other is an infinite > pattern or a subpattern is not clear. It could be part of a continued-fraction > approximation, related to the staircse appearance of a bitmap "straight line". > > Doug From will.senn at gmail.com Thu Dec 7 11:21:48 2017 From: will.senn at gmail.com (Will Senn) Date: Wed, 6 Dec 2017 19:21:48 -0600 Subject: [TUHS] how do I unsubscribe In-Reply-To: References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207004125.GB27244@mcvoy.com> Message-ID: Hi Deborah, I appreciate your comment. We need to be civil, especially in a world where so little civility remains. We who celebrate the past do not want our efforts to be diminished by our base demeanor. I do not think leaving is the best option, however. Perhaps this could serve as a call to our more honorable selves to step up and rethink our netiquette. Stick it out and see if the dialog improves in tone after your putting the community on notice. I think most folks on the list are reasonable and honestly desirous of a positive community experience. Regards, Will On 12/6/17 6:55 PM, Deborah Scherrer wrote: > In the "good old days" of Unix, the community succeeded because we all > shared and treated each other with respect.  Each listened to the > other.  Sure, there were disagreements about technical issues, as well > there should have been, but they were rarely made personal. That's > what made that community great.  I liked those times, and loved the > people in them.   What happened to lose those aspects?   I don't think > I want to be part of the new community where egos seem to run rampant... > > Deborah > > On 12/6/17 4:41 PM, Larry McVoy wrote: >> Deborah, >> >> I'm pretty sure I know the conversation (and I don't believe I was a >> part of it, just read it) and I'm 100% sure nobody intended to be >> rude, they were just trying to get at an accurate history of what >> happened. >> >> I can see how you could take offense but I don't think any was intended >> and it would be a loss if you left.  Please reconsider. >> >> --lm >> >> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: >>> Could someone please tell me how to get off this list?  I was rather >>> appalled at the rudeness in the previous conversation... >>> >>> Deborah > > -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From angus at fairhaven.za.net Thu Dec 7 11:29:47 2017 From: angus at fairhaven.za.net (Angus Robinson) Date: Thu, 07 Dec 2017 01:29:47 +0000 Subject: [TUHS] how do I unsubscribe In-Reply-To: References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207004125.GB27244@mcvoy.com> Message-ID: Hi Deborah I remember a time like that, although this was the early 2000's. I joined a group of students at the local university. I must admit, Although the students where abit arrogant, I learned alot not only from them but from the staff that worked at the Computer Science department. I also learnt that an old family friend helped start the Internet in South Africa. From that, I learnt alot about history and to think outside of the box, with what they "Jimmy Rigged" to save bandwidth in the early days. I have been this mailing list for years and like then, I have learnt alot. Not only about history but the basis for the technology we have now. Unlike the students, it's extremely rare that egos come in to play. I think this is the first. Granted I only read about 80% of the list due to time. If I may be so bold and to ask you to to maybe remain a subscriber to the list. As Larry has pointed out it would be a shame to have somebody with knowledge depart due to a rare occurrence. On Wed, Dec 6, 2017 at 4:55 PM Deborah Scherrer < dscherrer at solar.stanford.edu> wrote: > In the "good old days" of Unix, the community succeeded because we all > shared and treated each other with respect. Each listened to the > other. Sure, there were disagreements about technical issues, as well > there should have been, but they were rarely made personal. That's what > made that community great. I liked those times, and loved the people in > them. What happened to lose those aspects? I don't think I want to > be part of the new community where egos seem to run rampant... > > Deborah > > On 12/6/17 4:41 PM, Larry McVoy wrote: > > Deborah, > > > > I'm pretty sure I know the conversation (and I don't believe I was a > > part of it, just read it) and I'm 100% sure nobody intended to be > > rude, they were just trying to get at an accurate history of what > > happened. > > > > I can see how you could take offense but I don't think any was intended > > and it would be a loss if you left. Please reconsider. > > > > --lm > > > > On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: > >> Could someone please tell me how to get off this list? I was rather > >> appalled at the rudeness in the previous conversation... > >> > >> Deborah > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Dec 7 11:32:10 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 6 Dec 2017 18:32:10 -0700 Subject: [TUHS] how do I unsubscribe In-Reply-To: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> Message-ID: <7CCA5485-7ED7-4E47-8865-28DBDEE4954B@tnetconsulting.net> Hi Deborah, I too would prefer that you stay subscribed and hold the rest of us in the community to a higher standard. You asked a direct question, which deserves a direct answer. If you choose to unsubscribe, you can do so at the following page. http://minnie.tuhs.org/mailman/listinfo/tuhs Thank you for your contributions. -- Grant. . . . unix || die > On Dec 6, 2017, at 5:39 PM, Deborah Scherrer wrote: > > Could someone please tell me how to get off this list? I was rather appalled at the rudeness in the previous conversation... > > Deborah > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2338 bytes Desc: not available URL: From lm at mcvoy.com Thu Dec 7 11:33:08 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 6 Dec 2017 17:33:08 -0800 Subject: [TUHS] how do I unsubscribe In-Reply-To: References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207004125.GB27244@mcvoy.com> Message-ID: <20171207013308.GI27244@mcvoy.com> +1 Will. And just as an aside, Deborah used to be president of Usenix. She's part of the history that this list is all about, I've appealed to her as well to stick around. Deborah, for the record, if it helps at all, Warren (who runs the list), has booted at least one person who was not so cool (I'm biased because I got into with that person, just so you know). If people are repeatedly out of line, it's very rare that happens, but if they are it will get taken care of. This is a friendly place, rudeness is not part of the list. I want to keep as many people around as possible, I love Unix, love the history of it all, more history, more better. Please consider giving the list a second chance. --lm On Wed, Dec 06, 2017 at 07:21:48PM -0600, Will Senn wrote: > Hi Deborah, > > I appreciate your comment. We need to be civil, especially in a world where > so little civility remains. We who celebrate the past do not want our > efforts to be diminished by our base demeanor. I do not think leaving is the > best option, however. Perhaps this could serve as a call to our more > honorable selves to step up and rethink our netiquette. Stick it out and see > if the dialog improves in tone after your putting the community on notice. I > think most folks on the list are reasonable and honestly desirous of a > positive community experience. > > Regards, > > Will > > On 12/6/17 6:55 PM, Deborah Scherrer wrote: > >In the "good old days" of Unix, the community succeeded because we all > >shared and treated each other with respect.? Each listened to the other.? > >Sure, there were disagreements about technical issues, as well there > >should have been, but they were rarely made personal. That's what made > >that community great.? I liked those times, and loved the people in > >them.?? What happened to lose those aspects??? I don't think I want to be > >part of the new community where egos seem to run rampant... > > > >Deborah > > > >On 12/6/17 4:41 PM, Larry McVoy wrote: > >>Deborah, > >> > >>I'm pretty sure I know the conversation (and I don't believe I was a > >>part of it, just read it) and I'm 100% sure nobody intended to be > >>rude, they were just trying to get at an accurate history of what > >>happened. > >> > >>I can see how you could take offense but I don't think any was intended > >>and it would be a loss if you left.? Please reconsider. > >> > >>--lm > >> > >>On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: > >>>Could someone please tell me how to get off this list?? I was rather > >>>appalled at the rudeness in the previous conversation... > >>> > >>>Deborah > > > > > > -- > GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From ron at ronnatalie.com Thu Dec 7 12:49:30 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 6 Dec 2017 21:49:30 -0500 Subject: [TUHS] standard types In-Reply-To: <20171207003941.GA27244@mcvoy.com> References: <20171207003941.GA27244@mcvoy.com> Message-ID: <012801d36f06$01e33230$05a99690$@ronnatalie.com> The standard includes a similar set of typedefs. The problem is that this does little to insure portability. From wkt at tuhs.org Thu Dec 7 14:11:00 2017 From: wkt at tuhs.org (Warren Toomey) Date: Thu, 7 Dec 2017 14:11:00 +1000 Subject: [TUHS] how do I unsubscribe In-Reply-To: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> Message-ID: <20171207041100.GA6532@minnie.tuhs.org> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: >Could someone please tell me how to get off this list? Deborah, I'll also add my voice in to ask for you to stay on the list. There were things said that could have been expressed better, but I don't think that there was malicious intent. You bring a wealth of knowledge and experience to the TUHS list, and the list would be poorer in your absence. Yours sincerely, Warren From ken at google.com Thu Dec 7 14:26:05 2017 From: ken at google.com (Ken Thompson) Date: Wed, 6 Dec 2017 20:26:05 -0800 Subject: [TUHS] how do I unsubscribe In-Reply-To: <20171207041100.GA6532@minnie.tuhs.org> References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207041100.GA6532@minnie.tuhs.org> Message-ID: Deborah, you've made this a better place, so, please stay. ken On Wed, Dec 6, 2017 at 8:11 PM, Warren Toomey wrote: > On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: >> >> Could someone please tell me how to get off this list? > > > Deborah, I'll also add my voice in to ask for you to stay on the list. > There were things said that could have been expressed better, but I > don't think that there was malicious intent. You bring a wealth of > knowledge and experience to the TUHS list, and the list would be > poorer in your absence. > > Yours sincerely, Warren From akosela at andykosela.com Thu Dec 7 14:40:21 2017 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 6 Dec 2017 22:40:21 -0600 Subject: [TUHS] how do I unsubscribe In-Reply-To: References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207004125.GB27244@mcvoy.com> Message-ID: On Wednesday, December 6, 2017, Deborah Scherrer < dscherrer at solar.stanford.edu> wrote: > In the "good old days" of Unix > > > I don't think I want to be part of the new community where egos seem to > run rampant... > > I do not want to add more fuel to the debate or even to judge anyone in it, but just like to point out that egos were always big in this community, or any other community, technical or not. It is just part of a human nature. If there would not be egos running rampant, we would have one, and not four Open Source BSD projects now. And dont even start me on the ego of RMS or Linus... :D It is a fallacy to believe that in the "good old days" people were better. There is nothing new under the Sun and people were always the same... for better or for worse. Just my $0.02 --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Dec 7 15:08:20 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 06 Dec 2017 21:08:20 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> , <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: <201712070508.vB758KqJ005950@darkstar.fourwinds.com> William Corcoran writes: > Well, sure in 1963 the T1 carrier was a huge pipe. It was a huge pipe in > 1970. It was also a huge pipe in 1980 for business. (Not so for the telcos, > as ATT had Metrobus in the 80’s and the telcos had SONET in the > 90’s—-completely inaccessible but to the largest corporations) > > However, today, I have Fios with nearly 1 Gigabit up and down for a small fee. > > > Thank you Judge Greene! > > (Let’s not forget, I now have access to a working v7 for free where the license > previously cost $28,000.) > > > Bill Corcoran Well yes, the consent degree made that possible. But remember that a whole pile of the technology came from BTL and that sort of stuff isn't getting done at the same level without research funding. And lucky you. I pay $450/month for a T1 which is the best that I can get where I live because there is no universal service. From grog at lemis.com Thu Dec 7 15:15:38 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 7 Dec 2017 16:15:38 +1100 Subject: [TUHS] Dash options In-Reply-To: <20171205132211.gYVHH%steffen@sdaoden.eu> References: <201711280551.vAS5pDZt014974@darkstar.fourwinds.com> <20171128062845.GB5277@eureka.lemis.com> <20171129191643.XPHH3%steffen@sdaoden.eu> <20171204054651.GA17671@eureka.lemis.com> <20171204215701.l9Pvr%steffen@sdaoden.eu> <20171205132211.gYVHH%steffen@sdaoden.eu> Message-ID: <20171207051538.GB78437@eureka.lemis.com> On Tuesday, 5 December 2017 at 14:22:11 +0100, Steffen Nurpmeso wrote: > Hello. > >>> On Wednesday, 29 November 2017 at 20:16:43 +0100, Steffen Nurpmeso wrote: >>>> Greg 'groggy' Lehey wrote: > ||>> @ADD,PL ASGDMS . ASSIGNIERT DATENBASIS > ||> > ||> "WEIßT DATENBASIS ZU" or "ZUWEISUNG DATENBASIS" > ... > ||>> @ASG,A PF. . PF IST PROGRAMM-FILE MIT GOPU > ||> > ||> "PF IST PROGRAMM-DATEI MIT GOPU" or so. > ... > > I have apologised for this brusque and rude tone in private. Particularly in view of other posts on this list, I'd like to note that I didn't take it to be rude. > Unfortunately Greg Lehey was the one who took up that thread. > Puh; he is also right correcting my statements, it should have > been "Weist Datenbasis zu" and "PF ist Programmdatei mit GOPU" > instead of what i falsely claimed. > >> The question that should have been asked with mild interest and >> very kind should have been "Why has German been used to comment >> this code?" at first, i am afraid to realize. This was a random choice of code that I happened to have on my machine. It was documentation for code written in Mannheim in November 1973. Arguably I should have removed the comments, but I thought that the comment syntax was of marginal interest. This has nothing more to do with Unix (it barely had in the first place), so let's forget it. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From dave at horsfall.org Thu Dec 7 15:21:36 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 7 Dec 2017 16:21:36 +1100 (EST) Subject: [TUHS] THANK YOU for flavors! (fwd) In-Reply-To: <20171207045615.GA78437@eureka.lemis.com> References: <20171207045615.GA78437@eureka.lemis.com> Message-ID: On Thu, 7 Dec 2017, Greg 'groggy' Lehey wrote: >> On Thu, 7 Dec 2017 11:01:51 +1100 (EST), Dave Horsfall wrote: > > Since we're being pedantic, note that this should be AEDT. EST is > ambiguous, but in general refers to the east coast of the USA. That appears to be how Alpine formats it (I certainly didn't write it)... If it can be overridden then naturally I'm all ears. >>> Serious question: is "FLAVOUR" accepted as an alias, or does the rest >>> of the world have to put up with American spelling? > > Think of it as a keyword. No national origin necessary. Fair enough, I suppose. > We really have better things to think of. Indeed; in the meantime I see you finally fixed your DNS... Yes, I 4xx mail from servers with an improper chain, in the hope that they'll eventually notice (it catches a lot of spammers). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jsteve at superglobalmegacorp.com Thu Dec 7 15:05:57 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 7 Dec 2017 13:05:57 +0800 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: They might actually. Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel. The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there. From: Dave Horsfall Sent: Thursday, 7 December 2017 6:33 AM To: The Eunuchs Hysterical Society Subject: Re: [TUHS] What UNIX Artifacts Are Still Missing? On Wed, 6 Dec 2017, Paul Ruizendaal wrote: > That is a good point: early Xenix is still missing. It would make an > excellent public relations move for Microsoft if they would make early > Xenix available to celebrate 50 years of Unix. Call me a cynical old bastard (which I am), but I can't see M$ raising a flag for Unix... Wasn't it Billy Gates who reportedly said that any PC running Linux is one not running Windoze, and did his best to discredit it? I still have horrible memories of porting Unify (an early RDBMS) to Xenix, and getting tangled up in the poxy small/large memory models on the equally-poxy 286 (no, not the 386). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Dec 7 15:27:52 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 7 Dec 2017 00:27:52 -0500 (EST) Subject: [TUHS] how do I unsubscribe Message-ID: <20171207052752.2351E18C09B@mercury.lcs.mit.edu> So, I'm getting the impression, from the reactions about civility, etc, that people aren't disagreeing with the characterization of "rudeness" (which can only be meaning my posts). Can someone please point to text in my messages which they consider "rude"? Thanks. Noel From akosela at andykosela.com Thu Dec 7 15:40:56 2017 From: akosela at andykosela.com (Andy Kosela) Date: Wed, 6 Dec 2017 23:40:56 -0600 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On Wednesday, December 6, 2017, Dave Horsfall wrote: > On Wed, 6 Dec 2017, Paul Ruizendaal wrote: > > That is a good point: early Xenix is still missing. It would make an >> excellent public relations move for Microsoft if they would make early >> Xenix available to celebrate 50 years of Unix. >> > > Call me a cynical old bastard (which I am), but I can't see M$ raising a > flag for Unix... Wasn't it Billy Gates who reportedly said that any PC > running Linux is one not running Windoze, and did his best to discredit it? > > I still have horrible memories of porting Unify (an early RDBMS) to Xenix, > and getting tangled up in the poxy small/large memory models on the > equally-poxy 286 (no, not the 386). > > I can understand no love for Xenix on this list, but actually M$ is part of the UNIX history and was actually quite successful with Xenix[1]. In the late 80s there were more computers running M$ Xenix than all other versions of UNIX combined. Some good history here: http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml --Andy [1] https://books.google.com/books?id=UE1HODexHKoC&pg=PA44#v=onepage&q&f=false -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Dec 7 15:46:56 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 7 Dec 2017 16:46:56 +1100 (EST) Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On Thu, 7 Dec 2017, Jason Stevens wrote: [ M$ donating Xenix or not ] > They might actually.  Gates isn’t in charge, and there has been a major > effort to being Linux compatibility into the Windows 10 kernel. I'd be happy to be proven wrong; in fact, I'll donate say $10 -- that's all I can afford -- to the TUHS Foundation (if there is one, otherwise the John Lions Chair) if it happens. Who'll join me? > The biggest issue will be the never ending tangle of licenses, if they > had other stuff integrated into there. Shakespeare certainly had it right (Henry VI, Act 4, Part 2)... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From robert at timetraveller.org Thu Dec 7 15:56:29 2017 From: robert at timetraveller.org (Robert Brockway) Date: Thu, 7 Dec 2017 15:56:29 +1000 (AEST) Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On Thu, 7 Dec 2017, Dave Horsfall wrote: > Call me a cynical old bastard (which I am), but I can't see M$ raising a flag > for Unix... Wasn't it Billy Gates who reportedly said that any PC running > Linux is one not running Windoze, and did his best to discredit it? Microsoft today is not the company of old. In recent years Microsoft has participated in standards bodies and worked on interoperability with other browser vendors. They even joined the Linux Foundation last year. https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/ Cheers, Rob From imp at bsdimp.com Thu Dec 7 16:07:58 2017 From: imp at bsdimp.com (Warner Losh) Date: Wed, 6 Dec 2017 23:07:58 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On Wed, Dec 6, 2017 at 10:56 PM, Robert Brockway wrote: > On Thu, 7 Dec 2017, Dave Horsfall wrote: > > Call me a cynical old bastard (which I am), but I can't see M$ raising a >> flag for Unix... Wasn't it Billy Gates who reportedly said that any PC >> running Linux is one not running Windoze, and did his best to discredit it? >> > > Microsoft today is not the company of old. In recent years Microsoft has > participated in standards bodies and worked on interoperability with other > browser vendors. They even joined the Linux Foundation last year. > > https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/ Yea, I wonder if there's anyway to get the early Xenix code bases? They are the same age as the MS-DOS versions they released to the kinda-sorta-almost public domain... Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Thu Dec 7 16:14:15 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Wed, 06 Dec 2017 22:14:15 -0800 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> Robert Brockway writes: > On Thu, 7 Dec 2017, Dave Horsfall wrote: > > > Call me a cynical old bastard (which I am), but I can't see M$ raising a flag > > for Unix... Wasn't it Billy Gates who reportedly said that any PC running > > Linux is one not running Windoze, and did his best to discredit it? > > Microsoft today is not the company of old. In recent years Microsoft has > participated in standards bodies and worked on interoperability with other > browser vendors. They even joined the Linux Foundation last year. > > https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/ > > Cheers, > > Rob Don't know how much time you've spent on standards committees; I've done my time. Standards committees are not filled with altruistic folks working to make something great. Much of the time people are there to prevent a standard from interfering with their market, or to prevent a good standard from being adopted. The examples of the NSA participating on crypto committees to weaken the standards got a lot of press and is emblematic of what happens. Microsoft has a well documented record of using standards to screw the competition so I didn't read any goodness into their joining up. I would agree that they're not the company of old in that they got themselves trounced by Apple and are no longer top dog and able to tell others what they're allowed to do. Jon From jsteve at superglobalmegacorp.com Thu Dec 7 16:14:30 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 7 Dec 2017 14:14:30 +0800 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: I know in ’87 Microsoft was working on ‘Football’ (http://www.os2museum.com/wp/playing-football/) which was what would eventually ship as OS/2 2.0, and Windows/386 launched in 1987, for the Compaq deskpro 386, and a NEC 386 model. I see that VP/IX was announced in 1986, with a ship date for 87 as well (https://books.google.com.hk/books?id=C5n2J7iQenwC&pg=PA13&lpg=PA13&dq=VP/IX+emulation+1987&source=bl&ots=4XABChXAMZ&sig=65eY7UV3UVjiji5mK8ZWrxFAc6k&hl=en&sa=X&ved=0ahUKEwiZkqO6nffXAhULlJQKHXJlADkQ6AEIJzAA#v=onepage&q=VP%2FIX%20emulation%201987&f=false) Not to mention products like VM/386 on the PC front. The hypervisor market was pretty hot, but I guess the price of RAM basically cooled things off pretty quickly. I had recently bought a copy of Citrix MULTIUSER 2.0 and it’s kind of weird trying to bring terminal functionality to OS/2. Its funny how NT had a POSIX subsystem that really wasn’t much good for anything other than tar & vi, and decided that if the implementation was too strong nobody would write Win32 apps (much like what happened to OS/2). Meanwhile a massive ecosystem built around Linux grew that they were unable to get people to use natively. From: Clem Cole Sent: Thursday, 7 December 2017 1:16 AM To: Paul Ruizendaal Cc: tuhs at minnie.tuhs.org Subject: Re: [TUHS] What UNIX Artifacts Are Still Missing? On Wed, Dec 6, 2017 at 9:33 AM, Paul Ruizendaal wrote: ​A​ lthough Xenix predates Venix, I'm not sure it predates it on PC hardware.  ​It really depends how you count.   I was there at time when AT&T was negotiating the replacement for the V7 license with 10 of us (the 10 firms included Microsoft - the only time I can say I was in the room with Willy G. - but that's another story)​.  This work would become the System III license. ​Xenix, which was V7 based originally, was target for the generic 8086 systems (as well as PDP-11, 68K and Z8000) but the Intel support was generic so it included the PC.   The bigger problem is that it really wanted a hard disk, which made its target a 'high end' computer in those days.  Running on a floppy was sort of possible (besides slow, it tended to wear out the oxide in the center of the disk where the superblock and i-list was storied from all r/w - I used to have an 8" floppy sans case hanging in my office).   But that said, the V7 based license was terrible for a 'small value system' and I'm not sure Microsoft shipped much against it.   That was the primary reason they wanted to a new license [Gate's line at the time: 'You guys don't get it.  The only thing that matters is volume.'].   So until the System III license, which is what Xenix 2.0 and later shipped, I don't think Microsoft really had much presence.  But at that time, Microsoft [via Bob Greenburg a founder and the only one of Gates roommates at Harvard to graduate btw] was trying to a UNIX porting house, similar to HCR.   That had been the original vision of Xenix, they would OEM the SW to other firms that build HW, just like they did for BASIC and were beginning to do for FORTRAN and COBOL. As you point out, other firms such as ISC, HCR and Locus appeared on the scene as more UNIX knowledgeable.   I also think IBM already had placed big bets on Microsoft for DOS and BASIC, so they wanted to spread the risk a little which is why ISC got the original UNIX for the PC HW deal.   Once Microsoft had Xenix stable, IBM was already their customer so selling Xenix on IBM was a secondary issue. For a little more on the history front; my former boss, Phill Shevrin, who would later switch from ISC to Locus where I worked for him, pulled what I always thought was one of the great tricks of salesmanship in the UNIX business.  When he was at ISC, he sold for $1.5M a 'port' to the 386 of System III to each of IBM, AT&T and Intel.   He got paid three times for same work and got to sell the result as their own product when they were done. Also, from a historical standpoint, I hope we do have the ISC 386 code base - that was the first of the 32-bit linear UNIX ports for the x86 systems.  The other thing that we should try to find is the Phoenix Tech VP/IX code base and the Locus Merge Code base.   These were the first VM/hypervisors.  They ran in PC/IX 386 and allowed Windows to run under it, long before VMware existed. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at timetraveller.org Thu Dec 7 17:02:01 2017 From: robert at timetraveller.org (Robert Brockway) Date: Thu, 7 Dec 2017 17:02:01 +1000 (AEST) Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> Message-ID: On Wed, 6 Dec 2017, Jon Steinhart wrote: > Don't know how much time you've spent on standards committees; I've done > my time. Standards committees are not filled with altruistic folks > working to make something great. Much of the time people are there to > prevent a standard from interfering with their market, or to prevent a > good standard from being adopted. The examples of the NSA participating > on crypto committees to weaken the standards got a lot of press and is > emblematic of what happens. Microsoft has a well documented record of > using standards to screw the competition so I didn't read any goodness > into their joining up. I would agree that they're not the company of > old in that they got themselves trounced by Apple and are no longer top > dog and able to tell others what they're allowed to do. I'm not suggesting any sort of altruism on the part of MS (or any other company). I have been very critical of MS in the past and was initially skeptical when they started to open up. IIRC one of the first signs of change was when they called the Mozilla Foundation and asked for a meeting. They met with the Mozilla Foundation and started working on interoperability. Many in the FOSS community were skeptical but that was a lot of years ago. I haven't seen any "embrace and extend" for many years. I'd be interested if anyone else has. The evidence I'm seeing suggests that today they consider working with others to be in their best interests. As you note they can no longer throw their weight around in the way they used to. No doubt that's a driver for change. If someone had told me 20 years ago that I'd be sitting here today defending Microsoft's involvement in FOSS... ;) Rob From arnold at skeeve.com Thu Dec 7 18:33:42 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 07 Dec 2017 01:33:42 -0700 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: <201712060553.vB65rFa3002734@freefriends.org> <201712060800.vB680wXG013646@freefriends.org> Message-ID: <201712070833.vB78XgQo028687@freefriends.org> > On Wed, 6 Dec 2017, arnold at skeeve.com wrote: > > > "goto" was in the V6 shell, I think (next to no experience with the V6 > > shell, and it was a LONG time ago anyway). But there never was a goto > > in the V7 shell. Dave Horsfall wrote: > Never got to use the V7 shell; we were stuck with 11/40s[*] :-( It was > certainly in the V6 shell, hence by bafflement at why labels were of the > form ": blah" instead of the sensible "blah: "... Come now, since then you've *never* used any kind of Bourne shell? BSD on vax? SunOS? System III or System V on anything else? You've been stuck in a time warp for 35 years? :-) Arnold From ralph at inputplus.co.uk Thu Dec 7 21:28:38 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 07 Dec 2017 11:28:38 +0000 Subject: [TUHS] how do I unsubscribe In-Reply-To: <20171207052752.2351E18C09B@mercury.lcs.mit.edu> References: <20171207052752.2351E18C09B@mercury.lcs.mit.edu> Message-ID: <20171207112838.2DF411FB3E@orac.inputplus.co.uk> Hi Noel, > So, I'm getting the impression, from the reactions about civility, > etc, that people aren't disagreeing with the characterization of > "rudeness" (which can only be meaning my posts). Can someone please > point to text in my messages which they consider "rude"? Thanks. I've just read through a large backlog and so saw all the emails in quick succession, and have then re-read from the archive. I can't point to ones where you were rude. You politely disagreed with recollections, e.g. from Deborah, giving references to literature, or statements, e.g. Jon F.'s `LBL has never been part of UC Berkeley'. You may have been pedantic, but you didn't make it personal, and I saw no rampant ego. This is a history list and, though in living memory, much of it is unwritten, vague, and contradictory. If we're not allowed to politely disagree then we won't work to clarify. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From ralph at inputplus.co.uk Thu Dec 7 21:42:12 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 07 Dec 2017 11:42:12 +0000 Subject: [TUHS] standard types In-Reply-To: <20171207003941.GA27244@mcvoy.com> References: <20171207003941.GA27244@mcvoy.com> Message-ID: <20171207114212.BFC561FB3E@orac.inputplus.co.uk> Hi Larry, > Instead we have uint64_t and I don't see the added value of more > chars. The `_t' suffix plonks them in the area that POSIX has reserved so if they do clash with existing ones that's the user's fault. Perhaps they felt the `uint' was still short enough and containing `int' was mnemonic. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From ralph at inputplus.co.uk Thu Dec 7 21:50:24 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 07 Dec 2017 11:50:24 +0000 Subject: [TUHS] looking for a quote In-Reply-To: <20171207003439.GB24409@mcvoy.com> References: <20171207003439.GB24409@mcvoy.com> Message-ID: <20171207115024.217CA1FB3E@orac.inputplus.co.uk> Hi Larry, > I *much* prefer sbuf.st_size than whatever.size, the former is > instantly a stat structure, the later is a "whatever". It's awful. :-) st.st_size `stutters' and that jars when reading in my head. If st.size isn't clear from context, then stbuf.size probably is. Ditto ar_hdr->uid versus hdr->ar_uid. There's a hierarchy to walking the data structure, and that should be represented in the identifiers. So big.little, not b.bg_little. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From pnr at planet.nl Thu Dec 7 22:09:21 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 7 Dec 2017 13:09:21 +0100 Subject: [TUHS] Early Xenix source code (was: What UNIX Artifacts Are Still Missing?) In-Reply-To: References: Message-ID: <785FE15D-D755-41D1-AE4F-F5F4E1F3025E@planet.nl> > They might actually. Gates isn’t in charge, and there has been a major effort to being Linux compatibility into the Windows 10 kernel. I agree that they might. Once there was strong commercial logic to disown their Unix history; that commercial logic may have reversed in the last decade. > The biggest issue will be the never ending tangle of licenses, if they had other stuff integrated into there. Let’s analyse that bit: - They could pick the Nokia solution, i.e. to simply make an undertaking not to sue and thus avoid taking a position on Unix ownership etc. - It would seem that Xenix 2 (no apparent version 1?) was more or less V7 and for internal use only (lacking a binary redistribution license, as Clem pointed out). Very little chance of 3rd party source code in there, but also of little interest for the historical record. - The first real ports occur with Xenix 2.x in 1981-83. This would appear to have been based on System III with the PDP-11, Z8000, 68000 and 8086 as targets. Considering the size of MS at the time and how busy they were with IBM and DOS I don’t think they would have had much time to do more than a basic port: they contracted out much of the work to SCO, a two man shop at the time. It would seem that MS owned the IP with SCO being a contractor & part-owned subsidiary. - This Altos manual https://web.archive.org/web/20170222131722/http://www.tenox.net/docs/xenix/Altos_Intro_to_Xenix.pdf actually says that Xenix 2.x was still based on V7 and would seem to be a vanilla port, i.e. unlikely to include other stuff than V7, some 2BSD and of course MS' own stuff. - The next release, Xenix 3.0 in 83-84, still appears to be SysIII based and would remain easy from that perspective. However, given two years of polishing it may have picked up bits and pieces from the outside and the tool chains probably started to include MS’ own compilers, it would be harder to figure out what could be released. However, looking at this highly interesting leaflet http://www.os2museum.com/wp/wp-content/uploads/2012/10/IBM-Seminar-Proceedings-Vol2-No9.pdf it would seem that it is still all SysIII, BSD and Microsoft code. In my opinion the real hurdle is finding a retired MS VP who’s interested in knocking on doors and making the case for this public relations move. Paul PS: There is scope for confusion over version numbers. It would seem that MS never directly sold Xenix, only via OEM’s. For example, IBM PC Xenix 1.0 would appear to be the same as MS Xenix 3.0 From ron at ronnatalie.com Fri Dec 8 00:03:11 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 7 Dec 2017 09:03:11 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <20171206203057.GA72441@wopr> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> <20171206203057.GA72441@wopr> Message-ID: <017001d36f64$1e7f0550$5b7d0ff0$@ronnatalie.com> T1 wasn't cheap nor ubiquitous. I ran the networking for the degree granting public colleges in NJ (which on the whole is a fairly metropolitan area) but there were places we couldn't get it. It was also expensive. Old school copper T1 required repeaters every quarter mile or so. Debugging could be fun. At least our telco (NJ Bell) back then could move the loop back around while I did tests to tell them where the line was failing. And yeah, I live in one of those backwaters now. No cable, no fiber optic anything. I use two DSL lines to get an aggregate 20M down 1.5M up. That's the best the vesiges of the old GTE telco down here can do. ATT has fiber in communities down the road but we're too sparse to attract their interest. Comcast won't even pull in a local drop from the main road. From ron at ronnatalie.com Fri Dec 8 00:26:18 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 7 Dec 2017 09:26:18 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <7a457110-994a-4a08-c47b-9e17ff369d41@gmail.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> <7a457110-994a-4a08-c47b-9e17ff369d41@gmail.com> Message-ID: <017501d36f67$59ade6c0$0d09b440$@ronnatalie.com> Ø For AT&T (which no longer is a company since the current AT&T is really AT&T in name only. SBC Communications bought AT&T Corp. on November 18, 2005, and changed its name to AT&T Inc. (The real AT&T is no longer...) Well SBC was one of the RBOCs so while it wasn’t the post-Greene ATT, it is a decent chunk of the original monopoly. Not only the old BellSouth but also Illinois, Inndiana, Michigan, Ohio, Pacific, Southwestern and Pacific Bells. They did acquire the old long lines AT&T and wireless sytem. Of course AT&T and already spun out what we would have called Western Electric in the days (and hence the UNIX heritage). -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Fri Dec 8 00:28:24 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 07 Dec 2017 09:28:24 -0500 Subject: [TUHS] Misguided standsads (was What UNIX Artifacts Are Still Missing?) Message-ID: <201712071428.vB7ESOKg009870@coolidge.cs.Dartmouth.EDU> > Standards committees are not filled with altruistic folks working to > make something great. Not only in big ways, such as to sway the market. An example from Posix is the undefined meaning of malloc(0). As I understand it, just one committee member held out for malloc(0) to be an optional error, thus confounding a harmless corner case with a fatal error. This nit has burdened conscientious programmers ever since, all so one company's easily fixable variant could be grandfathered into compliance. Doug From lm at mcvoy.com Fri Dec 8 00:59:47 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 7 Dec 2017 06:59:47 -0800 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> Message-ID: <20171207145947.GB6170@mcvoy.com> On Wed, Dec 06, 2017 at 10:14:15PM -0800, Jon Steinhart wrote: > Robert Brockway writes: > > On Thu, 7 Dec 2017, Dave Horsfall wrote: > > > > > Call me a cynical old bastard (which I am), but I can't see M$ raising a flag > > > for Unix... Wasn't it Billy Gates who reportedly said that any PC running > > > Linux is one not running Windoze, and did his best to discredit it? > > > > Microsoft today is not the company of old. In recent years Microsoft has > > participated in standards bodies and worked on interoperability with other > > browser vendors. They even joined the Linux Foundation last year. > > > > https://techcrunch.com/2016/11/16/microsoft-joins-the-linux-foundation/ > > > > Cheers, > > > > Rob > > Don't know how much time you've spent on standards committees; I've done my > time. Standards committees are not filled with altruistic folks working to > make something great. Much of the time people are there to prevent a standard > from interfering with their market, or to prevent a good standard from being > adopted. The examples of the NSA participating on crypto committees to weaken > the standards got a lot of press and is emblematic of what happens. Microsoft > has a well documented record of using standards to screw the competition so I > didn't read any goodness into their joining up. I would agree that they're not > the company of old in that they got themselves trounced by Apple and are no > longer top dog and able to tell others what they're allowed to do. My first job at Sun was POSIX conformance. As such, I worked a lot with the Sun POSIX guy, Don Cragun. He must have been the exception that proves your rule because he definitely matched the description of an altruistic person trying to make things better. They aren't all bad. From lm at mcvoy.com Fri Dec 8 01:09:03 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 7 Dec 2017 07:09:03 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <201712070508.vB758KqJ005950@darkstar.fourwinds.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> <201712070508.vB758KqJ005950@darkstar.fourwinds.com> Message-ID: <20171207150903.GC6170@mcvoy.com> On Wed, Dec 06, 2017 at 09:08:20PM -0800, Jon Steinhart wrote: > And lucky you. I pay $450/month for a T1 which is the best that I can get where > I live because there is no universal service. For you folks with crappy net connections, first I have felt your pain, my condolences. I live in the Santa Cruz mountains in a rural area even for the mountains. So no cable, no reliable DSL. But what we do have is line of sight to a tower on Loma Prieta. I worked a deal with Etheric where I get 8Mbit down and up guaranteed and they let it burst to available space on the radio. I average about 20 down/up, it sometimes goes lower but that's the average. Just tried now and 25 down/up. I worked a 5 year prepaid deal with them and got them down to $130/month. It's point to point wifi and works really well. See if you can get some of that. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jnc at mercury.lcs.mit.edu Fri Dec 8 01:14:20 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 7 Dec 2017 10:14:20 -0500 (EST) Subject: [TUHS] What UNIX Artifacts Are Still Missing? Message-ID: <20171207151420.3DB5D18C09E@mercury.lcs.mit.edu> > From: Larry McVoy > an altruistic person trying to make things better. They aren't all bad. I would echo that. During my time on the IESG, I'd say the vast majority of the people in the IETF really did want to make things better for everyone. Of course, that statement covers a vast range of subtle variations, from people who had nothing at all to gain personally, and thus really were pushing what they thought was best; through people who did stand to gain, but truly thought that what they were advocating was in everyone's interest; etc. But the people who I felt were deliberately and knowingly putting their own interests before the community's, i.e. recommending something they knew to be harmful because it was good for them - they were very rare. My recollection is now somewhat dim (too much was happening, at too high a pace) of the details of those later days (well, 'later' only in that they were considerably later than the very early days :-), but my sense is that people like that didn't last long in the community; I have the distinct impression that people figured them out, and as an eventual result, they tended to fade from the scene. The IETF culture was not welcoming to that kind of thinking. I dunno, maybe I'm just being naive (and I would certainly welcome correction if I'm wrong), but that's how I saw it. Noel From rminnich at gmail.com Fri Dec 8 01:24:53 2017 From: rminnich at gmail.com (ron minnich) Date: Thu, 07 Dec 2017 15:24:53 +0000 Subject: [TUHS] looking for a quote In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> Message-ID: I think the issue was when the folks at UCB added very long symbol names to the C compiler On Thu, Dec 7, 2017 at 3:50 AM Ralph Corderoy wrote: > Hi Larry, > > > I *much* prefer sbuf.st_size than whatever.size, the former is > > instantly a stat structure, the later is a "whatever". > > It's awful. :-) > st.st_size `stutters' and that jars when reading in my head. > If st.size isn't clear from context, then stbuf.size probably is. > Ditto ar_hdr->uid versus hdr->ar_uid. > > There's a hierarchy to walking the data structure, and that should be > represented in the identifiers. So big.little, not b.bg_little. > > -- > Cheers, Ralph. > https://plus.google.com/+RalphCorderoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Fri Dec 8 01:27:40 2017 From: steve at quintile.net (Steve Simon) Date: Thu, 7 Dec 2017 15:27:40 +0000 Subject: [TUHS] looking for a quote In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> Message-ID: +100 > On 7 Dec 2017, at 11:50, Ralph Corderoy wrote: > > Hi Larry, > >> I *much* prefer sbuf.st_size than whatever.size, the former is >> instantly a stat structure, the later is a "whatever". > > It's awful. :-) > st.st_size `stutters' and that jars when reading in my head. > If st.size isn't clear from context, then stbuf.size probably is. > Ditto ar_hdr->uid versus hdr->ar_uid. > > There's a hierarchy to walking the data structure, and that should be > represented in the identifiers. So big.little, not b.bg_little. > > -- > Cheers, Ralph. > https://plus.google.com/+RalphCorderoy From lm at mcvoy.com Fri Dec 8 01:32:04 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 7 Dec 2017 07:32:04 -0800 Subject: [TUHS] looking for a quote In-Reply-To: References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> Message-ID: <20171207153204.GD6170@mcvoy.com> The problem is crappy programmers. Good ones will do what you guys want and put the type in the name of the struct instance. Bad ones will do s.size and you have no idea what "s" is. When the compiler forced the issue the quality of the programmer didn't matter. I'd love to live in a world of all great programmers. Unfortunately, I don't. On Thu, Dec 07, 2017 at 03:27:40PM +0000, Steve Simon wrote: > +100 > > > > On 7 Dec 2017, at 11:50, Ralph Corderoy wrote: > > > > Hi Larry, > > > >> I *much* prefer sbuf.st_size than whatever.size, the former is > >> instantly a stat structure, the later is a "whatever". > > > > It's awful. :-) > > st.st_size `stutters' and that jars when reading in my head. > > If st.size isn't clear from context, then stbuf.size probably is. > > Ditto ar_hdr->uid versus hdr->ar_uid. > > > > There's a hierarchy to walking the data structure, and that should be > > represented in the identifiers. So big.little, not b.bg_little. > > > > -- > > Cheers, Ralph. > > https://plus.google.com/+RalphCorderoy -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From wlc at jctaylor.com Fri Dec 8 01:34:30 2017 From: wlc at jctaylor.com (William Corcoran) Date: Thu, 7 Dec 2017 15:34:30 +0000 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <017001d36f64$1e7f0550$5b7d0ff0$@ronnatalie.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> <20171206203057.GA72441@wopr>, <017001d36f64$1e7f0550$5b7d0ff0$@ronnatalie.com> Message-ID: <226E8011-09AA-4E31-8C41-D4750D6EB7A2@jctaylor.com> Oh, yes! I remember the copper T1’s eventually traveled over a single pair using ADSL at high voltage. In our metropolitan area, the copper plant had loading coils everywhere—undocumented. If your copper T1 had the misfortune of having a loading coil somewhere in its path then your circuit was doomed. Plus, these little Pairgain’s would literally explode inside the manholes. Copper and T1s should have been outlawed. Especially, since using fiber for everything but the last foot (TLF, lol) was far more reliable. I do hope that the archivists view the delivery mechanisms like the T1, POTS, and so on as having historical significance and are inextricably linked to UNIX. Talking to anyone that worked on the Bell System (and later telcos) always reveal great stories. Many are worthy of preservation. Incidentally, I had a similar issue with a staffer needing remote access. There were no viable wired solutions. However, surprisingly, 4G MIFI with an unlimited data plan actually was a stable solution—-and she even received a dedicated IP. Bill Corcoran On Dec 7, 2017, at 9:04 AM, Ron Natalie > wrote: T1 wasn't cheap nor ubiquitous. I ran the networking for the degree granting public colleges in NJ (which on the whole is a fairly metropolitan area) but there were places we couldn't get it. It was also expensive. Old school copper T1 required repeaters every quarter mile or so. Debugging could be fun. At least our telco (NJ Bell) back then could move the loop back around while I did tests to tell them where the line was failing. And yeah, I live in one of those backwaters now. No cable, no fiber optic anything. I use two DSL lines to get an aggregate 20M down 1.5M up. That's the best the vesiges of the old GTE telco down here can do. ATT has fiber in communities down the road but we're too sparse to attract their interest. Comcast won't even pull in a local drop from the main road. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nevin at eviloverlord.com Fri Dec 8 01:36:32 2017 From: nevin at eviloverlord.com (Nevin Liber) Date: Thu, 7 Dec 2017 09:36:32 -0600 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171207151420.3DB5D18C09E@mercury.lcs.mit.edu> References: <20171207151420.3DB5D18C09E@mercury.lcs.mit.edu> Message-ID: On Thu, Dec 7, 2017 at 9:14 AM, Noel Chiappa wrote: > > From: Larry McVoy > > > an altruistic person trying to make things better. They aren't all > bad. > > I would echo that. During my time on the IESG, I'd say the vast majority of > the people in the IETF really did want to make things better for everyone. > And as someone who has been involved with the C++ standardization effort for the last seven years, let me echo that as well. Most (if not all, as I cannot think of any exceptions to this) of us are involved because we want to make a better language, even if no two of us can agree on what that is. And that most certainly includes the folks that Microsoft sends to the meetings. -- Nevin ":-)" Liber +1-847-691-1404 -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at quintile.net Fri Dec 8 01:40:50 2017 From: steve at quintile.net (Steve Simon) Date: Thu, 7 Dec 2017 15:40:50 +0000 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171207145947.GB6170@mcvoy.com> References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> <20171207145947.GB6170@mcvoy.com> Message-ID: <207854D3-9C2D-4C4F-BE99-87773336B56C@quintile.net> i would like to see plan9 source for the 1st and 2nd editions if p9 on the tuhs archive - assuming the community would accept it. the 3rd edotion was a snapshot and is public and the 4th is still in use (a little) I can get access to the 1st ed (universities only) and am a 2nd ed licensee but it would be great if the lawyers where to allow those to be opened. Russ Cox did a fantastic online history/diff - though the only copy i could find was in the wayback machine: https://web.archive.org/web/20080226055938/http://swtch.com:80/cgi-bin/plan9history.cgi -Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Fri Dec 8 01:42:46 2017 From: chet.ramey at case.edu (Chet Ramey) Date: Thu, 7 Dec 2017 10:42:46 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <20171207145947.GB6170@mcvoy.com> References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> <20171207145947.GB6170@mcvoy.com> Message-ID: On 12/7/17 9:59 AM, Larry McVoy wrote: > My first job at Sun was POSIX conformance. As such, I worked a lot with > the Sun POSIX guy, Don Cragun. He must have been the exception that proves > your rule because he definitely matched the description of an altruistic > person trying to make things better. They aren't all bad. Agree. Don's a good guy. In my Posix standardization experience, most of the participants really are trying to improve the standard and ineroperability, within some fairly serious constraints. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU chet at case.edu http://tiswww.cwru.edu/~chet/ From jon at fourwinds.com Fri Dec 8 02:22:51 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 07 Dec 2017 08:22:51 -0800 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> Message-ID: <201712071622.vB7GMpdn021285@darkstar.fourwinds.com> Robert Brockway writes: > On Wed, 6 Dec 2017, Jon Steinhart wrote: > > > Don't know how much time you've spent on standards committees; I've done > > my time. Standards committees are not filled with altruistic folks > > working to make something great. Much of the time people are there to > > prevent a standard from interfering with their market, or to prevent a > > good standard from being adopted. The examples of the NSA participating > > on crypto committees to weaken the standards got a lot of press and is > > emblematic of what happens. Microsoft has a well documented record of > > using standards to screw the competition so I didn't read any goodness > > into their joining up. I would agree that they're not the company of > > old in that they got themselves trounced by Apple and are no longer top > > dog and able to tell others what they're allowed to do. > > I'm not suggesting any sort of altruism on the part of MS (or any other > company). I have been very critical of MS in the past and was initially > skeptical when they started to open up. IIRC one of the first signs of > change was when they called the Mozilla Foundation and asked for a > meeting. They met with the Mozilla Foundation and started working on > interoperability. Many in the FOSS community were skeptical but that was > a lot of years ago. I haven't seen any "embrace and extend" for many > years. I'd be interested if anyone else has. > > The evidence I'm seeing suggests that today they consider working with > others to be in their best interests. > > As you note they can no longer throw their weight around in the way they > used to. No doubt that's a driver for change. > > If someone had told me 20 years ago that I'd be sitting here today > defending Microsoft's involvement in FOSS... ;) > > Rob Yeah, I could have put it slightly better, which is that working on standards is working on standards and doing good is doing good but working on standards does not automatically equate to doing good. From tytso at mit.edu Fri Dec 8 02:24:48 2017 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 7 Dec 2017 11:24:48 -0500 Subject: [TUHS] looking for a quote In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> Message-ID: <20171207162448.hw4ehuwy4egeflsw@thunk.org> On Thu, Dec 07, 2017 at 11:50:24AM +0000, Ralph Corderoy wrote: > Hi Larry, > > > I *much* prefer sbuf.st_size than whatever.size, the former is > > instantly a stat structure, the later is a "whatever". > > It's awful. :-) > st.st_size `stutters' and that jars when reading in my head. > If st.size isn't clear from context, then stbuf.size probably is. > Ditto ar_hdr->uid versus hdr->ar_uid. The reason why it's useful is that it's much more likely to find relevant lines of code by using "grep st_size *.[ch]". If you grep for "size", there will be way too many false matches. - Ted From clemc at ccc.com Fri Dec 8 02:28:18 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 7 Dec 2017 11:28:18 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> Message-ID: On Thu, Dec 7, 2017 at 1:14 AM, Jon Steinhart wrote: > Don't know how much time you've spent on standards committees; I've done my > ​ ​ > time. > ​So true for many of us on this list ;-) ​ > Standards committees are not filled with altruistic folks working to > make something great. ​I would modify that to be: are not *ALL *filled​ There are some members that want the right thing and yet can be conflicted too. I remember at an later /usr/group meeting (before we became the POSIX committee) we were discussing case folding. From a historical stand point case flowing is left over from the 60s when files names were stored in 5 bits and ASR33s could not easily generate upper and lower case - as I like to point out in Kindergarten, kind Mrs Munger taught there was big A and little a and they were different. Anyway, at the time it was interesting the two folks from DEC were really conflicted. All of us there agreed that case folding was a no-no, but thanks to VMS and the layer DEC was starting to develop, they knew that it was going to be a fight inside of DEC. Doug's observation about malloc(0) and mine on case-foldin; the problem is 'self interest' - when is the 'good of the community at large' out weights the good of the on; but the one just happened to have the largest economic incentive. If I recall when we started that work, Sun might not have yet existed or was at its infancy. So the big player was DEC, and we were trying to get HP, IBM, *etc*. to join to fray. The economic argument won out, we wanted to big guys with us if we were going to succeed, so we backed off that requirement. Political flame to follow ... This is why things like Net Neutrality matters IMHO. Doing the right thing for everyone, means a few big players have to make changes that cost them money. They don't like being told to do that. They are applying the economic golden rule (he who has the gold, makes the rules). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Dec 8 02:30:18 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 7 Dec 2017 11:30:18 -0500 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> <201712070614.vB76EFiQ014953@darkstar.fourwinds.com> Message-ID: s/case flowing/case folding/ -- dylexia and autocorrect be bad ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Dec 8 02:44:55 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 7 Dec 2017 11:44:55 -0500 Subject: [TUHS] looking for a quote In-Reply-To: <20171207162448.hw4ehuwy4egeflsw@thunk.org> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> <20171207162448.hw4ehuwy4egeflsw@thunk.org> Message-ID: <6f52ca3f-a015-fc50-edde-53b52e40543f@kilonet.net> On 12/7/2017 11:24 AM, Theodore Ts'o wrote: > > The reason why it's useful is that it's much more likely to find > relevant lines of code by using "grep st_size *.[ch]". If you grep > for "size", there will be way too many false matches. > > I've actually changed variables' or struct members' names based on the fact that searching for them in an editor yielded too many bad hits. But not often ;) From dscherrer at solar.stanford.edu Fri Dec 8 03:35:03 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Thu, 7 Dec 2017 09:35:03 -0800 Subject: [TUHS] how do I unsubscribe In-Reply-To: References: <7df6ad03-4aa7-fb95-636f-0ac414e4830d@solar.stanford.edu> <20171207041100.GA6532@minnie.tuhs.org> Message-ID: Thanks for the many good words of support. Sure, I'll stay around. Thanks again, everyone. Deborah On 12/6/17 8:26 PM, Ken Thompson wrote: > Deborah, you've made this a better place, > so, please stay. > ken > > > On Wed, Dec 6, 2017 at 8:11 PM, Warren Toomey wrote: >> On Wed, Dec 06, 2017 at 04:39:03PM -0800, Deborah Scherrer wrote: >>> Could someone please tell me how to get off this list? >> >> Deborah, I'll also add my voice in to ask for you to stay on the list. >> There were things said that could have been expressed better, but I >> don't think that there was malicious intent. You bring a wealth of >> knowledge and experience to the TUHS list, and the list would be >> poorer in your absence. >> >> Yours sincerely, Warren From ralph at inputplus.co.uk Fri Dec 8 03:45:00 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Thu, 07 Dec 2017 17:45:00 +0000 Subject: [TUHS] looking for a quote In-Reply-To: <20171207162448.hw4ehuwy4egeflsw@thunk.org> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> <20171207162448.hw4ehuwy4egeflsw@thunk.org> Message-ID: <20171207174500.B08E61FB3E@orac.inputplus.co.uk> Hi Ted, > The reason why it's useful is that it's much more likely to find > relevant lines of code by using "grep st_size *.[ch]". If you grep > for "size", there will be way too many false matches. True, but hasn't static analysis come on since then? I don't use them, but tools like http://ffevotte.github.io/clang-tags/ build on clang's work to allow queries like finding all mentions of st_size AFAIK. They'll even cope with two different struct definitions with a st_size kicking about and use the one you give as a seed reference. I'm surprised with things like DWARF in ELF that compilers weren't used to generate a super `ctags' longer ago. We had cscope, that was Bell Labs IIRC. And then there's been GNU GLOBAL, GNU's idutils, ... -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From gtaylor at tnetconsulting.net Fri Dec 8 03:47:15 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 7 Dec 2017 10:47:15 -0700 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: On 12/06/2017 11:07 PM, Warner Losh wrote: > Yea, I wonder if there's anyway to get the early Xenix code bases? I wonder how willing (the new) Microsoft would be to releasing Xenix code. My main concern is that (as I understand it) SCO has some code decedent from Xenix in it. Seeing as how SCO is still a current selling product (unlike MS-DOS) there may be some reluctance. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From jnc at mercury.lcs.mit.edu Fri Dec 8 04:03:46 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 7 Dec 2017 13:03:46 -0500 (EST) Subject: [TUHS] V7 Addendem Message-ID: <20171207180346.79E1518C09E@mercury.lcs.mit.edu> > From: Clem Cole > it's direct predecessor (UNIX/TS) which was not officially released made > its way to number of places ... heavily hacked systems that were combo's > of V6, PWB [1.0], UNIX/TS plus local additions. UNIX/TS had a newer > kernel, updated FS and the compiler that was released with troff - > a.k.a. 'Typesetter C' I'm not sure quite what the MIT system was. I've never seen a detailed description of UNIX/TS, although I have seen the "Unix Program Description" (January 1976) which documents the USG version, and of course PWB is described in the BSTJ issue, and UNIX/TS is supposedly a merge of those two. (If we ever do find V6+ USG source, it should be easy to verify - that document is pretty detailed.) I should look at the MIT kernel and see how much of it is USG, and see if I can find any traces of the changes described as done for PWB. I know the MIT version has provisions for longer exec() arguments, and text.c is considerably more complex than the one in V6 (and IIRC matches the description in the USG document); but I don't recall withough careful checking, what was done where. Perhaps the MIT system really was /TS, and I didn't know that - I've always described it as a hacked PWB1, but I might be wrong there. Did the later USG versions takeup some of the PWB work, does anyone know? (My thinking is 'if I find traces of PWB, would that be from /TS, or could it be a later USG version' - I think there were 1-3, from something I saw online.) I initially got /TS mixed up with /RT, which is the system I'd _really_ like to find - well, MERT, actually. I think that's a really early micro-kernel system (although I haven't done any research to confirm that), a direction I think is important. (I think the 'THE Multiprogramming System' may be the earliest work in that direction, although I'd be interested to hear of anything else.) I actually got contact info for some of the original MERT people, and was going to contact them to see if they still retained anything, but I never got a 'round tuit'... too many other projects. :-( Noel From jon at fourwinds.com Fri Dec 8 04:38:22 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Thu, 07 Dec 2017 10:38:22 -0800 Subject: [TUHS] V7 Addendem In-Reply-To: <20171207180346.79E1518C09E@mercury.lcs.mit.edu> References: <20171207180346.79E1518C09E@mercury.lcs.mit.edu> Message-ID: <201712071838.vB7IcMxO005631@darkstar.fourwinds.com> Noel Chiappa writes: > I initially got /TS mixed up with /RT, which is the system I'd _really_ like > to find - well, MERT, actually. I think that's a really early micro-kernel > system (although I haven't done any research to confirm that), a direction I > think is important. (I think the 'THE Multiprogramming System' may be the > earliest work in that direction, although I'd be interested to hear of > anything else.) > > I actually got contact info for some of the original MERT people, and was > going to contact them to see if they still retained anything, but I never > got a 'round tuit'... too many other projects. :-( Unless there's more than one MERT I recall that that was something originally done by Heinz Lycklama who is still around. He's busy trying to convince people that the bible proves the laws of thermodynamics these days but still might have some useful information. Jon From tytso at mit.edu Fri Dec 8 07:06:53 2017 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 7 Dec 2017 16:06:53 -0500 Subject: [TUHS] looking for a quote In-Reply-To: <20171207174500.B08E61FB3E@orac.inputplus.co.uk> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> <20171207162448.hw4ehuwy4egeflsw@thunk.org> <20171207174500.B08E61FB3E@orac.inputplus.co.uk> Message-ID: <20171207210653.ev7dyasd5tnyvhqf@thunk.org> On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote: > Hi Ted, > > > The reason why it's useful is that it's much more likely to find > > relevant lines of code by using "grep st_size *.[ch]". If you grep > > for "size", there will be way too many false matches. > > True, but hasn't static analysis come on since then? I don't use them, > but tools like http://ffevotte.github.io/clang-tags/ build on clang's > work to allow queries like finding all mentions of st_size AFAIK. > They'll even cope with two different struct definitions with a st_size > kicking about and use the one you give as a seed reference. First of all, these tools didn't exist in the days of BSD 4.x. Second of all, those tools aren't integrated into ctags and etags, so for the needs of working programmers, the need to run some modified clang and then parse clang output when trying to figure out where all the places that use some structure field would be unnecessarily complex and destructive of a working programmer's productivity. So arguably the tools *still* don't exist in a useful form for developers to use. > I'm surprised with things like DWARF in ELF that compilers weren't used > to generate a super `ctags' longer ago. We had cscope, that was Bell > Labs IIRC. And then there's been GNU GLOBAL, GNU's idutils, ... DWARF is incredibly bloated for large projects, because unless the header files which are #included in each .c file is exactly the same (the exact same header files, included in the exact same order, with no other local structure or type definitions in the C source file), there will N different copies of the structure information in the .o files, and this duplication will also exist in combined executable's DWARF information. I complained about this a decade ago, when this defect essentially made Systemtap completely unusable by real kernel developers. Compiling with DWARF exploded the compile time, and size of the build tree, and the size of the insatlled kernel, by a factor of at least ten. We now have a way of generated reduced debuginfo files, but it works by eliding all of the structure definitions, and only keeping the file/line number information. So that won't work for your "super ctags" proposal. If you want to try to fix this, feel free --- but we don't actually have a solution that works in the real world today. It's something that only really works in the Powerpoint Slideware world inhabited by IBM executives.... - Ted From clemc at ccc.com Fri Dec 8 07:41:46 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 7 Dec 2017 16:41:46 -0500 Subject: [TUHS] looking for a quote In-Reply-To: <20171207210653.ev7dyasd5tnyvhqf@thunk.org> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> <20171207162448.hw4ehuwy4egeflsw@thunk.org> <20171207174500.B08E61FB3E@orac.inputplus.co.uk> <20171207210653.ev7dyasd5tnyvhqf@thunk.org> Message-ID: On Thu, Dec 7, 2017 at 4:06 PM, Theodore Ts'o wrote: > On Thu, Dec 07, 2017 at 05:45:00PM +0000, Ralph Corderoy wrote: > > Hi Ted, > > > > > The reason why it's useful is that it's much more likely to find > > > relevant lines of code by using "grep st_size *.[ch]". If you grep > > > for "size", there will be way too many false matches. > > > > True, but hasn't static analysis come on since then? I don't use them, > > but tools like http://ffevotte.github.io/clang-tags/ build on clang's > > work to allow queries like finding all mentions of st_size AFAIK. > > They'll even cope with two different struct definitions with a st_size > > kicking about and use the one you give as a seed reference. > > First of all, these tools didn't exist in the days of BSD 4.x. > > Second of all, those tools aren't integrated into ctags and etags, so > for the needs of working programmers, the need to run some modified > clang and then parse clang output when trying to figure out where all > the places that use some structure field would be unnecessarily > complex and destructive of a working programmer's productivity. > > So arguably the tools *still* don't exist in a useful form for > developers to use. > > > I'm surprised with things like DWARF in ELF that compilers weren't used > > to generate a super `ctags' longer ago. We had cscope, that was Bell > > Labs IIRC. And then there's been GNU GLOBAL, GNU's idutils, ... > > DWARF is incredibly bloated for large projects, because unless the > header files which are #included in each .c file is exactly the same > (the exact same header files, included in the exact same order, with > no other local structure or type definitions in the C source file), > there will N different copies of the structure information in the .o > files, and this duplication will also exist in combined executable's > DWARF information. > > I complained about this a decade ago, when this defect essentially > made Systemtap completely unusable by real kernel developers. > Compiling with DWARF exploded the compile time, and size of the build > tree, and the size of the insatlled kernel, by a factor of at least > ten. We now have a way of generated reduced debuginfo files, but it > works by eliding all of the structure definitions, and only keeping > the file/line number information. So that won't work for your "super > ctags" proposal. > > If you want to try to fix this, feel free --- but we don't actually > have a solution that works in the real world today. It's something > that only really works in the Powerpoint Slideware world inhabited by > IBM executives.... > > - Ted > ​+1​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Dec 8 07:46:14 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 8 Dec 2017 08:46:14 +1100 (EST) Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: <201712070833.vB78XgQo028687@freefriends.org> References: <201712060553.vB65rFa3002734@freefriends.org> <201712060800.vB680wXG013646@freefriends.org> <201712070833.vB78XgQo028687@freefriends.org> Message-ID: On Thu, 7 Dec 2017, arnold at skeeve.com wrote: >> Never got to use the V7 shell; we were stuck with 11/40s[*] :-( It was >> certainly in the V6 shell, hence by bafflement at why labels were of >> the form ": blah" instead of the sensible "blah: "... > > Come now, since then you've *never* used any kind of Bourne shell? BSD > on vax? SunOS? System III or System V on anything else? You've been > stuck in a time warp for 35 years? :-) Sigh; there's one in every bunch :-) OK, I never got to use the V7 shell on V7, because I never got to use V7 on my machines (and the use of "goto" had been thoroughly beaten out of me by then, so I never thought to try it). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Fri Dec 8 07:51:40 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 8 Dec 2017 08:51:40 +1100 (EST) Subject: [TUHS] looking for a quote In-Reply-To: <20171207115024.217CA1FB3E@orac.inputplus.co.uk> References: <20171207003439.GB24409@mcvoy.com> <20171207115024.217CA1FB3E@orac.inputplus.co.uk> Message-ID: On Thu, 7 Dec 2017, Ralph Corderoy wrote: > st.st_size `stutters' and that jars when reading in my head. Hey, as a stutterer myself I'm used to it :-) No, no offence taken... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Fri Dec 8 07:54:50 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 7 Dec 2017 16:54:50 -0500 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: <201712060553.vB65rFa3002734@freefriends.org> <201712060800.vB680wXG013646@freefriends.org> Message-ID: On Wed, Dec 6, 2017 at 6:57 PM, Dave Horsfall wrote: > > Never got to use the V7 shell; we were stuck with 11/40s[*] ​Dave I don't understand this statement. We ran Seventh Edition on 11/40 class processors more than anything else. The issue was lack of separate I/D space and the kernel got large so you ran out of physical memory. The later was solved with things like the Able ENABLE, which I admit I put one couple of 11/34 and our 11/60 (which are 11/40 class). But V7 ran fine on it. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Dec 8 10:31:37 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 8 Dec 2017 11:31:37 +1100 (EST) Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: <201712060553.vB65rFa3002734@freefriends.org> <201712060800.vB680wXG013646@freefriends.org> Message-ID: On Thu, 7 Dec 2017, Clem Cole wrote: > > Never got to use the V7 shell; we were stuck with 11/40s[*]  > > Dave I don't understand this statement.  We ran Seventh Edition on 11/40 > class processors more than anything else.  The issue was lack of separate > I/D space and the kernel got large so you ran out of physical memory.   The > later was solved with things like the Able ENABLE, which I admit I put one > couple of 11/34 and our 11/60 (which are 11/40 class).  But V7 ran fine on > it. I tried, but no way it would work; the only non-DEC gear we ended up with was extra memory (nothing special, but of course not covered by Field Circus) and an Ampex[*] RP-03 clone (I think). For all intents and porpoises it was a maxed-out 11/40 (then the /60 later on). As I mentioned before, the AUSAM buffer scheme certainly helped, and we kissed goodbye to deadlocks; we even modified character devices (LP. XY, LV etc) to use the buffer pool instead of the character queues, and they went damned fast. I should mention that the /40s were originally specced to run RSX-11D (yuck), and when the ACM article came out the rest was history... [*] My spell checker suggested "Tampax" for "Ampex"... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Fri Dec 8 12:08:56 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 8 Dec 2017 13:08:56 +1100 (EST) Subject: [TUHS] ARPAnet now 4 nodes In-Reply-To: References: Message-ID: On Tue, 5 Dec 2017, Dave Horsfall wrote: > The ARPAnet reached four nodes on this day in 1969 (anyone know which?) > [...] Well, that sure as hell started a shit-storm; not my intention, of course. Anyway, thanks for all the corrections; I don't want to be a party to spreading misinformation (I see enough of it as it is). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jsteve at superglobalmegacorp.com Fri Dec 8 12:36:20 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 8 Dec 2017 10:36:20 +0800 Subject: [TUHS] AT&T 3B2/400 Emulator In-Reply-To: <20171206190051.GA15028@xenon.retronet.net> References: <20171206190051.GA15028@xenon.retronet.net> Message-ID: <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com> Wow so glad you got it to boot! It’s great that this reference platform is now ‘alive’ through emulation. To say these machines are super hard to find these days is difficult is an understatement. Even in the mid ‘90s finding anything for these beasts was a monster chore. Outside of college and using them for style and diction, I’ve only seen one paired with an AT&T Definity phone switch, but everything was quickly moving to NCR/SUN. Great job!! Sent from Mail for Windows 10 From: Seth Morabito Sent: Thursday, 7 December 2017 3:10 AM To: tuhs at tuhs.org Subject: [TUHS] AT&T 3B2/400 Emulator Hello everyone, A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator into the main SIMH source tree, and I realized that I should mention it here, where there may be particular interest. The 3B2 and 3B5 were main porting platforms for AT&T System V Release 3, and when I realized how scarce the equipment has become to find, I set out to write an emulator for the 3B2. It was rough going at points due to lack of documentation, but I was able to reverse engineer quite a bit of the system through reading the SVR3 source code, and of course strapping my own 3B2/310 to a logic analyzer. The emulator is fairly complete. It certainly works well as a standalone, single-user UNIX system. Support for multiple terminals is coming very soon (as soon as I find the time, that is) so it will soon be possible to allow multiple users to telnet into virtual terminals, similar to how the SIMH PDP-11 and VAX emulators work. For now, information about the emulator lives here: https://loomcom.com/3b2/emulator/ Best Wishes, -Seth -- Seth Morabito web at loomcom.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri Dec 8 12:55:12 2017 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 7 Dec 2017 18:55:12 -0800 Subject: [TUHS] AT&T 3B2/400 Emulator In-Reply-To: <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com> References: <20171206190051.GA15028@xenon.retronet.net> <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com> Message-ID: <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net> Heh incidentally I am awaiting the arrival of a 3B2/400 and already have a Definity...;) Sent from my iPhone > On Dec 7, 2017, at 18:36, Jason Stevens wrote: > > Wow so glad you got it to boot! > > It’s great that this reference platform is now ‘alive’ through emulation. To say these machines are super hard to find these days is difficult is an understatement. Even in the mid ‘90s finding anything for these beasts was a monster chore. > > Outside of college and using them for style and diction, I’ve only seen one paired with an AT&T Definity phone switch, but everything was quickly moving to NCR/SUN. > > Great job!! > > Sent from Mail for Windows 10 > > From: Seth Morabito > Sent: Thursday, 7 December 2017 3:10 AM > To: tuhs at tuhs.org > Subject: [TUHS] AT&T 3B2/400 Emulator > > > Hello everyone, > > A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator > into the main SIMH source tree, and I realized that I should mention > it here, where there may be particular interest. > > The 3B2 and 3B5 were main porting platforms for AT&T System V Release > 3, and when I realized how scarce the equipment has become to find, I > set out to write an emulator for the 3B2. It was rough going at points > due to lack of documentation, but I was able to reverse engineer quite > a bit of the system through reading the SVR3 source code, and of > course strapping my own 3B2/310 to a logic analyzer. > > The emulator is fairly complete. It certainly works well as a > standalone, single-user UNIX system. Support for multiple terminals is > coming very soon (as soon as I find the time, that is) so it will soon > be possible to allow multiple users to telnet into virtual terminals, > similar to how the SIMH PDP-11 and VAX emulators work. > > For now, information about the emulator lives here: > > https://loomcom.com/3b2/emulator/ > > > Best Wishes, > > -Seth > -- > Seth Morabito > web at loomcom.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.senn at gmail.com Fri Dec 8 15:24:51 2017 From: will.senn at gmail.com (Will Senn) Date: Thu, 7 Dec 2017 23:24:51 -0600 Subject: [TUHS] how do I unsubscribe In-Reply-To: <20171207052752.2351E18C09B@mercury.lcs.mit.edu> References: <20171207052752.2351E18C09B@mercury.lcs.mit.edu> Message-ID: On 12/6/17 11:27 PM, Noel Chiappa wrote: > So, I'm getting the impression, from the reactions about civility, etc, that > people aren't disagreeing with the characterization of "rudeness" (which can > only be meaning my posts). Can someone please point to text in my messages > which they consider "rude"? Thanks. > > Noel Noel, Yikes! I admit to reacting to the content of Deborah's email comments about how things used to be and on a general level without doing my due diligence and checking into the specific conversation that sparked the appeal. If the conversation she was referring to was your ARPAnet clarification, and I fear it was, then was I ever out of line for commenting about civility, and I'd like to set the record straight here. I have since done my due diligence and read through the ARPAnet thread, and your comments were direct, for sure, but not at all inappropriate given the personal experience you have with this particular group and the circumstances of the events in question. It would seem that my sentiments while well-meaning ,and generally sound,  were mistakenly motivated by what appears to have been a skewed understanding, and you have my apologies for the unintended implications of my civility and netiquette comments. I apologize. Regards, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF From arnold at skeeve.com Fri Dec 8 16:12:05 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 07 Dec 2017 23:12:05 -0700 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: <201712060553.vB65rFa3002734@freefriends.org> <201712060800.vB680wXG013646@freefriends.org> <201712070833.vB78XgQo028687@freefriends.org> Message-ID: <201712080612.vB86C5AT017775@freefriends.org> Hi. Dave Horsfall wrote: > On Thu, 7 Dec 2017, arnold at skeeve.com wrote: > > >> Never got to use the V7 shell; we were stuck with 11/40s[*] :-( It was > >> certainly in the V6 shell, hence by bafflement at why labels were of > >> the form ": blah" instead of the sensible "blah: "... > > > > Come now, since then you've *never* used any kind of Bourne shell? BSD > > on vax? SunOS? System III or System V on anything else? You've been > > stuck in a time warp for 35 years? :-) > > Sigh; there's one in every bunch :-) Sorry. I tend to be too literal-minded sometimes. That can help for doing software development, but can get in the way at other times. > OK, I never got to use the V7 shell on V7, because I never got to use > V7 on my machines (and the use of "goto" had been thoroughly beaten out > of me by then, so I never thought to try it). I see. Much better. :-) Thanks, Arnold From erc at pobox.com Fri Dec 8 18:48:45 2017 From: erc at pobox.com (Ed Carp) Date: Fri, 8 Dec 2017 00:48:45 -0800 Subject: [TUHS] AT&T 3B2/400 Emulator In-Reply-To: <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net> References: <20171206190051.GA15028@xenon.retronet.net> <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com> <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net> Message-ID: Speaking of which, does anyone have any plans on writing an emulator for the 3B1 (aka PC7300)? On 12/7/17, Cory Smelosky wrote: > Heh incidentally I am awaiting the arrival of a 3B2/400 and already have a > Definity...;) > > Sent from my iPhone > >> On Dec 7, 2017, at 18:36, Jason Stevens >> wrote: >> >> Wow so glad you got it to boot! >> >> It’s great that this reference platform is now ‘alive’ through emulation. >> To say these machines are super hard to find these days is difficult is an >> understatement. Even in the mid ‘90s finding anything for these beasts >> was a monster chore. >> >> Outside of college and using them for style and diction, I’ve only seen >> one paired with an AT&T Definity phone switch, but everything was quickly >> moving to NCR/SUN. >> >> Great job!! >> >> Sent from Mail for Windows 10 >> >> From: Seth Morabito >> Sent: Thursday, 7 December 2017 3:10 AM >> To: tuhs at tuhs.org >> Subject: [TUHS] AT&T 3B2/400 Emulator >> >> >> Hello everyone, >> >> A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator >> into the main SIMH source tree, and I realized that I should mention >> it here, where there may be particular interest. >> >> The 3B2 and 3B5 were main porting platforms for AT&T System V Release >> 3, and when I realized how scarce the equipment has become to find, I >> set out to write an emulator for the 3B2. It was rough going at points >> due to lack of documentation, but I was able to reverse engineer quite >> a bit of the system through reading the SVR3 source code, and of >> course strapping my own 3B2/310 to a logic analyzer. >> >> The emulator is fairly complete. It certainly works well as a >> standalone, single-user UNIX system. Support for multiple terminals is >> coming very soon (as soon as I find the time, that is) so it will soon >> be possible to allow multiple users to telnet into virtual terminals, >> similar to how the SIMH PDP-11 and VAX emulators work. >> >> For now, information about the emulator lives here: >> >> https://loomcom.com/3b2/emulator/ >> >> >> Best Wishes, >> >> -Seth >> -- >> Seth Morabito >> web at loomcom.com >> > From arnold at skeeve.com Fri Dec 8 19:44:34 2017 From: arnold at skeeve.com (Arnold Robbins) Date: Fri, 08 Dec 2017 11:44:34 +0200 Subject: [TUHS] A nice review of a retrospective paper on the PDP-11 Message-ID: <201712080944.vB89iYLg006301@skeeve.com> https://dave.cheney.net/2017/12/04/what-have-we-learned-from-the-pdp-11 Arnold From emu at e-bbes.com Fri Dec 8 18:53:37 2017 From: emu at e-bbes.com (emanuel stiebler) Date: Fri, 8 Dec 2017 09:53:37 +0100 Subject: [TUHS] AT&T 3B2/400 Emulator In-Reply-To: References: <20171206190051.GA15028@xenon.retronet.net> <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com> <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net> Message-ID: On 2017-12-08 09:48, Ed Carp wrote: > Speaking of which, does anyone have any plans on writing an emulator > for the 3B1 (aka PC7300)? http://philpem.me.uk/code/3b1emu/ From jnc at mercury.lcs.mit.edu Fri Dec 8 23:01:18 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 8 Dec 2017 08:01:18 -0500 (EST) Subject: [TUHS] V7 Addendem Message-ID: <20171208130118.1F25718C097@mercury.lcs.mit.edu> > I've never seen a detailed description of UNIX/TS, although I have seen > the "Unix Program Description" (January 1976) which documents the USG > version, and of course PWB is described in the BSTJ issue, and UNIX/TS > is supposedly a merge of those two. > ... > Did the later USG versions takeup some of the PWB work, does anyone > know? (My thinking is 'if I find traces of PWB [in the MIT system], > would that be from /TS, or could it be a later USG version' - I think > there were 1-3, from something I saw online.) So I seem to have stumbled on something interesting here (or maybe it's not, and the history is just unclear - well, unclear to me at least, I'm sure someone knows). Looking at "Unix Program Description" (January 1976), it's clearly marked as "Published by the UNIX Support Group". (I have an actual hardcopy, which I don't recall how I came by, but for those who wish to follow along this document is available in the TUHS archive, at: http://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_jan_1976.pdf and in other TUHS mirrors). So, given the credit, I _assume_ that it documents some version of the USG system. So I started looking at that, and the PWB version that's in the archive: http://www.tuhs.org/Archive/Distributions/USDL/spencer_pwb.tar.gz to see how they compare, and it turns out (somewhat to my surprise) that the USG document describes what seems to be an older version of the system. For example, in text.c, it doesn't cover xlock()/xunlock()/xexpand(), all in the PWB system - just xalloc()/xccdec()/xfree()/xswap(). Even more telling, in sys1.c, the USG document describes the older version of exec(), where arguments are collected in a disk buffer, not (as in the PWB system) in swap space. (I had thought that this change was mentioned in the PWB paper in the BSTJ issue, but on checking, it appears my memory was incorrect. Many of the PWB changes appear to be to things like the shell, not the OS.) So it seems the USG document describes a system very close to the 'classic' V6 - not what I had expected. This may also make it hard to recognize USG source (at least, the early versions). More generally, it would be good to try and elucidate the relationship among all these early Bell/AT+T versions: Research, USG, PWB, etc. Clearly the two latter (from what we know now) are descended from V6 - but was there any interchange between USG and PWB? And did either of them feed back into V7? Or, perhaps more likely, were the improvements to text.c, exec() etc _Research_ improvements that got fed into PWB? More questions than answers, sadly... I'm not at all familiar with V7, I'll have to go read it at some point, and compare it to PWB. Not that I expect it will answer many (any?) of these questions, but maybe we'll get lucky and there will e.g. be stuff in this PWB which isn't in V7. Speaking of which, I seem to recall there's more than one PWB version. I wonder which one we have (above). Although there's another 'PWB' tape in the archive: http://www.tuhs.org/Archive/Distributions/USDL/bostic_pwb.tar.gz (much larger than the other one), when I poked around a bit through that, seeing what's there, and comparing it to the other one, the system sources I looked at there all seemed to be the same as the one on the Spencer tape. > I should look at the MIT kernel and see how much of it is USG, and see > if I can find any traces of the changes described as done for PWB. I > know the MIT version has provisions for longer exec() arguments, and > text.c is considerably more complex than the one in V6 (and IIRC matches > the description in the USG document) So, my memory was in error here; the text.c matches the one from the PWB tape, _not_ the USG document. In general, the parts of the MIT system seem to be a close match to what's on the PWB tape, with the exception that the MIT one seems to be slightly earlier (no 'register' argument types). > Perhaps the MIT system really was /TS Without a better understanding of what was really in /TS, this is totally opaque. > I've always described it as a hacked PWB1, but I might be wrong there. And for once, I think I was right. The MIT system _does_ closely match the one on the 'PWB' tapes - whatever that was! Noel From dave at horsfall.org Sat Dec 9 09:26:39 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 9 Dec 2017 10:26:39 +1100 (EST) Subject: [TUHS] Grace Hopper Message-ID: (At the risk of being flamed because it's not strictly Unix...) We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing Grace", she was a remarkable woman, both in computers and the Navy. She coined the term "debugging" when she extracted a moth from a set of relay contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in the log, taping the deceased Lepidoptera in there as well. She was convinced that computers could be programmed in an English-like language and developed Flow-Matic, which in turn became, err, COBOL... She was posthumously awarded the Presidential Medal of Freedom in 2016 by Barack Obama. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lm at mcvoy.com Sat Dec 9 10:05:06 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 8 Dec 2017 16:05:06 -0800 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: <20171209000506.GT16028@mcvoy.com> On Sat, Dec 09, 2017 at 10:26:39AM +1100, Dave Horsfall wrote: > (At the risk of being flamed because it's not strictly Unix...) It might not be Unix but seems appropriate to me, she was amazing. > We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing > Grace", she was a remarkable woman, both in computers and the Navy. She > coined the term "debugging" when she extracted a moth from a set of relay > contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in > the log, taping the deceased Lepidoptera in there as well. She was > convinced that computers could be programmed in an English-like language and > developed Flow-Matic, which in turn became, err, COBOL... She was > posthumously awarded the Presidential Medal of Freedom in 2016 by Barack > Obama. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From mike.ab3ap at gmail.com Sat Dec 9 10:39:17 2017 From: mike.ab3ap at gmail.com (Mike Markowski) Date: Fri, 8 Dec 2017 19:39:17 -0500 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: On 12/08/2017 06:26 PM, Dave Horsfall wrote: > (At the risk of being flamed because it's not strictly Unix...) > > We gained Rear Admiral Grace Hopper on this day in 1906; known as > "Amazing Grace", she was a remarkable woman, both in computers and the > Navy.  [...] Coincidentally, I work in Hopper Hall, named after her, and complete with a nice bronze plaque with her likeness in the lobby. There's a short blurb on her about 2/3 down the page at: https://www.army.mil/article/66745/new_campus_built_on_tradition_of_excellence Mike Markowski From beebe at math.utah.edu Sat Dec 9 11:08:02 2017 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Fri, 8 Dec 2017 18:08:02 -0700 Subject: [TUHS] Grace Hopper Message-ID: For more on Admiral Grace Murray Hopper, by one who knew her well, see Jean Sammet's remembrance: Farewell to Grace Hopper: end of an era! https://doi.org/10.1145/129852.214846 A Ph.D. thesis about her: The Contributions of Grace Murray Hopper to Computer Science and Computer Education https://digital.library.unt.edu/ark:/67531/metadc278692/m2/1/high_res_d/1002721264-mitchell.pdf Books: Grace Hopper: Admiral of the Cyber Sea 1-59114-978-9 Grace Hopper and the Invention of the Information Age ISBN 0-262-51726-4 Grace Hopper: Computer Whiz ISBN 0-7660-2273-0 [juvenile literature] I've always found it amusing that she was a strong proponent of the work ethic: "Act first, get permission later", which is in direct opposition to the military chain of command, despite her rank as Rear Admiral of the US Navy. See also ACM Grace Murray Hopper Award https://awards.acm.org/hopper https://awards.acm.org/hopper/award-winners [Awarded to the outstanding young computer professional of the year, selected on the basis of a single recent major technical or service contribution. This award is accompanied by a prize of $35,000. The candidate must have been 35 years of age or less at the time the qualifying contribution was made. Financial support of the Grace Murray Hopper Award is provided by Microsoft.] Don Knuth of Stanford was the first GMHA winner, in 1971; other well-known people include Steve Wozniak (1971), Bob Metcalf (1980), Dan Bricklin (1981), Brian Reid (1982), Bill Joy (1986), John Ousterhout (1987), Guy Steele (1988), Richard Stallman (1990), Bjarne Stroustrup (1993), Vern Paxson (2007), Craig Gentry (2010), ... There is also a 1983 interview on a popular US news broadcast that celebrates its 50th anniversary this year: The 60 Minutes interview with Grace Murray Hopper https://www.cbsnews.com/news/the-60-minutes-interview-with-grace-murray-hopper/ ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu - - 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- From dave at horsfall.org Sat Dec 9 12:21:44 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 9 Dec 2017 13:21:44 +1100 (EST) Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: On Fri, 8 Dec 2017, Nelson H. F. Beebe wrote: > I've always found it amusing that she was a strong proponent of the work > ethic: "Act first, get permission later", which is in direct opposition > to the military chain of command, despite her rank as Rear Admiral of > the US Navy. Thanks! Now noted in my calendar... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From crossd at gmail.com Sat Dec 9 12:47:24 2017 From: crossd at gmail.com (Dan Cross) Date: Fri, 8 Dec 2017 21:47:24 -0500 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: On Fri, Dec 8, 2017 at 8:08 PM, Nelson H. F. Beebe wrote: > [...] > I've always found it amusing that she was a strong proponent of the > work ethic: "Act first, get permission later", which is in direct > opposition to the military chain of command, despite her rank as Rear > Admiral of the US Navy. > Sorry, this is a bit off-topic, but I'm going to actually disagree with this to some extent. In the Naval Services, we're used to bucking the chain; this has even been codified in the US Marine Corps doctrine of distributed operations and maneuver warfare [*]; the idea is that the people on the ground know the local situation best, so empower them to make decisions in accordance with the overall commander's intent. Sure, you understand that those decisions aren't going to be perfect, but that's ok. In this way, RDML Hopper was following a long and noble tradition of the United States Navy. - Dan C. (Former Captain, US Marines) [*] See MCDP-1: Warfighting. http://www.marines.mil/Portals/59/Publications/MCDP%201%20Warfighting.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ches at cheswick.com Sat Dec 9 12:47:55 2017 From: ches at cheswick.com (William Cheswick) Date: Fri, 8 Dec 2017 21:47:55 -0500 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: <2A5827F5-56BB-4E11-943E-17E36848AC90@cheswick.com> I plan to show some nanoseconds to some second-graders. From dave at horsfall.org Sat Dec 9 13:21:44 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 9 Dec 2017 14:21:44 +1100 (EST) Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: On Sat, 9 Dec 2017, Dave Horsfall wrote: > (At the risk of being flamed because it's not strictly Unix...) I tremble to think of the reception for Countess Augusta Ada King-Noel's birthday tomorrow; then again, it's also JFO's birthday! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Sat Dec 9 14:44:47 2017 From: imp at bsdimp.com (Warner Losh) Date: Fri, 8 Dec 2017 21:44:47 -0700 Subject: [TUHS] V7 32V 3BSD dates Message-ID: OK. I'm confused. Maybe people here can help me understand. Looking at the V7 sources, it looks for all the world like they were released Jan 10, 1979. This release was PDP-11 only. So far, so good. 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in the archive suggest March 26th, 1979 (though there are dates as late as May 3rd and April 30th on two files that are trivial). The tape we have in the archive has a date Feb 22, 1980 written on it. Given the dates, that's only 3 months after V7 was released. This seems very fast, but maybe it's OK since it's a swapping release.... 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems reasonable for turning V7 from swapping into paging... about a year is fast but not crazy fast. My question is: did these three events really happen in this quick succession? Did USDL folks get started with a preliminary V7 for V32 or was the port really done in 2 and a half months? Likewise with UCB and 3bsd: did they start early? Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From nw at retrocomputingtasmania.com Sat Dec 9 16:03:05 2017 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Sat, 9 Dec 2017 17:03:05 +1100 Subject: [TUHS] What UNIX Artifacts Are Still Missing? In-Reply-To: References: <1512559547.S.4343.377.f5-147-236.1512565117.28135@webmail.rediffmail.com> Message-ID: I would hope we will one day find more of the UNIX emulators that existed over the years, my list includes: PRIMIX for PRIME computers running PRIMEOS (had to cope with several PRIME weirdnesses) Eunice for VAX/VMS : https://en.wikipedia.org/wiki/Eunice_(software) 0nix : A Unix emulator for VAX/VMS : http://www.caam.rice.edu/caam/trs/82/TR82-08.pdf I find attempts to make other systems behave like Unix fascinating and the implementations inevitably embellished with interesting and amusing hackery. I have a long list of UNIX-hosted programming languages I would like to find too, but that is wandering off-topic for this list. From imp at bsdimp.com Sat Dec 9 17:14:16 2017 From: imp at bsdimp.com (Warner Losh) Date: Sat, 9 Dec 2017 00:14:16 -0700 Subject: [TUHS] V7 32V 3BSD dates In-Reply-To: References: Message-ID: On Sat, Dec 9, 2017 at 12:00 AM, Jeremy C. Reed wrote: > On Fri, 8 Dec 2017, Warner Losh wrote: > > > OK. I'm confused. Maybe people here can help me understand. > > Looking at the V7 sources, it looks for all the world like they were > > released Jan 10, 1979. This release was PDP-11 only. So far, so good. > > > > 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in > the > > archive suggest March 26th, 1979 (though there are dates as late as May > 3rd > > and April 30th on two files that are trivial). The tape we have in the > > archive has a date Feb 22, 1980 written on it. Given the dates, that's > only > > 3 months after V7 was released. This seems very fast, but maybe it's OK > > since it's a swapping release.... > > > > 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This > seems > > reasonable for turning V7 from swapping into paging... about a year is > fast > > but not crazy fast. > > > > My question is: did these three events really happen in this quick > > succession? Did USDL folks get started with a preliminary V7 for V32 or > was > > the port really done in 2 and a half months? Likewise with UCB and 3bsd: > did > > they start early? > > Bell got their VAX in Feb. 1978. > > London and Reiser ported Unix to it and was multi-user in April. > > Then spent five months to clean up for internal release in the Fall. > > UCB purchased their VAX in the Fall. > > Bell sent their prototype 32/V to Berkeley. > > Bell's paging work began in late 1978. > > Berkeley's own work from swap to paging began in late spring of 1979. > (Joy presented about this PUNIXVAX in June 1979 UNIX Conference.) > > 32/V did come out a few weeks after System 7. > Yea, the dates on the files in the archives say January 10 -> March 28th in 79... It makes a lot of sense that they started a year or more earlier... > By mid November, the Berkeley virtual memory code was in use > and was expected to be available for others by early December. > > Berkeley's "Virtual Vax/UNIX" was available for students after > Christmas (1979) break. > > BSD distribution to others began in January 1980. > Looks like 3BSD was cut in March 28th 1980, so that fits. Most of the work appears to end sometime over what would be that Christmas break (judging from file dates), with bug fixes continuing through March... > The Kashtan performance evaluation versus VMS (with benchmark code) was > done very soon after. (And Joy's fixes in March.) > Which matches the 3BSD release.... > (I did a few interviews specifically related to this. I have long > chapters about this and I can provide my references/citations when I get > back from a trip I am on.) > That's totally cool! The key missing bits were that 32/V work started before 7th Edition was finalized. This is way more detailed than I expected... Thank You! Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From reed at reedmedia.net Sat Dec 9 17:00:41 2017 From: reed at reedmedia.net (Jeremy C. Reed) Date: Sat, 9 Dec 2017 01:00:41 -0600 (CST) Subject: [TUHS] V7 32V 3BSD dates In-Reply-To: References: Message-ID: On Fri, 8 Dec 2017, Warner Losh wrote: > OK. I'm confused. Maybe people here can help me understand. > Looking at the V7 sources, it looks for all the world like they were > released Jan 10, 1979. This release was PDP-11 only. So far, so good. > > 32V, a port to the VAX, is listed as 'early 1979'. Dates in the files in the > archive suggest March 26th, 1979 (though there are dates as late as May 3rd > and April 30th on two files that are trivial). The tape we have in the > archive has a date Feb 22, 1980 written on it. Given the dates, that's only > 3 months after V7 was released. This seems very fast, but maybe it's OK > since it's a swapping release.... > > 3BSD, The Berkeley 32V has file dates as late as Mar 22, 1980... This seems > reasonable for turning V7 from swapping into paging... about a year is fast > but not crazy fast. > > My question is: did these three events really happen in this quick > succession? Did USDL folks get started with a preliminary V7 for V32 or was > the port really done in 2 and a half months? Likewise with UCB and 3bsd: did > they start early? Bell got their VAX in Feb. 1978. London and Reiser ported Unix to it and was multi-user in April. Then spent five months to clean up for internal release in the Fall. UCB purchased their VAX in the Fall. Bell sent their prototype 32/V to Berkeley. Bell's paging work began in late 1978. Berkeley's own work from swap to paging began in late spring of 1979. (Joy presented about this PUNIXVAX in June 1979 UNIX Conference.) 32/V did come out a few weeks after System 7. By mid November, the Berkeley virtual memory code was in use and was expected to be available for others by early December. Berkeley's "Virtual Vax/UNIX" was available for students after Christmas (1979) break. BSD distribution to others began in January 1980. The Kashtan performance evaluation versus VMS (with benchmark code) was done very soon after. (And Joy's fixes in March.) (I did a few interviews specifically related to this. I have long chapters about this and I can provide my references/citations when I get back from a trip I am on.) From jsteve at superglobalmegacorp.com Sat Dec 9 20:11:10 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sat, 9 Dec 2017 18:11:10 +0800 Subject: [TUHS] AT&T 3B2/400 Emulator In-Reply-To: References: <20171206190051.GA15028@xenon.retronet.net> <79bc4345-d97f-44bc-a404-791acee6ee85@HK2APC01FT115.eop-APC01.prod.protection.outlook.com> <1BB2D24A-80E8-4187-B038-D7996E9017F7@gewt.net> Message-ID: <13746f9f-cabe-4a9d-af19-f154177d749c@HK2APC01FT015.eop-APC01.prod.protection.outlook.com> There is this: http://www.philpem.me.uk/code/3b1emu/ It does boot UNIX, although there is further issues which prevent things like cc from running. But if you want to poke around as a user, it’s enough to do that. Sent from Mail for Windows 10 From: Ed Carp Sent: Friday, 8 December 2017 4:49 PM To: Cory Smelosky Cc: tuhs at tuhs.org Subject: Re: [TUHS] AT&T 3B2/400 Emulator Speaking of which, does anyone have any plans on writing an emulator for the 3B1 (aka PC7300)? On 12/7/17, Cory Smelosky wrote: > Heh incidentally I am awaiting the arrival of a 3B2/400 and already have a > Definity...;) > > Sent from my iPhone > >> On Dec 7, 2017, at 18:36, Jason Stevens >> wrote: >> >> Wow so glad you got it to boot! >> >> It’s great that this reference platform is now ‘alive’ through emulation. >> To say these machines are super hard to find these days is difficult is an >> understatement. Even in the mid ‘90s finding anything for these beasts >> was a monster chore. >> >> Outside of college and using them for style and diction, I’ve only seen >> one paired with an AT&T Definity phone switch, but everything was quickly >> moving to NCR/SUN. >> >> Great job!! >> >> Sent from Mail for Windows 10 >> >> From: Seth Morabito >> Sent: Thursday, 7 December 2017 3:10 AM >> To: tuhs at tuhs.org >> Subject: [TUHS] AT&T 3B2/400 Emulator >> >> >> Hello everyone, >> >> A few weeks ago, I merged my work-in-progress AT&T 3B2/400 emulator >> into the main SIMH source tree, and I realized that I should mention >> it here, where there may be particular interest. >> >> The 3B2 and 3B5 were main porting platforms for AT&T System V Release >> 3, and when I realized how scarce the equipment has become to find, I >> set out to write an emulator for the 3B2. It was rough going at points >> due to lack of documentation, but I was able to reverse engineer quite >> a bit of the system through reading the SVR3 source code, and of >> course strapping my own 3B2/310 to a logic analyzer. >> >> The emulator is fairly complete. It certainly works well as a >> standalone, single-user UNIX system. Support for multiple terminals is >> coming very soon (as soon as I find the time, that is) so it will soon >> be possible to allow multiple users to telnet into virtual terminals, >> similar to how the SIMH PDP-11 and VAX emulators work. >> >> For now, information about the emulator lives here: >> >> https://loomcom.com/3b2/emulator/ >> >> >> Best Wishes, >> >> -Seth >> -- >> Seth Morabito >> web at loomcom.com >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Sat Dec 9 20:04:20 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sat, 9 Dec 2017 18:04:20 +0800 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: I always liked her quick talk on a nanosecond vs a microsecond https://www.youtube.com/watch?v=JEpsKnWZrJ8 I wonder what she’d think about a PDP-11 running in javascript... Sent from Mail for Windows 10 From: Dave Horsfall Sent: Saturday, 9 December 2017 7:27 AM To: The Eunuchs Hysterical Society Subject: [TUHS] Grace Hopper (At the risk of being flamed because it's not strictly Unix...) We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing Grace", she was a remarkable woman, both in computers and the Navy. She coined the term "debugging" when she extracted a moth from a set of relay contacts from a computer (the Harvard Mk I) and wrote "computer debugged" in the log, taping the deceased Lepidoptera in there as well. She was convinced that computers could be programmed in an English-like language and developed Flow-Matic, which in turn became, err, COBOL... She was posthumously awarded the Presidential Medal of Freedom in 2016 by Barack Obama. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sun Dec 10 03:31:18 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Sat, 9 Dec 2017 12:31:18 -0500 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: I attended a lecture by Admiral Hopper ca. 1981 at DEC's software engineering facility in Nashua NH. She used the micorsecond/nanosecond demonstration as part of a prediction of the end of Moore's Law, and the eventual need for parallel processing to make further gains in computing speed. She drew another analogy: in the 19th century, if you wanted to haul a larger load, you didn't breed bigger and bigger horses; you hitched up several horses as a team. She was quite the visionary. She handed out nanoseconds as souvenirs after the talk. I still treasure mine. -Paul W. From arnold at skeeve.com Sun Dec 10 04:03:10 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Sat, 09 Dec 2017 11:03:10 -0700 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: <201712091803.vB9I3AYQ006833@freefriends.org> Dave Horsfall wrote: > We gained Rear Admiral Grace Hopper on this day in 1906; known as "Amazing > Grace", she was a remarkable woman, both in computers and the Navy. No argument there. > She coined the term "debugging" when she extracted a moth from a set of > relay contacts from a computer (the Harvard Mk I) and wrote "computer > debugged" in the log, taping the deceased Lepidoptera in there as well. See https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term which indicates that "bug" and "debugging" had been around as technical terms long before that incident. Otherwise, yes, an amazing person. Arnold From lyndon at orthanc.ca Sun Dec 10 06:03:50 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Sat, 9 Dec 2017 12:03:50 -0800 Subject: [TUHS] Grace Hopper In-Reply-To: References: Message-ID: <10C35EA0-FADA-4ADE-9311-8485D53BE91F@orthanc.ca> > On Dec 9, 2017, at 2:04 AM, Jason Stevens wrote: > > I always liked her quick talk on a nanosecond vs a microsecond Her Letterman appearance is a classic :-) https://www.youtube.com/watch?v=1-vcErOPofQ From dave at horsfall.org Sun Dec 10 09:02:16 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 10 Dec 2017 10:02:16 +1100 (EST) Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: As promised :-) Augusta Ada King-Noel, Countess of Lovelace (and daughter of Lord Byron), was born on this day in 1815; arguably the world's first computer programmer and a highly independent woman, she saw the potential in Charles Babbage's new-fangled invention. J.F.Ossanna was given unto us on this day in 1928; a prolific programmer, he not only had a hand in developing Unix but also gave us the ROFF series. Who'ld've thought that two computer greats would share the same birthday? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ralph at inputplus.co.uk Sun Dec 10 09:08:59 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 09 Dec 2017 23:08:59 +0000 Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! In-Reply-To: References: Message-ID: <20171209230859.BA00C21CB3@orac.inputplus.co.uk> Hi Dave, > Who'ld've thought that two computer greats would share the same birthday? Obligatory https://en.wikipedia.org/wiki/Birthday_problem -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From dave at horsfall.org Sun Dec 10 09:17:54 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 10 Dec 2017 10:17:54 +1100 (EST) Subject: [TUHS] Grace Hopper In-Reply-To: <201712091803.vB9I3AYQ006833@freefriends.org> References: <201712091803.vB9I3AYQ006833@freefriends.org> Message-ID: On Sat, 9 Dec 2017, arnold at skeeve.com wrote: >> She coined the term "debugging" when she extracted a moth from a set of >> relay contacts from a computer (the Harvard Mk I) and wrote "computer >> debugged" in the log, taping the deceased Lepidoptera in there as well. > > See https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term which > indicates that "bug" and "debugging" had been around as technical terms > long before that incident. I need to investigate that further (I'd hate to spread misinformation, which is why I enjoy being corrected, esp. in public). (Pause for a message from the sponsor) Ah yes, the quote is "First actual case of bug being found" (and it was a Mk II, not a Mk I); thanks! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sun Dec 10 09:33:35 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 10 Dec 2017 10:33:35 +1100 (EST) Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! In-Reply-To: <20171209230859.BA00C21CB3@orac.inputplus.co.uk> References: <20171209230859.BA00C21CB3@orac.inputplus.co.uk> Message-ID: On Sat, 9 Dec 2017, Ralph Corderoy wrote: > Obligatory https://en.wikipedia.org/wiki/Birthday_problem Yeah, but all the same, two famous people in the same industry would surely lengthen the odds somewhat... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From ralph at inputplus.co.uk Sun Dec 10 09:37:03 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 09 Dec 2017 23:37:03 +0000 Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! In-Reply-To: References: <20171209230859.BA00C21CB3@orac.inputplus.co.uk> Message-ID: <20171209233703.46BD621CB3@orac.inputplus.co.uk> > > Obligatory https://en.wikipedia.org/wiki/Birthday_problem > > Yeah, but all the same, two famous people in the same industry would > surely lengthen the odds somewhat... Yeah, you're pulling my leg. :-) https://en.wikipedia.org/wiki/List_of_computer_scientists -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From grog at lemis.com Sun Dec 10 09:41:17 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 10 Dec 2017 10:41:17 +1100 Subject: [TUHS] Origin of "bug" (was: Grace Hopper) In-Reply-To: References: <201712091803.vB9I3AYQ006833@freefriends.org> Message-ID: <20171209234117.GG78437@eureka.lemis.com> On Sunday, 10 December 2017 at 10:17:54 +1100, Dave Horsfall wrote: > On Sat, 9 Dec 2017, arnold at skeeve.com wrote: > >>> She coined the term "debugging" when she extracted a moth from a set of >>> relay contacts from a computer (the Harvard Mk I) and wrote "computer >>> debugged" in the log, taping the deceased Lepidoptera in there as well. >> >> See https://en.wikipedia.org/wiki/Debugging#Origin_of_the_term which >> indicates that "bug" and "debugging" had been around as technical terms >> long before that incident. > > I need to investigate that further (I'd hate to spread misinformation, > which is why I enjoy being corrected, esp. in public). I was going to pipe up here, but I wasn't sure if it would be interesting. The Oxford English Dictionary has a first reference to in this sense in 1875: 5. orig. U.S. a. A defect or fault in a machine (esp. an electrical or electronic one), or in a process, etc. 1875 Operator 15 Aug. 5/1 The biggest ‘bug’ yet has been discovered in the U.S. Hotel Electric Annunciator. 1889 Pall Mall Gaz. 11 Mar. 1/1 Mr. Edison, I was informed, had been up the two previous nights discovering ‘a bug’ in his phonograph—an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble. Grace Hopper's bug doesn't get a mention. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From dave at horsfall.org Sun Dec 10 10:23:29 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 10 Dec 2017 11:23:29 +1100 (EST) Subject: [TUHS] Card reader on Unix Message-ID: Something's been bothering me for a while... I've just remembered that our 11/40 with more peripherals than you could shake a stick at -- it had just about everything except a DECtape -- also had, so help me, a card reader! As I dimly recall, 'twas a slow CDC (?) model; we didn't have it for long, either because it was on loan or because it was so unreliable, I simply don't remember. Anyway, our driver handled it in two modes: you either got a raw image of each card (likely via DMA instead of column by column, but I could be wrong) i.e. 80 words with each column of 12 holes fitting nicely into a 16-bit word, or there was a half-arsed attempt at converting EBCDIC to ASCII, with trailing blanks replaced by a newline (i.e. think of it as a line printer in reverse). Or was it converting from whatever KRONOS used to ASCII? Now, what I *distinctly* remember was writing two scripts: "/etc/cdc" and "/etc/dec" which switched between the two modes, quite likely by patching the in-core kernel! I'd give a testicle to have that "CSU tape" back again (and no doubt so would Warren), but can anyone else remember this (or dare to call me a liar; yes, I'm still touchy about that)? The snag is, towards the end of the CSU before they were about to be engulfed by the admin suits and forced to support payroll programs in COBOL etc, I was the only senior Unix bod left, so it's unlikely that the CSU source code followed someone else home... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From bakul at bitblocks.com Sun Dec 10 10:30:57 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 9 Dec 2017 16:30:57 -0800 Subject: [TUHS] Origin of "bug" (was: Grace Hopper) In-Reply-To: <20171209234117.GG78437@eureka.lemis.com> References: <201712091803.vB9I3AYQ006833@freefriends.org> <20171209234117.GG78437@eureka.lemis.com> Message-ID: May be it is derived from “bugbear”? As per Merriam-Webster: 1) an imaginary goblin or specter used to excite fear 2) a source of dread, a continuing source of irritation: a problem. First known use 1552. From dave at horsfall.org Sun Dec 10 12:23:13 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST) Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! In-Reply-To: <20171209233703.46BD621CB3@orac.inputplus.co.uk> References: <20171209230859.BA00C21CB3@orac.inputplus.co.uk> <20171209233703.46BD621CB3@orac.inputplus.co.uk> Message-ID: On Sat, 9 Dec 2017, Ralph Corderoy wrote: >> Yeah, but all the same, two famous people in the same industry would >> surely lengthen the odds somewhat... > > Yeah, you're pulling my leg. :-) > https://en.wikipedia.org/wiki/List_of_computer_scientists OK, it was worth a try :-) (I'm a born stirrer, and I blame my parents for that.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Sun Dec 10 13:20:09 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Sun, 10 Dec 2017 14:20:09 +1100 Subject: [TUHS] Origin of "bug" (was: Grace Hopper) In-Reply-To: References: <201712091803.vB9I3AYQ006833@freefriends.org> <20171209234117.GG78437@eureka.lemis.com> Message-ID: <20171210032009.GJ78437@eureka.lemis.com> On Saturday, 9 December 2017 at 16:30:57 -0800, Bakul Shah wrote: > May be it is derived from ???bugbear???? As per Merriam-Webster: > 1) an imaginary goblin or specter used to excite fear > 2) a source of dread, a continuing source of irritation: a problem. > First known use 1552. OED suggests that both our "bug" and "bugbear" are derived from "bug" (An insect or other arthropod). It agrees with the 1552 date: 1552 R. King Funerall Serm. sig. F.iiiiv Momishe mopers whiche can do none other thyng else, but mope vppon ther bookes, to make vs afraied of shadowes and buggeberes. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From rudi.j.blom at gmail.com Mon Dec 11 14:59:15 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Mon, 11 Dec 2017 11:59:15 +0700 Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: Anyone on TUHS who made the list? Greeting from your Dutch uncle rubl For all the sound advise you don't want to hear. Date: Sun, 10 Dec 2017 13:23:13 +1100 (EST) From: Dave Horsfall To: The Eunuchs Hysterical Society Subject: Re: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed On Sat, 9 Dec 2017, Ralph Corderoy wrote: >> Yeah, but all the same, two famous people in the same industry would >> surely lengthen the odds somewhat... > > Yeah, you're pulling my leg. :-) > https://en.wikipedia.org/wiki/List_of_computer_scientists OK, it was worth a try :-) (I'm a born stirrer, and I blame my parents for that.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Dec 11 15:49:15 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 11 Dec 2017 16:49:15 +1100 (EST) Subject: [TUHS] Happy birthday, Grace Hopper and J.F.Ossana! In-Reply-To: References: Message-ID: On Mon, 11 Dec 2017, Rudi Blom wrote: >> https://en.wikipedia.org/wiki/List_of_computer_scientists > Anyone on TUHS who made the list? I've seen Ken Thompson post a few times... Well, somebody using that name, anyway :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From gtaylor at tnetconsulting.net Mon Dec 11 16:13:42 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sun, 10 Dec 2017 23:13:42 -0700 Subject: [TUHS] Other history lists... Message-ID: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> Does anyone know of any other similar history discussion mailing lists / newsgroups to discuss things like Mainframes or (Open)VMS? I have some questions as I try to broaden my horizons, but I don't think they fit in the TUHS context. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From kevin.bowling at kev009.com Mon Dec 11 19:33:48 2017 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Mon, 11 Dec 2017 02:33:48 -0700 Subject: [TUHS] Other history lists... In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> Message-ID: Both are good criteria for http://www.classiccmp.org/cctalk.html although it gets a lot of random chatter. I find SNR goes down quickly where personal computers are included in lists/forums although that may be my own interests reflecting. On Sunday, December 10, 2017, Grant Taylor via TUHS wrote: > Does anyone know of any other similar history discussion mailing lists / > newsgroups to discuss things like Mainframes or (Open)VMS? > > I have some questions as I try to broaden my horizons, but I don't think > they fit in the TUHS context. > > > > -- > Grant. . . . > unix || die > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Tue Dec 12 04:17:13 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Mon, 11 Dec 2017 13:17:13 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <201712061849.vB6InBKS031624@darkstar.fourwinds.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: On 12/6/17, Jon Steinhart wrote: > > There's another aspect of this that I think that many people misunderstand > which is that Judge Green gave AT&T exactly what they wanted. AT&T knew > that in the future the money was in data and were willing to trade their > monopoly for that business. From their perspective, it worked. For the > rest of us, not so good. Except that the new AT&T, liberated from the regulatory chains of the Bell operating companies, never learned how to compete in the free market. They got their clock cleaned by the competition. In desperation they bought Olivetti and only managed to run it into the ground. -Paul W. From clemc at ccc.com Tue Dec 12 04:39:44 2017 From: clemc at ccc.com (Clem Cole) Date: Mon, 11 Dec 2017 13:39:44 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski wrote: > On 12/6/17, Jon Steinhart wrote: > > > > There's another aspect of this that I think that many people > misunderstand > > which is that Judge Green gave AT&T exactly what they wanted. AT&T knew > > that in the future the money was in data and were willing to trade their > > monopoly for that business. From their perspective, it worked. For the > > rest of us, not so good. > > Except that the new AT&T, liberated from the regulatory chains of the > Bell operating companies, never learned how to compete in the free > market. They got their clock cleaned by the competition. In > desperation they bought Olivetti and only managed to run it into the > ground ​To be fair you are both right. I think at the time Charlie Brown and Team at AT&T wanted to make a go at IBM and DEC (*i.e.* large systems) and Paul's right, they missed. But Jon is right that they had realized that it going to be a data centric business and he and his team felt that the current consent decree we going to keep them from being players in it. To me there were a couple of issues. The Phone System and 'TPC' was centrally controlled (a lot like a communist country). Where it worked, it was fine. But... the problem was that anything outside their view of reality was a threat. It's funny as the time, IBM, DEC et al were trying to build centrally managed (closed garden networks) too, just like the phone system, so it was not a stretch for them the think that way. IP and datagrams were very much built on no central control, which was something TPC thought was bad and fought. I remember so, so many of those fights at the time and trying to explain that IP was going to win. In the end, it was MetCalfe's law (which was formulated on observations about the phone system) that caused IP to win, along with "Clark's Observation" making everything a "network of networks" instead if a single managed system - which made the plumbing work. So while I find it sad to see Comcast, Current version of AT&T, Verizon et al, all want to see the net neutrality go away, I do not find it surprising. Its the same behavior as before. What would have happened if Judge Green had not broken them up? I do think broadband would be more universal, but .... I suspect AT&T would have fought it and tried to use things that dreamed up (ATM, ISDN, et al). My 2 cents.... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Dec 12 05:23:28 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 14:23:28 -0500 (EST) Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] Message-ID: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> > From: Clem Cole > IP and datagrams were very much built on no central control Well, yes and no. One can easily have a centrally controlled datagram network (q.v. the ARPANET) - although it's true that its path-selection algorithms, etc were not centrally controlled - but other aspects of the network were. (Interestingly, after various routing disasters the Internet caused by improper configuration, some aspects of path selection in _parts_ of it are now effectively centrally controlled; but I digress.) The IP Internet was designed with no _overall_ central control, but as a collection of autonomous entities. > In the end, it was MetCalfe's law (which was formulated on observations > about the phone system) that caused IP to win Over any and all comers, including other decentralized datagram networks like CLNP. MetCalfe's law doesn't talk about decentralized, it's just about 'first to field'. > all want to see the net neutrality go away This whole 'net neutrality' campaign drives me completely crazy. If all people wanted was a rule saying 'ISPs can't give third parties _worse_ service, or - more importantly - deny service altogether, unless those parties pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a rule like that. But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not aware of/thinking about these details) are all signing up for a much more expansive rule, one that says 'no ISP can offer anyone _better_ service for paying more money' - which is quite different. My problems with this latter form are two-fold. First, what's wrong with that anyway? Do we have a rule saying you can't get better road service if you pay? Absolutely not - restricted toll lanes are becoming more and more common. So there's clearly no societal agreement on this principle. (I suspect this 'net netrality' campaign has as a goal some sort of 'forced equality' thing - unless the people behind it simply don't even understand the difference.) Second, that rule is, with a little extra work on the ISPs' part, ineffective anyway. All they have to do is build _two_ networks, one better provisioned than the other - and priced accordingly. You want better service? Sign up for the second network; you'll pay more, but it's your choice. Noel From lm at mcvoy.com Tue Dec 12 05:36:57 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 11 Dec 2017 11:36:57 -0800 Subject: [TUHS] net neutrality In-Reply-To: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> Message-ID: <20171211193657.GI26887@mcvoy.com> On Mon, Dec 11, 2017 at 02:23:28PM -0500, Noel Chiappa wrote: > This whole 'net neutrality' campaign drives me completely crazy. > > If all people wanted was a rule saying 'ISPs can't give third parties _worse_ > service, or - more importantly - deny service altogether, unless those parties > pay up' (i.e. what would amount to targeted extortion), I'd be _all for_ a > rule like that. > > But the 'net neutrality' aficionados (most of whom, I'm fairly sure, are not > aware of/thinking about these details) are all signing up for a much more > expansive rule, one that says 'no ISP can offer anyone _better_ service for > paying more money' - which is quite different. My problems with this latter > form are two-fold. So that's not at all the case. Go look at the history, various ISPs like Verizon, Comcast, etc, have done stuff like block bittorrent, skype, etc, anything that they decided wasn't in their interest. The problem is I paid for the bits. Bits is bits. I paid for a rate, that's what they got paid for, why should they get to charge a second time for the same bits? That's exactly what they want to do. You pay them, you pay netflix, you've paid for the carrier, you've paid for the content, oh, you want it to actually stream? Too bad, Netflix didn't pay their extortion so your movie watching sucks. Don't believe me? OK, how about this? https://np.reddit.com/r/NeutralPolitics/comments/7i595b/will_the_repeal_of_net_neutrality_actually_help/dqwzn1g/ From clemc at ccc.com Tue Dec 12 05:48:59 2017 From: clemc at ccc.com (Clem Cole) Date: Mon, 11 Dec 2017 14:48:59 -0500 Subject: [TUHS] net neutrality In-Reply-To: <20171211193657.GI26887@mcvoy.com> References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> <20171211193657.GI26887@mcvoy.com> Message-ID: On Mon, Dec 11, 2017 at 2:36 PM, Larry McVoy wrote: > > The problem is I paid for the bits. Bits is bits. I paid for a rate, ​Amen brother... they must be made a common carrier. Just like a shipping contain is 'said to contain' - they don't get to peek inside. The bits are not theirs. They have one and only one job -- delivery them. Just like the electric company, needs to deliver electrons at some rate/force. They don't get to say I what I use them for. The bits coming in/going out are between me and the side I am communicating. They are carriers i.e. plumbing --- which of course they do not like. It means its a lot hard for them to differentiate themselves other than in service and price for delivery. Period. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Dec 12 06:10:22 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 15:10:22 -0500 (EST) Subject: [TUHS] net neutrality Message-ID: <20171211201022.26C4418C08C@mercury.lcs.mit.edu> > From: Larry McVoy > look at the history, various ISPs like Verizon, Comcast, etc, have done > stuff like block bittorrent, skype, etc Bittorrent is a complex situation, some ISPs were ordered by a court to block it. As to Skype, I agree ISPs shouldn't block sites - but if you read my message, I already said that. > The problem is I paid for the bits. Bits is bits. I paid for a rate, > that's what they got paid for, why should they get to charge a second > time for the same bits? That's exactly what they want to do. Fine, you pay your money, you get X Mbits/second. If you (or the site you're getting bits from) wants _more_ than X Mbits/second, charging you - or them, which is I gather mostly what ISPs want to do - for that privilege is a problem... how? Noel From ches at cheswick.com Tue Dec 12 06:11:22 2017 From: ches at cheswick.com (William Cheswick) Date: Mon, 11 Dec 2017 15:11:22 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: <07C431DE-4AB4-4180-8C65-3D58589E83A1@cheswick.com> While I am no fan of how AT&T ran its business, and the diminution of Bell Labs is a capital crime to humanity, it must be noted that AT&T was competing with MCI, who was cooking the books. “How can they offer phone calls for $0.01/minute?” The answer: they couldn’t, but did anyway. BTW, there are still good people doing good work at Bell Labs. But it certainly isn’t what it used to be. > On 11Dec 2017, at 1:17 PM, Paul Winalski wrote: > > Except that the new AT&T, liberated from the regulatory chains of the > Bell operating companies, never learned how to compete in the free > market. They got their clock cleaned by the competition. In > desperation they bought Olivetti and only managed to run it into the > ground. > > -Paul W. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Tue Dec 12 06:13:18 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 15:13:18 -0500 (EST) Subject: [TUHS] net neutrality Message-ID: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu> > From: Clem Cole > Just like the electric company, needs to deliver electrons at some > rate/force. If you want electrons at more than X bazillion per second, you'll have to pay to have a higher-amperage service. And if you use more electrons, you pay more. What's your problem with ISPs doing the same? Noel From lm at mcvoy.com Tue Dec 12 06:13:39 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 11 Dec 2017 12:13:39 -0800 Subject: [TUHS] net neutrality In-Reply-To: <20171211201022.26C4418C08C@mercury.lcs.mit.edu> References: <20171211201022.26C4418C08C@mercury.lcs.mit.edu> Message-ID: <20171211201339.GJ26887@mcvoy.com> On Mon, Dec 11, 2017 at 03:10:22PM -0500, Noel Chiappa wrote: > > From: Larry McVoy > > > look at the history, various ISPs like Verizon, Comcast, etc, have done > > stuff like block bittorrent, skype, etc > > Bittorrent is a complex situation, some ISPs were ordered by a court to block > it. > > As to Skype, I agree ISPs shouldn't block sites - but if you read my message, > I already said that. > > > > The problem is I paid for the bits. Bits is bits. I paid for a rate, > > that's what they got paid for, why should they get to charge a second > > time for the same bits? That's exactly what they want to do. > > Fine, you pay your money, you get X Mbits/second. > > If you (or the site you're getting bits from) wants _more_ than X > Mbits/second, charging you - or them, which is I gather mostly what ISPs want > to do - for that privilege is a problem... how? Did you read the reddit link I sent? Because if you had you wouldn't be asking this. I took the time to go find it, it lays out past bad behaviour that is nothing like what you are suggesting. It took me a while to find it, you could at least scan it and then maybe there is a conversation to be had (not sure what though, it's pretty obvious in this, and pretty much every other case, that unregulated businesses will do whatever they can to make more money with absolutely no concern about the consequences). From lm at mcvoy.com Tue Dec 12 06:14:44 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 11 Dec 2017 12:14:44 -0800 Subject: [TUHS] net neutrality In-Reply-To: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu> References: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu> Message-ID: <20171211201444.GK26887@mcvoy.com> On Mon, Dec 11, 2017 at 03:13:18PM -0500, Noel Chiappa wrote: > > From: Clem Cole > > > Just like the electric company, needs to deliver electrons at some > > rate/force. > > If you want electrons at more than X bazillion per second, you'll have to pay > to have a higher-amperage service. And if you use more electrons, you pay > more. What's your problem with ISPs doing the same? They already do that. You pay based on how fast you want it to be. Just like the electrons. We regulate utility companies for a reason. From wkt at tuhs.org Tue Dec 12 06:18:43 2017 From: wkt at tuhs.org (Warren Toomey) Date: Tue, 12 Dec 2017 06:18:43 +1000 Subject: [TUHS] net neutrality In-Reply-To: <20171211201444.GK26887@mcvoy.com> References: <20171211201318.9E42E18C08C@mercury.lcs.mit.edu> <20171211201444.GK26887@mcvoy.com> Message-ID: <20171211201843.GA25613@minnie.tuhs.org> All, the net neutrality thread is way too off-topic for TUHS. Please continue the conversation off the list. Many thanks, Warren From jnc at mercury.lcs.mit.edu Tue Dec 12 06:27:10 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 15:27:10 -0500 (EST) Subject: [TUHS] net neutrality Message-ID: <20171211202710.3658018C08C@mercury.lcs.mit.edu> > From: Larry McVoy > Did you read the reddit link I sent? No, because I despise Reddit. > Because if you had you wouldn't be asking this. Now that I look at it, most of what I lists is ISP's _blocking_ sites. I _already_ said I wanted to see a rule preventing that. > unregulated businesses will do whatever they can to make more money with > absolutely no concern about the consequences Sure - like content providers. Noel From rminnich at gmail.com Tue Dec 12 07:09:05 2017 From: rminnich at gmail.com (ron minnich) Date: Mon, 11 Dec 2017 21:09:05 +0000 Subject: [TUHS] net neutrality In-Reply-To: <20171211202710.3658018C08C@mercury.lcs.mit.edu> References: <20171211202710.3658018C08C@mercury.lcs.mit.edu> Message-ID: in gmail, you just hit m and the thread is gone. On Mon, Dec 11, 2017 at 12:27 PM Noel Chiappa wrote: > > From: Larry McVoy > > > Did you read the reddit link I sent? > > No, because I despise Reddit. > > > Because if you had you wouldn't be asking this. > > Now that I look at it, most of what I lists is ISP's _blocking_ sites. > I _already_ said I wanted to see a rule preventing that. > > > unregulated businesses will do whatever they can to make more money > with > > absolutely no concern about the consequences > > Sure - like content providers. > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Dec 12 09:26:10 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 11 Dec 2017 18:26:10 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <07C431DE-4AB4-4180-8C65-3D58589E83A1@cheswick.com> References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> <07C431DE-4AB4-4180-8C65-3D58589E83A1@cheswick.com> Message-ID: On 12/11/2017 3:11 PM, William Cheswick wrote: > While I am no fan of how AT&T ran its business, and the diminution of > Bell Labs is > a capital crime to humanity, it must be noted that AT&T was competing > with MCI, who > was cooking the books. “How can they offer phone calls for > $0.01/minute?”  The answer: > they couldn’t, but did anyway. > As I recall, MCI was also passing calls into Canada, routing them back to the US and avoiding all sorts of fees. They were doing it to the US Govt, I'm not sure if they did that to regular people. art .k From scj at yaccman.com Tue Dec 12 10:27:17 2017 From: scj at yaccman.com (Steve Johnson) Date: Mon, 11 Dec 2017 16:27:17 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: Message-ID: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> I don't dispute anything you said, but I think there is another element.  It was simply an element of faith that to send voice you needed to have a guaranteed rate of speed.  Thus the interest in time-division multiplexing.  Deeply built into the Bell System mentality was the notion that you shouldn't offer service unless it is good service.  Thus the dial tone -- if the network was jammed, they didn't let you make a call.  But the ones that got through ran with no problems... Recently I've been attempting to Skype on a group call with 5 people in Europe.  I would LOVE to have a guaranteed bandwidth for my call.  For "ordinary", non-time critical things, I'd be happy to fight for bits on an equal footing with everybody else.  Maybe the best solution is two networks... Steve ----- Original Message ----- From: "Clem Cole" To: "Paul Winalski" Cc: "TUHS main list" Sent: Mon, 11 Dec 2017 13:39:44 -0500 Subject: Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski wrote: On 12/6/17, Jon Steinhart wrote: > > There's another aspect of this that I think that many people misunderstand > which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew > that in the future the money was in data and were willing to trade their > monopoly for that business.  From their perspective, it worked.  For the > rest of us, not so good. Except that the new AT&T, liberated from the regulatory chains of the Bell operating companies, never learned how to compete in the free market.  They got their clock cleaned by the competition.  In desperation they bought Olivetti and only managed to run it into the ground ​To be fair you are both right.  I think at the time Charlie Brown and Team at AT&T wanted to make a go at IBM and DEC (_i.e._ large systems) and Paul's right, they missed. But Jon is right that they had realized that it going to be a data centric business and he and his team felt that the current consent decree we going to keep them from being players in it.    To me there were a couple of issues.  The Phone System and 'TPC' was centrally controlled (a lot like a communist country).   Where it worked, it was fine.   But... the problem was that anything outside their view of reality was a threat.  It's funny as the time, IBM, DEC et al were trying to build centrally managed (closed garden networks) too, just like the phone system, so it was not a stretch for them the think that way. IP and datagrams were very much built on no central control, which was something TPC thought was bad and fought.   I remember so, so many of those fights at the time and trying to explain that IP was going to win.    In the end, it was MetCalfe's law (which was formulated on observations about the phone system) that caused IP to win, along with "Clark's Observation" making everything a "network of networks" instead if a single managed system - which made the plumbing work. So while I find it sad to see Comcast, Current version of AT&T, Verizon et al, all want to see the net neutrality go away, I do not find it surprising.   Its the same behavior as before. What would have happened if Judge Green had not broken them up?   I do think broadband would be more universal, but .... I suspect AT&T would have fought it and tried to use things that dreamed up (ATM, ISDN, et al). My 2 cents.... Clem Links: ------ [1] mailto:paul.winalski at gmail.com [2] mailto:jon at fourwinds.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon at fourwinds.com Tue Dec 12 11:05:10 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 11 Dec 2017 17:05:10 -0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] [ and besides it's "Addendum" ] In-Reply-To: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> Message-ID: <201712120105.vBC15A2q026046@darkstar.fourwinds.com> "Steve Johnson" writes: > I don't dispute anything you said, but I think there is another element.  It > was simply an element of faith that to send voice you needed to have a > guaranteed rate of speed.  Thus the interest in time-division multiplexing.  > Deeply built into the Bell System mentality was the notion that you shouldn't > offer service unless it is good service.  Thus the dial tone -- if the network > was jammed, they didn't let you make a call.  But the ones that got through ran > with no problems... > > Recently I've been attempting to Skype on a group call with 5 people in > Europe.  I would LOVE to have a guaranteed bandwidth for my call.  For > "ordinary", non-time critical things, I'd be happy to fight for bits on an > equal footing with everybody else.  Maybe the best solution is two networks... > > Steve Well, many of us pine for the days in which one could get a quality voice call. I agree with Steve that Bell did quality. But I'm not sure that the relationship between bandwidth and dial tone is correct. It's my recollection that, because they were more expensive than other parts of the exchange especially back in the relay days, that the number of incoming registers was determined statistically. The incoming register was the thing that showed up on your line, gave you dial tone, accepted your dialing, hooked you up to the designated recipient, and then went away to service another line. In other words, they were transient resources. Theoretically every circuit on an exchange could be connected to another because it was a switched circuit system. But there were only so many of the machines available to make the connections. That's why it was hard to get dial tone in an emergency; everybody was trying to dial at the same time and had to wait for an incoming register to show up on their line. That's also why you get a busy signal if you don't dial quickly enough; the incoming register times out, hooks your line up to a busy tone generator, and goes off to do work for another line. Note that that's all independent from whether or not there were available circuits for toll calls between exchanges. I believe that it was the same general setup in the good old (hackable) common-control days; you just didn't get to hear the key pulse sender in operation. Funny story on that which is when the SS1 (slave switch one) was being developed which was possibly the first all digital exchange, Carl had a coding error that forgot to send the ST pulse and took every key pulse sender out of service at the Berkeley Heights exchange. I recall that the KP units don't time out and that some very angry person over there had to go in and manually reset all of them. But hey, they were the phone company and so were we so what could one do? For those of you that don't know about the SS1 project, which you wouldn't know about unless you were there, it was the first application of the digital filtering work done by Jim Kaiser and Hal Alles. It used a pair of PDP-11/10s. Tried to use LSI-11s but their idiotic memory refresh mechanism made them useless for real time work. It might have been Heinz created MERT for this project. Jon From jnc at mercury.lcs.mit.edu Tue Dec 12 11:28:35 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 20:28:35 -0500 (EST) Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] Message-ID: <20171212012835.B290518C08C@mercury.lcs.mit.edu> > From: Steve Johnson > Recently I've been attempting to Skype on a group call with 5 people in > Europe. I would LOVE to have a guaranteed bandwidth for my call. The Internet engineering community did quite a bit of work on resource guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control protocol.) Unfortunately, there was never much interest in it. People started doing voice with just plain 'best effort' service, and I guess it worked 'well enough' that nobody was interested in IntServ/RSVP. Noel From ggm at algebras.org Tue Dec 12 11:42:58 2017 From: ggm at algebras.org (George Michaelson) Date: Tue, 12 Dec 2017 11:42:58 +1000 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <20171212012835.B290518C08C@mercury.lcs.mit.edu> References: <20171212012835.B290518C08C@mercury.lcs.mit.edu> Message-ID: I don't think this list is the right place to conduct that particular debate. Its true RSVP didn't get traction, but the economics which underpin it are pretty bad, for the current Internet model of settlement and 'who pays, and when' -There was no point at which RSVP was going to deploy into the inter-carrier settlement regime we have, and have had for some time. It didn't actually mean buying 'more' of anything, it simply meant pushing people who wouldn't buy more, into smaller drop buckets. I'd counter (sort of) with a comment that I heard at NANOG San Jose from a US tier-1. There is more glass in the ground, than lit, by at least one order of magnitude. If you have congestion on any US domestic link, its not because you don't actually have clear channel, its because somebody is making money from artificial scarcity. I don't know for sure that the same is true trans-atlantic or trans-pacific, but it would not surprise me if there is a lot of unlit capacity, and more dropped packets than strictly speaking the glass expects. n-way conferencing is about as stressful as it gets for loss, and delay. I think its a minor miracle I can do 3 or 4 way, heads and voice at all. If I was paying, I'd expect better. Free QDU's are like greshams law: bad (cheap) comms drives out good (paid) comms. -G On Tue, Dec 12, 2017 at 11:28 AM, Noel Chiappa wrote: > > From: Steve Johnson > > > Recently I've been attempting to Skype on a group call with 5 people in > > Europe. I would LOVE to have a guaranteed bandwidth for my call. > > The Internet engineering community did quite a bit of work on resource > guarantees. (Google 'IntServ' and 'RSVP' - the latter is the control > protocol.) > > Unfortunately, there was never much interest in it. People started doing > voice with just plain 'best effort' service, and I guess it worked 'well > enough' that nobody was interested in IntServ/RSVP. > > Noel From lm at mcvoy.com Tue Dec 12 11:45:39 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 11 Dec 2017 17:45:39 -0800 Subject: [TUHS] MERT? In-Reply-To: <201712120105.vBC15A2q026046@darkstar.fourwinds.com> References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> <201712120105.vBC15A2q026046@darkstar.fourwinds.com> Message-ID: <20171212014539.GX26887@mcvoy.com> Do we have those sources? -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jnc at mercury.lcs.mit.edu Tue Dec 12 12:04:32 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 21:04:32 -0500 (EST) Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] Message-ID: <20171212020432.4821118C08C@mercury.lcs.mit.edu> > From: George Michaelson > I don't think this list is the right place to conduct that particular > debate. Not disagreeing; my message was a very short gloss on a very complicated situation, and I wasn't trying to push any particular position, just pointing out that work (whether the right direction, or not, I didn't opine) had been done. > Its true RSVP didn't get traction, but the economics which underpin it > are pretty bad, for the current Internet model of settlement Yes, but would _any_ resource reservation system, even one that _was_ 'perfect', have caught on? Because: > it would not surprise me if there is ... more dropped packets than > strictly speaking the glass expects. This is related to something I didn't mention; if there is a lot more bandwidth (in the loose sense, not the exact original meaning) than demand, then resource reservation mechanisms buy you nothing, and are a lot of complexity. While there were bandwidth shortages in the 90s, later on they pretty much went away. So I think the perception (truth?) that there was a lot of headroom (and thus no need for resource reservation, to do applications like voice) played a really big role in the lack of interest (or so people argued at the time, in saying IntServ wasn't needed). Noel From jon at fourwinds.com Tue Dec 12 12:09:54 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Mon, 11 Dec 2017 18:09:54 -0800 Subject: [TUHS] MERT? In-Reply-To: <20171212014539.GX26887@mcvoy.com> References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> <201712120105.vBC15A2q026046@darkstar.fourwinds.com> <20171212014539.GX26887@mcvoy.com> Message-ID: <201712120209.vBC29sVZ001569@darkstar.fourwinds.com> Larry McVoy writes: > Do we have those sources? I don't know if I've ever seen 'em outside of BTL. Probably the best person to ask is Heinz Lycklama. From ggm at algebras.org Tue Dec 12 12:17:39 2017 From: ggm at algebras.org (George Michaelson) Date: Tue, 12 Dec 2017 12:17:39 +1000 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <20171212020432.4821118C08C@mercury.lcs.mit.edu> References: <20171212020432.4821118C08C@mercury.lcs.mit.edu> Message-ID: It lives on, in the QoS tagging gamers and VOIP people do on their home routers, in a faint hope that apart from outbound queues, inbound queues from their local provider do some kind of (re)prioritization based on it. Since thats the person who they pay money to, it kind-of makes sense. I didn't mean to disrespect the people who did the models or the protocol or standards work btw. Like you, I think it was a solution in search of a problem, in a point in time now past. What we have now, is a horrid war on capital investment. Nobody wants to turn up the unlit glass, because it would expose the pricing models which depend on artificially constructed scarcity. It interests me that a lot of stuff which doesn't work 'in the wide' does work in specific contexts. So I would not be surprised if RSVP and like things survive inside large corporate networks. In like sense, aircraft databusses are often just normal switches with isochronous TDM slot markers, to give them guaranteed/bounded delivery behaviours. I think Christian Huitema did some stuff . on that in Ethernet while he was in INRIA (or somebody in the same unit) -G On Tue, Dec 12, 2017 at 12:04 PM, Noel Chiappa wrote: > > From: George Michaelson > > > I don't think this list is the right place to conduct that particular > > debate. > > Not disagreeing; my message was a very short gloss on a very complicated > situation, and I wasn't trying to push any particular position, just pointing > out that work (whether the right direction, or not, I didn't opine) had been > done. > > > Its true RSVP didn't get traction, but the economics which underpin it > > are pretty bad, for the current Internet model of settlement > > Yes, but would _any_ resource reservation system, even one that _was_ > 'perfect', have caught on? Because: > > > it would not surprise me if there is ... more dropped packets than > > strictly speaking the glass expects. > > This is related to something I didn't mention; if there is a lot more > bandwidth (in the loose sense, not the exact original meaning) than demand, > then resource reservation mechanisms buy you nothing, and are a lot of > complexity. > > While there were bandwidth shortages in the 90s, later on they pretty much > went away. So I think the perception (truth?) that there was a lot of headroom > (and thus no need for resource reservation, to do applications like voice) > played a really big role in the lack of interest (or so people argued at the > time, in saying IntServ wasn't needed). > > Noel From jnc at mercury.lcs.mit.edu Tue Dec 12 13:11:55 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 11 Dec 2017 22:11:55 -0500 (EST) Subject: [TUHS] MERT? Message-ID: <20171212031155.0B69118C08C@mercury.lcs.mit.edu> > From: Jon Steinhart > Probably the best person to ask is Heinz Lycklama. I checked my email log for my previous MERT enquiries, and that's the exact same advice I got from Brian Kernighan when I asked him (a couple of years back) if he had any suggestions for tracking it down. I guess I need to finally get a 'round tuit'... unless there's someone else here who knows him well, and wants to give it a go. Noel From jnc at mercury.lcs.mit.edu Tue Dec 12 23:59:14 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 12 Dec 2017 08:59:14 -0500 (EST) Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] Message-ID: <20171212135914.EE38218C087@mercury.lcs.mit.edu> > From: George Michaelson > I didn't mean to disrespect the people who did the models or the > protocol or standards work btw. Oh, I personally have no problem with you saying hard things about this work, as long as it's what you really think. One never finds the truth unless one is willing to look hard, neh? And I'm pretty sure Dave Clark (who was a leading light in IntServ) would be OK with you doing so too (I worked very closely with him for years, to the point where I deputized for him at meetings). I honestly don't remember exactly what my take was on IntServ and RSVP; I'd have to go look. I recollect seeing the case that _if resources were limited_, certain classes of application (I guess we called them 'inelastic') would need reservations to work properly. So I was probably susceptible to the argument that 'if we've got bandwidth to light our with, we don't need resource reservation'. And I remember being not _thrilled_ with RSVP, but I don't recall exactly why. But, as, you said, wrong list. Maybe internet-history: http://mailman.postel.org/mailman/listinfo/internet-history if you did want to delve into it. Noel From clemc at ccc.com Wed Dec 13 00:18:15 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 12 Dec 2017 09:18:15 -0500 Subject: [TUHS] The French SOL Project Message-ID: In the early 1980s, a bunch of French researchers set out to build a clone of UNIX/V7 in Pascal (using a ukernel IIRC). The project was the SOL project [Gien, 1983]. I believe it eventually begat the Chorus system (which was C++); which UI was going to use for System V/R5 before it all blew up. 1) Does anyone know what happen to SOL? Was it finished, deployed, used for anything? 2.) Did the sources and doc survive (and who owns the IP)? I think those should be in the TUHS archives, as I think this was the first attempt at a rewrite of UNIX in something other than C (or assembler). 3.) On a similar thought, did the Chorus code survive and who owns the IP? Clem [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX Association, 1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada, July, 1983, Pages 75-78 -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Dec 13 00:40:31 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 12 Dec 2017 09:40:31 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives Message-ID: My question about SOL got me thinking a bit. It would be nice to have section in TUHS of any early clones that could be collected. The two that I can think of that probably should be there are (other feel free to point ones that we should try to find): 1.) Idris, which was fairly true to V6 (enough that the one time I test it, things from pretty much just worked). It was notable from being first. Although the C compiler and the 'anat' (the assembler) were a tad different. It the system that got Bill Plauger in trouble @ USENIX @ UDEL when he was booed for a 'marketing' talk. 2.) CRDS (pronounced Cruds by those of use that use it at the time) - Charles River Data Systems. It was a UNIX-like system, although I do not think really attempted to hold to a V7 API much more than intent. Although if my memory serves me, one of the unique features was the use of Reed & Kanodia synchronization in its kernel [REED79], which I was a always a fan. The system was slow as sin bit it ran on a 68000. [CRUDS system, a Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used to bootstrap]. Clem [REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and Sequencers" -------------- next part -------------- An HTML attachment was scrubbed... URL: From catwell at catwell.info Wed Dec 13 00:52:30 2017 From: catwell at catwell.info (Pierre Chapuis) Date: Tue, 12 Dec 2017 15:52:30 +0100 Subject: [TUHS] The French SOL Project In-Reply-To: References: Message-ID: <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com> SOL was a spin-off research project from a more famous French research project called Cyclades, the first datagram network [1]. Knowing that I would guess that the IP may be owned by INRIA. Chorus Systems was a startup which was acquired by Sun in 1997, and the IP belongs to Oracle. However version 5.0 was open sourced by Sun and forked under the name Jaluna, apparently the sources can still be found at SourceForge [2]. I couldn't find any sources for SOL, and I don't think it has ever been completed. [1] https://en.wikipedia.org/wiki/CYCLADES [2] https://sourceforge.net/projects/jaluna/files/Developer%20Edition/1.0/ -- Pierre Chapuis On Tue, Dec 12, 2017, at 15:18, Clem Cole wrote: > In the early 1980s, a bunch of French researchers set out to build a > clone of UNIX/V7 in Pascal (using a ukernel IIRC). The project was > the SOL project [Gien, 1983]. I believe it eventually begat the > Chorus system (which was C++); which UI was going to use for System > V/R5 before it all blew up.> > 1) Does anyone know what happen to SOL? Was it finished, deployed, > used for anything?> > 2.) Did the sources and doc survive (and who owns the IP)? I think > those should be in the TUHS archives, as I think this was the first > attempt at a rewrite of UNIX in something other than C (or > assembler).> > 3.) On a similar thought, did the Chorus code survive and who owns > the IP?> > > Clem > > > > > > [Gien, 1983]*“The SOL Operating System*”, Michel Gien, USENIX > Association, 1983, Proceedings of the Summer ’83 USENIX Conference, > Toronto, On, Canada, July, 1983, Pages 75-78> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 13 01:16:53 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 12 Dec 2017 10:16:53 -0500 (EST) Subject: [TUHS] Early Clones / Rewrites for TUHS archives Message-ID: <20171212151653.1922118C087@mercury.lcs.mit.edu> > From: Clem Cole > It would be nice to have section in TUHS of any early clones that could > be collected. The Unix Tree does have a section for "Unix Clones", and it has Coherent, Xinu, Minix and some early Linuxes. Another one that's missing (although in a different category) is Ultrix-32.> Noel From imp at bsdimp.com Wed Dec 13 02:01:37 2017 From: imp at bsdimp.com (Warner Losh) Date: Tue, 12 Dec 2017 09:01:37 -0700 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171212151653.1922118C087@mercury.lcs.mit.edu> References: <20171212151653.1922118C087@mercury.lcs.mit.edu> Message-ID: On Dec 12, 2017 7:17 AM, "Noel Chiappa" wrote: > From: Clem Cole > It would be nice to have section in TUHS of any early clones that could > be collected. The Unix Tree does have a section for "Unix Clones", and it has Coherent, Xinu, Minix and some early Linuxes. Another one that's missing (although in a different category) is Ultrix-32.> Ultrix-11 is there though. It's interesting to see how it evolved from v7m which evolved from v7. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Wed Dec 13 02:04:42 2017 From: random832 at fastmail.com (Random832) Date: Tue, 12 Dec 2017 11:04:42 -0500 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> Message-ID: <1513094682.1327351.1202579448.2AE94EE8@webmail.messagingengine.com> On Mon, Dec 11, 2017, at 14:23, Noel Chiappa wrote: > If all people wanted was a rule saying 'ISPs can't give third parties > _worse_ service, or - more importantly - deny service altogether, > unless those parties pay up' (i.e. what would amount to targeted > extortion), I'd be _all for_ a rule like that. > > But the 'net neutrality' aficionados (most of whom, I'm fairly sure, > are not aware of/thinking about these details) are all signing up for > a much more expansive rule, one that says 'no ISP can offer anyone > _better_ service for paying more money' - which is quite different. My > problems with this latter form are two-fold. The rule that I want is that I am the customer. If Comcast wants to give better service to my neighbor who is paying more, that's fine, but that's not remotely the same thing as making it harder for me to connect to Netflix than to their own streaming service because Netflix didn't pay up. They're essentially taking money from me twice - once from actually charging me for internet service, and once from the portion of my Netflix (etc) subscription that goes to paying their extortion fees (because let's not pretend that "fast lanes" won't go hand-in-hand with degradation of the standard service). If they want more money from me they should have to raise the actual price they bill me with instead of being sneaky about it. From random832 at fastmail.com Wed Dec 13 02:29:38 2017 From: random832 at fastmail.com (Random832) Date: Tue, 12 Dec 2017 11:29:38 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: Message-ID: <1513096178.1334371.1202613584.6544B615@webmail.messagingengine.com> On Tue, Dec 12, 2017, at 09:40, Clem Cole wrote: > My question about SOL got me thinking a bit. It would be nice to have > section in TUHS of any early clones that could be collected. The two > that I can think of that probably should be there are (other feel free > to point ones that we should try to find): A while ago I ran across a manual for "Cromix" - which looks like it wasn't really unix-compatible as such, but clearly a 'clone' of it in a looser sense, and ran on a Z80 machine. "Micronix" seems to have also run on Z80 machines, and to have been a much closer imitation of V6 unix. http://www.autometer.de/unix4fun/z80pack/ftp/cromemco/Cromemco%20Cromix%20Instruction%20Manual%20023-4022%20198212.pdf http://bitsavers.trailing-edge.com/pdf/morrow/decision/Micronix_Operating_System_1.61_Jun83.pdf From random832 at fastmail.com Wed Dec 13 02:41:54 2017 From: random832 at fastmail.com (Random832) Date: Tue, 12 Dec 2017 11:41:54 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <1513096178.1334371.1202613584.6544B615@webmail.messagingengine.com> References: <1513096178.1334371.1202613584.6544B615@webmail.messagingengine.com> Message-ID: <1513096914.1337959.1202632488.432CB09C@webmail.messagingengine.com> On Tue, Dec 12, 2017, at 11:29, Random832 wrote: > On Tue, Dec 12, 2017, at 09:40, Clem Cole wrote: > > My question about SOL got me thinking a bit. It would be nice to have > > section in TUHS of any early clones that could be collected. The two > > that I can think of that probably should be there are (other feel free > > to point ones that we should try to find): > > A while ago I ran across a manual for "Cromix" I should have realized this was from it being posted here in April. http://minnie.tuhs.org/pipermail/tuhs/2017-April/009685.html From jon at fourwinds.com Wed Dec 13 02:52:06 2017 From: jon at fourwinds.com (Jon Steinhart) Date: Tue, 12 Dec 2017 08:52:06 -0800 Subject: [TUHS] [ really net neutrality - don't you folks believe in subject lines? ] In-Reply-To: <1513094682.1327351.1202579448.2AE94EE8@webmail.messagingengine.com> References: <20171211192328.AA20B18C08C@mercury.lcs.mit.edu> <1513094682.1327351.1202579448.2AE94EE8@webmail.messagingengine.com> Message-ID: <201712121652.vBCGq6GB023315@darkstar.fourwinds.com> Random832 writes: > The rule that I want is that I am the customer. If Comcast wants to give > better service to my neighbor who is paying more, that's fine, but > that's not remotely the same thing as making it harder for me to connect > to Netflix than to their own streaming service because Netflix didn't > pay up. They're essentially taking money from me twice - once from > actually charging me for internet service, and once from the portion of > my Netflix (etc) subscription that goes to paying their extortion fees > (because let's not pretend that "fast lanes" won't go hand-in-hand with > degradation of the standard service). If they want more money from me > they should have to raise the actual price they bill me with instead of > being sneaky about it. To me this all comes down to the network stack model. At the low level I'd like to be paying X dollars for Y bits per second. There shouldn't be any restrictions on what I can do with those bits. Netflix et. al. should be doing the same. Of course, they buy a lot more bits/second. There's a big difference between the internet and the old phone system which comes down to "peering agreements". In the phone system, if an AT&T customer called a GTE customer a connection would be made for that call. If an AT&T customer in an isolated district called another AT&T customer it was AT&T's problem to route the call; it didn't go through GTE's network. Quick diversion here for a good story. The town in which I went to college was exactly one of these districts; we were New York Telephone but separated from the rest of that network by a GTE district. Dialing 1 in the pre-computer days said "hit the microwave tower 'cause it's long distance". We found a local number that had a 300-3300 Hz sweep test tone. We could dial 1 which would send the call out over the microwave, then dial the local number. There was no checking to see that it could just be connected as a local call. So the sweep tone would start at 300 Hz and continue until it hit 2600 Hz at which point the it would disconnect and leave the originator with an unallocated trunk circuit just waiting for MF tones. The great thing about it was they NYT was looking for the 2600 Hz tone coming from our end but it was coming from theirs. They eventually caught on and installed a notch filter. Anyway, there is a real issue with the internet is that traffic can go anywhere. Netflix can be on provider A, I can be on provider A in some other part of the world, and the traffic might get routed through provider B who doesn't have anybody paying for either end of the connection. If I were a provider B customer then I'd at least be paying them something for those bits. Topology means that some providers route more traffic for non-customers than customers. It would be as if NYT sent all of its long distance calls via GTE to another NYT customer; GTE wouldn't get paid for the service. It would seem that this might be addressed by having monthly traffic settlements or something. This is a different issue that end providers screwing their end users. This is more a matter of providers owning too much of the stack. It's why I support providers being common carriers of bits for all content providers. There is a separate political issue here which is control of information. It's obvious that the net is part of a huge propaganda machine now, and that "bad folks" want to keep people from messing with them. This is similar to how ADM and Koch Industries getting seats on the NPR board has eliminated any good reporting that they don't like. Like a lot of things today, sounds like news but isn't. This is a non-technical issue that probably doesn't belong on this list but is very very important. Jon From jnc at mercury.lcs.mit.edu Wed Dec 13 04:01:17 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 12 Dec 2017 13:01:17 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Heh, my V6 machine thinks (via 'date') that today is _Monday_, December 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the date code is probably missing the '400 year' exception. Noel From imp at bsdimp.com Wed Dec 13 04:21:35 2017 From: imp at bsdimp.com (Warner Losh) Date: Tue, 12 Dec 2017 11:21:35 -0700 Subject: [TUHS] Date madness In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Message-ID: The date on my Venix system doesn't grok 20xx at all. I had to hack date.c from v7 to make it work. So at some point you had to hack things in to make 20xx work, no? Warner On Tue, Dec 12, 2017 at 11:01 AM, Noel Chiappa wrote: > Heh, my V6 machine thinks (via 'date') that today is _Monday_, December > 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess the > date code is probably missing the '400 year' exception. > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Dec 13 04:31:11 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 12 Dec 2017 13:31:11 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171212183111.00ECE18C087@mercury.lcs.mit.edu> > From: Warner Losh > So at some point you had to hack things in to make 20xx work, no? I had a number of date issues with V6; more here: http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#Issues That one was the easiest to fix! (Although this one will probably also be pretty easy, too.) Noel From rudi.j.blom at gmail.com Wed Dec 13 11:52:14 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Wed, 13 Dec 2017 08:52:14 +0700 Subject: [TUHS] Early Clones Message-ID: actually not an early clone but a late(r), Philips MPX (Multi-processor UNIX) based on SystemV running on Moterola CPUs. Mostly sold in the (Retail) Banking Industry as branch server. The "M" was more related to having various boards running their own UNIX. That would be an Ethernet board and one Networking board for SDLC and X.25. These boards run their own copy of unix to 'offload' the main CPU. I've worked with this UNIX but more a system tester, interface to National Sales Organisations. No idea where the source is, but guess it would be IP of Philips (or DEC, or Compaq, or HP, or HPE) if anyone still remembers that is. For a (very) short while there was also an Intel CPU based version, but dropped in favour of SCO UNIX when DEC bought Philips Computer division. A very little bit in this 1987 article. https://www.cbronline.com/news/better_late_philips_enters_the_uk_unix_market/ Cheers, uncle rubl From cym224 at gmail.com Wed Dec 13 12:11:38 2017 From: cym224 at gmail.com (Nemo) Date: Tue, 12 Dec 2017 21:11:38 -0500 Subject: [TUHS] The French SOL Project In-Reply-To: <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com> References: <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com> Message-ID: On 12 December 2017 at 09:52, Pierre Chapuis wrote: > SOL was a spin-off research project from a more famous French research > project called Cyclades, the first datagram network [1]. Knowing that I > would guess that the IP may be owned by INRIA. I was curious to see if Cyclades wound up in any of hte INRIA repos. No luck but I did find this curious repository: https://www.softwareheritage.org/ that may one day have it. N. > > Chorus Systems was a startup which was acquired by Sun in 1997, and the IP > belongs to Oracle. However version 5.0 was open sourced by Sun and forked > under the name Jaluna, apparently the sources can still be found at > SourceForge [2]. > > I couldn't find any sources for SOL, and I don't think it has ever been > completed. > > [1] https://en.wikipedia.org/wiki/CYCLADES > [2] https://sourceforge.net/projects/jaluna/files/Developer%20Edition/1.0/ > > -- > Pierre Chapuis > > > On Tue, Dec 12, 2017, at 15:18, Clem Cole wrote: > > In the early 1980s, a bunch of French researchers set out to build a clone > of UNIX/V7 in Pascal (using a ukernel IIRC). The project was the SOL > project [Gien, 1983]. I believe it eventually begat the Chorus system > (which was C++); which UI was going to use for System V/R5 before it all > blew up. > > 1) Does anyone know what happen to SOL? Was it finished, deployed, used > for anything? > > 2.) Did the sources and doc survive (and who owns the IP)? I think those > should be in the TUHS archives, as I think this was the first attempt at a > rewrite of UNIX in something other than C (or assembler). > > 3.) On a similar thought, did the Chorus code survive and who owns the IP? > > > Clem > > > > > > [Gien, 1983]“The SOL Operating System”, Michel Gien, USENIX Association, > 1983, Proceedings of the Summer ’83 USENIX Conference, Toronto, On, Canada, > July, 1983, Pages 75-78 > > > From lyndon at orthanc.ca Wed Dec 13 12:14:48 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Tue, 12 Dec 2017 18:14:48 -0800 Subject: [TUHS] The French SOL Project In-Reply-To: References: <1513090350.694168.1202482048.331BA9BB@webmail.messagingengine.com> Message-ID: <32A878D9-09BA-4421-8503-3D989785B9ED@orthanc.ca> > On Dec 12, 2017, at 6:11 PM, Nemo wrote: > > I was curious to see if Cyclades wound up in any of hte INRIA repos. > No luck but I did find this curious repository: > https://www.softwareheritage.org/ that may one day have it. Such a pity a site promoting Olde Software needs eight CPU cores and a 2GB memory footprint browser to render its home page :-P From nw at retrocomputingtasmania.com Wed Dec 13 12:15:33 2017 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Wed, 13 Dec 2017 13:15:33 +1100 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171212151653.1922118C087@mercury.lcs.mit.edu> References: <20171212151653.1922118C087@mercury.lcs.mit.edu> Message-ID: On Wed, Dec 13, 2017 at 2:16 AM, Noel Chiappa wrote: > The Unix Tree does have a section for "Unix Clones", and it has Coherent, > Xinu, Minix and some early Linuxes. https://upload.wikimedia.org/wikipedia/commons/5/50/Unix_history-simple.png Another Unix clone to find: http://i.imgur.com/dlGTh.png Yourdon UNIX known as OMNIX for the Zilog Z-80 - compatible with CP/M - ran on Industrial Microsystems and Cromemco CS-3 - had its own shell? - multi-user and multi-process I remain surprised/impressed that so many people from that era simply decided to write their own Unix clone, no small undertaking at the time. From jsteve at superglobalmegacorp.com Wed Dec 13 14:16:25 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 13 Dec 2017 12:16:25 +0800 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: Message-ID: <2b92d6c7-d67c-4029-a25e-b344f8c0afb9@HK2APC01FT050.eop-APC01.prod.protection.outlook.com> And then in the early 90’s (91 or 92) we had ixemul on the Amiga, and EMX on MS-DOS and OS/2. Although I guess that is too new? Sent from Mail for Windows 10 From: Clem Cole Sent: Tuesday, 12 December 2017 10:41 PM To: The Eunuchs Hysterical Society Subject: [TUHS] Early Clones / Rewrites for TUHS archives My question about SOL got me thinking a bit.  It would be nice to have section in TUHS of any early clones that could be collected.   The two that I can think of that probably should be there are (other feel free to point ones that we should try to find): 1.) Idris, which was fairly true to V6 (enough that the one time I test it, things from pretty much just worked).  It was notable from being first.  Although the C compiler and the 'anat' (the assembler) were a tad different.  It the system that got Bill Plauger in trouble @ USENIX @ UDEL when he was booed for a 'marketing' talk. 2.) CRDS (pronounced Cruds by those of use that use it at the time) - Charles River Data Systems.   It was a UNIX-like system, although I do not think really attempted to hold to a V7 API much more than intent.  Although if my memory serves me, one of the unique features was the use of Reed & Kanodia synchronization in its kernel [REED79], which I was a always a fan.   The system was slow as sin bit it ran on a 68000.  [CRUDS system, a Fortune box and our Vax/750 running BSD4.1 were the systems Masscomp used to bootstrap]. Clem [REED79] D.P. Reed and R.K. Kanodia, "Synchronization with Eventcounts and Sequencers" -------------- next part -------------- An HTML attachment was scrubbed... URL: From mj at mjturner.net Wed Dec 13 21:32:47 2017 From: mj at mjturner.net (Michael-John Turner) Date: Wed, 13 Dec 2017 11:32:47 +0000 Subject: [TUHS] Other history lists... In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> Message-ID: <20171213113247.rckdsh2pfzzqotqj@saucer.turnde.net> On Sun, Dec 10, 2017 at 11:13:42PM -0700, Grant Taylor via TUHS wrote: >Does anyone know of any other similar history discussion mailing lists >/ newsgroups to discuss things like Mainframes or (Open)VMS? Two I quite like are the Geeks and Rescue lists: http://www.sunhelp.org/mailman/listinfo/rescue http://www.sunhelp.org/mailman/listinfo/geeks Some folks there have mainframes, Crays, etc. There's also Info-VAX, the comp.os.vms to email gateway: http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com Cheers, MJ -- Michael-John Turner * mj at mjturner.net * http://mjturner.net/ From clemc at ccc.com Wed Dec 13 23:46:41 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 13 Dec 2017 08:46:41 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171212151653.1922118C087@mercury.lcs.mit.edu> Message-ID: On Tue, Dec 12, 2017 at 9:15 PM, Nigel Williams < nw at retrocomputingtasmania.com> wrote: > > I remain surprised/impressed that so many people from that era simply > decided to write their own Unix clone, no small undertaking at the > ​ ​ > time. > ​+1 I remember Leor bringing BDS C and his Unix emulation for CP/M to a Boston USENIX and showing it to a number of us in his hotel room. At the time we were all always worried about what IP was 'open' and what was not (remember this is before Judge Green, much less the AT&T/BSDi case). Dennis' comment at the time was it reminded him of early UNIX in look and feel from the 11/20 days. Which considering the Z80 was a 64K address space is not surprising. IIRC: Leor's system had a bank switched memory scheme so he could get more physical memory in it was a trick that was in vogue for the S-100 bus systems. But it was an 8" floppy based machine. I looked at it longingly because I could not afford to own an S-100 based system of my own! A year or two later, Onyx brought their Z8000 based system to the UDel USENIX and wowed us again. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Thu Dec 14 01:07:56 2017 From: random832 at fastmail.com (Random832) Date: Wed, 13 Dec 2017 10:07:56 -0500 Subject: [TUHS] Date madness In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Message-ID: <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com> Seeing this thread (and in particular the "no long" versions of the date code) got me thinking, how could the 2038 problem be solved for classic unix? Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get to Y10K and is coincidentally as far as my ad-hoc implementation of dividing by 86400 got) structure? How to encode times within 32-bit fields on filesystems and such? Is it even worth it to do a fully general implementation rather than simply treating it as unsigned, delaying the problem until 2106? And, for that matter, would a full implementation of modern time zone data code (2.11BSD has one from a while back, though only supporting 32-bit times) be too large for smaller 16-bit unix systems? On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote: > Heh, my V6 machine thinks (via 'date') that today is _Monday_, December > 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess > the > date code is probably missing the '400 year' exception. > > Noel From helbig at mailbox.org Thu Dec 14 01:39:24 2017 From: helbig at mailbox.org (Wolfgang Helbig) Date: Wed, 13 Dec 2017 16:39:24 +0100 Subject: [TUHS] Date madness In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Message-ID: Hi, years ago I fixed some overflow bugs in v6. The file ctime.README reads: This tape (see enb.README) fixes some y2k and integer overflow issues in V6. ctime.c: Use Central European Timezone ctime(): Don't blindly assume "19" to be the first two digits of the year. gmtime(): The division of the current time by 8 hours overflows nowadays. Instead divide by 24 hours, and use a routine which computes the quotient and remainder with unsigned double word arithmetic. (ludiv()) If you want to understand ludiv and know modern program notations have a look at ludiv.README. date.c: Interpret the user entered year "00" as "2000", not as "1900”. The fixes are distributed on v6-tar tapes enblocked for simh (*.enb) I think, the enb-directory is archived at tuhs. If not, let me know. Here is the enb.README: The contents of this directory are .README and .enb files with the following basenames: ctime: Some y2k related changes to V6. dcheck: Bug fix and enhancement of dcheck. dist: The V6 distribution tape: dist.README explains how to install and setup V6 in the Supnik simulator. The file dist.enb is missing for copyright and space reasons, you have to prepare it yourself. (see enb.README). dotdot: Kernel enhancement: If in a root directoy of a mounted filesystem, let ".." mean the parent of the mount point, not the root directory. enb: Conventions and usage of .enb files. Contains C-source of a program which prepares tape files for the Supnik simulator and tells you how to get the V6 distribution tape. ludiv: Derivation of a double word unsigned division algorithm, which is used in ctime. (no corresponding .enb) man: The man command, which was missing from the distribution, and some changes do make nroff output readable on an xterm. Have fun, Wolfgang Helbig Stauferstr. 22 71334 Waiblingen From jnc at mercury.lcs.mit.edu Thu Dec 14 01:56:55 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Dec 2017 10:56:55 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171213155655.1869618C095@mercury.lcs.mit.edu> > Guess the date code is probably missing the '400 year' exception. So, I looked at the code, and the bug is not obvious. (The routine for detecting leap years in V6's ctime.c is so minimalistic it actually works for 2000!) The version I'm currently running had been worked on some, to have a hack fix for the overflow of the number of 8-hour periods since the epoch ("hack" since the 'fixed' version will break in 2029 or so), and I was worried that 'fix' was wrong and caused the week-day problem, but I don't think so. Noel From jnc at mercury.lcs.mit.edu Thu Dec 14 02:08:24 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Dec 2017 11:08:24 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171213160824.36BE518C094@mercury.lcs.mit.edu> > So, I looked at the code, and the bug is not obvious. Because there _was_ no bug!!! :-) It was saying December 12 was a Monday because the _year_ was still set to _2016_, and in 2016, December 12 _was_ a Monday! {Smacks forehead!} Noel From arnold at skeeve.com Thu Dec 14 02:23:43 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 13 Dec 2017 09:23:43 -0700 Subject: [TUHS] Date madness In-Reply-To: <20171213160824.36BE518C094@mercury.lcs.mit.edu> References: <20171213160824.36BE518C094@mercury.lcs.mit.edu> Message-ID: <201712131623.vBDGNhId009495@freefriends.org> jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > So, I looked at the code, and the bug is not obvious. > > Because there _was_ no bug!!! :-) > > It was saying December 12 was a Monday because the _year_ was still set to > _2016_, and in 2016, December 12 _was_ a Monday! > > {Smacks forehead!} > > Noel So how did you manage to lose a whole year? Time travel? :-) From jnc at mercury.lcs.mit.edu Thu Dec 14 02:31:41 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Dec 2017 11:31:41 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171213163141.946F718C094@mercury.lcs.mit.edu> > From: Arnold > So how did you manage to lose a whole year? Time travel? :-) No, I just haven't booted the V6 often in the last year, and when I did, I never bothered to reset the time; so it was still on Nov, 2016. Noel From arnold at skeeve.com Thu Dec 14 02:50:49 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 13 Dec 2017 09:50:49 -0700 Subject: [TUHS] Date madness In-Reply-To: <20171213163141.946F718C094@mercury.lcs.mit.edu> References: <20171213163141.946F718C094@mercury.lcs.mit.edu> Message-ID: <201712131650.vBDGonVx012500@freefriends.org> jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Arnold > > > So how did you manage to lose a whole year? Time travel? :-) > > No, I just haven't booted the V6 often in the last year, and when I did, I > never bothered to reset the time; so it was still on Nov, 2016. > > Noel One would think that SIMH would pass the current real time of day into the simulated computer's time of day clock. Or is it like a real cold boot where the power was off, no battery on the clock, etc.? Just wondering. Thanks, Arnold From lm at mcvoy.com Thu Dec 14 02:58:14 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 13 Dec 2017 08:58:14 -0800 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171212151653.1922118C087@mercury.lcs.mit.edu> Message-ID: <20171213165814.GJ26887@mcvoy.com> On Wed, Dec 13, 2017 at 08:46:41AM -0500, Clem Cole wrote: > I remember Leor bringing BDS C and > his Unix emulation for CP/M to a Boston USENIX I wrote a lot of code in BDS C, remember it fondly (even though it's stdio was non-stdio :) I never heard about any Unix emulation from him, do you mean the libraries or something else. I ask because I wrote a bunch of tiny CP/M programms, in assembler because I was using every trick I could to make them small. I believe the ones I had on every floppy were: ls cp mv rm and each one of those I made fit in either one or two 512 byte sectors because they weren't memory resident, it had to spin up the floppy and read them in each time I ran them. So I wanted them small for two reasons: speed of reading them in and not taking up precious space on the floppy. I had a utils floppy that had larger programs on it, like grep, my quicknet terminal emulator/file transfer tool (I wish I had saved the source to that). my CP/M machine was an Okidata with a color(!) monitor and a built in printer with two floppies so I could do work on one floppy and get the utils on the other. Hmm, wonder if there is picture of that machine on the net? Of course there is: http://www.old-computers.com/museum/computer.asp?c=94 So Clem, did Leor do any utilities that I didn't know about or are you talking about his not so standard C library? --lm From jsteve at superglobalmegacorp.com Thu Dec 14 03:00:16 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 14 Dec 2017 01:00:16 +0800 Subject: [TUHS] Date madness In-Reply-To: <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com> Message-ID: Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. I did 4.3BSD a long while back, and the only thing I really changed was the date command so I could enter 4 year dates, otherwise everything seemed to run fine in the year 2040. Sent from Mail for Windows 10 From: Random832 Sent: Wednesday, 13 December 2017 11:08 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Date madness Seeing this thread (and in particular the "no long" versions of the date code) got me thinking, how could the 2038 problem be solved for classic unix? Use double as "time_t", or some 64-bit (48-bit? 39-bit is enough to get to Y10K and is coincidentally as far as my ad-hoc implementation of dividing by 86400 got) structure? How to encode times within 32-bit fields on filesystems and such? Is it even worth it to do a fully general implementation rather than simply treating it as unsigned, delaying the problem until 2106? And, for that matter, would a full implementation of modern time zone data code (2.11BSD has one from a while back, though only supporting 32-bit times) be too large for smaller 16-bit unix systems? On Tue, Dec 12, 2017, at 13:01, Noel Chiappa wrote: > Heh, my V6 machine thinks (via 'date') that today is _Monday_, December > 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess > the > date code is probably missing the '400 year' exception. > > Noel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Dec 14 03:16:25 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Dec 2017 12:16:25 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> > From: Arnold > One would think that SIMH I'm using Ersatz-11... > into the simulated computer's time of day clock. What Time of Day clock? We're talking PDP-11's here! :-) The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure none of their others did. And of course V6 long pre-dated the /93-94. Noel From ron at ronnatalie.com Thu Dec 14 03:18:31 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 13 Dec 2017 12:18:31 -0500 Subject: [TUHS] Date madness In-Reply-To: References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com> Message-ID: <00e601d37436$671baf80$35530e80$@ronnatalie.com> If I recall correctly, the original time system call used a pointer to two (16-bit) ints rather than a long. Time was maintained in the kernel that way as well. There are other systems that ran out of “time” a long time ago. The TOPS-10 software ran out in 1975 or so if I recall. The Apollo domain/os ran out of time as well but I think the whole OS became obsolete before it’s time function. The last release of the OS came out eight years earlier. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Thu Dec 14 03:05:51 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 14 Dec 2017 01:05:51 +0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: References: <20171206010736.GA16514@minnie.tuhs.org> <1512576671.3978479.1196132360.0C9F95D9@webmail.messagingengine.com> <201712061615.vB6GFKYd013874@darkstar.fourwinds.com> <201712061849.vB6InBKS031624@darkstar.fourwinds.com> Message-ID: <537aa993-e428-477b-8c36-5c068b1bf5a1@HK2APC01FT014.eop-APC01.prod.protection.outlook.com> It absolutely was too late. By 1984 IBM had pushed out the AT, and although from there, we had PC stagnation until 1987, in those three years the rise of the IBM PC Clone was so insurmountable that IBM couldn’t push the PS/2 on anyone. IBM had utterly lost momentum and the Compaq Deskpro 386 with Windows/386 had setup the world in which we live in today. It’s crazy how seeming short that window was, and yet a company the size of IBM or AT&T couldn’t compete. Sent from Mail for Windows 10 From: Clem Cole Sent: Tuesday, 12 December 2017 2:41 AM To: Paul Winalski Cc: TUHS main list Subject: Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski wrote: On 12/6/17, Jon Steinhart wrote: > > There's another aspect of this that I think that many people misunderstand > which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew > that in the future the money was in data and were willing to trade their > monopoly for that business.  From their perspective, it worked.  For the > rest of us, not so good. Except that the new AT&T, liberated from the regulatory chains of the Bell operating companies, never learned how to compete in the free market.  They got their clock cleaned by the competition.  In desperation they bought Olivetti and only managed to run it into the ground ​To be fair you are both right.  I think at the time Charlie Brown and Team at AT&T wanted to make a go at IBM and DEC (i.e. large systems) and Paul's right, they missed. But Jon is right that they had realized that it going to be a data centric business and he and his team felt that the current consent decree we going to keep them from being players in it.    To me there were a couple of issues.  The Phone System and 'TPC' was centrally controlled (a lot like a communist country).   Where it worked, it was fine.  But... the problem was that anything outside their view of reality was a threat.  It's funny as the time, IBM, DEC et al were trying to build centrally managed (closed garden networks) too, just like the phone system, so it was not a stretch for them the think that way. IP and datagrams were very much built on no central control, which was something TPC thought was bad and fought.   I remember so, so many of those fights at the time and trying to explain that IP was going to win.    In the end, it was MetCalfe's law (which was formulated on observations about the phone system) that caused IP to win, along with "Clark's Observation" making everything a "network of networks" instead if a single managed system - which made the plumbing work. So while I find it sad to see Comcast, Current version of AT&T, Verizon et al, all want to see the net neutrality go away, I do not find it surprising.   Its the same behavior as before. What would have happened if Judge Green had not broken them up?   I do think broadband would be more universal, but .... I suspect AT&T would have fought it and tried to use things that dreamed up (ATM, ISDN, et al). My 2 cents.... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Thu Dec 14 03:09:32 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 14 Dec 2017 01:09:32 +0800 Subject: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] In-Reply-To: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> References: <55ae73ea572ccb9047afc6a973ccbf4a34b5dd19@webmail.yaccman.com> Message-ID: I pay for QOS from Asia to the USA. I’m super bottom tier, but it’s a heck of a lot better than ‘normal let the bits fly’ type service. Some of those VPNs out there have private data centre backhauls which can actually make things smoother. For a while I was looking at doing one through Azure or Amazon but it was far less hassle to just go to my telco and upgrade my internet to business class, and get onto a direct connection to a trans pacific connection to San Francisco vs a shared line that went through Japan. Sent from Mail for Windows 10 From: Steve Johnson Sent: Tuesday, 12 December 2017 8:28 AM To: Clem Cole; Paul Winalski Cc: TUHS main list Subject: Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] I don't dispute anything you said, but I think there is another element.  It was simply an element of faith that to send voice you needed to have a guaranteed rate of speed.  Thus the interest in time-division multiplexing.  Deeply built into the Bell System mentality was the notion that you shouldn't offer service unless it is good service.  Thus the dial tone -- if the network was jammed, they didn't let you make a call.  But the ones that got through ran with no problems... Recently I've been attempting to Skype on a group call with 5 people in Europe.  I would LOVE to have a guaranteed bandwidth for my call.  For "ordinary", non-time critical things, I'd be happy to fight for bits on an equal footing with everybody else.  Maybe the best solution is two networks... Steve ----- Original Message ----- From: "Clem Cole" To: "Paul Winalski" Cc: "TUHS main list" Sent: Mon, 11 Dec 2017 13:39:44 -0500 Subject: Re: [TUHS] V7 Addendem [ really lawyers and AT&T consent decree ] On Mon, Dec 11, 2017 at 1:17 PM, Paul Winalski wrote: On 12/6/17, Jon Steinhart wrote: > > There's another aspect of this that I think that many people misunderstand > which is that Judge Green gave AT&T exactly what they wanted.  AT&T knew > that in the future the money was in data and were willing to trade their > monopoly for that business.  From their perspective, it worked.  For the > rest of us, not so good. Except that the new AT&T, liberated from the regulatory chains of the Bell operating companies, never learned how to compete in the free market.  They got their clock cleaned by the competition.  In desperation they bought Olivetti and only managed to run it into the ground ​To be fair you are both right.  I think at the time Charlie Brown and Team at AT&T wanted to make a go at IBM and DEC (i.e. large systems) and Paul's right, they missed. But Jon is right that they had realized that it going to be a data centric business and he and his team felt that the current consent decree we going to keep them from being players in it.    To me there were a couple of issues.  The Phone System and 'TPC' was centrally controlled (a lot like a communist country).   Where it worked, it was fine.  But... the problem was that anything outside their view of reality was a threat.  It's funny as the time, IBM, DEC et al were trying to build centrally managed (closed garden networks) too, just like the phone system, so it was not a stretch for them the think that way. IP and datagrams were very much built on no central control, which was something TPC thought was bad and fought.   I remember so, so many of those fights at the time and trying to explain that IP was going to win.    In the end, it was MetCalfe's law (which was formulated on observations about the phone system) that caused IP to win, along with "Clark's Observation" making everything a "network of networks" instead if a single managed system - which made the plumbing work. So while I find it sad to see Comcast, Current version of AT&T, Verizon et al, all want to see the net neutrality go away, I do not find it surprising.   Its the same behavior as before. What would have happened if Judge Green had not broken them up?   I do think broadband would be more universal, but .... I suspect AT&T would have fought it and tried to use things that dreamed up (ATM, ISDN, et al). My 2 cents.... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Dec 14 04:02:43 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 13 Dec 2017 13:02:43 -0500 Subject: [TUHS] Date madness In-Reply-To: <00e601d37436$671baf80$35530e80$@ronnatalie.com> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <1513177676.2580511.1203714576.15A48921@webmail.messagingengine.com> <00e601d37436$671baf80$35530e80$@ronnatalie.com> Message-ID: <9ac6727e-17cc-3d8e-b175-c94d83d0c1d6@kilonet.net> On 12/13/2017 12:18 PM, Ron Natalie wrote: > The TOPS-10 software ran out in 1975 or so if I recall. Nope, I can boot a 7.03 monitor and it understands Y2K and higher. I had to edit SYSTAT.MAC to make it print the currect year after 2000, but everything else just worked. I believe a 6.03A monitor also behaves correctly. Although, I believe the year is coming soon when it will implode and wrap back around. I don't recall the specifics of that. ../simh/simhv28/pdp10 ks10.cfg.gold PDP-10 simulator V2.8-4 Listening on socket 6 Modem control activated sim> boot rp0 BOOT V3(47) BOOT> [Loading from DSKB:SYSTEM.EXE[1,4]] LIRICS Timesharing Gold 07-08-01 Why reload: PM Date: ** Time: ** Startup option: go ** .SYS Status of LIRICS Timesharing Gold at 12:59:09 on 13-Dec-2017 Uptime 3:17, 99% Null time = 99% Idle + 0% Lost, 0% Overhead 12 Jobs in use out of 128.  12 logged in, 10 detached. * *. Monitor LIRICS Timesharing Gold System uptime :04:08 Current date/time 13-Dec-2017 13:00:00 *<-- This time is spewed by the monitor directly which I did not have to change>* ** -------------- next part -------------- An HTML attachment was scrubbed... URL: From tih at hamartun.priv.no Thu Dec 14 04:53:38 2017 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Wed, 13 Dec 2017 19:53:38 +0100 Subject: [TUHS] Date madness In-Reply-To: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> (Noel Chiappa's message of "Wed, 13 Dec 2017 12:16:25 -0500 (EST)") References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> Message-ID: Noel Chiappa writes: > The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure > none of their others did. And of course V6 long pre-dated the /93-94. My /83s have them, but I'm not so sure it's a feature of the CPU board: there's this thought nagging in the back of my head that the ToY thing actually sits in the front panel module with the various buttons on it. Anyone with more specific knowledge? -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From clemc at ccc.com Thu Dec 14 05:03:45 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 13 Dec 2017 14:03:45 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171213165814.GJ26887@mcvoy.com> References: <20171212151653.1922118C087@mercury.lcs.mit.edu> <20171213165814.GJ26887@mcvoy.com> Message-ID: He had some utilities (that came with the compiler I thought, but I've forgotten that detail to be honest). IIRC, he had a simple shell and the traditional simple file manipulation, although again, IIRC he did not write the associated tools, someone else had. On Wed, Dec 13, 2017 at 11:58 AM, Larry McVoy wrote: > On Wed, Dec 13, 2017 at 08:46:41AM -0500, Clem Cole wrote: > > I remember Leor bringing BDS C resources/bdsc.html>and > > his Unix emulation for CP/M to a Boston USENIX > > I wrote a lot of code in BDS C, remember it fondly (even though it's stdio > was non-stdio :) > > I never heard about any Unix emulation from him, do you mean the libraries > or something else. > > I ask because I wrote a bunch of tiny CP/M programms, in assembler because > I was using every trick I could to make them small. I believe the ones I > had on every floppy were: > > ls > cp > mv > rm > > and each one of those I made fit in either one or two 512 byte sectors > because they weren't memory resident, it had to spin up the floppy and > read them in each time I ran them. So I wanted them small for two > reasons: speed of reading them in and not taking up precious space on > the floppy. > > I had a utils floppy that had larger programs on it, like grep, my quicknet > terminal emulator/file transfer tool (I wish I had saved the source to > that). > > my CP/M machine was an Okidata with a color(!) monitor and a built in > printer with two floppies so I could do work on one floppy and get the > utils on the other. Hmm, wonder if there is picture of that machine > on the net? Of course there is: > > http://www.old-computers.com/museum/computer.asp?c=94 > > So Clem, did Leor do any utilities that I didn't know about or are you > talking about his not so standard C library? > > --lm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Thu Dec 14 05:12:37 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 13 Dec 2017 14:12:37 -0500 Subject: [TUHS] Date madness Message-ID: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU> > Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. Easy, but perhaps unwise. The sign bit is a potential escape hatch for times, just as it is for characters in UTF-8. Doug From michael at kjorling.se Thu Dec 14 05:27:21 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 13 Dec 2017 19:27:21 +0000 Subject: [TUHS] Other history lists... In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> Message-ID: <20171213192721.GC20937@h-174-65.A328.priv.bahnhof.se> On 10 Dec 2017 23:13 -0700, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS): > Does anyone know of any other similar history discussion mailing > lists / newsgroups to discuss things like Mainframes or (Open)VMS? Not a mailing list, but have you considered the Retrocomputing Stack Exchange? https://retrocomputing.stackexchange.com/ Many of the questions there currently relate primarily to personal computers and consoles, but I see no reason why questions about e.g. historical mainframes would not be welcome. -- Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From lars at nocrew.org Thu Dec 14 05:44:06 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 13 Dec 2017 19:44:06 +0000 Subject: [TUHS] Other history lists... In-Reply-To: <20171213192721.GC20937@h-174-65.A328.priv.bahnhof.se> ("Michael \=\?utf-8\?Q\?Kj\=C3\=B6rling\=22's\?\= message of "Wed, 13 Dec 2017 19:27:21 +0000") References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> <20171213192721.GC20937@h-174-65.A328.priv.bahnhof.se> Message-ID: <7windamn09.fsf@junk.nocrew.org> Michael Kjörling wrote: > https://retrocomputing.stackexchange.com/ > > Many of the questions there currently relate primarily to personal > computers and consoles, but I see no reason why questions about e.g. > historical mainframes would not be welcome. I brought that up during the proposal stage, and I gather the response was positive: https://area51.meta.stackexchange.com/questions/22734/what-about-biggish-iron Now there seems to be a handful of questions about minis and mainframes. And, on topic!, Unix. From gtaylor at tnetconsulting.net Thu Dec 14 05:45:14 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 13 Dec 2017 12:45:14 -0700 Subject: [TUHS] Other history lists... In-Reply-To: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> References: <348d0cdf-a63f-6ba7-93a0-e7c835dcafe4@spamtrap.tnetconsulting.net> Message-ID: <4833851c-b19d-18af-9f28-1370351743ff@spamtrap.tnetconsulting.net> On 12/10/2017 11:13 PM, Grant Taylor via TUHS wrote: > Does anyone know of any other similar history discussion mailing lists / > newsgroups to discuss things like Mainframes or (Open)VMS? Thank you everyone for all of the intriguing pointers. :-) -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From jnc at mercury.lcs.mit.edu Thu Dec 14 06:22:26 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 13 Dec 2017 15:22:26 -0500 (EST) Subject: [TUHS] Date madness Message-ID: <20171213202226.5214E18C094@mercury.lcs.mit.edu> > From: Tom Ivar Helbekkmo > My /83s have them, but I'm not so sure it's a feature of the CPU board: > there's this thought nagging in the back of my head that the ToY thing > actually sits in the front panel module with the various buttons on it. /83 documentation seems to be very thin on the ground, alas. It's definitely not the CPU; the KDJ11-B CPU (of the /83) manual (EK-KDJ1B-UG-001) makes no mention of it; and in the PDP-11/94E System User and Maintenance Guide (EK-KDJ1E-UG-001), section D.2 "PDP-11/94 and 11/84 Hardware Differences" (the /?3 and /?4 models use the same CPU board, but a different backplane, with QBUS/UNIBUS converter, so this could equally well be titled "PDP-11/93 and 11/83 Hardware Differences") says "Time of Year Clock", indicating the 83/84 don't have one. Several companies made after-market ToD clocks to plug into the QBUS, e.g. here: https://www.ebay.com/itm/371284594072 Is something like that what your /83 has? Noel From arnold at skeeve.com Thu Dec 14 06:46:25 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 13 Dec 2017 13:46:25 -0700 Subject: [TUHS] Date madness In-Reply-To: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> Message-ID: <201712132046.vBDKkPbk002217@freefriends.org> jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > From: Arnold > > > One would think that SIMH > > I'm using Ersatz-11... > > > into the simulated computer's time of day clock. > > What Time of Day clock? We're talking PDP-11's here! :-) > > The very last DEC models of the -11 (/93-94) had a ToY clock; I'm pretty sure > none of their others did. And of course V6 long pre-dated the /93-94. > > Noel ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s for several years and I don't remember having to set the date / time every time I did a reboot. They sat in a data center, so I may have never done a cold boot from power on. It was a LONG time ago now, so there's undoubtedly lots that I just plain don't remember. (There was an old USENET joke about how with the size of transistors going down, pretty soon you'd be able to get an S/370 inside your watch. But of course, as soon as you booted MVS on it, it would ask you to set the time! :-) Arnold From cym224 at gmail.com Thu Dec 14 07:22:03 2017 From: cym224 at gmail.com (Nemo) Date: Wed, 13 Dec 2017 16:22:03 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <2b92d6c7-d67c-4029-a25e-b344f8c0afb9@HK2APC01FT050.eop-APC01.prod.protection.outlook.com> References: <2b92d6c7-d67c-4029-a25e-b344f8c0afb9@HK2APC01FT050.eop-APC01.prod.protection.outlook.com> Message-ID: On 12 December 2017 at 23:16, Jason Stevens wrote: > And then in the early 90’s (91 or 92) we had ixemul on the Amiga, and EMX on > MS-DOS and OS/2. Although I guess that is too new? I would note that Mattes's EMX was a memory extender (and a fantastic one at that). But, on a case-sensitive OS/2, it allowed people to compile a *lot* of Unix code. N. From norman at oclsc.org Thu Dec 14 08:16:40 2017 From: norman at oclsc.org (Norman Wilson) Date: Wed, 13 Dec 2017 17:16:40 -0500 Subject: [TUHS] Date madness Message-ID: <1513203404.29181.for-standards-violators@oclsc.org> Arnold: ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s for several years and I don't remember having to set the date / time every time I did a reboot. They sat in a data center, so I may have never done a cold boot from power on. It was a LONG time ago now, so there's undoubtedly lots that I just plain don't remember. ==== I believe all the VAXes had time-of-year clocks, though the implementation and the method of access varied from model to model. On `Big' VAXes, the clock was considered part of the console front-end, and accessed through the model-specific console scheme. MicroVAXes had no console front-end; I believe the clock was accessed through registers, but it was an off-the-shelf digital-watch chip with some funny format (separate registers for year, month, day, hour, minute, second). So they all had proper battery-backed-up clocks, but of many different types. It wasn't as simple as reading a single counter out of a register, sensible as that might seem. If anyone's really interested I can dig up details for the several models of Big and MicroVAX I dealt with; I still have all the code lying around. Norman Wilson Toronto ON From rmswierczek at gmail.com Thu Dec 14 10:26:54 2017 From: rmswierczek at gmail.com (Robert Swierczek) Date: Wed, 13 Dec 2017 19:26:54 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: Message-ID: A nifty little Unix clone/rewrite is OMU (One Man Unix): http://discordia.org.uk/~steve/omu.html Also Xv6, Fuzix, and UZI: https://pdos.csail.mit.edu/6.828/2012/xv6.html http://www.fuzix.org/ http://www.dougbraun.com/uzi.html From torek at elf.torek.net Thu Dec 14 10:24:35 2017 From: torek at elf.torek.net (Chris Torek) Date: Wed, 13 Dec 2017 16:24:35 -0800 (PST) Subject: [TUHS] Date madness In-Reply-To: <1513203404.29181.for-standards-violators@oclsc.org> Message-ID: <201712140024.vBE0OZQC079168@elf.torek.net> The 780 had only the Time Of Day Register (mfpr $TODR,reg), but it covered more than a year's worth of "time of day": http://h41379.www4.hpe.com/wizard/wiz_1450.html http://rbur004.github.io/MacVAX/VAX-IPR/IPL_CLOCK.html so the standard trick was to assume that the computer had been booted within a year or so, and use the file system time plus the TODR value to compute the correct time. Various MicroVAXen may have added CMOS clock chips, and I vaguely recall dealing wth BCD-encoded time on another VAX, perhaps the 8800. I wrote some clock-chip driver code for the 4BSD SPARC port and tried to consolidate the general issues of dealing with multiple chip registers, two and four digit year encoding, BCD vs decimal, and so on. Chris From dave at horsfall.org Thu Dec 14 10:57:49 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 14 Dec 2017 11:57:49 +1100 (EST) Subject: [TUHS] Date madness In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Message-ID: On Tue, 12 Dec 2017, Noel Chiappa wrote: > Heh, my V6 machine thinks (via 'date') that today is _Monday_, December > 12th. Oddly enough, 'cal 17 2017' on it produces the right thing. Guess > the date code is probably missing the '400 year' exception. I fixed a Y2K bug once, when I found some code that baldly asserted that 2000 was *not* a leap year (and written by my then boss, no less). Oh, I was also on duty around 0700 on 1/1/2000, just in case; yeah, there were a couple of minor glitches, such as printing cheques for the year 19100... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From random832 at fastmail.com Thu Dec 14 13:07:35 2017 From: random832 at fastmail.com (Random832) Date: Wed, 13 Dec 2017 22:07:35 -0500 Subject: [TUHS] Date madness In-Reply-To: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU> References: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU> Message-ID: <1513220855.2223106.1204498584.3CB1C63A@webmail.messagingengine.com> On Wed, Dec 13, 2017, at 14:12, Doug McIlroy wrote: > > Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. > > Easy, but perhaps unwise. The sign bit is a potential escape hatch for > times, just as it is for characters in UTF-8. > > Doug I'm not sure what you're suggesting - UTF-8 works because it's a variable length encoding - a variable length timestamp might be interesting as an academic exercise, but there's no way for time() to specify how much space is needed, or be informed of how much space is allocated Anyway, making it use an "unsigned" 32-bit value is a bit less trivial on V7 (where AIUI there's an unsigned type and a long type, but not both), but the following works - not tested on actual V7 yet, but works with the values as int16_t/int32_t on a modern system /* * break initial number into days */ hms = *tim % 86400; day = *tim / 86400; if(*tim < 0) { hms += 109696; day += 49709 + hms / 86400; hms %= 86400; } 47909 days + 109696 seconds = 2^32 seconds. The "extra day" is to ensure hms is positive. This is instead of the existing hms < 0 clause Making V6 do it (no long *or* unsigned type) is a bit more involved, but I'm close to something viable. Incidentally, one gotcha I've run into is that the code as-is passes the year minus 1900 to dysize, whereas modern dysize implementations that respect the 100 and 400 year rules require the full year. My current attempt to extend it to more bits without resorting to floating point relies on the fact that 86400=675*128 to eke out an extra seven bits without implementing a general purpose division algorithm, which gets it as far as the year ~10680 (~19391 unsigned). Though without a long for the day count, V6 can only get to 2149. From dave at horsfall.org Thu Dec 14 13:08:04 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 14 Dec 2017 14:08:04 +1100 (EST) Subject: [TUHS] Date madness In-Reply-To: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> Message-ID: On Wed, 13 Dec 2017, Noel Chiappa wrote: > > into the simulated computer's time of day clock. > > What Time of Day clock? We're talking PDP-11's here! :-) On V6 at least, the time was set from the mod time (?) in inode #1, as I vaguely recall, so it was "pretty close". My memory is *really* dim here... Or was that one of the zillions of custom mods at the time?. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Thu Dec 14 13:13:17 2017 From: imp at bsdimp.com (Warner Losh) Date: Wed, 13 Dec 2017 19:13:17 -0800 Subject: [TUHS] Date madness In-Reply-To: References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> Message-ID: On Wed, Dec 13, 2017 at 7:08 PM, Dave Horsfall wrote: > On Wed, 13 Dec 2017, Noel Chiappa wrote: > > > into the simulated computer's time of day clock. >> >> What Time of Day clock? We're talking PDP-11's here! :-) >> > > On V6 at least, the time was set from the mod time (?) in inode #1, as I > vaguely recall, so it was "pretty close". My memory is *really* dim > here... Or was that one of the zillions of custom mods at the time?. BSD falls back to this method if no TOD source is registered to get a time to set. Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ches at cheswick.com Fri Dec 15 00:09:31 2017 From: ches at cheswick.com (William Cheswick) Date: Thu, 14 Dec 2017 09:09:31 -0500 Subject: [TUHS] Date madness In-Reply-To: References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Message-ID: <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> During my first few years in the Unix room (starting in 1988) there was what seemed like a semiannual flurry of leap year corrections made to research unix. Apparently, there was some aspect that kept misbehaving, with new bugs appearing at the next shift in time. I never bothered to investigate the specifics, but it happened over several years. There are probably some on this list who know more details. I don’t recall this being a problem on Plan 9. ches From gtaylor at tnetconsulting.net Fri Dec 15 09:00:32 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Thu, 14 Dec 2017 16:00:32 -0700 Subject: [TUHS] Difference in purpose of /var/spool vs /var/lib Message-ID: <81c54c6f-2efb-48e7-c5ee-afd1297323ff@spamtrap.tnetconsulting.net> Can anyone enlighten me on the effective difference in the use of /var/spool vs /var/lib? It's my understanding that spools are for files that are in transit. Effectively like packages moving through a shipping depo or people waiting in line. I.e. they come in, they hang around for a while, and then they leave. I'm of the opinion that files in /var/lib should stick around longer and are not nearly as dynamic (if at all, save for code updates). As sure as I type this, I can't think of a reason library files would go under /var vs a different */lib directory. Does it make any difference if the files are actually executed and / or consumed on the system? I don't consider the POP3 / IMAP / NNTP server to be processing files when people access messages / articles (read: files) via the respective protocols. Back story: I'm considering writing something that will download a file every day and process the last day's / week's / month's file(s) to generate output which is itself stored elsewhere. - I feel like these files should live in the /var/spool/ subdirectory. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From krewat at kilonet.net Fri Dec 15 09:38:53 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 14 Dec 2017 18:38:53 -0500 Subject: [TUHS] Difference in purpose of /var/spool vs /var/lib In-Reply-To: <81c54c6f-2efb-48e7-c5ee-afd1297323ff@spamtrap.tnetconsulting.net> References: <81c54c6f-2efb-48e7-c5ee-afd1297323ff@spamtrap.tnetconsulting.net> Message-ID: <53aab8cc-0b03-3437-ee4d-a5a35c098b50@kilonet.net> In my humble opinion, "spool" means files in transit. Run something locally, it generates a file, it gets shipped somewhere (email, printer, etc) and it's gone. On Linux and Solaris (to a lesser extent), /var/lib seems to be configuration files like samba's password database, and other "non transient" files. If you're storing files for long periods, /var/spool is not where you want to do that. Again, IMHO. On 12/14/2017 6:00 PM, Grant Taylor via TUHS wrote: > Can anyone enlighten me on the effective difference in the use of > /var/spool vs /var/lib? > > It's my understanding that spools are for files that are in transit. > Effectively like packages moving through a shipping depo or people > waiting in line.  I.e. they come in, they hang around for a while, and > then they leave. > > I'm of the opinion that files in /var/lib should stick around longer > and are not nearly as dynamic (if at all, save for code updates). > > As sure as I type this, I can't think of a reason library files would > go under /var vs a different */lib directory. > > Does it make any difference if the files are actually executed and / > or consumed on the system? > > I don't consider the POP3 / IMAP / NNTP server to be processing files > when people access messages / articles (read: files) via the > respective protocols. > > Back story:  I'm considering writing something that will download a > file every day and process the last day's / week's / month's file(s) > to generate output which is itself stored elsewhere.  -  I feel like > these files should live in the /var/spool/ subdirectory. > > > From random832 at fastmail.com Fri Dec 15 13:04:49 2017 From: random832 at fastmail.com (Random832) Date: Thu, 14 Dec 2017 22:04:49 -0500 Subject: [TUHS] Date madness In-Reply-To: <1513220855.2223106.1204498584.3CB1C63A@webmail.messagingengine.com> References: <201712131912.vBDJCb3a120561@tahoe.cs.Dartmouth.EDU> <1513220855.2223106.1204498584.3CB1C63A@webmail.messagingengine.com> Message-ID: <1513307089.3651124.1205701656.4E468085@webmail.messagingengine.com> On Wed, Dec 13, 2017, at 22:07, Random832 wrote: > Making V6 do it (no long *or* unsigned type) is a bit more involved, but > I'm close to something viable. Incidentally, one gotcha I've run into is > that the code as-is passes the year minus 1900 to dysize, whereas modern > dysize implementations that respect the 100 and 400 year rules require > the full year. I managed to get it working - an implementation that works on V6 (well, works on apout with the V6 compiler and library) for all dates between 1970-01-01 and 2106-02-07 06:28:15. I even tried to do as much as possible in the register variables, to approximate the same performance as the original (though I suspect the O(N) year incrementing loop probably doesn't perform as well now as it did in 1975, especially with a proper dysize implementation) Other features: localtime supports all correct US rules and offsets greater than 9 hours (though it still has the US rules and EST hardcoded), and ctime supports Y2K (and 2.1K) If anyone wants it I can post it somewhere, or just put it on the list. From paul.winalski at gmail.com Sat Dec 16 02:41:35 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 15 Dec 2017 11:41:35 -0500 Subject: [TUHS] Date madness In-Reply-To: <201712132046.vBDKkPbk002217@freefriends.org> References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> <201712132046.vBDKkPbk002217@freefriends.org> Message-ID: On 12/13/17, arnold at skeeve.com wrote: > > ISTR that the vaxen did have such things. Or rather, I ran some BSD 780s > for several years and I don't remember having to set the date / time > every time I did a reboot. They sat in a data center, so I may have never > done a cold boot from power on. It was a LONG time ago now, so there's > undoubtedly lots that I just plain don't remember. The first two VAXen, the 11/780 and 11/750, both had TOY clocks that ran when the machine was powered off. The 11/730 was designed to be a low-cost VAX, and one of the ways they lowered the cost was elimination of the TOY clock. VMS (and I assume also UNIX) asked you to enter the time whenever you cold booted the 11/730. After the 11/730 came out, Dick Hustvedt (lead VMS architect and engineer) and Stan Rabinowitz put together an elaborate April fool's hack. On April 1, the 11/730 in the VMS group's machine room had next to it a pedestal with a sundial on it and a ribbon cable leading into the 11/730, with sales brochures placed next to it. The sales brochures announced the SD730 Fixed Head Solar Horologue, a sundial with a photocell for detecting noon that could be used to automatically set the 11/730's time-of-day clock. The thing actually worked--it was connected via a UNIBUS real-time device controller, and Hustvedt had written a VMS device driver for it. All VAXen after the 11/730 had TOY clocks. -Paul W. From dave at horsfall.org Sat Dec 16 03:19:09 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 16 Dec 2017 04:19:09 +1100 (EST) Subject: [TUHS] Date madness In-Reply-To: References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> <201712132046.vBDKkPbk002217@freefriends.org> Message-ID: On Fri, 15 Dec 2017, Paul Winalski wrote: > After the 11/730 came out, Dick Hustvedt (lead VMS architect and > engineer) and Stan Rabinowitz put together an elaborate April fool's > hack. On April 1, the 11/730 in the VMS group's machine room had next > to it a pedestal with a sundial on it and a ribbon cable leading into > the 11/730, with sales brochures placed next to it. The sales > brochures announced the SD730 Fixed Head Solar Horologue, a sundial > with a photocell for detecting noon that could be used to > automatically set the 11/730's time-of-day clock. The thing actually > worked--it was connected via a UNIBUS real-time device controller, and > Hustvedt had written a VMS device driver for it. Cripes; I remember that story! Wasn't there a GIF of the brochure somewhere? Ah, here's a reference: https://slashdot.org/comments.pl?sid=76256&cid=6805264 along with the dreaded microfortnights... (Sad what happened to Dick.) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sat Dec 16 13:39:53 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 16 Dec 2017 14:39:53 +1100 (EST) Subject: [TUHS] Date madness In-Reply-To: <201712132046.vBDKkPbk002217@freefriends.org> References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> <201712132046.vBDKkPbk002217@freefriends.org> Message-ID: On Wed, 13 Dec 2017, arnold at skeeve.com wrote: > (There was an old USENET joke about how with the size of transistors > going down, pretty soon you'd be able to get an S/370 inside your watch. > But of course, as soon as you booted MVS on it, it would ask you to set > the time! :-) A bit OT, I know, but how close would S/370 and Apple's iWatch be? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From random832 at fastmail.com Sat Dec 16 13:43:58 2017 From: random832 at fastmail.com (Random832) Date: Fri, 15 Dec 2017 22:43:58 -0500 Subject: [TUHS] Partition table rationales? Message-ID: <1513395838.858529.1206806712.4081AE92@webmail.messagingengine.com> Is there any information on the rationales behind the sizes and positions of the hardcoded partitions in the rp/hp drivers in V6? There are odd gaps of unused space between ones that appear to be intended to be used together (I think I have some pieces of the puzzle worked out below, but not all). For the rp driver, only rp[01] uses the whole disk - rp2 and rp3 are 9200 blocks. The hp partitions looked more complicated, but it looks like the manpage is wrong about where partition 2 starts - 84018 vs 48018. Partitions 0123 are 161584 blocks, 4567 are 162400 blocks. 4567 start on 100-cylinder boundaries, but are only a bit over 97 cylinders long - in fact, they are the same length as rp[01]: 203 RP03 cylinders. rp6 and rp7 are not mentioned in the manpage, and are 15600 blocks, making rp[65] and 47 reasonably non-wasteful configurations. Is there something special about 9200 blocks? rp2 and rp3 are that size, and hp1 is that size rounded to the next cylinder. V7 is much simpler: rp0 is the whole disk, 123 is a non-overlapping set with no wasted space. hp[0145], 016, and 017 are non-overlapping sets. From lyndon at orthanc.ca Sat Dec 16 13:45:04 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri, 15 Dec 2017 19:45:04 -0800 Subject: [TUHS] Date madness In-Reply-To: References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> <201712132046.vBDKkPbk002217@freefriends.org> Message-ID: > On Dec 15, 2017, at 7:39 PM, Dave Horsfall wrote: > > A bit OT, I know, but how close would S/370 and Apple's iWatch be? ~25 MHz CPU on the 3[67]0? I/O channel controller bandwidth to the peripherals in low megabytes/s? 16 MB of core. Do you think your iWatch could support 200 VM/370 APL, or general MTS, terminal sessions? :-) From dave at horsfall.org Sat Dec 16 14:50:00 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 16 Dec 2017 15:50:00 +1100 (EST) Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171213165814.GJ26887@mcvoy.com> References: <20171212151653.1922118C087@mercury.lcs.mit.edu> <20171213165814.GJ26887@mcvoy.com> Message-ID: On Wed, 13 Dec 2017, Larry McVoy wrote: > I wrote a lot of code in BDS C, remember it fondly (even though it's > stdio was non-stdio :) I had BDS C for my Z-80 box (the Australian 128Kb Microbee with bank-switched memory), and hated it, as it barely understood C. $BOSS then bought me Hi-Tech C, and it was full ANSI, to my surprise (that's when I found the TMPFS M: drive stuff from somewhere). I ported a few programs over that way (GREP etc, but damned slow, and I'll probably get told that it couldn't possibly have worked[*]), but now all sadly lost, alas. [*] I have a long history of doing the impossible, mostly because I was the only one dumb enough to actually try it. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From doug at cs.dartmouth.edu Sat Dec 16 20:50:45 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 16 Dec 2017 05:50:45 -0500 Subject: [TUHS] Date madness Message-ID: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU> >>> Flipping it to unsigned int was the quickest way out to kick the can until Sun Feb 6 06:28:15 2106. If you have source it’s incredibly trivial to change, and nothing changes size wise. >> >> Easy, but perhaps unwise. The sign bit is a potential escape hatch for >> times, just as it is for characters in UTF-8. > > I'm not sure what you're suggesting - UTF-8 works because it's a variable length encoding - a variable length timestamp might be interesting as an academic exercise, but there's no way for time() to specify how much space is needed, or be informed of how much space is allocated Like UTF-8, a variable-length time would be something normal programs aren't supposed to see--it would be a format for external media (i.e. file systems). Times in inodes would be variable-length. Times returned by stat() and time() would be full length. Only the kernel needs to know the encoding. One may note that inodes already use a variable-length encoding for the list of physical block addresses, so there is nothing radical here. I admit, though, that if the kernel can tell "old" from "new" inodes, then they could have different time encodings rather than one variable-length encoding. Doug From clemc at ccc.com Sun Dec 17 01:45:56 2017 From: clemc at ccc.com (Clem Cole) Date: Sat, 16 Dec 2017 10:45:56 -0500 Subject: [TUHS] Date madness In-Reply-To: References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> <201712132046.vBDKkPbk002217@freefriends.org> Message-ID: Apologies to Warren and the list for keeping this OT for UNIX thread going, but it is history.... On Fri, Dec 15, 2017 at 11:41 AM, Paul Winalski wrote: > The first two VAXen, the 11/780 and 11/750, both had TOY clocks that > ran when the machine was powered off. The 11/730 was designed to be a > low-cost VAX, and one of the ways they lowered the cost was > elimination of the TOY clock. VMS (and I assume also UNIX) asked you > to enter the time whenever you cold booted the 11/730. > > After the 11/730 came out, Dick Hustvedt (lead VMS architect and > engineer) and Stan Rabinowitz put together an elaborate April fool's > hack. On April 1, the 11/730 in the VMS group's machine room had next > to it a pedestal with a sundial on it and a ribbon cable leading into > the 11/730, with sales brochures placed next to it. The sales > brochures announced the SD730 Fixed Head Solar Horologue, a sundial > with a photocell for detecting noon that could be used to > automatically set the 11/730's time-of-day clock. The thing actually > worked--it was connected via a UNIBUS real-time device controller, and > Hustvedt had written a VMS device driver for it. > > All VAXen after the 11/730 had TOY clocks. > > -Paul W. > ​As Paul and us ex-DECies remember, that hack lived on for years. The ZK0 site (*a.k.a.* Spitbrook Road in Nashua, NH) was nominally DEC's SW bldging. At each site, there was a theme for naming the conference rooms; *i.e.* LK0 (Littleton King St) it was towns/villages in New England. It conference room being so name had a nice touch and much more fun than a boring naming scheme of SITE_BLD-FLOOR-RM#-SIZE (such as Intel). ** The ZK0 site theme had been historically famous people from science and mathematics (CS, *etc*.). Each room had painted on a wall a little history about the person(s) and was 'dressed' with something, usually on the walls, to depict one of their infamous ideas/inventions (e.g. Babbage had difference engine, Ada, had pictures of things she used to program it, I've forgotten what was in von Nueman but you get the idea). After his accident, one of the large conference rooms in VMS land, was renamed ​Hustvedt and had the SD730 in the corner along with the story. When we (Intel) moved out the building, HP was closing shop in large sites in NE. They had already sold the bldgs to the local real-estate firm that sublets them. I've often wondered what happened to those rooms and in particular the SD730 itself. That one really should be in the Computer Museum. Clem ** For the couple of years after the team was sold to Intel but not moved desks, *i.e.* still on the second floor of ZK2, we had kept the DECs names of our two large conference rooms which actually had official Intel names, but everyone still called them by their DEC names. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Sun Dec 17 02:11:59 2017 From: random832 at fastmail.com (Random832) Date: Sat, 16 Dec 2017 11:11:59 -0500 Subject: [TUHS] Date madness In-Reply-To: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU> References: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU> Message-ID: <1513440719.1943285.1207178784.050ABA15@webmail.messagingengine.com> On Sat, Dec 16, 2017, at 05:50, Doug McIlroy wrote: > Like UTF-8, a variable-length time would be something normal > programs aren't supposed to see--it would be a format for > external media (i.e. file systems). Times in inodes would be > variable-length. Times returned by stat() and time() would > be full length. Only the kernel needs to know the encoding. > > One may note that inodes already use a variable-length > encoding for the list of physical block addresses, so there > is nothing radical here. > > I admit, though, that if the kernel can tell "old" from "new" > inodes, then they could have different time encodings rather > than one variable-length encoding. I actually thought about this some more since making my previous post, though I hadn't connected it to your post since I'd thought we were still talking about the userspace interface. One way the kernel could tell old from new inodes is by reserving the high bit of one of the current 32-bit fields (either time, or size since IIRC an existing inode can't actually hold a 2GB file) as a flag. My initial thought was to simply encode in place (stealing some bits from atime for the flag and high bits of ctime, and exploiting the relationship that ctime<=mtime<=atime) Or a whole "extended inode", that occupies two (or more) inodes on disk, either adjacent to each other or by stealing a whole field as an inode pointer. Speaking of the address list, it looks like there's an unused byte in the on-disk address list, which is 40 bytes for 13*3=39 bytes of addresses (The above is for V7 - V6 inodes are smaller and have less unused space) Making this robust to being mounted by old kernels (and preventing old kernels from creating files that would appear to new kernels to have extended inodes) is the hard part, and I haven't thought any about what the format of an extended inode would be. From ralph at inputplus.co.uk Sun Dec 17 03:11:32 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Sat, 16 Dec 2017 17:11:32 +0000 Subject: [TUHS] Date madness In-Reply-To: <1513440719.1943285.1207178784.050ABA15@webmail.messagingengine.com> References: <201712161050.vBGAojbd027976@coolidge.cs.Dartmouth.EDU> <1513440719.1943285.1207178784.050ABA15@webmail.messagingengine.com> Message-ID: <20171216171132.4D5ED21CB8@orac.inputplus.co.uk> Hi Randy, > One way the kernel could tell old from new inodes is by reserving the > high bit of one of the current 32-bit fields When Doug mentioned the high bit being an escape I assumed something like, using eight bits for ease, 00-7f existing positive meaning 80-df new meaning as if unsigned e0-ff existing negative meaning existing 80 81...df e0...fe ff 00 01...7f new e0...fe ff 00 01...7f 80 81..df This would extend the positive range beyond 2038, but keep a small range of negatives for their existing pre-1970 meaning. This is storage representation. Calculations can be done in a wider int, with intermediate values simply being signed, as before. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From dfawcus+lists-tuhs at employees.org Sun Dec 17 03:42:24 2017 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sat, 16 Dec 2017 17:42:24 +0000 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: References: Message-ID: <20171216174224.GA91421@accordion.employees.org> On Wed, Dec 06, 2017 at 11:22:52AM +1000, George Michaelson wrote: > I tried a long time ago to set PS1 and PS2 to character sequences > which would permit cut-paste to work. I failed, but I didn't try very > hard. h=spuggy$; ssh copper h=copper$; h=copper$; pwd /usr/home/derek h=copper$; h=copper$; pwd /usr/home/derek h=copper$; .pdf From helbig at mailbox.org Sun Dec 17 04:12:00 2017 From: helbig at mailbox.org (Wolfgang Helbig) Date: Sat, 16 Dec 2017 19:12:00 +0100 Subject: [TUHS] Date madness In-Reply-To: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> Message-ID: <83F6894B-9C11-4D6B-9081-783A4DB5DFB9@mailbox.org> Hi Noel, may I draw your attention to http://www.tuhs.org/Archive/Distributions/Research/Bug_Fixes/V6enb/ ? There you'll find some modification to Unix V6. They are distributed as what I call .enb. This suffix stands for “enblocked”. Enblocking means marking blocks on a tape file suitable for simh. You’ll find more about V6 and the modifications at http://doc.cat-v.org/unix/v6/operating-systems-lecture-notes/ Greetings, Wolfgang Helbig Stauferstr. 22 71334 Waiblingen From dave at horsfall.org Sun Dec 17 11:43:47 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 17 Dec 2017 12:43:47 +1100 (EST) Subject: [TUHS] Date madness In-Reply-To: References: <20171213171625.6FB1418C094@mercury.lcs.mit.edu> <201712132046.vBDKkPbk002217@freefriends.org> Message-ID: On Fri, 15 Dec 2017, Lyndon Nerenberg wrote: >> A bit OT, I know, but how close would S/370 and Apple's iWatch be? > > ~25 MHz CPU on the 3[67]0? I/O channel controller bandwidth to the > peripherals in low megabytes/s? 16 MB of core. > > Do you think your iWatch could support 200 VM/370 APL, or general MTS, > terminal sessions? :-) Touché :-) I was just tickled by the OP's reference to an OS fitting inside a watch, and immediately thought of the iWatch (well, it runs iOS). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From don at DonHopkins.com Sun Dec 17 23:12:33 2017 From: don at DonHopkins.com (Don Hopkins) Date: Sun, 17 Dec 2017 14:12:33 +0100 Subject: [TUHS] shell PS1/PS2 which survive cut-paste In-Reply-To: <20171216174224.GA91421@accordion.employees.org> References: <20171216174224.GA91421@accordion.employees.org> Message-ID: I just put a newline at the end of my prompt, so the command has the whole next line to itself and there’s no prompt to get in the way of copying and pasting. -Don > On 16 Dec 2017, at 18:42, Derek Fawcus wrote: > > On Wed, Dec 06, 2017 at 11:22:52AM +1000, George Michaelson wrote: >> I tried a long time ago to set PS1 and PS2 to character sequences >> which would permit cut-paste to work. I failed, but I didn't try very >> hard. > > h=spuggy$; ssh copper > h=copper$; > h=copper$; pwd > /usr/home/derek > h=copper$; h=copper$; pwd > /usr/home/derek > h=copper$; > > > .pdf From ron at ronnatalie.com Mon Dec 18 02:19:05 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 17 Dec 2017 11:19:05 -0500 Subject: [TUHS] Date madness In-Reply-To: <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> Message-ID: <024c01d37752$c30d03b0$49270b10$@ronnatalie.com> Year corrections? Don't recall that but there were a bunch of changes to handle the insertion of leap SECONDS over the years. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of William Cheswick Sent: Thursday, December 14, 2017 9:10 AM Cc: The Eunuchs Hysterical Society Subject: Re: [TUHS] Date madness During my first few years in the Unix room (starting in 1988) there was what seemed like a semiannual flurry of leap year corrections made to research unix. Apparently, there was some aspect that kept misbehaving, with new bugs appearing at the next shift in time. I never bothered to investigate the specifics, but it happened over several years. There are probably some on this list who know more details. I don’t recall this being a problem on Plan 9. ches From ron at ronnatalie.com Mon Dec 18 02:20:24 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 17 Dec 2017 11:20:24 -0500 Subject: [TUHS] Date madness In-Reply-To: <201712140024.vBE0OZQC079168@elf.torek.net> References: <1513203404.29181.for-standards-violators@oclsc.org> <201712140024.vBE0OZQC079168@elf.torek.net> Message-ID: <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> I remember the fun and games when we had systems that went back and forth between UNIX and VMS. VMS set the time of day clock in local time. UNIX set it to GMT. From ches at cheswick.com Mon Dec 18 02:33:27 2017 From: ches at cheswick.com (William Cheswick) Date: Sun, 17 Dec 2017 11:33:27 -0500 Subject: [TUHS] Date madness In-Reply-To: <024c01d37752$c30d03b0$49270b10$@ronnatalie.com> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> <024c01d37752$c30d03b0$49270b10$@ronnatalie.com> Message-ID: No, these weren’t seconds updates (though Plan 9 has a list it applies.) These were off-by-one-hour problems at each time shift. There would be a sudden flurry of hard, indignant work, then repeat next time shift. This was in V10 Unix. > On 17Dec 2017, at 11:19 AM, Ron Natalie wrote: > > Year corrections? Don't recall that but there were a bunch of changes to handle the insertion of leap SECONDS over the years. > > -----Original Message----- > From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of William Cheswick > Sent: Thursday, December 14, 2017 9:10 AM > Cc: The Eunuchs Hysterical Society > Subject: Re: [TUHS] Date madness > > During my first few years in the Unix room (starting in 1988) there was what seemed like a semiannual flurry of leap year corrections made to research unix. Apparently, there was some aspect that kept misbehaving, with new bugs appearing at the next shift in time. > > I never bothered to investigate the specifics, but it happened over several years. There are probably some on this list who know more details. > > I don’t recall this being a problem on Plan 9. > > ches > > From random832 at fastmail.com Mon Dec 18 03:54:58 2017 From: random832 at fastmail.com (Random832) Date: Sun, 17 Dec 2017 12:54:58 -0500 Subject: [TUHS] Date madness In-Reply-To: References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> <024c01d37752$c30d03b0$49270b10$@ronnatalie.com> Message-ID: <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com> On Sun, Dec 17, 2017, at 11:33, William Cheswick wrote: > No, these weren’t seconds updates (though Plan 9 has a list it > applies.) These were off-by-one-hour problems at each time shift. > There would be a sudden flurry of hard, indignant work, then repeat > next time shift. This was in V10 Unix. That'd be daylight savings, then, not leap years. 1987 was the year that the US changed the date of the time shift from the last sunday of April to the first. The V10 source in the archive has an "octime.c" and "ctime.c", which differ in the "sunday" function: /* * The argument is a 0-origin day number. - * The value is the day number of the last - * Sunday before or after the day. + * The value is the day number of the next + * Sunday after the day. */ static sunday(t, d) register struct tm *t; register int d; { if (d >= 58) d += dysize(t->tm_year) - 365; - return(d - (d - t->tm_yday + t->tm_wday + 700) % 7); + return(d + 7 - (d - t->tm_yday + t->tm_wday + 700) % 7); } The "daytab" table itself (read in from /lib/dst) is not available in the archive - and even if it were, we can't know the history of how it was maintained or whether the 'flurry of hard work' involved maintaining this file, making that change to the ctime routine, or recompiling programs that needed it (and had been missed in a previous round). From tih at hamartun.priv.no Mon Dec 18 04:53:22 2017 From: tih at hamartun.priv.no (Tom Ivar Helbekkmo) Date: Sun, 17 Dec 2017 19:53:22 +0100 Subject: [TUHS] Date madness In-Reply-To: <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> (Ron Natalie's message of "Sun, 17 Dec 2017 11:20:24 -0500") References: <1513203404.29181.for-standards-violators@oclsc.org> <201712140024.vBE0OZQC079168@elf.torek.net> <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> Message-ID: Ron Natalie writes: > I remember the fun and games when we had systems that went back and forth > between UNIX and VMS. VMS set the time of day clock in local time. > UNIX set it to GMT. We used TGV Multinet to put our VAX/VMS cluster on the Internet. Great product, and really great service! I loved the simple ingenuity of the daylight savings switch on that system: for the forward shift in the spring, it would run the system clock at double speed for an hour, and for the autumn changeover, it would run it at half speed for two hours. Since it took place during the night, it didn't bother anyone, and it let the VMS system (which, as you say, ran on local time) maintain a strictly increasing system clock at all times. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay From ron at ronnatalie.com Mon Dec 18 06:07:16 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 17 Dec 2017 15:07:16 -0500 Subject: [TUHS] Date madness In-Reply-To: References: <1513203404.29181.for-standards-violators@oclsc.org> <201712140024.vBE0OZQC079168@elf.torek.net> <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> Message-ID: <02cd01d37772$a37865b0$ea693110$@ronnatalie.com> The VM systems at the UofM ran in local time. There was no way to set the time short of rebooting. In the fall they'd announce. System going down for reboot at 0130. Back up at 0100. Amtrak has an amusing way of handling the time change. A train just never departs before it's published time. This means in the spring; the trains just tend to run an hour late (or later than normal). In the fall, the train sits at whatever station it had arrived at before 2 AM and waits until the clock catches up. From itz at very.loosely.org Mon Dec 18 07:24:00 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Sun, 17 Dec 2017 13:24:00 -0800 Subject: [TUHS] OT: trains [Was: Date madness] In-Reply-To: <02cd01d37772$a37865b0$ea693110$@ronnatalie.com> References: <1513203404.29181.for-standards-violators@oclsc.org> <201712140024.vBE0OZQC079168@elf.torek.net> <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> <02cd01d37772$a37865b0$ea693110$@ronnatalie.com> Message-ID: <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com> On 2017-12-17 15:07, Ron Natalie wrote: > Amtrak has an amusing way of handling the time change. A train just > never departs before it's published time. This means in the spring; > the trains just tend to run an hour late (or later than normal). In > the fall, the train sits at whatever station it had arrived at before > 2 AM and waits until the clock catches up. How do other train systems handle it, e.g. the European intercity system? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From dave at horsfall.org Mon Dec 18 08:15:13 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 18 Dec 2017 09:15:13 +1100 (EST) Subject: [TUHS] Date madness In-Reply-To: <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com> References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> <024c01d37752$c30d03b0$49270b10$@ronnatalie.com> <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com> Message-ID: On Sun, 17 Dec 2017, Random832 wrote: > That'd be daylight savings, then, not leap years. 1987 was the year that > the US changed the date of the time shift from the last sunday of April > to the first. You should try living in Australia :-) It was a political plaything for quite a while, until it finally stabilised (except for the Sydney Olympics in 2000). Neither QLD nor WA have it. Broken Hill, a city in NSW, observes Central Time. And there was something odd about the railway line at Echuca at one time (did it observe Central Time once, despite being in VIC?)... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Dec 18 08:35:51 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 18 Dec 2017 09:35:51 +1100 (EST) Subject: [TUHS] OT: trains [Was: Date madness] In-Reply-To: <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com> References: <1513203404.29181.for-standards-violators@oclsc.org> <201712140024.vBE0OZQC079168@elf.torek.net> <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> <02cd01d37772$a37865b0$ea693110$@ronnatalie.com> <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com> Message-ID: On Sun, 17 Dec 2017, Ian Zimmerman wrote: > How do other train systems handle [DST], e.g. the European intercity > system? UTC? It's not hard to get used to it. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From itz at very.loosely.org Mon Dec 18 08:54:39 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Sun, 17 Dec 2017 14:54:39 -0800 Subject: [TUHS] Date madness In-Reply-To: References: <20171212180117.BFB5918C087@mercury.lcs.mit.edu> <3DB85765-AFE5-4356-8E26-DDD0A2805116@cheswick.com> <024c01d37752$c30d03b0$49270b10$@ronnatalie.com> <1513533298.4100251.1207907264.55A36789@webmail.messagingengine.com> Message-ID: <20171217225439.jlxruhtoot6bloet@matica.foolinux.mooo.com> On 2017-12-18 09:15, Dave Horsfall wrote: > You should try living in Australia :-) And then there's Canada, which always follows what the US does, after 1 or 2 years of bickering and pretend independence. Can't risk the trade. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From dave at horsfall.org Mon Dec 18 10:25:16 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 18 Dec 2017 11:25:16 +1100 (EST) Subject: [TUHS] OT: Konrad Zuse Message-ID: We lost Konrad Zuse on this day in 1995; he invented the world's first programmable computer -- the Z3 -- which was unfortunately lost in the Berlin bombing during 1943. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From akosela at andykosela.com Mon Dec 18 13:29:19 2017 From: akosela at andykosela.com (Andy Kosela) Date: Sun, 17 Dec 2017 21:29:19 -0600 Subject: [TUHS] OT: Konrad Zuse In-Reply-To: References: Message-ID: On Sunday, December 17, 2017, Dave Horsfall wrote: > We lost Konrad Zuse on this day in 1995; he invented the world's first > programmable computer -- the Z3 -- which was unfortunately lost in the > Berlin bombing during 1943. > > He is also known for being a pioneer in digital physics and has written a very peculiar book on the subject[1]. Highly recommended if anyone is interested in those subjects. --Andy [1] https://en.m.wikipedia.org/wiki/Calculating_Space -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rulingia.com Mon Dec 18 20:10:55 2017 From: peter at rulingia.com (Peter Jeremy) Date: Mon, 18 Dec 2017 21:10:55 +1100 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: Message-ID: <20171218101055.GA46385@server.rulingia.com> On 2017-Dec-12 09:40:31 -0500, Clem Cole wrote: >My question about SOL got me thinking a bit. It would be nice to have >section in TUHS of any early clones that could be collected. One thing I haven't seen mentioned is QNX - I didn't directly use it but a colleague was using it in the mid-1980s on PC-AT class hardware. ISTR one of my colleague's whinges was the 256-byte command-line limit. My earliest exposure would have been Xenix on a 286 - my main recollections are: 1) The Pascal compiler that didn't ignore comments (changing a comment could make the code fail to compile with an obscure error. 2) The fork() system call could sometimes return -1 to the parent, even when it succeeded - that caused a lot of head-scratching. 3) Hacking one of the Emacs clones (I no longer recall which) to use "far" pointers for the buffers, so I could edit files >64K without paying the performance penalty of writing "large model" code. (286 protected-mode performance was abyssmal if it needed to do segment descriptor loads) Unfortunately, I no longer have that code. -- Peter Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From arrigo at alchemistowl.org Mon Dec 18 20:31:40 2017 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Mon, 18 Dec 2017 11:31:40 +0100 Subject: [TUHS] History of exploits - request for authors Message-ID: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> Dear all, I am starting a new “history” section of the “weird machines and security” publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues). Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before. As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives. I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined. Cheers, Arrigo From norman at oclsc.org Mon Dec 18 23:03:20 2017 From: norman at oclsc.org (Norman Wilson) Date: Mon, 18 Dec 2017 08:03:20 -0500 Subject: [TUHS] OT: trains [Was: Date madness] Message-ID: <1513602204.10161.for-standards-violators@oclsc.org> Ian Zimmerman: > How do other train systems handle [DST], e.g. the European intercity > system? Dave Horsfall: UTC? It's not hard to get used to it. ===== You misunderstand the problem. Suppose I'm planning to board a train at 0300 on the morning Daylight Time ends. Now suppose the train actually departs an hour early, at 0200, because it originated before the time change and some nerd who never rides trains declared that it shall not wait the extra hour until scheduled departure time. Nerds may be happy, but the paying passengers won't be. Telling passengers to set their watches to UTC just won't happen. (Some of us nerds actually had our watches on GMT for a few months back in the years that gave the `Nixon table' in old ctime.c its (informal) name, but gave up because it was just too damn much work to stay in sync with the real world.) Once upon a time, before railways had radio communications and proper track-occupancy signalling, the consequences were more serious than that: if you run an hour ahead of schedule, you risk colliding with another train somewhere. That is why it was the railways that first accepted and promoted standard time zones. Nowadays it's not about scheduling and safety, just about having an acceptable user interface. In a similar vein, I know of at least one case in which Amtrak changed the official departure time of a train (that requires advance reservations and often runs full) from 0000 to 2359, because people would get confused about which day midnight falls on and show up a day late. (Actually the Amtrak timetable read 1200 midnight and 11:59 PM, but 24-hour time is one of the changes I agree people should just accept and use.) Norman Wilson Toronto ON From lm at mcvoy.com Tue Dec 19 01:46:38 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 18 Dec 2017 07:46:38 -0800 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218101055.GA46385@server.rulingia.com> References: <20171218101055.GA46385@server.rulingia.com> Message-ID: <20171218154638.GP11683@mcvoy.com> On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote: > On 2017-Dec-12 09:40:31 -0500, Clem Cole wrote: > >My question about SOL got me thinking a bit. It would be nice to have > >section in TUHS of any early clones that could be collected. > > One thing I haven't seen mentioned is QNX - I didn't directly use it but a > colleague was using it in the mid-1980s on PC-AT class hardware. I've used it in that timeframe. It was pretty amazing on a 286, you could have multiple people logged in via terminals and get work done. I became friends with one of the people who did the OS: Dan Hildebrandt (QNX) 613-591-0931 x204 (RIP 1998) I can't remember how we crossed paths, but we both cared about design a lot and liked bouncing ideas off of each other. QNX was an actual microkernel, the kernel part neatly fit in a 4K instruction cache. I remember Dan telling me that it worked because only a few people were allowed to touch the actual kernel, they wanted to keep it small and fast. This was all pre-posix, it was Unix-like but porting stuff was much harder than going from SunOS to IRIX. I think that it lives on in cars, someone told me that QNX is the basis for a lot of the car stuff. Anyone know? From usotsuki at buric.co Tue Dec 19 01:57:01 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 18 Dec 2017 10:57:01 -0500 (EST) Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218154638.GP11683@mcvoy.com> References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: On Mon, 18 Dec 2017, Larry McVoy wrote: > QNX was an actual microkernel, the kernel part neatly fit in a 4K > instruction cache. I remember Dan telling me that it worked because > only a few people were allowed to touch the actual kernel, they wanted > to keep it small and fast. > > This was all pre-posix, it was Unix-like but porting stuff was much > harder than going from SunOS to IRIX. > > I think that it lives on in cars, someone told me that QNX is the basis > for a lot of the car stuff. Anyone know? Isn't it the OS of the Blackberry? -uso. From lm at mcvoy.com Tue Dec 19 01:59:48 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 18 Dec 2017 07:59:48 -0800 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: <20171218155948.GR11683@mcvoy.com> On Mon, Dec 18, 2017 at 10:57:01AM -0500, Steve Nickolas wrote: > On Mon, 18 Dec 2017, Larry McVoy wrote: > > >QNX was an actual microkernel, the kernel part neatly fit in a 4K > >instruction cache. I remember Dan telling me that it worked because > >only a few people were allowed to touch the actual kernel, they wanted > >to keep it small and fast. > > > >This was all pre-posix, it was Unix-like but porting stuff was much > >harder than going from SunOS to IRIX. > > > >I think that it lives on in cars, someone told me that QNX is the basis > >for a lot of the car stuff. Anyone know? > > Isn't it the OS of the Blackberry? Yep, that too. From steve.mynott at gmail.com Tue Dec 19 02:12:08 2017 From: steve.mynott at gmail.com (Steve Mynott) Date: Mon, 18 Dec 2017 16:12:08 +0000 Subject: [TUHS] OT: trains [Was: Date madness] In-Reply-To: <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com> References: <1513203404.29181.for-standards-violators@oclsc.org> <201712140024.vBE0OZQC079168@elf.torek.net> <024e01d37752$f1e95260$d5bbf720$@ronnatalie.com> <02cd01d37772$a37865b0$ea693110$@ronnatalie.com> <20171217212400.x7r3lwqopjzs5g5o@matica.foolinux.mooo.com> Message-ID: On 17 December 2017 at 21:24, Ian Zimmerman wrote: > On 2017-12-17 15:07, Ron Natalie wrote: > >> Amtrak has an amusing way of handling the time change. A train just >> never departs before it's published time. This means in the spring; >> the trains just tend to run an hour late (or later than normal). In >> the fall, the train sits at whatever station it had arrived at before >> 2 AM and waits until the clock catches up. > > How do other train systems handle it, e.g. the European intercity system? A thread on https://www.railforums.co.uk/threads/about-the-clocks-going-forward.43348/ suggests the UK practice (at least in 2011) as documented in the "Weekly Operating Notice" for the time change week is: "trains to due to commence their journey before 0100 should run as if GMT still applies. Trains due to commence their journey at or after 0200 will run at BST. Train crew booking on times should be adjusted accordingly. Any times between 0100 and 0200 should clearly indicate whether they are BST or GMT." A quick google suggests other railway companies might generally handle this problem differently with Sweden claimed to use the Amtrak solution of waiting an hour so probably domestic European train practice differs. I would guess international trains might function as aircraft and use local time. The timetabling for such trains is more likely to regularly use different time zones anyway. I wonder how Amtrak handles different time zones within the US? -- 4096R/EA75174B Steve Mynott From steve at quintile.net Tue Dec 19 02:13:38 2017 From: steve at quintile.net (Steve Simon) Date: Mon, 18 Dec 2017 16:13:38 +0000 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218154638.GP11683@mcvoy.com> References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: <6F7CF4B5-65B2-412C-89E8-3FB69F09CE6A@quintile.net> Qnx is used in cars quite a bit , also in the telecoms sector i wad told. we used it for control of image processing systems, however it it wad a rather foolish management decision IMHO as qnx is heavyweight for the simple user interfaces we needed -Steve > On 18 Dec 2017, at 15:46, Larry McVoy wrote: > >> On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote: >>> On 2017-Dec-12 09:40:31 -0500, Clem Cole wrote: >>> My question about SOL got me thinking a bit. It would be nice to have >>> section in TUHS of any early clones that could be collected. >> >> One thing I haven't seen mentioned is QNX - I didn't directly use it but a >> colleague was using it in the mid-1980s on PC-AT class hardware. > > I've used it in that timeframe. It was pretty amazing on a 286, you could > have multiple people logged in via terminals and get work done. > > I became friends with one of the people who did the OS: > > Dan Hildebrandt (QNX) 613-591-0931 x204 (RIP 1998) > > I can't remember how we crossed paths, but we both cared about design > a lot and liked bouncing ideas off of each other. > > QNX was an actual microkernel, the kernel part neatly fit in a 4K > instruction cache. I remember Dan telling me that it worked because > only a few people were allowed to touch the actual kernel, they wanted > to keep it small and fast. > > This was all pre-posix, it was Unix-like but porting stuff was much > harder than going from SunOS to IRIX. > > I think that it lives on in cars, someone told me that QNX is the basis > for a lot of the car stuff. Anyone know? From henry.r.bent at gmail.com Tue Dec 19 02:15:56 2017 From: henry.r.bent at gmail.com (Henry Bent) Date: Mon, 18 Dec 2017 11:15:56 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218154638.GP11683@mcvoy.com> References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: On 18 December 2017 at 10:46, Larry McVoy wrote: > > I think that it lives on in cars, someone told me that QNX is the basis > for a lot of the car stuff. Anyone know? > Quite a few car systems, it seems: http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Dec 19 02:18:22 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 18 Dec 2017 11:18:22 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <6F7CF4B5-65B2-412C-89E8-3FB69F09CE6A@quintile.net> References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> <6F7CF4B5-65B2-412C-89E8-3FB69F09CE6A@quintile.net> Message-ID: My Ford Taurus SHO's Sync 3 is running QNX. What a difference (in stability) between it and the Sync 2 that used Windows CE. On 12/18/2017 11:13 AM, Steve Simon wrote: > Qnx is used in cars quite a bit , also in the telecoms sector i wad told. > > we used it for control of image processing systems, however it it wad a rather foolish management decision IMHO as qnx is heavyweight for the simple user interfaces we needed > > From akosela at andykosela.com Tue Dec 19 02:34:29 2017 From: akosela at andykosela.com (Andy Kosela) Date: Mon, 18 Dec 2017 10:34:29 -0600 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: On Monday, December 18, 2017, Henry Bent wrote: > On 18 December 2017 at 10:46, Larry McVoy wrote: > >> >> I think that it lives on in cars, someone told me that QNX is the basis >> for a lot of the car stuff. Anyone know? >> > > Quite a few car systems, it seems: http://qnxauto.blogspot.ca/ > 2015/06/the-to-z-of-qnx-in-cars.html > > I remember in the late 90s there was a demo of QNX running the whole OS with GUI including web browser etc. from 1.44MB floppy. It was very fast too! Too bad they never open sourced it. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregg.drwho8 at gmail.com Tue Dec 19 02:37:39 2017 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 18 Dec 2017 11:37:39 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: Hello! I've tried it out a couple of times. Besides being a rare microkernel OS, it has a good support system, from its company. As far as its site would explain it is a favorite among some car companies. Ford for one. BlackBerry uses it for their devices, certainly. And I believe some industrial controllers use it. The big problem is still the licensing. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Dec 18, 2017 at 11:15 AM, Henry Bent wrote: > On 18 December 2017 at 10:46, Larry McVoy wrote: >> >> >> I think that it lives on in cars, someone told me that QNX is the basis >> for a lot of the car stuff. Anyone know? > > > Quite a few car systems, it seems: > http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html > > -Henry From gregg.drwho8 at gmail.com Tue Dec 19 02:39:19 2017 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Mon, 18 Dec 2017 11:39:19 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: Hello! You are correct. That's how I got my start. Eventually I was able to swing a hobbyist license.... There was talk of parts of it becoming open source, sadly that never really happened. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Mon, Dec 18, 2017 at 11:34 AM, Andy Kosela wrote: > > > On Monday, December 18, 2017, Henry Bent wrote: >> >> On 18 December 2017 at 10:46, Larry McVoy wrote: >>> >>> >>> I think that it lives on in cars, someone told me that QNX is the basis >>> for a lot of the car stuff. Anyone know? >> >> >> Quite a few car systems, it seems: >> http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html >> > > I remember in the late 90s there was a demo of QNX running the whole OS with > GUI including web browser etc. from 1.44MB floppy. It was very fast too! > Too bad they never open sourced it. > > --Andy From itz at very.loosely.org Tue Dec 19 02:45:26 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Mon, 18 Dec 2017 08:45:26 -0800 Subject: [TUHS] OT: trains [Was: Date madness] In-Reply-To: <1513602204.10161.for-standards-violators@oclsc.org> References: <1513602204.10161.for-standards-violators@oclsc.org> Message-ID: <20171218164526.ptsvevdf4touatg6@matica.foolinux.mooo.com> On 2017-12-18 08:03, Norman Wilson wrote: > Suppose I'm planning to board a train at 0300 on the morning > Daylight Time ends. > > Now suppose the train actually departs an hour early, at 0200, > because it originated before the time change and some nerd who > never rides trains declared that it shall not wait the extra > hour until scheduled departure time. > > Nerds may be happy, but the paying passengers won't be. Yes, this was the problem I was asking about. Plus the even more vexing problem of time discontinuity when the train is already en route. I can still remember the days of thick bound paper schedules in Europe, and I think for overnight routes there usually was a tiny footnote about the 2 critical days. New book schedules were issued each year so the footnotes could be specific about the dates. What I don't know is how this transitioned into the digital age. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From clemc at ccc.com Tue Dec 19 02:53:50 2017 From: clemc at ccc.com (Clem Cole) Date: Mon, 18 Dec 2017 11:53:50 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218101055.GA46385@server.rulingia.com> References: <20171218101055.GA46385@server.rulingia.com> Message-ID: On Mon, Dec 18, 2017 at 5:10 AM, Peter Jeremy wrote: > > One thing I haven't seen mentioned is QNX - I didn't directly use it but a > colleague was using it in the mid-1980s on PC-AT class hardware. ISTR one > of my colleague's whinges was the 256-byte command-line limit. QNX, indeed a cool system. It's predecessor was Thoth and successor, the Stanford V-Kernel; QNX was the same timeframe as Mach. RIG/Accent and Thoth were all contemporaries and at the time, "UNIX" interface was not yet standard, nor C as the system language of choice, Thoth was in B IIRC, RIG assembler & Pascal, Accent / Pascal. Tunis was similar, although, like SOL was a rewrite, in that case Concurrent-Pascal; like UNIX, targeting the PDP-11. Both QNX and Mach were in C and tried to be more friendly to import UNIX code. QNX was definitely, Intel architecture target. Mach was trying to be all things on any HW target like UNIX., I got the impression some/much of QNX's kernel was assembler, but the 'servers' for the things like the FS, the IP stack, et al where 100% C. QNX, was clean, an extremely small, and was fairly good at real-time ( like Thoth had been before it, V gave up real-time to be more portable distribute better). I used a QNX on a PC/AT (286) that was, V7-ish and code from the PDP-11 pretty much just worked. The compiler was very slow, but it was 5.25" floppy based system so it may have been a lot to do with the disks I have. I remember they then add a POSIX subsystem when that was in vogue, but I never used it or their ANSI-C compiler. When 'embedded' types needed a RTOS, the QNX folks definitely had a following; particularly because the kernel was so small and efficient. I know a number of industrial robots from the 'Rust Belt' that had Mech-E types that swore by it (i.e. Millacron, Intelligrated to think of two). I understand that a number of folks/alumni are a lot of the current autonomous car people, and I had heard the brought that code base with them. Again, if I understand it correctly (and its been years since I played with it), the RTOS features are not POSIX conformant and mixing the different APIs could cause interesting effects. ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From khm at sciops.net Tue Dec 19 03:08:00 2017 From: khm at sciops.net (Kurt H Maier) Date: Mon, 18 Dec 2017 09:08:00 -0800 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218101055.GA46385@server.rulingia.com> References: <20171218101055.GA46385@server.rulingia.com> Message-ID: <20171218170800.GA87406@wopr> On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote: > One thing I haven't seen mentioned is QNX - I didn't directly use it but a > colleague was using it in the mid-1980s on PC-AT class hardware. ISTR one > of my colleague's whinges was the 256-byte command-line limit. Blackberry's phones are no longer QNX-based (they fell to the advancing Android hordes) but they still own it and are targeting the IVI market with it, apparently. They have a no-commercial-use no-cost license available. The first QNX device I saw in the wild was the 3com Audrey, which was a little all-in-one computer with an infrared keyboard and a resistive touchscreen. 3com seemed to want to sell them for kitchen use, but then the dot-com bust happened and the Audrey went with it. The QNX deployment on it was sufficiently unixlike that step one in doing anything interesting was exploiting a privilege escalation and editing the passwd file. khm From steve at quintile.net Tue Dec 19 03:35:52 2017 From: steve at quintile.net (Steve Simon) Date: Mon, 18 Dec 2017 17:35:52 +0000 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: <9B5822A8-8F46-4FC4-B12C-681CF0ACB362@quintile.net> maybe i am wrong but i thought QNX was open source for a while, but then it changed hands and the new owners “removed it from the internet”. interestingly if this is true its only the 2nd time i have heard of this happening ever happening. the other one was years ago with the Khronos dataflow signal processing system. -Steve > On 18 Dec 2017, at 16:34, Andy Kosela wrote: > > > >> On Monday, December 18, 2017, Henry Bent wrote: >>> On 18 December 2017 at 10:46, Larry McVoy wrote: >>> >>> I think that it lives on in cars, someone told me that QNX is the basis >>> for a lot of the car stuff. Anyone know? >> >> >> Quite a few car systems, it seems: http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html >> > > I remember in the late 90s there was a demo of QNX running the whole OS with GUI including web browser etc. from 1.44MB floppy. It was very fast too! Too bad they never open sourced it. > > --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at telegraphics.com.au Tue Dec 19 03:41:07 2017 From: toby at telegraphics.com.au (Toby Thain) Date: Mon, 18 Dec 2017 12:41:07 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <9B5822A8-8F46-4FC4-B12C-681CF0ACB362@quintile.net> References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> <9B5822A8-8F46-4FC4-B12C-681CF0ACB362@quintile.net> Message-ID: On 2017-12-18 12:35 PM, Steve Simon wrote: > > maybe i am wrong but i thought QNX was open source for a while, but then > it changed hands and the new owners “removed it from the internet”. > > interestingly if this is true its only the 2nd time i have heard of this > happening ever happening. the other one was years ago with the Khronos > dataflow signal processing system. What about Solaris. --T > > -Steve > > > On 18 Dec 2017, at 16:34, Andy Kosela > wrote: > >> >> >> On Monday, December 18, 2017, Henry Bent > > wrote: >> >> On 18 December 2017 at 10:46, Larry McVoy > > wrote: >> >> >> I think that it lives on in cars, someone told me that QNX is >> the basis >> for a lot of the car stuff.  Anyone know? >> >> >> Quite a few car systems, it seems: >> http://qnxauto.blogspot.ca/2015/06/the-to-z-of-qnx-in-cars.html >> >> >> >> I remember in the late 90s there was a demo of QNX running the whole >> OS with GUI including web browser etc. from 1.44MB floppy.  It was >> very fast too!  Too bad they never open sourced it. >> >> --Andy From bakul at bitblocks.com Tue Dec 19 04:32:27 2017 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 18 Dec 2017 10:32:27 -0800 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: <20171218154638.GP11683@mcvoy.com> References: <20171218101055.GA46385@server.rulingia.com> <20171218154638.GP11683@mcvoy.com> Message-ID: <838A8C87-68EB-4757-9415-8D7D09F058F6@bitblocks.com> > On Dec 18, 2017, at 7:46 AM, Larry McVoy wrote: > >> On Mon, Dec 18, 2017 at 09:10:55PM +1100, Peter Jeremy wrote: >>> On 2017-Dec-12 09:40:31 -0500, Clem Cole wrote: >>> My question about SOL got me thinking a bit. It would be nice to have >>> section in TUHS of any early clones that could be collected. >> >> One thing I haven't seen mentioned is QNX - I didn't directly use it but a >> colleague was using it in the mid-1980s on PC-AT class hardware. > > I've used it in that timeframe. It was pretty amazing on a 286, you could > have multiple people logged in via terminals and get work done. > > I became friends with one of the people who did the OS: > > Dan Hildebrandt (QNX) 613-591-0931 x204 (RIP 1998) > > I can't remember how we crossed paths, but we both cared about design > a lot and liked bouncing ideas off of each other. > > QNX was an actual microkernel, the kernel part neatly fit in a 4K > instruction cache. I remember Dan telling me that it worked because > only a few people were allowed to touch the actual kernel, they wanted > to keep it small and fast. > > This was all pre-posix, it was Unix-like but porting stuff was much > harder than going from SunOS to IRIX. > > I think that it lives on in cars, someone told me that QNX is the basis > for a lot of the car stuff. Anyone know? OKL4 (a variant of L4 micro kernel) is supposedly in billions of mobile devices. Apple’s “Secure Enclave” runs a modified version of L4. Likely OKL4. Their claim to fame is that it is “provably correct”. L4 is derived from Liedke’s L3 and is much more portable than L3. OKL4 and seL4 we’re both owned by Open Kernel Labs, which is now owned by General Dynamics. Now seL4 has been open sourced. There have been a few variations of L4 over time with names like fiasco & Pistachio etc. L4 is simpler than Mach or QNX. What I like about seL4 is that it is capability based. A contract I did ages ago was for a company that used QNX on their text to speech 286 based board. It had a peculiar crash only when used in a complex setup. After about a month of close study and experiments I guessed it was an Intel bug. Intel refused to help so then I had to catch it in action in a live setup, at which point Intel fessed up! Any way, I learned a bunch about QNX back then. From brad at anduin.eldar.org Tue Dec 19 04:41:10 2017 From: brad at anduin.eldar.org (Brad Spencer) Date: Mon, 18 Dec 2017 13:41:10 -0500 Subject: [TUHS] Early Clones / Rewrites for TUHS archives In-Reply-To: (message from Toby Thain on Mon, 18 Dec 2017 12:41:07 -0500) Message-ID: Toby Thain writes: > On 2017-12-18 12:35 PM, Steve Simon wrote: >> >> maybe i am wrong but i thought QNX was open source for a while, but then >> it changed hands and the new owners “removed it from the internet”. >> >> interestingly if this is true its only the 2nd time i have heard of this >> happening ever happening. the other one was years ago with the Khronos >> dataflow signal processing system. > > What about Solaris. > > --T > Depends on your point of view a bit.... One can probably say that Oracle Solaris has been "pulled back". But, Solaris has sufficiently escaped in a form that is still open source, if you ignore Oracle. The company which is my $DAYJOB uses Joyent Triton SmartOS, which is very Solaris in every way and completely open source. We run a couple of farily large private clouds with it. -- Brad Spencer - brad at anduin.eldar.org - KC8VKS http://anduin.eldar.org - & - http://anduin.ipv6.eldar.org [IPv6 only] From dave at horsfall.org Tue Dec 19 10:48:41 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 19 Dec 2017 11:48:41 +1100 (EST) Subject: [TUHS] OT: trains [Was: Date madness] In-Reply-To: <20171218164526.ptsvevdf4touatg6@matica.foolinux.mooo.com> References: <1513602204.10161.for-standards-violators@oclsc.org> <20171218164526.ptsvevdf4touatg6@matica.foolinux.mooo.com> Message-ID: On Mon, 18 Dec 2017, Ian Zimmerman wrote: >> Nerds may be happy, but the paying passengers won't be. > > Yes, this was the problem I was asking about. Plus the even more vexing > problem of time discontinuity when the train is already en route. Yeah, I misunderstood; sorry... Hey, at least China doesn't have the problem of multiple timezones :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Tue Dec 19 11:08:21 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 19 Dec 2017 12:08:21 +1100 (EST) Subject: [TUHS] History of exploits - request for authors In-Reply-To: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> Message-ID: On Mon, 18 Dec 2017, Arrigo Triulzi wrote: [...] > I hope a few of you will want to contribute something to the collection, > there is still space for the January 2018 edition if anyone is so > inclined. Depends on exactly what you want; I don't have time to document my, err, past before your deadline, but my favourites under Edition 6 would be: Planting 0 into u.u_uid via the switch register (physical access reqd). Planting same, but by sending a negative signal to yourself. And the usual run of insecure directory permissions etc. Planting trojans such as "pwd" called with 17 args (and same size!). Leaving a "login" simulator on a terminal (quite common). And on KRONOS, you could get system privileges quite easily on a terminal. With OS/360, you dumped low memory and traced where "SVC 254" went. Is that the sort of stuff you're after? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lm at mcvoy.com Tue Dec 19 11:25:25 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 18 Dec 2017 17:25:25 -0800 Subject: [TUHS] History of exploits - request for authors In-Reply-To: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> Message-ID: <20171219012525.GB11683@mcvoy.com> So the only one I was involved in was the CVS hack to the Linux kernel source tree. This was back in the early 2000's and the kernel used my SCM system, BitKeeper, but there were people who didn't like the license. We built an exporter that exported the history to CVS (it was a pretty nice exporter, on a per file basis it would find the longest path through a DAG and export that since CVS was straight line, not a DAG.) Me being me, I trusted nothing, so as part of the export process I compared the checked out BitKeeper tree to the checked out CVS tree. And found that someone had broken into the machine that hosted the CVS tree and stuck a back door into the source. https://www.linux.com/news/linux-kernel-development-process-thwarts-subversion-attempt I take umbrage at the reporting there, they said it was many eyes (the open source mantra) that found it, that's bullshit, it was my eyes that found it. On Mon, Dec 18, 2017 at 11:31:40AM +0100, Arrigo Triulzi wrote: > Dear all, > > I am starting a new ???history??? section of the ???weird machines and security??? publication PoC||GTFO (https://www.alchemistowl.org/pocorgtfo for my mirror, https://www.nostarch.com/gtfo for a printed compilation of the first 15 issues). > > Ideally we would like some articles about the history of security exploits where the historical importance is emphasised: we always get authors willing to tell us about the latest and greatest web exploit but they often lack any historical perspective about what has been done before. > > As PoC||GTFO has a strong emphasis on weird machines and generally forgotten hardware and software I thought that the contributors to TUHS would be ideally placed to write something about their preferred security exploits in the past. I have fond memories of taking over a machine using and NFS /home filesystem exported to the wide-world, of someone trying to hack into my MasPar via the DEC Ultrix which controlled it, etc. but I am really rather interested in other perspectives. > > I hope a few of you will want to contribute something to the collection, there is still space for the January 2018 edition if anyone is so inclined. > > Cheers, > > Arrigo -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From nw at retrocomputingtasmania.com Tue Dec 19 16:00:25 2017 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Tue, 19 Dec 2017 17:00:25 +1100 Subject: [TUHS] pre-UNIX legacy in UNIX? Message-ID: I blundered today into the GECOS field in /etc/passwd: https://en.wikipedia.org/wiki/Gecos_field "Some early Unix systems at Bell Labs used GECOS machines for print spooling and various other services,[3] so this field was added to carry information on a user's GECOS identity." I had forgotten about this field and I don't recall it being previously described as related to GECOS (I likely didn't take note at the time I first encountered it). Aside from the influence of Multics and other things on UNIX design are there other tangible[1] manifestations of non-UNIX operating system things like the GECOS field that were carried forward intact in later UNIX implementations? [1] things can be pointed at, rather than design ideas From lars at nocrew.org Tue Dec 19 16:21:55 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 19 Dec 2017 06:21:55 +0000 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: (Nigel Williams's message of "Tue, 19 Dec 2017 17:00:25 +1100") References: Message-ID: <7wd13bdypo.fsf@junk.nocrew.org> Nigel Williams wrote: > Aside from the influence of Multics and other things on UNIX design > are there other tangible[1] manifestations of non-UNIX operating > system things like the GECOS field that were carried forward intact in > later UNIX implementations? Job control was inspired by ITS job control capabilities. Control-Z does pretty much the same thing in both operating systems. From don at DonHopkins.com Tue Dec 19 17:07:30 2017 From: don at DonHopkins.com (Don Hopkins) Date: Tue, 19 Dec 2017 08:07:30 +0100 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: <7wd13bdypo.fsf@junk.nocrew.org> References: <7wd13bdypo.fsf@junk.nocrew.org> Message-ID: On ITS, you could pass a job back and forth between users, like a joint! ;) It was a very social operating system. http://victor.se/bjorn/its/ddt.html#Sophisticated :DISOWN $$^K "disowns" the current job. The job continues to exist, and if it was running continues to run, but it ceases to be DDT's inferior. Any information DDT has about the job that is not actually in the job itself is lost (for example, the starting address and symbols of the program). When a job has been disowned it no longer has a terminal, and if it tries to read from or print on its terminal it will halt. Disowning allows a job to continue to exist after the DDT that created it has logged out or been killed. It makes it possible to leave a job running without tying up a terminal. A disowned job can be reowned by selecting it with :JOB. What's more, any user can reown a job no matter who disowned it, using the :UJOB command and specifying the UNAME of the disowned job, as in :UJOB FOOSH TECO to reown the TECO that user FOOSH disowned. This makes it possible to hand a job to another user. :UJOB Selects the specified job (which can be any job in the system) for examination. If the job is disowned, it will have it's UNAME changed to your UNAME and will be reowned. Otherwise it will remain a foriegn job, i.e. can be examined but not modified or proceeded. :DETACH detaches the user's whole job-tree. The console becomes free just as if it had logged out, but the jobs are not destroyed. They remain in the system without a console. A detached job is just like a disowned job (see :DISOWN), but got that way differently. The opposite of detaching is attaching. There is a :ATTACH command which performs that operation, but it is too primitive to be convenient in the usual case (don't use it without reading the reference section). However, after logging in DDT automatically checks for the existence of a detached tree and offers to attach to it. After a is typed, the formerly detached tree will be connected to the console (which need not be the same one it was detached from). The new DDT that did the attaching will no longer exist. If something "goes wrong" with the console, a tree may be detached automatically by the system. For example, if a user coming over the ARPA network closes his connection, his tree will be detached. The same thing happens to all users of TV terminals if the TV front-end PDP-11 crashes. When this happens, the detached tree will be destroyed by the system after an hour goes by, unless it is attached first. As described above, logging back in will automatically tell the new DDT to look for the old detached one and offer to attach it. There is a program called REATTACH designed specifically for detaching jobs from consoles and attaching jobs to consoles. It can be used to move your jobs to another console, from either the old console, the new console, or someone else's console. :REATTACH HELP will print its documentation. :ATTACH makes the current job (which must be running) become the top level job, in place of DDT. That job's name is changed to HACTRN, and the existing HACTRN job (containing DDT) is killed, along with any other inferiors it may have. :ATTACH is very dangerous for that reason. Its main use is to set up a program other than DDT as the top-level command processor. It is possible to use :ATTACH to do the opposite of :DETACH. Just reown the detached former HACTRN (now called HACTRO or HACTRP or ...) using :JOB, and then :ATTACH it. However, it is probably safer to use the REATTACH program. Type :REATTACH ? for information. :SNARF When a HACTRN is detached because of trouble with the terminal, but is still basically healthy, it can be attached. When a HACTRN is detached because of fatal errors, it stops running and can't be attached (and, having run into such trouble, it would probably be useless if it were attached). However, its inferiors are likely to be unharmed. The :SNARF command exists to rescue those inferiors from under the sinking DDT. It is meant to be used after reowning that DDT as a subjob of a new, healthy DDT. The dead DDT should be the current job. :SNARF takes away the current job's inferior named and makes it a direct inferior of the DDT executing the :SNARF. Thus, after a HACTRN dies while having a TECO under it (and thus changes to a HACTRO), one can do (in a new HACTRN) :JOB HACTRO to reown the dead DDT, and :SNARF TECO to take the TECO away from it. The job TECO is then an inferior of the new HACTRN, and the HACTRO job can be killed without harm to the TECO. If you try to :SNARF a nonexistent job, a "No such job" error will result. :SNARF works by writing into the current job a program to disown any inferior named , and then doing a :JOB . Thus, :SNARF can garbage the job snarfed from. This is small loss when the job is already dead. -Don > On 19 Dec 2017, at 07:21, Lars Brinkhoff wrote: > > Nigel Williams wrote: >> Aside from the influence of Multics and other things on UNIX design >> are there other tangible[1] manifestations of non-UNIX operating >> system things like the GECOS field that were carried forward intact in >> later UNIX implementations? > > Job control was inspired by ITS job control capabilities. Control-Z > does pretty much the same thing in both operating systems. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrvalverde at cnb.csic.es Wed Dec 20 02:13:45 2017 From: jrvalverde at cnb.csic.es (Jose R. Valverde) Date: Tue, 19 Dec 2017 17:13:45 +0100 Subject: [TUHS] Various Unix Message-ID: <20171219171345.59efbf33@cnb.csic.es> Before we had to phase out our FTP server, I kept on it several versions of UNIX clones and related OS that were mostly not on TUHS. This post is to remember some of these systems. Many of these were open sourced or widely available at some time and were related to UNIX one way or another. I may not have the latest versions or all the versions, but at least I do keep something. The following ones have been open sourced at some point in time (I believe): ChorusOS Coherent EXOS L4 Lunix MaRTE-OS Mach OpenBLT OpenSolaris Sprite (I also own the original distribution CD) Trix UniFlex agnix amoeba bkunix bsd386 hurd iunix jaluna-c5 lsx-unix mini-unix minix omu opensolaris starunix thix from tliquest.net/local/unix: uzi and various other bits tme tropix tunix unix-v8 unix-wega uzi xhomer xinu xv6 yoctix Plus several archaic CDs with early versions of Linux, Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs) and even the Beowulf/Extreme Linux CDs (plus I must keep around the mirror we hosted for a long time of the Beowulf site). The hobbyist CDs for OpenSolaris 8 (and I believe 9) with sources. Oh, and MOSIX/OPENMOSIX. In addition, I have many other sources whose Copyright status I'm not aware of, but which are interesting for archival purposes. Regarding QNX, yes, it was open sourced (at least for hobbyist use, I have to check the license) for several distributions. I ported some bioinformatics software and kept for some time a distribution repository, and I'm pretty certain I must have the sources as well as the virtual machines. I'll try to verify the licenses to see if it can be redistributed, although I doubt they can. Oh, and I also own the mentioned famous 3.5" diskette. I think I digitized it long ago. Would have to check. Off the Net, it has been possible, one time or another, to recover executables and, sometime, even sources, of many systems. Archive.org has -I believe- a copy of a once famous repo of abandonware with binaries of SCO, System V, AIX, etc... I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64, OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at some time or another in source code format, and binaries of IRIX, Lisa, QNX, A/UX, xenix... Some years ago, I had more free time and could test many systems on emulators, and built images and accompanying scripts ready ti run. I also made some tools to be able to transfer data in and out of old unix versions (so I could edit the software off the virtual machine while back-porting a screen editor to V6, v5, etc... with only vt100 support). Not UNIX-related, I also keep copies of many other ancient operating systems and software and hardware emulators. Well, as I said at the beginning, everything that I had, I should still keep while the hard disks continue spinning. If there is any interest in adding any of these to TUHS, I can try to find a way to send it all. If I find time to browse through everything, I would like to upload all the source code to GitHub (at least anything that's redistributable). If I find the time... But, Warren, if you are interested in anything, let me know and I'll find a way to give you access. j -- Scientific Computing Service Solving all your computer needs for Scientific Research. http://bioportal.cnb.csic.es From gtaylor at tnetconsulting.net Wed Dec 20 04:21:26 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 19 Dec 2017 11:21:26 -0700 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: References: Message-ID: On 12/18/2017 11:00 PM, Nigel Williams wrote: > I blundered today into the GECOS field in /etc/passwd: > > https://en.wikipedia.org/wiki/Gecos_field > > "Some early Unix systems at Bell Labs used GECOS machines for print > spooling and various other services,[3] so this field was added to > carry information on a user's GECOS identity." Was the GECOS field meant to be consumed by a computer or human? All the descriptions I've seen about the GECOS field made me think that it was for human friendly information [1] and not really machine parsable. So, was there some sort of ID in the GECOS field in a users /etc/passwd entry that was then used by the GECOS machine / OS to identify the user? Or is my (complete) ignorance of GECOS (OS) showing that I'm not aware of something about user IDs on GECOS (OS)? > I had forgotten about this field and I don't recall it being > previously described as related to GECOS (I likely didn't take note at > the time I first encountered it). I had often wondered why it was called "GECOS", but had never really given it any thought as it seemed logical to have something to store the users contact information somewhere convenient and easily accessible by all applications. Thus the /etc/passwd file seemed like a logical choice. Now I wonder if we are using the GECOS field to store the same data as years ago? Or did we re-purpose the now unneeded GECOS to store name, address, office phone number, home phone, etc? I never knew about GECOS (OS) to put two and two together. #questionsQuestions -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From doug at cs.dartmouth.edu Wed Dec 20 04:48:31 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 19 Dec 2017 13:48:31 -0500 Subject: [TUHS] pre-UNIX legacy in UNIX? Message-ID: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU> > > are there other tangible[1] manifestations of non-UNIX operating > > system things like the GECOS field that were carried forward intact in > > later UNIX implementations? > > Job control was inspired by ITS job control capabilities. Control-Z > does pretty much the same thing in both operating systems. I don't think "carried forward" describes job control, which I believe was never in any Research system. "Borrowed" would be more accurate. In fact, I don't recall being aware of the existence of the ITS movement at the time Unix arose. Doug From ralph at inputplus.co.uk Wed Dec 20 05:05:09 2017 From: ralph at inputplus.co.uk (Ralph Corderoy) Date: Tue, 19 Dec 2017 19:05:09 +0000 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: References: Message-ID: <20171219190509.794961F96E@orac.inputplus.co.uk> Hi Grant, > > https://en.wikipedia.org/wiki/Gecos_field > > Was the GECOS field meant to be consumed by a computer or human? Computer for its original purpose. And computer again when things like finger(1) would take it apart. As well as reading the above page, there's http://catb.org/jargon/html/G/GECOS.html -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy From gtaylor at tnetconsulting.net Wed Dec 20 06:03:08 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Tue, 19 Dec 2017 13:03:08 -0700 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: <20171219190509.794961F96E@orac.inputplus.co.uk> References: <20171219190509.794961F96E@orac.inputplus.co.uk> Message-ID: <837bbe68-c13f-c31c-eb3b-123ff708f2c4@spamtrap.tnetconsulting.net> On 12/19/2017 12:05 PM, Ralph Corderoy wrote: > Hi Grant, Hi Ralph, > Computer for its original purpose. And computer again when things like > finger(1) would take it apart. As well as reading the above page, > there's http://catb.org/jargon/html/G/GECOS.html Thank you for the Jargon file link. It clearly indicates that the GECOS field held the GECOS user ID. So I guess at some point we transitioned from the GECOS user ID to the comma delimited format that we use today. I suppose it was after there was no longer a need to store GECOS user IDs. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From lars at nocrew.org Wed Dec 20 06:08:58 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 19 Dec 2017 20:08:58 +0000 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU> (Doug McIlroy's message of "Tue, 19 Dec 2017 13:48:31 -0500") References: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU> Message-ID: <7wd13aa3ad.fsf@junk.nocrew.org> Doug McIlroy wrote: >> Job control was inspired by ITS job control capabilities. Control-Z >> does pretty much the same thing in both operating systems. > I don't think "carried forward" describes job control, which I > believe was never in any Research system. "Borrowed" would be > more accurate. Fair enough! Job control was a BSD thing in the beginning. > In fact, I don't recall being aware of the existence of the ITS > movement at the time Unix arose. Was there ever a movement? It was just four machines at MIT. From arnold at skeeve.com Wed Dec 20 06:14:53 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 19 Dec 2017 13:14:53 -0700 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: <837bbe68-c13f-c31c-eb3b-123ff708f2c4@spamtrap.tnetconsulting.net> References: <20171219190509.794961F96E@orac.inputplus.co.uk> <837bbe68-c13f-c31c-eb3b-123ff708f2c4@spamtrap.tnetconsulting.net> Message-ID: <201712192014.vBJKErI9010289@freefriends.org> Grant Taylor via TUHS wrote: > So I guess at some point we transitioned from the GECOS user ID to the > comma delimited format that we use today. I suppose it was after there > was no longer a need to store GECOS user IDs. I think this happened at UCB, where they split it into comma-separated fields indicating full name, office, phone number and something else I don't remember at the moment. Probably for the finger command. I'm pretty sure the BSD passwd(7) (or was it passwd(5)?) man page described things in detail. HTH, Arnold From dfawcus+lists-tuhs at employees.org Wed Dec 20 06:25:01 2017 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 19 Dec 2017 20:25:01 +0000 Subject: [TUHS] History of exploits - request for authors In-Reply-To: References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> Message-ID: <20171219202501.GB95741@accordion.employees.org> A version independent, but terminal dependent one was using the echo status line back to input mechanism of some terminals. When combined with getting the victim to to copy a setuid stub, one would get permanent access to their account - until root did a fs sweep looking for unusual setuid programs. DF From dfawcus+lists-tuhs at employees.org Wed Dec 20 06:17:21 2017 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Tue, 19 Dec 2017 20:17:21 +0000 Subject: [TUHS] History of exploits - request for authors In-Reply-To: References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> Message-ID: <20171219201721.GA95741@accordion.employees.org> On Tue, Dec 19, 2017 at 12:08:21PM +1100, Dave Horsfall wrote: > > Leaving a "login" simulator on a terminal (quite common). Well if you include that one, you may want to include the simple brute force testing of passwords against /etc/passwd (before shadow files existed). The login name and real names (direct or reversed) would tend to get at least one hit. DF From ron at ronnatalie.com Wed Dec 20 06:32:18 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Tue, 19 Dec 2017 15:32:18 -0500 Subject: [TUHS] History of exploits - request for authors In-Reply-To: <20171219201721.GA95741@accordion.employees.org> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> <20171219201721.GA95741@accordion.employees.org> Message-ID: <012401d37908$771c77d0$65556770$@ronnatalie.com> Hence the CTL-ALT-DEL log in feature of NT (and later windows). I remember when the beta NTs came out and I loaded up countless floppies to see the Windows NT "Preliminary" logo come up and then a pop up telling me to type CTL-ALT-DEL to log in. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Derek Fawcus Sent: Tuesday, December 19, 2017 3:17 PM To: The Eunuchs Hysterical Society Subject: Re: [TUHS] History of exploits - request for authors On Tue, Dec 19, 2017 at 12:08:21PM +1100, Dave Horsfall wrote: > > Leaving a "login" simulator on a terminal (quite common). Well if you include that one, you may want to include the simple brute force testing of passwords against /etc/passwd (before shadow files existed). The login name and real names (direct or reversed) would tend to get at least one hit. DF From richard at inf.ed.ac.uk Wed Dec 20 06:29:36 2017 From: richard at inf.ed.ac.uk (Richard Tobin) Date: Tue, 19 Dec 2017 20:29:36 +0000 (GMT) Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: Lars Brinkhoff's message of Tue, 19 Dec 2017 20:08:58 +0000 Message-ID: <20171219202936.795A71874077@macaroni.inf.ed.ac.uk> > > In fact, I don't recall being aware of the existence of the ITS > > movement at the time Unix arose. > Was there ever a movement? It was just four machines at MIT. When AT&T sued BSD Inc over (among other things) the phone number 1-800-ITS-UNIX, the joke was that MIT should have sued them too. -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From doug at cs.dartmouth.edu Wed Dec 20 08:26:41 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 19 Dec 2017 17:26:41 -0500 Subject: [TUHS] pre-UNIX legacy in UNIX? In-Reply-To: <7wd13aa3ad.fsf@junk.nocrew.org> References: <201712191848.vBJImVwD028248@coolidge.cs.Dartmouth.EDU> <7wd13aa3ad.fsf@junk.nocrew.org> Message-ID: <201712192226.vBJMQfVg029760@coolidge.cs.Dartmouth.EDU> >> In fact, I don't recall being aware of the existence of the ITS >> movement at the time Unix arose. >Was there ever a movement? It was just four machines at MIT. I struggled over the word when I wrote it. ITS has been described as some kind of pushback against the big (and ostensibly commerce- oriented) Multics project. I still haven't though of a word with really appropriate connotations. Doug From random832 at fastmail.com Wed Dec 20 08:30:35 2017 From: random832 at fastmail.com (Random832) Date: Tue, 19 Dec 2017 17:30:35 -0500 Subject: [TUHS] History of passwd fullname/info/"gecos" field (was Re: pre-UNIX legacy in UNIX?) In-Reply-To: References: Message-ID: <1513722635.2334092.1210504848.09B5B6C0@webmail.messagingengine.com> On Tue, Dec 19, 2017, at 13:21, Grant Taylor via TUHS wrote: > Now I wonder if we are using the GECOS field to store the same data as > years ago? Or did we re-purpose the now unneeded GECOS to store name, > address, office phone number, home phone, etc? The V6 and V7 passwd manpage says "GCOS job number, box number, optional GCOS user-id", and "The GCOS field is used only when communicating with that system, and in other installations can contain any desired information." (Has all information on what tools were used to communicate with it and how they consumed the passwd file been lost to history?) V3 and V4 say "GCOS job number and box number". V2 does not have the field. PWB describes the field as "comment" and says "The comment field should identify the user, e.g., name (account #)." The distributed passwd file seems to have some structure to this field, with system accounts (all of the accounts in the file except "games") beginning with a dash and having (9999) after [the use of which is unclear]. It looks like the usage to store the other things in the specific modern format originated at Berkeley - the chfn utility appears in 3BSD, with a description of this format in the manpage (which likely influenced other sites), and 4.2BSD prompts for each field individually. The format is associated with the Finger utility, which first appears in 2BSD and has the following comment in its source code: /* This is a finger program. It prints out useful information about users * by digging it up from various system files. It is not very portable * because the most useful parts of the information (the full user name, * office, and phone numbers) are all stored in the VAX-unused gecos field * of /etc/passwd, which, unfortunately, other UNIXes use for other things. AUSAM contains extensive modifications to the code around the passwd handling - it uses a binary hashtable-based passwd database, with separate first and last name fields and a "staff or student number" (referred to in code as "other"). From dave at horsfall.org Wed Dec 20 09:45:21 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 20 Dec 2017 10:45:21 +1100 (EST) Subject: [TUHS] History of exploits - request for authors In-Reply-To: <20171219201721.GA95741@accordion.employees.org> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> <20171219201721.GA95741@accordion.employees.org> Message-ID: On Tue, 19 Dec 2017, Derek Fawcus wrote: >> Leaving a "login" simulator on a terminal (quite common). > > Well if you include that one, you may want to include the simple brute > force testing of passwords against /etc/passwd (before shadow files > existed). The login name and real names (direct or reversed) would tend > to get at least one hit. Too easy :-) Re the simulator, a former boss suggested (when these things were rife) that the BEL character could only be outputted by "root", and if you didn't hear "ding", well... I (and likely others) worked around them by deliberating typing a wrong password (the kiddies were rarely smart enough to loop a couple of times or to test it), and I was glad when I started working there and had my own terminal (OK, a shared one in our office). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From cym224 at gmail.com Wed Dec 20 10:01:50 2017 From: cym224 at gmail.com (Nemo) Date: Tue, 19 Dec 2017 19:01:50 -0500 Subject: [TUHS] History of exploits - request for authors In-Reply-To: <20171219012525.GB11683@mcvoy.com> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> <20171219012525.GB11683@mcvoy.com> Message-ID: On 18/12/2017, Larry McVoy wrote (in part): [...] > https://www.linux.com/news/linux-kernel-development-process-thwarts-subversion-attempt > > I take umbrage at the reporting there, they said it was many eyes (the open > source mantra) that found it, that's bullshit, it was my eyes that found it. Yea, many eyes simply just glaze over. (OT but remember Feynman and the school texts.) N. From jnc at mercury.lcs.mit.edu Wed Dec 20 11:03:21 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 19 Dec 2017 20:03:21 -0500 (EST) Subject: [TUHS] pre-UNIX legacy in UNIX? Message-ID: <20171220010321.7D5E718C094@mercury.lcs.mit.edu> > From: Doug McIlroy > In fact, I don't recall being aware of the existence of the ITS > movement at the time Unix arose. For background, here are a few selected timeline items: ?/1967 ITS design starts 7/67 ITS first becomes operational 12/67 Multics single process boot on 645 10/68 Initial Multics milestone (8 users) 01/69 Limited Initial Multics milestone (12 users) 04/69 Bell Labs drops out of Multics (I included the latter since I'm assuming the "time Unix arose" is after the Bell Labs departure.) Note: I'm not saying or implying anything about the 3 systems with this; this is purely data. Noel From dave at horsfall.org Wed Dec 20 12:22:39 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 20 Dec 2017 13:22:39 +1100 (EST) Subject: [TUHS] History of exploits - request for authors In-Reply-To: <012401d37908$771c77d0$65556770$@ronnatalie.com> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> <20171219201721.GA95741@accordion.employees.org> <012401d37908$771c77d0$65556770$@ronnatalie.com> Message-ID: On Tue, 19 Dec 2017, Ron Natalie wrote: > Hence the CTL-ALT-DEL log in feature of NT (and later windows). I > remember when the beta NTs came out and I loaded up countless floppies > to see the Windows NT "Preliminary" logo come up and then a pop up > telling me to type CTL-ALT-DEL to log in. First time I had to use NT at work (our little company got taken over by them and they chucked our Xterms out) I commented "Wow; it comes with its own Blue Screen of Death!" - I didn't make many friends amongst the M$ lusers there. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From noel.hunt at gmail.com Wed Dec 20 13:07:46 2017 From: noel.hunt at gmail.com (Noel Hunt) Date: Wed, 20 Dec 2017 14:07:46 +1100 Subject: [TUHS] History of passwd fullname/info/"gecos" field (was Re: pre-UNIX legacy in UNIX?) In-Reply-To: <1513722635.2334092.1210504848.09B5B6C0@webmail.messagingengine.com> References: <1513722635.2334092.1210504848.09B5B6C0@webmail.messagingengine.com> Message-ID: On Wed, Dec 20, 2017 at 9:30 AM, Random832 wrote: > AUSAM contains extensive modifications to the code around the passwd > handling - it uses a binary hashtable-based passwd database, with separate > first and last name fields and a "staff or student number" (referred to in > code as "other"). > ​And I have a dim memory that when we started using Eight Edition (at Basser) the password file was a mounted process.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wobblygong at gmail.com Wed Dec 20 18:25:22 2017 From: wobblygong at gmail.com (Wesley Parish) Date: Wed, 20 Dec 2017 21:25:22 +1300 Subject: [TUHS] Various Unix In-Reply-To: <20171219171345.59efbf33@cnb.csic.es> References: <20171219171345.59efbf33@cnb.csic.es> Message-ID: I've just dropped in to the QNX Foundry27 FAQ page: https://community.qnx.com/sf/wiki/do/viewPage/projects.community/wiki/FAQ " I want to access the source code, how can I?# QSS classifies proprietary QNX source code as either Open (available to anyone under an open source license), Accessible (available to registered users on the QNX Source project), or Restricted (please contact your QSS Sales or Support contact to request access). Source code is available through the SVN Web interface. To do so, access the desired project, select its 'Source Code' section, select the repository, select 'View Commits', then select 'Browse Repository'. Registered members can access the Subversion repository using any Subversion client application. Such a client is offered as part of the QNX Momentics IDE. Is this open source?# Simple answer is 'no'. But the complete answer is 'sometimes' since each Foundry27 project is free to expose its technology under its sponsor's own licensing terms. As an example, some of the BSPs delivered as part of the BSPs and Drivers project are published under the terms of the Apache 2.0 license; these are clearly open source. The QSS components delivered as part of the QNX Operating System project can be considered very close to open within the QNX development community with access to Restricted code; their source is published, the binaries are available, the source code can be modified and even redistributed to other QSS licensed developers. More details are available at the Community Redistribution page at http://licensing.qnx.com/. " FWIW Wesley Parish On 12/20/17, Jose R. Valverde wrote: > Before we had to phase out our FTP server, I kept on it several > versions of UNIX clones and related OS that were mostly not on TUHS. > This post is to remember some of these systems. Many of these were > open sourced or widely available at some time and were related to UNIX > one way or another. I may not have the latest versions or all the > versions, but at least I do keep something. > > The following ones have been open sourced at some point in time (I > believe): > > ChorusOS > Coherent > EXOS > L4 > Lunix > MaRTE-OS > Mach > OpenBLT > OpenSolaris > Sprite (I also own the original distribution CD) > Trix > UniFlex > agnix > amoeba > bkunix > bsd386 > hurd > iunix > jaluna-c5 > lsx-unix > mini-unix > minix > omu > opensolaris > starunix > thix > from tliquest.net/local/unix: uzi and various other bits > tme > tropix > tunix > unix-v8 > unix-wega > uzi > xhomer > xinu > xv6 > yoctix > > Plus several archaic CDs with early versions of Linux, > Open/Free/NetBSD, (Walnut Creek, InfoMagic, etc. CD/ROMs) > and even the Beowulf/Extreme Linux CDs (plus I must keep around the > mirror we hosted for a long time of the Beowulf site). The hobbyist CDs > for OpenSolaris 8 (and I believe 9) with sources. Oh, and > MOSIX/OPENMOSIX. > > > In addition, I have many other sources whose Copyright status I'm not > aware of, but which are interesting for archival purposes. > > Regarding QNX, yes, it was open sourced (at least for hobbyist use, I > have to check the license) for several distributions. I ported some > bioinformatics software and kept for some time a distribution > repository, and I'm pretty certain I must have the sources as well as > the virtual machines. I'll try to verify the licenses to see if it can > be redistributed, although I doubt they can. Oh, and I also own the > mentioned famous 3.5" diskette. I think I digitized it long ago. Would > have to check. > > Off the Net, it has been possible, one time or another, to recover > executables and, sometime, even sources, of many systems. Archive.org > has -I believe- a copy of a once famous repo of abandonware with > binaries of SCO, System V, AIX, etc... > > I know that AIX, ATT systemV vI, II, III and IV, Solaris V6, Tru64, > OSF-1, Dynix, Ultrix 11, BSDI, Ultrix-32 etc... have been out there at > some time or another in source code format, and binaries of IRIX, Lisa, > QNX, A/UX, xenix... > > Some years ago, I had more free time and could test many systems on > emulators, and built images and accompanying scripts ready ti run. I > also made some tools to be able to transfer data in and out of old > unix versions (so I could edit the software off the virtual machine > while back-porting a screen editor to V6, v5, etc... with only vt100 > support). > > Not UNIX-related, I also keep copies of many other ancient operating > systems and software and hardware emulators. > > > Well, as I said at the beginning, everything that I had, I should still > keep while the hard disks continue spinning. If there is any > interest in adding any of these to TUHS, I can try to find a way to > send it all. > > If I find time to browse through everything, I would like to upload all > the source code to GitHub (at least anything that's redistributable). > If I find the time... > > But, Warren, if you are interested in anything, let me know and I'll > find a way to give you access. > > j > > -- > Scientific Computing Service > Solving all your computer needs for Scientific > Research. > > http://bioportal.cnb.csic.es > From wlc at jctaylor.com Fri Dec 22 08:12:33 2017 From: wlc at jctaylor.com (William Corcoran) Date: Thu, 21 Dec 2017 22:12:33 +0000 Subject: [TUHS] SYSTEM V R1 HELP Message-ID: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran From clemc at ccc.com Fri Dec 22 08:30:50 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 21 Dec 2017 17:30:50 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> Message-ID: Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying. Also see what value errno is, hopefully it has not been lost. Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned. See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel. Could you be running out of open files, maybe. Another thing to try, is: cd / find . -print ​ > /tmp/file.lst cpio -ocvB > /dev/null ​ < /tmp/file.lst See if that changes anything. It should remove some of pressure on the kernel tables. ​Clem​ ​ ᐧ On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran wrote: > Hello Team TUHS: > > I am having a problem with my PDP-11 SVR1 running under a recent SIMH > build. My problem occurs on both MAC OS X and FreeBSD. > > First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with > swap placed on drive 1. The system behaves beautifully as FSCK reports > clean. Eight users can login with no problem. > > Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no > DZ and booted the default kernel (gdtm) and I see the same problem > described below. > > Third, when using the tape driver instead of /dev/null i get the same > results. > > Next, here is the issue: > > cd / > find . -print | cpio -ocvB > /dev/null > > It runs for a short while and then shitz a core: > I am using /dev/null to take the tape driver out of the equation. > > Here is the backtrace for cpio: > > $c > __strout(053522,043,0,053012) > __doprnt(046652,0177606,053012) > _fprintf(053012,046652,053522) > ~main(02,0177636) > > > Now, interestingly, I run into a similar issue when using tar: > > cd /usr > tar -cvf /dev/null . > > Again, this will run for a while, then drops a core. Here is the > backtrace for tar: > > $c > __strout(043123,02,0,045506) > __doprnt(043123,0167472,045506) > _fprintf(045506,043123,0170600) > ~putfile(0170600,0170641) > ~putfile(0171654,0171704) > ~putfile(0172730,0172745) > ~putfile(0174004,0174016) > ~putfile(0175060,0175066) > ~putfile(0176134,0176136) > ~putfile(0177672,0177672) > ~dorep(0177632) > ~main(04,0177630) > > This really bugging me since my SVR1 is otherwise working flawlessly. I > was able to remake the entire system and custom kernels that boot with no > problem. > Also, I configured my main port to run inside the AWS Lightsail and now I > have access to SVR1 from anywhere in the world! > > I was also wondering if doing a CPIO or TAR on the entire system was > overflowing some link tables and maybe this is expected behavior for the > minimal resource of the PDP-11? > > Thank you for any help. > > Would you expect tar or cpio to dump core if you attempted to copy large > filesystems (or the entire system) on a PDP-11? > Note: All of my testing has been in single user mode. > > > Truly, > > Bill Corcoran > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlc at jctaylor.com Fri Dec 22 10:34:26 2017 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 22 Dec 2017 00:34:26 +0000 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> Message-ID: <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> Hello Clem, Well, I have some interesting results. First, your comments about fprintf made me think about turning off the output. So: cd / find . -print | cpio -ocB > /dev/null Works perfectly, the return code is a nice clean 0—No more core dump! However, when I enable the verbose option to cpio, it dumps core. Next, it dumps core using your example below. However, if I remove the verbose option, cpio completes without error!!! Next, I got a super weird result when I try to print the error code: find . -print | cpio -ocvB > /dev/null files are displayed…. Memory Fault: core dumped echo $? 1003 Now, I thought all return values were 8 bit? What is that all about? I just wanted to pass along the update. I will see if I can follow the string pointers in fprintf. Truly, Bill Corcoran On Dec 21, 2017, at 5:30 PM, Clem Cole wrote: Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying. Also see what value errno is, hopefully it has not been lost. Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned. See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel. Could you be running out of open files, maybe. Another thing to try, is: cd / find . -print​ > /tmp/file.lst cpio -ocvB > /dev/null​ < /tmp/file.lst See if that changes anything. It should remove some of pressure on the kernel tables. ​Clem​ ​ ᐧ On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran wrote: Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran From dave at horsfall.org Fri Dec 22 10:42:40 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 22 Dec 2017 11:42:40 +1100 (EST) Subject: [TUHS] OT: Happy birthday, Tommy Flowers! Message-ID: Tommy Flowers MBE was born on this day in 1905; an electrical and mechanical engineer, he designed Colossus, arguably the world's first electronic computer, which was used to break the German "Lorenz" high-level cipher (not Enigma, as some think). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lyndon at orthanc.ca Fri Dec 22 11:43:27 2017 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Thu, 21 Dec 2017 17:43:27 -0800 Subject: [TUHS] OT: Happy birthday, Tommy Flowers! In-Reply-To: References: Message-ID: > On Dec 21, 2017, at 4:42 PM, Dave Horsfall wrote: > > Tommy Flowers MBE was born on this day in 1905; an electrical and mechanical engineer, he designed Colossus, arguably the world's first electronic computer, which was used to break the German "Lorenz" high-level cipher (not Enigma, as some think). And if you find yourself in the UK with a day to spare, by all means make the trip to Bletchley Park and see the beast (okay, a replica) live in action! I say "a day" because you need at least that to even begin to see everything there. The Colossus and Tunny working replicas are hosted in the National Museum of Computing (http://www.tnmoc.org/), located inside Bletchley Park, but not part of it per se (it's a long sad stupid story). The museum holds an amazing collection of retro computer hardware, from Kaypro-IIs to at least a couple models of (pre-SGI!) Crays. The resident grey-beards will happily demonstrate working mercury delay lines for you :-) Next time I'm there, I plan to devote at least two full days just for the museum. --lyndon From wlc at jctaylor.com Fri Dec 22 11:51:22 2017 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 22 Dec 2017 01:51:22 +0000 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> Message-ID: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> Okay, I think I am on to something… Whenever tar or cpio dumps core, it is always when 32769 bytes have been written to stdout. I looked at fprintf and there is a register int called “count.” It looks like when it overflows its clobbering a structure and then the kernel gets mad and kills the process. Is it possible this is a latent defect in SVR1 or is there something going on with SIMH? I can’t believe this is a latent defect. Thank you so much for all of your help TEAM TUHS! Much thanks to Clem’s help! Bill Corcoran On Dec 21, 2017, at 7:34 PM, William Corcoran wrote: Hello Clem, Well, I have some interesting results. First, your comments about fprintf made me think about turning off the output. So: cd / find . -print | cpio -ocB > /dev/null Works perfectly, the return code is a nice clean 0—No more core dump! However, when I enable the verbose option to cpio, it dumps core. Next, it dumps core using your example below. However, if I remove the verbose option, cpio completes without error!!! Next, I got a super weird result when I try to print the error code: find . -print | cpio -ocvB > /dev/null files are displayed…. Memory Fault: core dumped echo $? 1003 Now, I thought all return values were 8 bit? What is that all about? I just wanted to pass along the update. I will see if I can follow the string pointers in fprintf. Truly, Bill Corcoran On Dec 21, 2017, at 5:30 PM, Clem Cole wrote: Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying. Also see what value errno is, hopefully it has not been lost. Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned. See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel. Could you be running out of open files, maybe. Another thing to try, is: cd / find . -print​ > /tmp/file.lst cpio -ocvB > /dev/null​ < /tmp/file.lst See if that changes anything. It should remove some of pressure on the kernel tables. ​Clem​ ​ ᐧ On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran wrote: Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran From wlc at jctaylor.com Fri Dec 22 11:54:29 2017 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 22 Dec 2017 01:54:29 +0000 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com>, <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> Message-ID: Strike that... this is UNIX. Please forgive my offensive post. I should have said when count overflows it attempts to clobber the structure and the kernel gets mad and kills the process. Please forgive my transgression. On Dec 21, 2017, at 8:51 PM, William Corcoran > wrote: Okay, I think I am on to something… Whenever tar or cpio dumps core, it is always when 32769 bytes have been written to stdout. I looked at fprintf and there is a register int called “count.” It looks like when it overflows its clobbering a structure and then the kernel gets mad and kills the process. Is it possible this is a latent defect in SVR1 or is there something going on with SIMH? I can’t believe this is a latent defect. Thank you so much for all of your help TEAM TUHS! Much thanks to Clem’s help! Bill Corcoran On Dec 21, 2017, at 7:34 PM, William Corcoran > wrote: Hello Clem, Well, I have some interesting results. First, your comments about fprintf made me think about turning off the output. So: cd / find . -print | cpio -ocB > /dev/null Works perfectly, the return code is a nice clean 0—No more core dump! However, when I enable the verbose option to cpio, it dumps core. Next, it dumps core using your example below. However, if I remove the verbose option, cpio completes without error!!! Next, I got a super weird result when I try to print the error code: find . -print | cpio -ocvB > /dev/null files are displayed…. Memory Fault: core dumped echo $? 1003 Now, I thought all return values were 8 bit? What is that all about? I just wanted to pass along the update. I will see if I can follow the string pointers in fprintf. Truly, Bill Corcoran On Dec 21, 2017, at 5:30 PM, Clem Cole > wrote: Bill, in the debugger, for both cpio and tar, follow the string ptrs in fprintf and see if you can figure out where its dying. Also see what value errno is, hopefully it has not been lost. Neither program should be using printf except for messages to the console, so I'm guessing this is an error message trying to be output from an error the kernel returned. See if you can find the message from cpio/tar and the error code and that might give you a hint to look in the kernel. Could you be running out of open files, maybe. Another thing to try, is: cd / find . -print​ > /tmp/file.lst cpio -ocvB > /dev/null​ < /tmp/file.lst See if that changes anything. It should remove some of pressure on the kernel tables. ​Clem​ ​ ᐧ On Thu, Dec 21, 2017 at 5:12 PM, William Corcoran > wrote: Hello Team TUHS: I am having a problem with my PDP-11 SVR1 running under a recent SIMH build. My problem occurs on both MAC OS X and FreeBSD. First, I created a six disk (RP06) and eight port TTY (DZ) kernel, with swap placed on drive 1. The system behaves beautifully as FSCK reports clean. Eight users can login with no problem. Second, I reverted to a pristine PDP-11 SVR1 with one drive (RP06) and no DZ and booted the default kernel (gdtm) and I see the same problem described below. Third, when using the tape driver instead of /dev/null i get the same results. Next, here is the issue: cd / find . -print | cpio -ocvB > /dev/null It runs for a short while and then shitz a core: I am using /dev/null to take the tape driver out of the equation. Here is the backtrace for cpio: $c __strout(053522,043,0,053012) __doprnt(046652,0177606,053012) _fprintf(053012,046652,053522) ~main(02,0177636) Now, interestingly, I run into a similar issue when using tar: cd /usr tar -cvf /dev/null . Again, this will run for a while, then drops a core. Here is the backtrace for tar: $c __strout(043123,02,0,045506) __doprnt(043123,0167472,045506) _fprintf(045506,043123,0170600) ~putfile(0170600,0170641) ~putfile(0171654,0171704) ~putfile(0172730,0172745) ~putfile(0174004,0174016) ~putfile(0175060,0175066) ~putfile(0176134,0176136) ~putfile(0177672,0177672) ~dorep(0177632) ~main(04,0177630) This really bugging me since my SVR1 is otherwise working flawlessly. I was able to remake the entire system and custom kernels that boot with no problem. Also, I configured my main port to run inside the AWS Lightsail and now I have access to SVR1 from anywhere in the world! I was also wondering if doing a CPIO or TAR on the entire system was overflowing some link tables and maybe this is expected behavior for the minimal resource of the PDP-11? Thank you for any help. Would you expect tar or cpio to dump core if you attempted to copy large filesystems (or the entire system) on a PDP-11? Note: All of my testing has been in single user mode. Truly, Bill Corcoran -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Fri Dec 22 11:55:09 2017 From: random832 at fastmail.com (Random832) Date: Thu, 21 Dec 2017 20:55:09 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> Message-ID: <1513907709.986360.1212983624.321F957E@webmail.messagingengine.com> On Thu, Dec 21, 2017, at 19:34, William Corcoran wrote: > echo $? > > 1003 > > Now, I thought all return values were 8 bit? What is that all about? In the Bourne shell, when a process exits a signal, $? is set to sig|SIGFLG, which is, for some unknown reason, defined to 1000 (Yes, as in 0x3E8. As in 1000|11 == 1000|3 == 1003) - a value that no other version before or since SVR1 (at least not SysIII or SVR4) seems to have - every other one I checked has 0200. I can only guess that the reason is to make it easier to read the signal number, and whoever it is only tested with SIGINT and SIGQUIT or they would have presumably changed it to sig+SIGFLG. Then at some point before a later SysV release, it was reverted to 0200. POSIX for its part only guarantees a value above 128, not any particular value or distinct values per signal. From random832 at fastmail.com Fri Dec 22 12:55:14 2017 From: random832 at fastmail.com (Random832) Date: Thu, 21 Dec 2017 21:55:14 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> Message-ID: <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> On Thu, Dec 21, 2017, at 20:51, William Corcoran wrote: > Okay, I think I am on to something… > > Whenever tar or cpio dumps core, it is always when 32769 bytes have been > written to stdout. Is that 32769 bytes to the tape (which is not stdout in your tar invocation), or 32769 bytes of printed output? Is it exactly 32769, or just some value above 32768 by some small amount? > I looked at fprintf and there is a register int called “count.” Your crash is in _strout, two calls deep before that variable is written since the adjust parameter is 0, the only thing of note in _strout is a putc loop. putc is a macro so it won't appear in the stack trace - that _flsbuf does not appear in the stack trace means this is happening in the 'ordinary' buffered I/O case. Strange, though, I can't see anything inside putc/flsbuf that seems like anything should be any different on the 32770th character than the 514th or 1026th. What are the strings being printed? (second argument to printf, and first argument to strout)? From wlc at jctaylor.com Fri Dec 22 13:47:01 2017 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 22 Dec 2017 03:47:01 +0000 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> Message-ID: <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> Hello Random832, Yes, I make a mistake, the issue is with STDERR. The pipeline: find . -print | cpio -ocvB >/dev/null 2>/tmp/ERRFILE will drop core: ERRFILE will have exactly 32769 bytes (no more and no less). STDOUT is redirected to /dev/null and there is no problem with STDOUT. For example: find . -print | cpio -ocB > /dev/null Succeeds because nothing (or close to nothing) is written to STDERR before cpio successfully terminates. STDOUT is fine and CPIO and tar can write thousands of blocks cleanly on STDOUT. Normally, as you know, STDOUT would be redirected to the tape device and not /dev/null. Here is my take: This may be a latent defect in that early releases may not have realized the very large amounts of data that can be written to STDERR. In this case, each file that is backed up with cpio is represented as a single line in STDERR. When STDERR exceeds 32768 bytes, it blows up. fprintf returns an int that is the number of bytes in the stream. For some reason, when this overflows, it is not wrapping around, instead it causes a segmentation violation. Could the issue be with fprintf or doprnt.c? I thought STDERR was unbuffered? Please forgive me. Thank you for all of your help. On Dec 21, 2017, at 9:55 PM, Random832 wrote: On Thu, Dec 21, 2017, at 20:51, William Corcoran wrote: > Okay, I think I am on to something… > > Whenever tar or cpio dumps core, it is always when 32769 bytes have been > written to stdout. Is that 32769 bytes to the tape (which is not stdout in your tar invocation), or 32769 bytes of printed output? Is it exactly 32769, or just some value above 32768 by some small amount? > I looked at fprintf and there is a register int called “count.” Your crash is in _strout, two calls deep before that variable is written since the adjust parameter is 0, the only thing of note in _strout is a putc loop. putc is a macro so it won't appear in the stack trace - that _flsbuf does not appear in the stack trace means this is happening in the 'ordinary' buffered I/O case. Strange, though, I can't see anything inside putc/flsbuf that seems like anything should be any different on the 32770th character than the 514th or 1026th. What are the strings being printed? (second argument to printf, and first argument to strout)? From jnc at mercury.lcs.mit.edu Fri Dec 22 17:03:34 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 22 Dec 2017 02:03:34 -0500 (EST) Subject: [TUHS] OT: Happy birthday, Tommy Flowers! Message-ID: <20171222070334.C263F18C08B@mercury.lcs.mit.edu> > From: Dave Horsfall > Colossus, arguably the world's first electronic computer Well, it all depends on your definition of "computer"... :-) I myself prefer to reserve that term for things that are programmable, and Turing-complete. (YMMV... :-) So I call things like Colossus and ABC "digital electronic calculating devices" (or something similar). None of which is to take anything away from the incredible job done by Flowers and his cohorts. It was an amazing device, and had a major effect on history. Noel From random832 at fastmail.com Fri Dec 22 19:09:49 2017 From: random832 at fastmail.com (Random832) Date: Fri, 22 Dec 2017 04:09:49 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> Message-ID: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote: > Could the issue be with fprintf or doprnt.c? > > I thought STDERR was unbuffered? Please forgive me. I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered. #define putc(x, p) (--(p)->_cnt >= 0 ? \ ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ _flsbuf((unsigned char) (x), (p))) Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf. However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered. You'll want to add iop->cnt = 0 to the second if clause in _flsbuf. From wlc at jctaylor.com Fri Dec 22 22:42:36 2017 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 22 Dec 2017 12:42:36 +0000 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com>, <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> Message-ID: <14180643-33A4-49E4-B866-C34ACB8ED773@jctaylor.com> Brilliant Random832! Very impressive! Thank you for the early Christmas present! Your initial analysis was equally spot on when you interpreted the backtrace. This is very much appreciated! Truly, Bill Corcoran On Dec 22, 2017, at 4:09 AM, Random832 > wrote: On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote: Could the issue be with fprintf or doprnt.c? I thought STDERR was unbuffered? Please forgive me. I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered. #define putc(x, p) (--(p)->_cnt >= 0 ? \ ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ _flsbuf((unsigned char) (x), (p))) Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf. However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered. You'll want to add iop->cnt = 0 to the second if clause in _flsbuf. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Dec 23 01:04:56 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 22 Dec 2017 10:04:56 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> Message-ID: On Thu, Dec 21, 2017 at 8:51 PM, William Corcoran wrote: > > > I can’t believe this is a latent defect. > ​Oh I can... SVR1 was not run on 16 bit machines that much I suspect. By the time SVR1 came on the scene, the VAX and ​ ​68K were the primary UNIX systems. AT&T was pushing the 3B but except for the Telco's not getting much luck. ​I'd look at the C runtime library. I bet there is a overflow. IIRC: The BSD compiler (and Research) compilers used a different buffering scheme​ ​ ​ that the Summit folks did - Steve may remember the argument (I only remember because I ran into that squirmish a few years early when the my thesis work was causing an strange error in the BSD runtime - I found and fixed it and mentioned it to Dennis who had the same problem in the V8 compiler at that time). The point is that 'standard' system in Summit by this time was likely to been a 3B and Vaxen (i.e. 32 bit) and if there was something that was assuming a 32 bit int in the runtime and it ran on PDP-11, it could easily have not been tested. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wlc at jctaylor.com Sat Dec 23 09:48:01 2017 From: wlc at jctaylor.com (William Corcoran) Date: Fri, 22 Dec 2017 23:48:01 +0000 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> Message-ID: <11175FE5-A345-43D3-A2DF-811CE18E7230@jctaylor.com> Hello Team TUHS: This note confirms that Random832’s System V Release 1 fix for CPIO and TAR core dump works PERFECTLY!!! iop->_cnt=0; Truly, Bill Corcoran On Dec 22, 2017, at 4:09 AM, Random832 wrote: On Thu, Dec 21, 2017, at 22:47, William Corcoran wrote: > Could the issue be with fprintf or doprnt.c? > > I thought STDERR was unbuffered? Please forgive me. I've got it. The problem is with putc (actually _flsbuf), and it is precisely *because* stderr is unbuffered. #define putc(x, p) (--(p)->_cnt >= 0 ? \ ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ _flsbuf((unsigned char) (x), (p))) Under normal circumstances for an unbuffered (or line-buffered) stream, _cnt starts as 0, and therefore every character is passed through _flsbuf. However, _cnt is still decremented (becoming -1, -2, etc) - _flsbuf should be resetting this to zero (and does in other versions, both earlier and later), but we can see in flsbuf.c it does not. So, after 32769 characters have been output it ticks from -32768 to +32767, and putc now thinks the stream is buffered. You'll want to add iop->cnt = 0 to the second if clause in _flsbuf. From dave at horsfall.org Sat Dec 23 10:19:30 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 23 Dec 2017 11:19:30 +1100 (EST) Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> Message-ID: On Fri, 22 Dec 2017, Random832 wrote: > I've got it. The problem is with putc (actually _flsbuf), and it is > precisely *because* stderr is unbuffered. > > #define putc(x, p) (--(p)->_cnt >= 0 ? \ > ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ > _flsbuf((unsigned char) (x), (p))) [...] That, sir, is one brilliant piece of analysis; well done! Of course, in hindsight it's bleedin' obvious :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From lm at mcvoy.com Sat Dec 23 10:21:46 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 22 Dec 2017 16:21:46 -0800 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> Message-ID: <20171223002146.GS17720@mcvoy.com> On Sat, Dec 23, 2017 at 11:19:30AM +1100, Dave Horsfall wrote: > On Fri, 22 Dec 2017, Random832 wrote: > > >I've got it. The problem is with putc (actually _flsbuf), and it is > >precisely *because* stderr is unbuffered. > > > >#define putc(x, p) (--(p)->_cnt >= 0 ? \ > > ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ > > _flsbuf((unsigned char) (x), (p))) > > [...] > > That, sir, is one brilliant piece of analysis; well done! Of course, in > hindsight it's bleedin' obvious :-) I'm curious as to which release of System V fixed this. The SVR4 was the release that gained (some) traction, was it busted until then? From clemc at ccc.com Sat Dec 23 22:26:58 2017 From: clemc at ccc.com (Clem cole) Date: Sat, 23 Dec 2017 07:26:58 -0500 Subject: [TUHS] SYSTEM V R1 HELP In-Reply-To: <20171223002146.GS17720@mcvoy.com> References: <8157BC46-2833-48D5-B224-B9E488A4B8F0@jctaylor.com> <95F61863-C025-469A-9577-D2F8E75A813A@jctaylor.com> <77B078BE-E3CD-4AFF-93B4-20AF4C8664FD@jctaylor.com> <1513911314.999748.1213050656.486E2E9E@webmail.messagingengine.com> <8C7D7E48-C9E5-4F75-A76F-3E9D7F651A6F@jctaylor.com> <1513933789.1081623.1213240800.50A34AF0@webmail.messagingengine.com> <20171223002146.GS17720@mcvoy.com> Message-ID: <49F79F9D-9E03-40C9-9973-14D4A3069257@ccc.com> V1. Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. > On Dec 22, 2017, at 7:21 PM, Larry McVoy wrote: > >> On Sat, Dec 23, 2017 at 11:19:30AM +1100, Dave Horsfall wrote: >>> On Fri, 22 Dec 2017, Random832 wrote: >>> >>> I've got it. The problem is with putc (actually _flsbuf), and it is >>> precisely *because* stderr is unbuffered. >>> >>> #define putc(x, p) (--(p)->_cnt >= 0 ? \ >>> ((int) (*(p)->_ptr++ = (unsigned char) (x))) : \ >>> _flsbuf((unsigned char) (x), (p))) >> >> [...] >> >> That, sir, is one brilliant piece of analysis; well done! Of course, in >> hindsight it's bleedin' obvious :-) > > I'm curious as to which release of System V fixed this. The SVR4 was the > release that gained (some) traction, was it busted until then? From krewat at kilonet.net Sun Dec 24 03:44:35 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Sat, 23 Dec 2017 12:44:35 -0500 Subject: [TUHS] Old tar bug in SVR4.2 was: SYSTEM V R1 HELP Message-ID: <7c41dbcc-ab26-8dcf-a1c1-716e24ee8a88@kilonet.net> Somewhat tangentially related to the other thread... So, back in the days when I was using Consensys SVR4.2, I found a bug in tar. It goes like this: If there is a symbolic link in the tree that you are taring, the first one works fine. If a second symbolic link has a shorter destination name than the first, the extra characters from the first symbolic link destination are appended to the end of the second. So for example: a -> abcdef b -> zyx Tar will actually tar these symbolic links as: a -> abcdef b -> zyxdef Being that I happen to have found, on the Internet, the sources to AT&T SVR4.2, and some other System V variants, I went and investigated. The relevant piece from AT&T SVR4.2 tar.c (broken): Jan 25  1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c         case S_IFLNK:                                 i = readlink(shortname, filetmp, NAMSIZ - 1);                 if (i < 0) {                         vperror(0, "can't read symbolic link %s", longname);                         return;                 } From USL-4.2 (apparently fixed): Jan 22  1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c         case S_IFLNK:                                 i = readlink(shortname, filetmp, NAMSIZ - 1);                 if (i < 0) {                         vperror(0, ":462:Cannot read symbolic link %s", longname);                         return;                 }                 else                         filetmp[i] = '\0';   /* since readlink does not supply a '\0' */ From Solaris 2.5:         case S_IFLNK:                                 i = readlink(shortname, filetmp, NAMSIZ - 1);                 if (i < 0) {                         vperror(0, gettext(                         "can't read symbolic link %s"), longname);                         if (aclp != NULL)                                 free(aclp);                         return;                 } else {                         filetmp[i] = 0;                 } BSD 4.4:         case S_IFLNK:                                 i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1);                 if (i < 0) {                         fprintf(stderr,                             "tar: can't read symbolic link %s: %s\n",                             longname, strerror(errno));                         return;                 }                 dblock.dbuf.linkname[i] = '\0'; Anyone know when/why/how tar diverged between the two branches? Note the readlink directly into dblock.dbuf, while the SVR4 variants use a temp string and then sprintf it in later. From: http://www.catb.org/esr/faqs/usl-bugs.txt 17. tar(1) fails to restore adjacent symbolic links properly Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports: SVR4 tar has another strange bug. Seems if when restoring files, you restore one file that is a link, say "a ->/a/b/c/d/e" and there is another link just after it called "b ->/a/b/c" tar will restore it as "b ->/a/b/c/d/e" This just seems to be a lack of the NULL at the end of the string, like someone did a memmov or memcpy(dest,src,strlen(src)); where it should be strlen(src)+1 to include the NULL. Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed. From dave at horsfall.org Tue Dec 26 09:58:47 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 26 Dec 2017 10:58:47 +1100 (EST) Subject: [TUHS] Happy birthday, Charles Babbage! Message-ID: Charles Babbage KH FRS was born on this day in 1791; pretty much the father of the computer, a model of his "difference engine" built to the standards of the day worked, complete with its printer. What is not so well known about him was that he dabbled in cryptography, and broke the Vigenère cipher; unfortunately for him it was classified as a military secret, so one Friedrich Kasiski got the credit instead. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From itz at very.loosely.org Tue Dec 26 10:21:29 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Mon, 25 Dec 2017 16:21:29 -0800 Subject: [TUHS] Happy birthday, Charles Babbage! In-Reply-To: References: Message-ID: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com> On 2017-12-26 10:58, Dave Horsfall wrote: > Charles Babbage KH FRS was born on this day in 1791 Did 20th century pioneers such as von Neumann and Zuse know about Babbage? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From dave at horsfall.org Tue Dec 26 13:01:04 2017 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 26 Dec 2017 14:01:04 +1100 (EST) Subject: [TUHS] Happy birthday, Charles Babbage! In-Reply-To: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com> References: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com> Message-ID: >> Charles Babbage KH FRS was born on this day in 1791 > > Did 20th century pioneers such as von Neumann and Zuse know about > Babbage? Probably; I have no idea. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From otto at drijf.net Tue Dec 26 18:55:48 2017 From: otto at drijf.net (Otto Moerbeek) Date: Tue, 26 Dec 2017 09:55:48 +0100 Subject: [TUHS] Happy birthday, Charles Babbage! In-Reply-To: References: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com> Message-ID: <20171226085548.GW5554@colo.drijf.net> On Tue, Dec 26, 2017 at 02:01:04PM +1100, Dave Horsfall wrote: > > > Charles Babbage KH FRS was born on this day in 1791 > > > > Did 20th century pioneers such as von Neumann and Zuse know about > > Babbage? > > Probably; I have no idea. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." This gives some hints: https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann -Otto From toby at telegraphics.com.au Wed Dec 27 04:49:44 2017 From: toby at telegraphics.com.au (Toby Thain) Date: Tue, 26 Dec 2017 13:49:44 -0500 Subject: [TUHS] Scanned: Xenix Abstract (1982) Message-ID: <3cf05eac-81a4-e573-bb68-25e29d7dc1ed@telegraphics.com.au> Hi, Found this in a box of papers... Scanned it in yesterday. Posting in case it's of list interest: https://docs.telegraphics.com.au/Microsoft_The%20Xenix%20Operating%20System_Abstract_January%204,%201982.tif An OCR'd PDF version will eventually appear here: http://chiclassiccomp.org/docs/index.php?dir=%2Fcomputing/Microsoft (but it's not there yet). --Toby From dave at horsfall.org Wed Dec 27 08:46:36 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 27 Dec 2017 09:46:36 +1100 (EST) Subject: [TUHS] Happy birthday, Charles Babbage! In-Reply-To: <20171226085548.GW5554@colo.drijf.net> References: <20171226002129.fsr3snxqzvn5hpc3@matica.foolinux.mooo.com> <20171226085548.GW5554@colo.drijf.net> Message-ID: On Tue, 26 Dec 2017, Otto Moerbeek wrote: [ Whether von Neumann knew of Babbage ] > https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann Fascinating; thanks! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From alec.muffett at gmail.com Thu Dec 28 07:02:11 2017 From: alec.muffett at gmail.com (Alec Muffett) Date: Wed, 27 Dec 2017 21:02:11 +0000 Subject: [TUHS] Why did PDPs become so popular? Message-ID: I apologise if this is too far from the main topic, but I wanted to check an urban legend. There is a story - as I have heard it told - that PDPs established their place (and popularity) in the marketplace by pointedly *not* advertising themselves as "computers", but instead as "programmed data processors". This was because - so the story goes - that everyone in corporations of the time simply *knew* that "computers" came only from IBM, lived in big datacentres, had million-dollar price-tags, and required extensive project management to purchase; whereas nobody cared enough about a thing called a "programmed data processor" to bother bikeshedding the few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an inevitable death. Thus, they flitted under the purchasing radar, and sold like hotcakes. I wonder: does this story have substance, please? Aside from anything else: I draw parallels to the adoption of Linux by Wall St, and the subsequent adoption of virtualisation / AWS by business - now reflected in companies explaining to ISO27001 auditors that "well, we don't actually possess any physical servers..." - alec -- http://dropsafe.crypticide.com/aboutalecm -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtaylor at tnetconsulting.net Thu Dec 28 07:50:23 2017 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Wed, 27 Dec 2017 14:50:23 -0700 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: Message-ID: <81a768c0-a8c6-6e4a-5c60-1526614ea851@spamtrap.tnetconsulting.net> On 12/27/2017 02:02 PM, Alec Muffett wrote: > There is a story - as I have heard it told - that PDPs established their > place (and popularity) in the marketplace by pointedly *not* advertising > themselves as "computers", but instead as "programmed data processors". That jives with what I understand as well. > This was because - so the story goes - that everyone in corporations of > the time simply *knew* that "computers" came only from IBM, lived in big > datacentres, had million-dollar price-tags, and required extensive > project management to purchase; whereas nobody cared enough about a > thing called a "programmed data processor" to bother bikeshedding the > few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an > inevitable death. Thus, they flitted under the purchasing radar, and > sold like hotcakes. I don't agree with "…only came from IBM…". Please point your web browser to your preferred search engine and ask it for Snow White and the Seven Dwarfs as it relates to the computer industry. It's my (mis?)understanding that PDPs had a significant advantage that they came in with a significantly lower price tag which allowed them to get through finance / bursar office with less scrutiny. > I wonder: does this story have substance, please? It mostly jive with what I've heard / read a number of places. Further, I'm not aware of any stories countermanding it. > Aside from anything else: I draw parallels to the adoption of Linux by > Wall St, and the subsequent adoption of virtualisation / AWS by business I don't know that I agree with that assessment. - Though as sure as I say that, what I start typing sort of parallels it. I think Linux broke into traditionally non-Unix shops as play things on old retired machines. Then as time moved on and things evolved, Linux started doing more to carry less-critical production load. More time passes with more evolution and Linux often picks up a non-trivial portion of the production work load from non-Linux systems. The other similar thing that I have seen, and think I will see more of, is that people play with Linux at home, learn some things, and realize that it can do things at work too. In which case it will likely more overtly take on production loads more directly. As for virtualization, I think that's evolution and people trying to avoid physical server sprawl. I think AWS (et al) are simply additional forms of virtualization. > now reflected in companies explaining to ISO27001 auditors that "well, > we don't actually possess any physical servers..." Okay. How does (the lack of) physical servers actually impact ISO 27001 compliance? - From my read of the Wikipedia article I don't see how (the lack of) physical on premise servers changes anything. I feel like ISO 27001 is more a business plan / policy / procedure type check than a technical to-do list. As such, I feel like such plans / policies / procedures would still apply to the infrastructure that people are using, be it physical on prem or virtual in the cloud. Someone still owns the equipment and is responsible for it. Further, businesses outsourcing to the cloud still have a responsibility to ensure that said infrastructure is secured / updated / managed to the same standards. Granted, virtual ~> AWS does make it a LOT simpler for people to start projects and do things that may be against company policy. But that's a matter of initial economics. For the project to continue, it will need to fall back in line with stated policies, be it physical on prem or virtual in the cloud. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From clemc at ccc.com Thu Dec 28 07:51:54 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 27 Dec 2017 16:51:54 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: Message-ID: You are mixing a couple of different stories I fear... If you want the full story get a copy of: Computer Engineering: A DEC View of Hardware Systems Design But a snap shot for this mailing list is this ... The PDP term was used by KO when he was funding Digital because the VC's the 60s did not believe that a computer company would succeed. But making things for the instrumentation market (Lincoln Labs, Livermore, *etc*.). This is how PDP-1 came to be. The PDP term was keep for the first 25 years (until the Vax and renaming of the PDP-10/PDP-20 to DECSystem 10/20). [The 1 begat the 6, 9, 15 an 10 families]. The concept of purchasing smaller system, was indeed true. This was the idea behind the >>mini-computer<< or *minimal computer* that Gordon Bell who lad left DEC temporarily to be a CMU Prof for a time began to explore. He took the idea and commercialized and the PDP-8 line was the first in that line. The 11 & 15 were full computer systems. DEC also made something called the PDP-16 'Register Transfer Modules' (RTMs) which was an attempt to make the small controller idea even more accessible, but the Intel microprocessor would eclipse them (I think I was the last group at CMU was talk a course using them. Another factoid, the predecessor to VHDL/Verilog and the like, ISPL and ISPS actually spit out 'code' for DEC RTM modules instead of gates). But the key point is that in 1975 dollars, a PDP-11/40 system that was good enough to run something like Sixth Edition of UNIX cost somewhere between $50k-$150k. This would have been much, much cheaper than say a PDP-10, or a equivilent IBM 'mainframe' size system which would have started above $1M. Clem On Wed, Dec 27, 2017 at 4:02 PM, Alec Muffett wrote: > I apologise if this is too far from the main topic, but I wanted to check > an urban legend. > > There is a story - as I have heard it told - that PDPs established their > place (and popularity) in the marketplace by pointedly *not* advertising > themselves as "computers", but instead as "programmed data processors". > > This was because - so the story goes - that everyone in corporations of > the time simply *knew* that "computers" came only from IBM, lived in big > datacentres, had million-dollar price-tags, and required extensive project > management to purchase; whereas nobody cared enough about a thing called a > "programmed data processor" to bother bikeshedding the > few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an > inevitable death. Thus, they flitted under the purchasing radar, and sold > like hotcakes. > > I wonder: does this story have substance, please? > > Aside from anything else: I draw parallels to the adoption of Linux by > Wall St, and the subsequent adoption of virtualisation / AWS by business - > now reflected in companies explaining to ISO27001 auditors that "well, we > don't actually possess any physical servers..." > > - alec > > -- > http://dropsafe.crypticide.com/aboutalecm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Dec 28 07:52:35 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 27 Dec 2017 16:52:35 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: Message-ID: Typo -- funding in the 50s -- sorry... On Wed, Dec 27, 2017 at 4:51 PM, Clem Cole wrote: > You are mixing a couple of different stories I fear... > > If you want the full story get a copy of: Computer Engineering: A DEC > View of Hardware Systems Design > > > But a snap shot for this mailing list is this ... The PDP term was used > by KO when he was funding Digital because the VC's the 60s did not believe > that a computer company would succeed. But making things for the > instrumentation market (Lincoln Labs, Livermore, *etc*.). This is how > PDP-1 came to be. The PDP term was keep for the first 25 years (until the > Vax and renaming of the PDP-10/PDP-20 to DECSystem 10/20). [The 1 begat the > 6, 9, 15 an 10 families]. > > The concept of purchasing smaller system, was indeed true. This was the > idea behind the >>mini-computer<< or *minimal computer* that Gordon Bell > who lad left DEC temporarily to be a CMU Prof for a time began to explore. > He took the idea and commercialized and the PDP-8 line was the first in > that line. The 11 & 15 were full computer systems. DEC also made > something called the PDP-16 'Register Transfer Modules' (RTMs) which was an > attempt to make the small controller idea even more accessible, but the > Intel microprocessor would eclipse them (I think I was the last group at > CMU was talk a course using them. Another factoid, the predecessor to > VHDL/Verilog and the like, ISPL and ISPS actually spit out 'code' for DEC > RTM modules instead of gates). > > But the key point is that in 1975 dollars, a PDP-11/40 system that was > good enough to run something like Sixth Edition of UNIX cost somewhere > between $50k-$150k. This would have been much, much cheaper than say a > PDP-10, or a equivilent IBM 'mainframe' size system which would have > started above $1M. > > Clem > > On Wed, Dec 27, 2017 at 4:02 PM, Alec Muffett > wrote: > >> I apologise if this is too far from the main topic, but I wanted to check >> an urban legend. >> >> There is a story - as I have heard it told - that PDPs established their >> place (and popularity) in the marketplace by pointedly *not* advertising >> themselves as "computers", but instead as "programmed data processors". >> >> This was because - so the story goes - that everyone in corporations of >> the time simply *knew* that "computers" came only from IBM, lived in big >> datacentres, had million-dollar price-tags, and required extensive project >> management to purchase; whereas nobody cared enough about a thing called a >> "programmed data processor" to bother bikeshedding the >> few-tens-or-hundreds-of-thousands-of-dollars purchase proposal to an >> inevitable death. Thus, they flitted under the purchasing radar, and sold >> like hotcakes. >> >> I wonder: does this story have substance, please? >> >> Aside from anything else: I draw parallels to the adoption of Linux by >> Wall St, and the subsequent adoption of virtualisation / AWS by business - >> now reflected in companies explaining to ISO27001 auditors that "well, we >> don't actually possess any physical servers..." >> >> - alec >> >> -- >> http://dropsafe.crypticide.com/aboutalecm >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Thu Dec 28 08:10:56 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 28 Dec 2017 09:10:56 +1100 (EST) Subject: [TUHS] Happy birthday, John von Neumann! Message-ID: We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human... As computer science goes, he's right up there with Alan Turing. There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann . -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From deritchie at yahoo.com Thu Dec 28 08:25:35 2017 From: deritchie at yahoo.com (Dave Ritchie) Date: Wed, 27 Dec 2017 22:25:35 +0000 (UTC) Subject: [TUHS] Why did PDPs become so popular? References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> Message-ID: <109152082.5216233.1514413535270@mail.yahoo.com> I think that steep educational discounts and equipment grants from Digital to major collages also had a major impact,as did the existence of DECUS that made a lot of software readily available. Best regards, David Ritchie -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Dec 28 08:26:19 2017 From: cym224 at gmail.com (Nemo Nusquam) Date: Wed, 27 Dec 2017 17:26:19 -0500 Subject: [TUHS] Happy birthday, John von Neumann! In-Reply-To: References: Message-ID: <58e32359-5c52-edad-e429-de21227183ef@gmail.com> On 12/27/17 17:10, Dave Horsfall wrote: > We gained John von Neumann on this day in 1903, and if you haven't > heard of him then you are barely human... As computer science goes, > he's right up there with Alan Turing. There is speculation that he > knew of Babbage's work; see > https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann > . Coincidentally, I ran across my copy of Goldstine, "The computer from Pascal to von Neumann", as I was cleaning up, and plan to reread in the coming weeks. Short of checking the references in von Neumann's papers, I would think something would in there. N. From dave at horsfall.org Thu Dec 28 08:32:23 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 28 Dec 2017 09:32:23 +1100 (EST) Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <109152082.5216233.1514413535270@mail.yahoo.com> References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> <109152082.5216233.1514413535270@mail.yahoo.com> Message-ID: On Wed, 27 Dec 2017, Dave Ritchie via TUHS wrote: > I think that steep educational discounts and equipment grants from > Digital to major collages also had a major impact, as did the existence > of DECUS that made a lot of software readily available. IBM practically gave away their kit to educational institutions too (and made their money from the maintenance); there was no way that the University of NSW e.g. could've afforded their 360/50 otherwise, And IBM had their SHARE group, which was pretty much the same as DECUS. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From stewart at serissa.com Thu Dec 28 09:38:27 2017 From: stewart at serissa.com (Lawrence Stewart) Date: Wed, 27 Dec 2017 18:38:27 -0500 Subject: [TUHS] Happy birthday, John von Neumann! In-Reply-To: References: Message-ID: <3AA0CD78-C24E-45FD-B7B7-BE0F219E04CA@serissa.com> I would recommend https://deepblue.lib.umich.edu/handle/2027.42/3972 which is the Preliminary Discussion of the Logical Design of an Electronic Computing Instrument, which describes the IAS machine. > On 2017, Dec 27, at 5:10 PM, Dave Horsfall wrote: > > We gained John von Neumann on this day in 1903, and if you haven't heard of him then you are barely human... As computer science goes, he's right up there with Alan Turing. There is speculation that he knew of Babbage's work; see https://cstheory.stackexchange.com/questions/10828/the-relation-between-babbage-and-von-neumann . > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.bowling at kev009.com Thu Dec 28 09:38:59 2017 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 27 Dec 2017 16:38:59 -0700 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <109152082.5216233.1514413535270@mail.yahoo.com> References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> <109152082.5216233.1514413535270@mail.yahoo.com> Message-ID: I understand IBM systems history a lot better, but it looks simplistically to me that, in business terms, DEC created or became the brand leader for a net new market for minicomputers rather than competing against the establish(ed, ing) market of large systems. I'm sure their marketers worked very hard to differentiate the systems from large systems, precisely because they didn't want to compete with anyone. This is one of the most common motifs in technology business, start with a small niche and build out. It happened with UNIX, PCs, networking, etc. These things also usually follow power laws, where only a couple companies control the market. There are awesome plate tectonics and associated earthquakes, disasters, and rebuilding from ashes where markets collide, like UNIX systems taking on system of record, transaction processing, CAD in the '80s-'90s against mainframes, and the associated brand names tend to reshuffle (i.e. Sun for a while). Regards, On Wed, Dec 27, 2017 at 3:25 PM, Dave Ritchie via TUHS wrote: > > I think that steep educational discounts and equipment grants from Digital > to major collages also had a major impact, > as did the existence of DECUS that made a lot of software readily available. > > Best regards, > David Ritchie From paul.winalski at gmail.com Thu Dec 28 09:44:07 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 27 Dec 2017 18:44:07 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> <109152082.5216233.1514413535270@mail.yahoo.com> Message-ID: On 12/27/17, Dave Horsfall wrote: > On Wed, 27 Dec 2017, Dave Ritchie via TUHS wrote: > >> I think that steep educational discounts and equipment grants from >> Digital to major collages also had a major impact, as did the existence >> of DECUS that made a lot of software readily available. > > IBM practically gave away their kit to educational institutions too (and > made their money from the maintenance); there was no way that the > University of NSW e.g. could've afforded their 360/50 otherwise, That may have been true in the 1960s, but by the mid-1970s IBM System/360/370 was no longer competitive in the educational market. Circa 1973, Boston College--a true Blue IBM shop with a System/370-145--wanted to provide time-sharing services to the student body. For less than the cost to upgrade the model 145 to a 158, they bought a PDP-11/70 and ran RSTS on it. Similarly Holy Cross (my alma mater) had outgrown their System/370-125 by 1976. For the price of an upgrade to a model 135, they could by a complete VAX-11/780 system for academic use and retain the S/370-125 exclusively for college admin purposes. The 11/780 was equivalent in compute power and memory capacity to a S/370-158, but for about 1/4 the cost. -Paul W. From paul.winalski at gmail.com Thu Dec 28 10:07:21 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Wed, 27 Dec 2017 19:07:21 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> <109152082.5216233.1514413535270@mail.yahoo.com> Message-ID: On 12/27/17, Kevin Bowling wrote: > I understand IBM systems history a lot better, but it looks > simplistically to me that, in business terms, DEC created or became > the brand leader for a net new market for minicomputers rather than > competing against the establish(ed, ing) market of large systems. By the mid 1960s IBM had established a huge market presence and took advantage of it to reap large profit margins by not passing along the ever-decreasing manufacturing costs (corollary of Moore's law) to its customers. DEC, Data General, etc. were willing to accept lower profit margins. This allowed them to sell into new markets (e.g., small research groups) that IBM had priced themselves out of, and from that base to make inroads into the general business marketplace. > I'm > sure their marketers worked very hard to differentiate the systems > from large systems, precisely because they didn't want to compete with > anyone. Not really, in my experience and from my perspective both as a DEC customer and as a DEC development engineer. DEC's original customer base were experienced research engineers and scientists who knew what they wanted and didn't have to be sold to. Ken Olsen grew up simply taking customer orders, and he never understood or really supported marketing. Lack of marketing skill eventually caught up to DEC by the late 1980s and was a principal reason for its downfall. In the days of the PDP-11 and VAX, DEC also didn't provide the level of customer service, support, and hand-holding that IBM did (this was part of the reason why IBM systems were so expensive). Among IBM customers the saying was, "minicomputers aren't sold, they're abandoned". When our VAX arrived in 1978, we were appalled at DEC's inability to send on-site customer engineers to help us with software problems. Someone (Scott McNealy?) once said to survive a computer company has to be prepared to eat its own children. That is, to accept the faster, lower cost technology as it comes along and not to try to protect high profit margins on the older technology. Minicomputers ate the floor out from under mainframes, and IBM lost market dominance by attempting to protect the mainframe cost structure. PCs did the same thing to minicomputers in the early 1990s, and DEC repeated IBM's mistake by trying to defend against PCs instead of embracing them. -Paul W. From kevin.bowling at kev009.com Thu Dec 28 10:45:03 2017 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Wed, 27 Dec 2017 17:45:03 -0700 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> <109152082.5216233.1514413535270@mail.yahoo.com> Message-ID: On Wed, Dec 27, 2017 at 5:07 PM, Paul Winalski wrote: > Not really, in my experience and from my perspective both as a DEC > customer and as a DEC development engineer. DEC's original customer > base were experienced research engineers and scientists who knew what > they wanted and didn't have to be sold to. That is the very definition of good market development and sales, and it is quite hard and never accidental. The marketing might not look like any marketing ever done before i.e. you don't take out TV spots to sell minicomputers, but showing research engineers your machine and your instruction set any chance you create might do it. Typically founders (or some equivalent like a GM or fellow in a technology company) are intimately involved, because they can hold the entire calculus in their working set, at least for a while. As a company grows and goes on, it becomes harder to fight people that thrive on the illusion of work and hubris instead of what the actual market is or what customers need that nobody else is giving them. > Someone (Scott McNealy?) once said to survive a computer company has > to be prepared to eat its own children. That is, to accept the > faster, lower cost technology as it comes along and not to try to > protect high profit margins on the older technology. Minicomputers > ate the floor out from under mainframes, and IBM lost market dominance > by attempting to protect the mainframe cost structure. PCs did the > same thing to minicomputers in the early 1990s, and DEC repeated IBM's > mistake by trying to defend against PCs instead of embracing them. That's a common view but I don't see it as black and white as a downward race. I see it more as entrepreneurs vying to reshuffle the deck, most customers (executives?, corporate governance?) don't really care that much about the specific technology they use but don't want to be seen as too conservative nor reckless. But there is opportunity to make a lot of money as a startup or technology company when you get technology to switch up drastically. If you can convince people to go back to timesharing on semi-proprietary equipment there is a lot of money to be made.. Amazon has done this marvelously and will have a nice 10+ year run yet doing that. Most developers enthusiastically using AWS don't think they were marketed or sold to either. Great market development and sales. From alec.muffett at gmail.com Thu Dec 28 11:23:35 2017 From: alec.muffett at gmail.com (Alec Muffett) Date: Thu, 28 Dec 2017 01:23:35 +0000 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <81a768c0-a8c6-6e4a-5c60-1526614ea851@spamtrap.tnetconsulting.net> References: <81a768c0-a8c6-6e4a-5c60-1526614ea851@spamtrap.tnetconsulting.net> Message-ID: If there's any followup then Grant and I can take it off-thread, but for clarity: On 27 December 2017 at 21:50, Grant Taylor via TUHS wrote: > > now reflected in companies explaining to ISO27001 auditors that "well, we >> don't actually possess any physical servers..." >> > > Okay. How does (the lack of) physical servers actually impact ISO 27001 > compliance? - From my read of the Wikipedia article I don't see how (the > lack of) physical on premise servers changes anything. > There is none; but the preconceptions which are exposed when meets his/her first - are hilarious to experience. Q: "Where are the servers?" A: "Well, that depends..." ...etc. -a -- http://dropsafe.crypticide.com/aboutalecm -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Thu Dec 28 11:39:51 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 27 Dec 2017 20:39:51 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <109152082.5216233.1514413535270.ref@mail.yahoo.com> <109152082.5216233.1514413535270@mail.yahoo.com> Message-ID: <079401d37f7c$c183f800$448be800$@ronnatalie.com> The PDP-8 and 11 were cheap and this allowed them to be used both in lab situations (I remember working with PDP-8's around 1975 at UofM in non engineering departments like psychological-pharmacology) and at the departmental level, in contrast to the central data centers. I cut my teeth on the PDP-11/45 (running UNIX) in the Electrical Engineering department. One of the Biomedical Engineering labs used an LSI-11 running miniunix followed by an 11/23 also running UNIX. I used PDP-11's in several locations in the Psych department and in the biomedical and opthomological departmetns at the Med School. All this typically by people they wouldn't let anywhere near the campus computing mainframes. The CS Department at the UofM taught a OS course (where students wrote one of their own) on a pair of 11's upstairs from the computer center. Amusingly, on the cloud subject, years later those PDP-11's were getting long in the tooth (and you had to share them single user between a large class). The computer center downstairs had installed several IBM VM/CMS systems. We offered to rewrite the course curriculum, very centered on the PDP-11, to allow them to teach it on VM (writing their own hosted OS under VM). Couldn't convince the faculty. Made too much sense. From itz at very.loosely.org Thu Dec 28 12:10:35 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Wed, 27 Dec 2017 18:10:35 -0800 Subject: [TUHS] Happy birthday, John von Neumann! In-Reply-To: References: Message-ID: <20171228021035.d7wl3uerwhhpv2l2@matica.foolinux.mooo.com> On 2017-12-28 09:10, Dave Horsfall wrote: > We gained John von Neumann on this day in 1903, and if you haven't > heard of him then you are barely human... As computer science goes, > he's right up there with Alan Turing. There is speculation that he > knew of Babbage's work And those like me who are Masters Of No Trade know that he started as a pure maths person, inventing the encoding of ordered pairs and ordinal numbers in formalized set theory. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain. From grog at lemis.com Thu Dec 28 12:14:04 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 28 Dec 2017 13:14:04 +1100 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: Message-ID: <20171228021404.GM70143@eureka.lemis.com> On Wednesday, 27 December 2017 at 16:51:54 -0500, Clem Cole wrote: > > The concept of purchasing smaller system, was indeed true. This was the > idea behind the >>mini-computer<< or *minimal computer* that Gordon Bell > who lad left DEC temporarily to be a CMU Prof for a time began to explore. This ties in very much with what I recall from the late 1960s. My very first computer was a PDP-8/I, and we certainly called it a computer, not a data processor. > He took the idea and commercialized and the PDP-8 line was the first > in that line. Not the PDP-5? I thought there was little difference. If there was, it would be interesting to know. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From grog at lemis.com Thu Dec 28 12:15:31 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 28 Dec 2017 13:15:31 +1100 Subject: [TUHS] Happy birthday, John von Neumann! In-Reply-To: References: Message-ID: <20171228021531.GN70143@eureka.lemis.com> On Thursday, 28 December 2017 at 9:10:56 +1100, Dave Horsfall wrote: > We gained John von Neumann on this day in 1903, ... If you're in to this sort of thing, it's interesting to note that it's also Linus Torvalds' birthday (66 years younger than John). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From jsteve at superglobalmegacorp.com Thu Dec 28 23:40:47 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 28 Dec 2017 21:40:47 +0800 Subject: [TUHS] XINU for the 68000 / 68010 In-Reply-To: <20171228021531.GN70143@eureka.lemis.com> References: <20171228021531.GN70143@eureka.lemis.com> Message-ID: <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com> I came across this page while looking for man pages to SYSVr3 for someone... Completely unrelated but I thought it’d be interesting to someone. Apparently it can be built with GCC/GAS/Binutils from a 680x0 based SUN. http://unixpc.taronga.com/xinu7300/ >From the readme: Xinu for the ATT7300 (3B1) and MECB (Motorola Educational Computer Board) This is an implementation of the Vol. I Xinu for diskless singleboard 68000/68010 systems. The ATT7300 is the preferred system, having at least .5M memory vs. the MECB's cramped 32K. ATT7300 hardware and the Xinu support provided here: MC68010, 10Mhz .5M-2M onboard memory, up to 4M with expansion memory VA space of 4M, monolithic page table (not used here for paging) RS232 port with software-selectable baudrates to 19.2K baud, with NEC7201 SLU (used for Xinu console) Line clock interrupting at 60Hz, used for Xinu clock. Keyboard interface with MC6850 SLU--Xinu tty driver for it here, but not compatible with the serial encoding from the native keyboard, so you need to attach another terminal to use it. Centronics parallel printer port (start on LPR driver here, fleshing it out is a good student project) Floppy disk--not supported in Xinu, but used to boot monitor/downloading system Hard disk--not supported or needed. Realtime clock--not supported in Xinu. Telephone interfaces--not supported. Bitmap graphics monitor interface--not supported. MECB hardware and Xinu support: MC68000 CPU, 4Mhz 32K memory 2 serial ports, each with MC6850 SLUs, available as Xinu ttys or dlcs. Easy to add a third MC6850 at 0x30001, for 2nd dlc. (However running a Xinu net takes more than 32K memory, not so easy) MC68230 PI/timer: Timer used as Xinu clock, setup for LPR driver using PI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Dec 29 00:05:51 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 28 Dec 2017 09:05:51 -0500 (EST) Subject: [TUHS] Why did PDPs become so popular? Message-ID: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> > From: Paul Winalski > Lack of marketing skill eventually caught up to DEC by the late 1980s > and was a principal reason for its downfall. I got the impression that fundamentally, DEC's engineering 'corporate culture' was the biggest problem; it wasn't suited to the commodity world of computing, and it couldn't change fast enough. (DEC had always provided very well built gear, lots of engineering documentation, etc, etc.) I dunno, maybe my perception is wrong? There's a book about DEC's failure: Edgar H. Schein, "DEC is Dead, Long Live DEC", Berett-Koehler, San Francisco, 2003 which probably has some good thoughts. Also: Clayton M. Christensen, "The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail", Harvard Business School, Boston, 1997 briefly mentions DEC. Noel From arnold at skeeve.com Fri Dec 29 00:06:52 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 28 Dec 2017 07:06:52 -0700 Subject: [TUHS] XINU for the 68000 / 68010 In-Reply-To: <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com> References: <20171228021531.GN70143@eureka.lemis.com> <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com> Message-ID: <201712281406.vBSE6qkL026800@freefriends.org> Jason Stevens wrote: > I came across this page while looking for man pages to SYSVr3 for > someone... Completely unrelated but I thought it’d be interesting > to someone. Apparently it can be built with GCC/GAS/Binutils from a > 680x0 based SUN. Small clarification: The AT&T 3B1 isn't related to Suns. It was made for AT&T by Convergent. It was a nice box; I owned one for a while and have many happy memories thereof. > http://unixpc.taronga.com/xinu7300/ Hmmm, are there other Xinu versions in the archive? Thanks, Arnold From paul.winalski at gmail.com Fri Dec 29 01:59:29 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Thu, 28 Dec 2017 10:59:29 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> Message-ID: On 12/28/17, Noel Chiappa wrote: > > From: Paul Winalski > > > Lack of marketing skill eventually caught up to DEC by the late 1980s > > and was a principal reason for its downfall. > > I got the impression that fundamentally, DEC's engineering 'corporate culture' > was the biggest problem; it wasn't suited to the commodity world of computing, > and it couldn't change fast enough. (DEC had always provided very well built > gear, lots of engineering documentation, etc, etc.) > > I dunno, maybe my perception is wrong? I think you're right. The disinterest in marketing and advertising (Ken Olsen, and therefore DEC, had a "build it and they will come" mentality) was one aspect of the corporate culture. An example of its negative impact: When the Alpha EV5 came out, it was several times faster than anything else around. At the same time, Intel and AMD were involved in the clock rate race. Every time Intel leapfrogged AMD, they trumpeted in the media (both trade and public) that they'd produced the fastest microprocessor in the world. DEC did nothing to counter this false impression. DEC's corporate culture also led to slow decision making. DEC believed in consensus building--everyone had to buy into a decision before it was final. We low-level DEC engineers used to joke that any decision worth making was worth making ten times. Consensus building is great if you can reach a consensus, but terrible when you can't. What was needed was something more like Sun's "lead, follow, or get out of the way", or Intel's "disagree and commit". DEC was also prone to over-engineering its products. This slowed down time to market and also increased production costs. It's true that, particularly in software, spending extra time in design up front pays back in reduced maintenance costs down the road, but if you can't get V1.0 out the door within its market time frame, there will never be a V2.0. -Paul W. From lm at mcvoy.com Fri Dec 29 02:08:11 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 28 Dec 2017 08:08:11 -0800 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> Message-ID: <20171228160811.GA13474@mcvoy.com> On Thu, Dec 28, 2017 at 10:59:29AM -0500, Paul Winalski wrote: > On 12/28/17, Noel Chiappa wrote: > > > From: Paul Winalski > > > > > Lack of marketing skill eventually caught up to DEC by the late 1980s > > > and was a principal reason for its downfall. > > > > I got the impression that fundamentally, DEC's engineering 'corporate culture' > > was the biggest problem; it wasn't suited to the commodity world of computing, > > and it couldn't change fast enough. (DEC had always provided very well built > > gear, lots of engineering documentation, etc, etc.) > > > > I dunno, maybe my perception is wrong? > > I think you're right. The disinterest in marketing and advertising > (Ken Olsen, and therefore DEC, had a "build it and they will come" > mentality) was one aspect of the corporate culture. An example of its > negative impact: When the Alpha EV5 came out, it was several times > faster than anything else around. Got a reference for that performance claim? Wasn't that mid 1990's? If so, I was heavily into benchmarking and performance work during that period. If there was a processor that was 2x faster, let alone several times faster, I would have noticed. http://www.bitmover.com/lmbench/lmbench-usenix.pdf -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From jsteve at superglobalmegacorp.com Fri Dec 29 03:20:09 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 29 Dec 2017 01:20:09 +0800 Subject: [TUHS] XINU for the 68000 / 68010 In-Reply-To: <201712281406.vBSE6qkL026800@freefriends.org> References: <20171228021531.GN70143@eureka.lemis.com> <9c4a623a-93bc-4678-9ec3-413e6ccf6372@HK2APC01FT032.eop-APC01.prod.protection.outlook.com> <201712281406.vBSE6qkL026800@freefriends.org> Message-ID: The relationship with GNU & SUN would be that the SUN & VAX were the first target platforms for GCC/GAS/Binutils. So it would have been expected that if you were running a 68000 version of GCC it’d probably be running on a SUN-2 or SUN-3. Not to mention it was their build platform as mentioned here: ftp://ftp.cs.purdue.edu/pub/comer/XINU-68K.README There is some additional platforms here: ftp://ftp.cs.purdue.edu/pub/comer I haven’t tried to run any of it yet though. From: arnold at skeeve.com Sent: Thursday, 28 December 2017 10:07 PM To: tuhs at tuhs.org; jsteve at superglobalmegacorp.com Subject: Re: [TUHS] XINU for the 68000 / 68010 Jason Stevens wrote: > I came across this page while looking for man pages to SYSVr3 for > someone... Completely unrelated but I thought it’d be interesting > to someone. Apparently it can be built with GCC/GAS/Binutils from a > 680x0 based SUN. Small clarification: The AT&T 3B1 isn't related to Suns. It was made for AT&T by Convergent. It was a nice box; I owned one for a while and have many happy memories thereof. > http://unixpc.taronga.com/xinu7300/ Hmmm, are there other Xinu versions in the archive? Thanks, Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From tytso at mit.edu Fri Dec 29 09:28:52 2017 From: tytso at mit.edu (Theodore Ts'o) Date: Thu, 28 Dec 2017 18:28:52 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <20171228160811.GA13474@mcvoy.com> References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> <20171228160811.GA13474@mcvoy.com> Message-ID: <20171228232852.GC30269@thunk.org> On Thu, Dec 28, 2017 at 08:08:11AM -0800, Larry McVoy wrote: > > I think you're right. The disinterest in marketing and advertising > > (Ken Olsen, and therefore DEC, had a "build it and they will come" > > mentality) was one aspect of the corporate culture. An example of its > > negative impact: When the Alpha EV5 came out, it was several times > > faster than anything else around. > > Got a reference for that performance claim? Wasn't that mid 1990's? > If so, I was heavily into benchmarking and performance work during > that period. If there was a processor that was 2x faster, let alone > several times faster, I would have noticed. > > http://www.bitmover.com/lmbench/lmbench-usenix.pdf "Digital's 21164 Reaches 500 MHz: Alpha Regains Performance Lead, Leaves Pentium Pro in Dust" -- Microprocessor Report July 8, 1996. http://noel.feld.cvut.cz/vyu/scs/alpha/164_500.pdf Looks to me from the article that Alpha was certain participating in the clock speed wars, though. - Ted From wobblygong at gmail.com Fri Dec 29 18:26:25 2017 From: wobblygong at gmail.com (Wesley Parish) Date: Fri, 29 Dec 2017 21:26:25 +1300 Subject: [TUHS] origin of C header files Message-ID: Hi I've just had an interesting experience, explaining C header files to a nephew programmer who didn't understand them. I pointed him in the direction of Minix as an example of a small well-engineered system which would display their use. Which raised the question: when did header files come into use? Who was the first to use header files to store common system-wide or application-wide data definitions? Was it used in any languages prior to C? Thanks Wesley Parish From nw at retrocomputingtasmania.com Fri Dec 29 20:58:28 2017 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Fri, 29 Dec 2017 21:58:28 +1100 Subject: [TUHS] origin of C header files In-Reply-To: References: Message-ID: On Fri, Dec 29, 2017 at 7:26 PM, Wesley Parish wrote: > Which raised the question: when did header files come into use? Who > was the first to use header files to store common system-wide or > application-wide data definitions? Was it used in any languages prior > to C? COBOL 60 (April 1960) had INCLUDE (page V-27): http://bitsavers.trailing-edge.com/pdf/codasyl/COBOL_Report_Apr60.pdf FUNCTION: To save the programmer effort by automatically incorporating library subroutines into the source program. It even had a literal substitution mechanism to rewrite the included text. From kevin.bowling at kev009.com Fri Dec 29 21:04:01 2017 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 29 Dec 2017 04:04:01 -0700 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <20171228232852.GC30269@thunk.org> References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> <20171228160811.GA13474@mcvoy.com> <20171228232852.GC30269@thunk.org> Message-ID: I can mostly only comment from my readings, but this is IMHO a non-trivial question even in retrospect because it depends on what you or your workload valued. I do like how lmbench categorizes across multiple "interesting" vectors, showing some of the design tradeoffs of CPU architecture and then how the OS plays a role in real world applications. Alpha generally maintained integer/ALU and clockspeed leadership for most of the '90s http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf For intel the Pentium Pro was pivotal in being able to position vs the contemporary RISC CPUs with multi-MB caches. And federating cost effective CPUs together with Laissez-faire mainboard/system packaging/OSes turned out to be more important than pretty much anything else. I know that IBM Austin did some wizard of oz stuff in early POWER.. Bi-CMOS superscalar that put it 4-5 years ahead of most competing microprocessor designs in floating point, though SGI and HP traded respectable volleys. But POWER also had fat memory bandwidth, they tended to make well balanced braniacs that didn't blindly pursue the clockspeed war (http://www.cs.virginia.edu/~mccalpin/papers/balance/). They got into a weird spot in the second half of the 90s with an out-dated bus, internal competition from PowerPC and RS64, but returned to leadership with POWER4 and up to today. POWER's IO leadership made it a good fit for many early internet routers in the early '90s, NSFNET and others. Interestingly modern POWER retains that leadership on memory and I/O which can put it 2 to 4 years ahead of everything else depending on what you value (Google seems to see the light using it for gluing GPUs together..). From IBM Rochester, RS64 was kind of interesting in being the first use of SMT and having incredibly low TDP which were both interesting clairvoyance into the next decade. In retrospect I don't think SPARC ever had a reasonable showing pound for pound vs other microprocessors :) Regards, On Thu, Dec 28, 2017 at 4:28 PM, Theodore Ts'o wrote: > On Thu, Dec 28, 2017 at 08:08:11AM -0800, Larry McVoy wrote: >> > I think you're right. The disinterest in marketing and advertising >> > (Ken Olsen, and therefore DEC, had a "build it and they will come" >> > mentality) was one aspect of the corporate culture. An example of its >> > negative impact: When the Alpha EV5 came out, it was several times >> > faster than anything else around. >> >> Got a reference for that performance claim? Wasn't that mid 1990's? >> If so, I was heavily into benchmarking and performance work during >> that period. If there was a processor that was 2x faster, let alone >> several times faster, I would have noticed. >> >> http://www.bitmover.com/lmbench/lmbench-usenix.pdf > > "Digital's 21164 Reaches 500 MHz: Alpha Regains Performance Lead, > Leaves Pentium Pro in Dust" -- Microprocessor Report July 8, 1996. > > http://noel.feld.cvut.cz/vyu/scs/alpha/164_500.pdf > > Looks to me from the article that Alpha was certain participating in > the clock speed wars, though. > > - Ted From arrigo at alchemistowl.org Fri Dec 29 21:14:14 2017 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Fri, 29 Dec 2017 12:14:14 +0100 Subject: [TUHS] History of exploits - request for authors In-Reply-To: <20171219012525.GB11683@mcvoy.com> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> <20171219012525.GB11683@mcvoy.com> Message-ID: <30BA09E9-C575-4205-B383-68EA6D3D4F1C@alchemistowl.org> On 19 Dec 2017, at 02:25, Larry McVoy wrote: > So the only one I was involved in was the CVS hack to the Linux kernel > source tree. This was back in the early 2000's and the kernel used > my SCM system, BitKeeper, but there were people who didn't like the > license. We built an exporter that exported the history to CVS (it > was a pretty nice exporter, on a per file basis it would find the > longest path through a DAG and export that since CVS was straight > line, not a DAG.) Personally I believe it would make a fine historical article for the next issue (17 is out now with 34C3). Would you be willing to write it up? With enough articles we might even pull a “history issue”! Arrigo From arrigo at alchemistowl.org Fri Dec 29 21:22:52 2017 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Fri, 29 Dec 2017 12:22:52 +0100 Subject: [TUHS] History of exploits - request for authors In-Reply-To: <20171219201721.GA95741@accordion.employees.org> References: <8460DBBB-A4E2-468B-B294-A2B021213F3C@alchemistowl.org> <20171219201721.GA95741@accordion.employees.org> Message-ID: <45CBBAF3-CE6D-4DA5-B685-E78CEE6674C1@alchemistowl.org> On 19 Dec 2017, at 21:17, Derek Fawcus wrote: > > On Tue, Dec 19, 2017 at 12:08:21PM +1100, Dave Horsfall wrote: >> >> Leaving a "login" simulator on a terminal (quite common). > > Well if you include that one, you may want to include the simple > brute force testing of passwords against /etc/passwd > (before shadow files existed). The login name and real names > (direct or reversed) would tend to get at least one hit. Well, we all ran Alec’s crack for fun & profit (and some to land themselves in trouble)… I think that doesn’t really qualify as a hack per-se, just a technique which used to work easily and now requires a little bit more computing power (OK, a lot more as the hashing of passwords has become rather more serious). Personally I feel that if we go down the password route then, besides the “easy” brute-forcing of old /etc/passwd files, we have to include the LANMAN password hashes but, again, of historical interest definitely but not sure it can be turned into an article unless someone manages to write it all the way to the latest oopsies like Linux’s systemd and usernames starting with a digit or Apple’s 10.13 “be root with a simple Enter”. I guess one could write it from the point of view of looking at the bad decisions, their implications and the bugs which made even bad decisions look almost good. Arrigo From lm at mcvoy.com Sat Dec 30 02:38:32 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 29 Dec 2017 08:38:32 -0800 Subject: [TUHS] Why did PDPs become so popular? Message-ID: <20171229163832.GA17231@mcvoy.com> On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote: > Alpha generally maintained integer/ALU and clockspeed leadership for > most of the '90s > http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf Wow, that first graph is the most misleading graph on CPU performance I've ever seen. Ever. So from 1993 to 2000 the only CPUs released were Alphas? That era was when I was busy measuring performance across cpus and operating systems and I don't ever remember any processor being a factor of 2 better than its peers. And maybe I missed it, I only owned a couple of alpha systems, but I never saw an Alpha that was a game changer. Alpha was cool but it was too little, too late to save DEC. In that time period, even more so now, you had to be 2x better to get a customer to switch to your platform. 2x cheaper 2x faster 2x more reliable Do one of those and people would consider switching platforms. Less than that was really tough and it was always, so far as I remember, less than that. SMP might be an exception but we went through that whole learning process of "well, we advertised symmetric but when we said that what we really meant was you should lock your processes down to a processor because caches turn out to matter". So in theory, N processors were N times faster than 1 but in practice not so much. I was very involved in performance work and cpu architecture and I'd love to be able to claim that we had a 2x faster CPU than someone else but we didn't, not at Sun and not at SGI. It sort of make sense that there weren't huge gaps, everyone was more or less using the same sized transistors, the same dram, the same caches. There were variations, Intel had/has the biggest and most advanced foundries but IBM would push the state of the art, etc. But I don't remember anyone ever coming out with a chip that was 2x faster. I suspect you can find one where chip A is introduced at the end of chip B's lifespan and A == 2*B but wait a few month's and B gets replaced and A == .9*C. Can anyone point to a 2x faster than it's current peers chip introduction? Am I just not remembering one or is that not a thing? --lm From mutiny.mutiny at rediffmail.com Sat Dec 30 03:58:44 2017 From: mutiny.mutiny at rediffmail.com (Mutiny ) Date: 29 Dec 2017 17:58:44 -0000 Subject: [TUHS] =?utf-8?q?tuhs=40minnie=2Etuhs=2Eorg?= Message-ID: <1514569490.S.62633.autosave.drafts.1514570324.4716@webmail.rediffmail.com> 'FUNCTION: To save the programmer effort by automatically incorporating         library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From mutiny.mutiny at rediffmail.com Sat Dec 30 03:55:24 2017 From: mutiny.mutiny at rediffmail.com (Mutiny ) Date: 29 Dec 2017 17:55:24 -0000 Subject: [TUHS] =?utf-8?q?tuhs=40minnie=2Etuhs=2Eorg?= Message-ID: <20171229175524.8604.qmail@f4mail-235-146.rediffmail.com> 'FUNCTION: To save the programmer effort by automatically incorporating         library subroutines into the source program.'in Cobol whole 'functions' (subroutines) and even code snipplets are 'copied' into the main source file by the copy statement. That's different to preprocessor macros, -definitions, -literals and, since ansi c, function prototypes.  -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.winalski at gmail.com Sat Dec 30 05:28:06 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 29 Dec 2017 14:28:06 -0500 Subject: [TUHS] origin of C header files In-Reply-To: References: Message-ID: On 12/29/17, Wesley Parish wrote: > > Which raised the question: when did header files come into use? Who > was the first to use header files to store common system-wide or > application-wide data definitions? Was it used in any languages prior > to C? It probably all started with macro-instructions (macros) in assembly languages. The assembler for System/360 in the 1960s had a pretty complex and powerful conditional assembly and macro expansion capability. That technology I'm sure dates back to the 1950s. When higher-level languages came along, programmers moving from assembly code to a HLL would want the same sort of preprocessor functionality. I know that IBM PL/I had %include, and I suspect that other HLLs of the day had similar features. What's very clear is that C did not invent include files or conditional compilation, it merely carried on existing tradition. -Paul W. From clemc at ccc.com Sat Dec 30 06:31:54 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 29 Dec 2017 15:31:54 -0500 Subject: [TUHS] origin of C header files In-Reply-To: References: Message-ID: On Fri, Dec 29, 2017 at 2:28 PM, Paul Winalski wrote: > > When higher-level languages came along, programmers moving from > assembly code to a HLL would want the same sort of preprocessor > functionality. I know that IBM PL/I had %include, and I suspect that > other HLLs of the day had similar features. > > What's very clear is that C did not invent include files or > conditional compilation, it merely carried on existing tradition. > ​I'll +1 Paul's comment and add a couple of observations. Languages such a PL/1 and FORTRAN would could support a preprocessor and conditional compilation, were more easy to use to build 'products' - as opposed to Pascal. Folks did splice an backwards conditi​onal compiling scheme with include files into some Pascal flavors but it was non-standard. Fortran folks used tools like RATFOR or m4, but the key was the there was some why to preprocess code for different targets. In a production shop, particularly where your 'target' customer was different, this ability becomes more and more of an requirement. I've always said as contemporary production systems programming languages, while BLISS had a better Macro system then C, the include file and conditional scheme worked much better/was much cleaner - to the point that ifdef is abused and the cause of much pain in actual code. But the truth is that is a success problem. When used properly, the C header scheme, while not invented by the BTL crew, was pretty much what people needed. No too fancy, but all the features you really needed and has been lasting. Clem ᐧ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobozo at gmail.com Sat Dec 30 09:35:27 2017 From: nobozo at gmail.com (Jon Forrest) Date: Fri, 29 Dec 2017 15:35:27 -0800 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> <20171228160811.GA13474@mcvoy.com> <20171228232852.GC30269@thunk.org> Message-ID: <12de637f-b6fc-cc24-ce33-40d4a5f1e475@gmail.com> On 12/29/2017 3:04 AM, Kevin Bowling wrote: > Alpha generally maintained integer/ALU and clockspeed leadership for > most of the '90s > http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf I worked in the Computer Science Dept. at UC Berkeley in the 1990s when Richard Sites, the chief architect of the Alpha, gave a talk describing the Alpha. I remember him saying that there was nothing out there from any other vendor that would be able to compete with the Alpha for the next 10 years (I'm pretty sure he said 10 years but it might have been longer). Because I was the system manager for the Sequoia 2000 project, DEC's big external research project after Project Athena, I got the first Alpha delivered to UC Berkeley. I remember it being quite fast, although I don't recall any specific benchmarks. The OS (OSF/1) was fairly primitive as first and didn't even support multiple processor systems. We were able to port Postgres to it fairly quickly in spite of various issues related to the 64-bit Alpha architecture. In fact, the Postgres group was using Alpha desktops when SQL was added to Postgres. As nice as the Alphas were, I don't recall any compelling reason we would have used them if we had to pay for them. In fact, at the same time Mike Stonebraker and I wrote a grant proposal to Sun to get a couple of SparcStation 10s to use to port Postgres to Solaris. The SparcStations were just as nice to use as the Alphas. DEC's later demise was quite sad to me, since before joining UC Berkeley I had been a VAX/VMS person. DEC did a great job supporting Project Sequoia 2000, and they were very generous with both their hardware and money. Judging from Sites' presentation, they thought they were going to win. Jon Forrest From kevin.bowling at kev009.com Sat Dec 30 09:54:25 2017 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 29 Dec 2017 16:54:25 -0700 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <20171229163832.GA17231@mcvoy.com> References: <20171229163832.GA17231@mcvoy.com> Message-ID: I trust your judgement and experience WRT the Alpha. If you're looking for massive performance deltas, what about ECL designs like the IBM 3090 and Cray designs in the late '80s/ early '90s? I believe those were not a multiple but a magnitude faster than contemporaries. Regards, On Fri, Dec 29, 2017 at 9:38 AM, Larry McVoy wrote: > On Fri, Dec 29, 2017 at 04:04:01AM -0700, Kevin Bowling wrote: >> Alpha generally maintained integer/ALU and clockspeed leadership for >> most of the '90s >> http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf > > Wow, that first graph is the most misleading graph on CPU performance > I've ever seen. Ever. > > So from 1993 to 2000 the only CPUs released were Alphas? > > That era was when I was busy measuring performance across cpus and > operating systems and I don't ever remember any processor being a > factor of 2 better than its peers. And maybe I missed it, I only > owned a couple of alpha systems, but I never saw an Alpha that was > a game changer. Alpha was cool but it was too little, too late to > save DEC. > > In that time period, even more so now, you had to be 2x better to get > a customer to switch to your platform. > > 2x cheaper > 2x faster > 2x more reliable > > Do one of those and people would consider switching platforms. Less than > that was really tough and it was always, so far as I remember, less than > that. SMP might be an exception but we went through that whole learning > process of "well, we advertised symmetric but when we said that what we > really meant was you should lock your processes down to a processor > because caches turn out to matter". So in theory, N processors were N > times faster than 1 but in practice not so much. > > I was very involved in performance work and cpu architecture and I'd love > to be able to claim that we had a 2x faster CPU than someone else but we > didn't, not at Sun and not at SGI. > > It sort of make sense that there weren't huge gaps, everyone was more or > less using the same sized transistors, the same dram, the same caches. > There were variations, Intel had/has the biggest and most advanced > foundries but IBM would push the state of the art, etc. But I don't > remember anyone ever coming out with a chip that was 2x faster. I > suspect you can find one where chip A is introduced at the end of chip > B's lifespan and A == 2*B but wait a few month's and B gets replaced > and A == .9*C. > > Can anyone point to a 2x faster than it's current peers chip introduction? > Am I just not remembering one or is that not a thing? > > --lm From lm at mcvoy.com Sat Dec 30 09:58:31 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 29 Dec 2017 15:58:31 -0800 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <12de637f-b6fc-cc24-ce33-40d4a5f1e475@gmail.com> References: <20171228140551.B6F9418C079@mercury.lcs.mit.edu> <20171228160811.GA13474@mcvoy.com> <20171228232852.GC30269@thunk.org> <12de637f-b6fc-cc24-ce33-40d4a5f1e475@gmail.com> Message-ID: <20171229235831.GH22177@mcvoy.com> On Fri, Dec 29, 2017 at 03:35:27PM -0800, Jon Forrest wrote: > >Alpha generally maintained integer/ALU and clockspeed leadership for > >most of the '90s > >http://www.cs.columbia.edu/~sedwards/classes/2012/3827-spring/advanced-arch-2011.pdf > > As nice as the Alphas were, I don't recall any compelling reason we > would have used them if we had to pay for them. In fact, at the same > time Mike Stonebraker and I wrote a grant proposal to Sun to get a > couple of SparcStation 10s to use to port Postgres to Solaris. The > SparcStations were just as nice to use as the Alphas. Yeah, that's my memory as well. Alpha was fine but it wasn't the bat it out of the park that DEC thought it would be. I've worked at Sun and SGI and had some influence on some of their processor work (Andy B redesigned the memory interconnect on one of the SparcStation SMP boxes because I showed him data that proved that we were about to suck; got a processor at SGI cancelled because it was just beyond hopeless, it was a floating point machine called Beast and it was being developed as the focus was shifting heavily from floating point to integer. The stupid thing had pins on all 6 sides - top, bottom, and the edges. The socket, just the socket, was predicted to cost SGI $1400/each at volume. No CPU, just the socket. And it had miserable integer performance. Bzzt.) What I've seen over and over is teams compete against their previous design rather than the competition. Many, many times I've seen designers who had barely a passing knowledge of what the other guys could do. Blew my mind. It was part of the reason I wrote LMbench, at least that gives you an idea of what the other guys can do. --lm From lm at mcvoy.com Sat Dec 30 10:04:25 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 29 Dec 2017 16:04:25 -0800 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> Message-ID: <20171230000425.GI22177@mcvoy.com> On Fri, Dec 29, 2017 at 04:54:25PM -0700, Kevin Bowling wrote: > I trust your judgement and experience WRT the Alpha. > > If you're looking for massive performance deltas, what about ECL > designs like the IBM 3090 and Cray designs in the late '80s/ early > '90s? I believe those were not a multiple but a magnitude faster than > contemporaries. For vector operations, yes. For stuff that you and I care about, running the OS, serving up data, not so much. As I recall, the supercomputers were pretty crappy on anything that wasn't a vector operation. I helped port Unix to a CDC spinoff, the ETA-10, and it was faster to cross compile stuff on a Sun 3/280 than compile it natively. I haven't run on either the 3090 or the Crays but I've got friends who did (some of whom still work at Cray) and when I was crowing about what I could do a Sun nobody told me that it was faster on a cray. If you were doing scalar floating point, especially at the larger precisions, yeah, the super computers were better. If you were doing that sort of thing as a vector, so a vector of 128 bit floats, yeah, I could imagine that could be a lot faster than a Sun. SGI did a tick/tock where it was floating point focus, then integer focus. It's possible that one of their floating point designs kept pace with the super computers, I know that they went to the super computing conference each year (I did the power wall over NFS at one). But I don't know much about floating point, never use it in my code :) --lm From stewart at serissa.com Sat Dec 30 10:54:03 2017 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 29 Dec 2017 19:54:03 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> Message-ID: <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> I'll chime in just to say that designing with ECL was one hell of a lot of fun compared to TTL. The first Alpha chip (EV3) had pad drivers that could be configured for TTL levels or for ECL levels. In fact, a good chunk of the ISSCC paper is about the pad driver. I was part of the team that built the first Alpha machine, the Alpha Demonstration Unit, see ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF For a limited number of machines, with power no object we were able to make an unabashed ECL design using the ECL 100K logic family, the ECLinPS family (300 ps gate delays) and some custom Gigabit Logic Gallium Arsenide parts for the memory board address line drivers. We got power supply cables from a local valley welding shop and had them cut to length. The shop owner wanted to know “what kind of a welder needs 18” cables?” The issue was the 400 Amps of -4.5 v. Each jelly bean chip was between 1/2 and 1 watt IIRC. The beauty of ECL is that it is perfectly happy to drive 50 ohm transmission lines, with shunt termination. This gives you incident wave switching and really beautiful signal integrity. I think if Cray had tried to build the Cray 1 with anything other than ECL it just would never have worked reliably, especially with such long wires needed. Essentially, ECL let you build big machines with the same reliability that could only be achieved with small machines using TTL. Great stuff if you can afford the power consumption. In the same way that it is worthwhile to own a sports car at least once in your life, it was a joy to build an ECL design. -Larry > On 2017, Dec 29, at 6:54 PM, Kevin Bowling wrote: > > I trust your judgement and experience WRT the Alpha. > > If you're looking for massive performance deltas, what about ECL > designs like the IBM 3090 and Cray designs in the late '80s/ early > '90s? I believe those were not a multiple but a magnitude faster than > contemporaries. > > Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Sat Dec 30 11:06:34 2017 From: scj at yaccman.com (Steve Johnson) Date: Fri, 29 Dec 2017 17:06:34 -0800 Subject: [TUHS] origin of C header files In-Reply-To: Message-ID: I was told once that McIlroy and Morris invented macro instructions for assembly language.   And certainly they wrote the definitive paper on macros, with, as I recall, something like 10 decisions you needed to make about a macro processor and you could generate 1024 different macro systems that way.  I wonder if that ever got published -- it blew my mind when I encountered it at the beginning of my career... There were two features of the C preprocessor that were, I think, unique to the labs for some time.  One was a problem that came up with program generators.  In RATFOR, for example, an IF statement on line 50 might get translated to become line 125 of the output FORTRAN program.   And if when there was an error, it could be very painful to discover where it came from.  I ran into the same problem in spades with Yacc.  When someone wrote a Yacc program (especially when using a makefile), an error on line 50 in foo.y could easily be reported as being on line 125 in foo.c.   The natural thing was to fix the error in foo.c.   And lo, it compiled and ran.  Until the next time you changed foo.y, and  then it reappeared in all its glory.   I begged Dennis for a solution, and he came up with #line, which allowed you to say to the C compiler "treat the next line as if it were line nnn in file fff, and following lines as successor lines in file fff.  It instantly solved the problem, and was used multiple times for various applications (probably most notably cfront).  So far as I know, many languages including FORTRAN, Pascal and Python do not have such a mechanism, making it awkward to use them as preprocessor targets. The other thing that I think was pretty unique was the search path for include files (-I on the compilers).   When writing the portable C compiler, I had a directory of source and header files that were machine independent, and other directories that were specific to different target architectures.   Just by changing the command line you could compile for any desired architecture.  This would have been a maintenance nightmare if I'd had to make different makefiles for each desired language and keep them all in sync. Steve ----- Original Message ----- From: "Clem Cole" To: "Paul Winalski" Cc: "TUHS main list" Sent: Fri, 29 Dec 2017 15:31:54 -0500 Subject: Re: [TUHS] origin of C header files On Fri, Dec 29, 2017 at 2:28 PM, Paul Winalski wrote: When higher-level languages came along, programmers moving from assembly code to a HLL would want the same sort of preprocessor functionality.  I know that IBM PL/I had %include, and I suspect that other HLLs of the day had similar features. What's very clear is that C did not invent include files or conditional compilation, it merely carried on existing tradition. ​I'll +1 Paul's comment and add a couple of observations.   Languages such a PL/1 and FORTRAN would could support a preprocessor and conditional compilation, were more easy to use to build 'products' - as opposed to Pascal.    Folks did splice an backwards conditi​onal compiling scheme with include files into some Pascal flavors but it was non-standard. Fortran folks used tools like RATFOR or m4, but the key was the there was some why to preprocess code for different targets.   In a production shop, particularly where your 'target' customer was different, this ability becomes more and more of an requirement. I've always said as contemporary production systems programming languages, while BLISS had a better Macro system then C, the include file and conditional scheme worked much better/was much cleaner - to the point that ifdef is abused and the cause of much pain in actual code.   But the truth is that is a success problem.   When used properly, the C header scheme, while not invented by the BTL crew, was pretty much what people needed.   No too fancy, but all the features you really needed and has been lasting. Clem ᐧ Links: ------ [1] mailto:paul.winalski at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Sat Dec 30 11:07:51 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Fri, 29 Dec 2017 20:07:51 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> Message-ID: <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com> In my second career after UNIX, I spent a lot of time writing high performance image processing software that ran on just about every platform out there: Sun3 , Spark, the DEC SPIM, ALPHA, the iTanium (or as we called it the iTanic), HP PA/RISC, Apollo DN10000, SGI from the O2 and the Indy all the way up to the reality engines, Stellar, Ardent, IBM RS6000, Masspar, weird IBM things like the W4 card in the PS/2, i860 OKI workstatiosn, Intergraph Clippers, and probably more I'm forgetting. The Alpha was hot stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly OSF/1. I remember one day Stardant called and said they needed the G1000 they loaned us right back. I boxed it up (it was a tradeshow machine and came in a road case). I set it on the loading dock. The next day Stardent announced they were going out of business. A year later I was out on the loading dock and "hey, is this stupid thing still here." A few minutes later I get a call from our sales guy. He's got a call from a guy looking for a copy of Motif for the Stellar G1000. I laugh. He says "I know, they're out of business." I said, "Yes, but today's your lucky day. I still have one." I powed it up, pulled off the Motif to send the guy and then trashed the machine. One of my coowrkers "decapitated" the WysePC the thing had on top of it as a control/bootup processor. We had one of the CPU cards on the wall as a "art" for a while. From kevin.bowling at kev009.com Sat Dec 30 11:47:18 2017 From: kevin.bowling at kev009.com (Kevin Bowling) Date: Fri, 29 Dec 2017 18:47:18 -0700 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> References: <20171229163832.GA17231@mcvoy.com> <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> Message-ID: That is awesome, thanks for the story and link. Enlightening to read about how the coherence protocol was developed in software. How was the ISA, and I assume even implementation detail, kept equal or close enough to the eventual microprocessor parts? Does the "Privileged Architecture Library" mean it was effectively microcoded? What kind of software structure was used to provide the I/O channel on the DECStations, for instance did it map the other TURBOChannel devices into the demo's address space so it ran the stock device drivers, or was the I/O server software intermediating a mailbox for doing SCSI, Ethernet etc with a different device model? Reminds me of a book I really liked "The Supermen: The Story of Seymour Cray and the Technical Wizards Behind the Supercomputer", especially Seymour Cray's willingness to throw out convention and redefine the game. Corollary to Larry's point about CPU designers losing by only competing against their own last design.. you can either make new markets or lead in the ongoing one, not a lot of air outside that. Regards, On Fri, Dec 29, 2017 at 5:54 PM, Lawrence Stewart wrote: > I'll chime in just to say that designing with ECL was one hell of a lot of > fun compared to TTL. > > The first Alpha chip (EV3) had pad drivers that could be configured for TTL > levels or for ECL levels. In fact, a good chunk of the ISSCC paper is about > the pad driver. > > I was part of the team that built the first Alpha machine, the Alpha > Demonstration Unit, see > ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF > > For a limited number of machines, with power no object we were able to make > an unabashed ECL design using the ECL 100K logic family, the ECLinPS family > (300 ps gate delays) and some custom Gigabit Logic Gallium Arsenide parts > for the memory board address line drivers. > > We got power supply cables from a local valley welding shop and had them cut > to length. The shop owner wanted to know “what kind of a welder needs 18” > cables?” The issue was the 400 Amps of -4.5 v. Each jelly bean chip was > between 1/2 and 1 watt IIRC. > > The beauty of ECL is that it is perfectly happy to drive 50 ohm transmission > lines, with shunt termination. This gives you incident wave switching and > really beautiful signal integrity. I think if Cray had tried to build the > Cray 1 with anything other than ECL it just would never have worked > reliably, especially with such long wires needed. > > Essentially, ECL let you build big machines with the same reliability that > could only be achieved with small machines using TTL. Great stuff if you > can afford the power consumption. > > In the same way that it is worthwhile to own a sports car at least once in > your life, it was a joy to build an ECL design. > > -Larry > > > On 2017, Dec 29, at 6:54 PM, Kevin Bowling wrote: > > I trust your judgement and experience WRT the Alpha. > > If you're looking for massive performance deltas, what about ECL > designs like the IBM 3090 and Cray designs in the late '80s/ early > '90s? I believe those were not a multiple but a magnitude faster than > contemporaries. > > Regards, > > From paul.winalski at gmail.com Sat Dec 30 11:52:00 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 29 Dec 2017 20:52:00 -0500 Subject: [TUHS] origin of C header files In-Reply-To: References: Message-ID: On 12/29/17, Steve Johnson wrote: > I begged Dennis for a solution, and he came up with #line, > which allowed you to say to the C compiler "treat the next line as if > it were line nnn in file fff, and following lines as successor lines > in file fff. It instantly solved the problem, and was used multiple > times for various applications (probably most notably cfront). So > far as I know, many languages including FORTRAN, Pascal and Python do > not have such a mechanism, making it awkward to use them as > preprocessor targets. Language processing systems where the preprocessor functionality is implemented as a part of the compiler itself never had the "associate the error message with the line in the original source" problem that you described. The compiler could keep an internal table mapping the lexical output of the preprocessor to the source lines/files that went into the preprocessor phase. Most (all?) of DEC's and IBM's compilers operate this way. In keeping with UNIX's philosophy of "one image/one purpose", C's preprocessor functionality was in a separate image from the compiler itself. There are many advantages to this design, including that cpp can then be used for other languages than C. But is has the disadvantage of introducing the source correlation problem that required the introduction of #line. -Paul W. From stewart at serissa.com Sat Dec 30 12:19:41 2017 From: stewart at serissa.com (Lawrence Stewart) Date: Fri, 29 Dec 2017 21:19:41 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> Message-ID: (Both the ADU and the DECstation front end ran OSF-1 or Ultrix, which was unix-y, although the ADU itself did run VMS as a second OS :) ) If I remember correctly, the OS running on the ADU itself had what we would now call paravirtualized drivers - they just handed off packets or disk block I/Os to the I/O service program running on the DECStation. The ADU device drivers just managed ring buffers of requests, rather than raw SCSI commands destined for the real I/O devices. PALcode is an Alpha thing, so that code running in PAL mode was responsible for things like TLB loads that might be different from model to model. Anything that was too expensive to implement in hardware or too infrequent to bother with got punted to PAL. PALcode was just ordinary Alpha assembler code, sometimes written in C I imagine, but it had to be very careful not to cause any faults or traps that required PALcode to implement. The EV3 was an early Alpha chip, in, I think, .9 micron CMOS, that did not have an FPU, so the floating point was emulated. The first products were 200 MHz EV4 machines that were in .75 micron CMOS. The 3 and 4 refer to Digital code names for CMOS processes. The EV stands for “Electric Vlasic” because the chip design team was fond of sticking nails into dill pickles and plugging them into the wall. The pickles could be seen to glow in a dark room before starting to smoke. Ken Olsen came to visit the lab and wanted to know why we had christmas tree lights decorating the ADU chassis. We explained it was a safety feature, to remind people the power was on. 400 amps was nothing to fool around with. No wedding rings allowed in the lab. -Larry > On 2017, Dec 29, at 8:47 PM, Kevin Bowling wrote: > > That is awesome, thanks for the story and link. Enlightening to read > about how the coherence protocol was developed in software. How was > the ISA, and I assume even implementation detail, kept equal or close > enough to the eventual microprocessor parts? Does the "Privileged > Architecture Library" mean it was effectively microcoded? What kind > of software structure was used to provide the I/O channel on the > DECStations, for instance did it map the other TURBOChannel devices > into the demo's address space so it ran the stock device drivers, or > was the I/O server software intermediating a mailbox for doing SCSI, > Ethernet etc with a different device model? > > Reminds me of a book I really liked "The Supermen: The Story of > Seymour Cray and the Technical Wizards Behind the Supercomputer", > especially Seymour Cray's willingness to throw out convention and > redefine the game. Corollary to Larry's point about CPU designers > losing by only competing against their own last design.. you can > either make new markets or lead in the ongoing one, not a lot of air > outside that. > > Regards, > > On Fri, Dec 29, 2017 at 5:54 PM, Lawrence Stewart wrote: >> I'll chime in just to say that designing with ECL was one hell of a lot of >> fun compared to TTL. >> >> The first Alpha chip (EV3) had pad drivers that could be configured for TTL >> levels or for ECL levels. In fact, a good chunk of the ISSCC paper is about >> the pad driver. >> >> I was part of the team that built the first Alpha machine, the Alpha >> Demonstration Unit, see >> ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/DTJ/DTJ803/DTJ803PF.PDF >> >> For a limited number of machines, with power no object we were able to make >> an unabashed ECL design using the ECL 100K logic family, the ECLinPS family >> (300 ps gate delays) and some custom Gigabit Logic Gallium Arsenide parts >> for the memory board address line drivers. >> >> We got power supply cables from a local valley welding shop and had them cut >> to length. The shop owner wanted to know “what kind of a welder needs 18” >> cables?” The issue was the 400 Amps of -4.5 v. Each jelly bean chip was >> between 1/2 and 1 watt IIRC. >> >> The beauty of ECL is that it is perfectly happy to drive 50 ohm transmission >> lines, with shunt termination. This gives you incident wave switching and >> really beautiful signal integrity. I think if Cray had tried to build the >> Cray 1 with anything other than ECL it just would never have worked >> reliably, especially with such long wires needed. >> >> Essentially, ECL let you build big machines with the same reliability that >> could only be achieved with small machines using TTL. Great stuff if you >> can afford the power consumption. >> >> In the same way that it is worthwhile to own a sports car at least once in >> your life, it was a joy to build an ECL design. >> >> -Larry >> >> >> On 2017, Dec 29, at 6:54 PM, Kevin Bowling wrote: >> >> I trust your judgement and experience WRT the Alpha. >> >> If you're looking for massive performance deltas, what about ECL >> designs like the IBM 3090 and Cray designs in the late '80s/ early >> '90s? I believe those were not a multiple but a magnitude faster than >> contemporaries. >> >> Regards, >> >> From paul.winalski at gmail.com Sat Dec 30 12:20:09 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 29 Dec 2017 21:20:09 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> Message-ID: On 12/29/17, Kevin Bowling wrote: > Enlightening to read > about how the coherence protocol was developed in software. How was > the ISA, and I assume even implementation detail, kept equal or close > enough to the eventual microprocessor parts? Does the "Privileged > Architecture Library" mean it was effectively microcoded? Yes, IMO the Alpha PALcode was a form of microcode. DEC designed the Alpha ISA with the hardware folks working closely with the VMS and DEC UNIX (soon to become Tru64 UNIX) OS groups to insure that the correct balance of PALcode vs. implemented-in-hardware was struck. -Paul W. From paul.winalski at gmail.com Sat Dec 30 12:30:11 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 29 Dec 2017 21:30:11 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com> References: <20171229163832.GA17231@mcvoy.com> <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com> Message-ID: On 12/29/17, Ron Natalie wrote: > The Alpha was hot > stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly > OSF/1. Digital UNIX for the VAX was indeed derived from OSF/1. The port to Alpha was called Tru64 UNIX. Tru64 UNIX was initially a pure 64-bit system, with no provision for building or running 32-bit program images. This turned out to be a mistake . DEC found out that a lot of ISVs had code that implicitly "knew" that sizeof() a pointer was the same as sizeof(int) was the same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility mode. There was also a problem with the C compiler initially developed at DECwest in Seattle. It supported ONLY ANSI standard C and issued fatal errors for violations/extensions of the standard. We (DEC mainstream compiler group) called it the Rush Limbaugh compiler--extremely conservative, and you can't argue with it. -Paul W. From paul.winalski at gmail.com Sat Dec 30 12:35:17 2017 From: paul.winalski at gmail.com (Paul Winalski) Date: Fri, 29 Dec 2017 21:35:17 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> Message-ID: On 12/29/17, Lawrence Stewart wrote: > > The EV3 was an early Alpha chip, in, I think, .9 micron CMOS, that did not > have an FPU, so the floating point was emulated. The first products were > 200 MHz EV4 machines that were in .75 micron CMOS. Yes. EV3 was a prototype, really, released as a development breadboard platform for early adopters and ISVs. EV4 was the first production Alpha. -Paul W. From doug at cs.dartmouth.edu Sun Dec 31 12:32:08 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 30 Dec 2017 21:32:08 -0500 Subject: [TUHS] origin of C header files Message-ID: <201712310232.vBV2W8rl014861@coolidge.cs.Dartmouth.EDU> Warning: off-topic info > I was told once that McIlroy and Morris invented macro instructions > for assembly language.   And certainly they wrote the definitive > paper on macros, with, as I recall, something like 10 decisions you > needed to make about a macro processor and you could generate 1024 > different macro systems that way.  I wonder if that ever got > published The suggestion that I invented macros can also be found on-line, but it's not true. I learned of macros in 1957 or before. GE had added a basic macro capability to an assembler; I don't know whether they invented the idea or borrowed it. In 1959 George Mealy suggested that Bell Labs install a similar facility in SAP (SHARE assembly program). Doug Eastwood wrote the definition part and I handled expansions. Vic Vyssotsky later asked whether a macro could define a macro--a neat idea that was obviously useful. When we went to demonstrate it, we were chagrinned that it didn't work: definition happening during expansion resulted in colliding calls to a low-level string-handling subroutine that was not re-entrant. Once that was fixed, Steve Johnson (as a high-school intern!) observed that it allowed the macro table to serve as an addressable memory, for which the store and load operations were MOP (macro define) and MAC (macro call). Probably before Steve's bright insight, Eastwood had folded the separate macro table into the opcode table, and I had implemented conditional assembly, iteration over a list, and automatic generation of symbols. These features yielded a clean Turing-complete language-extension mechanism. I believe we were the first to achieve this power via macros. However, with GPM, Christopher Strachey showed you don't need conditionals; the ability to generate new macro names is enough. It's conceivable, but unlikely, that this trick could be done with earlier macro mechanisms. As for publication, our macroprocessor inspired my CACM paper, "Macro nstruction extension of compiler languages", but the note that Steve remembers circulated only in the Labs. A nontrivial example of our original macros in action--a Turing machine simulator that ran completely within the assembler--was reproduced in Peter Wegner's programming book, so confusingly described that I am glad not to have been acknowledged as the original author. Doug From henry.r.bent at gmail.com Sun Dec 31 12:47:02 2017 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 30 Dec 2017 21:47:02 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> References: <20171229163832.GA17231@mcvoy.com> <4D7D27C2-CEDB-4C62-A8B9-AF61CEB96B9C@serissa.com> Message-ID: On 29 December 2017 at 19:54, Lawrence Stewart wrote: > > I was part of the team that built the first Alpha machine, the Alpha > Demonstration Unit, see > ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/DEC/ > DTJ/DTJ803/DTJ803PF.PDF > I couldn't access this on my phone - no FTP client - so I blindly assumed that it was DEC Technical Journal Vol. 8 no. 3. That turned out to be completely untrue, but in a perhaps amusing way - one of the articles was Bob Supnik discussing the reasoning behind the original development of SIM(H), intended to preserve computing history. As far as the article you posted - from Vol. 4 no. 3 - the idea that 35 prototypes were created in ECL and running as a multiprocessor system, taking over 4kW not including the front end, is absolutely remarkable to me. Does any of that original code for the front end still exist? -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From henry.r.bent at gmail.com Sun Dec 31 13:00:18 2017 From: henry.r.bent at gmail.com (Henry Bent) Date: Sat, 30 Dec 2017 22:00:18 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com> Message-ID: On 29 December 2017 at 21:30, Paul Winalski wrote: > On 12/29/17, Ron Natalie wrote: > > The Alpha was hot > > stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly > > OSF/1. > > Digital UNIX for the VAX was indeed derived from OSF/1. The port to > Alpha was called Tru64 UNIX. > > Tru64 UNIX was initially a pure 64-bit system, with no provision for > building or running 32-bit program images. This turned out to be a > mistake . DEC found out that a lot of ISVs had code that implicitly > "knew" that sizeof() a pointer was the same as sizeof(int) was the > same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility > mode. > > There was also a problem with the C compiler initially developed at > DECwest in Seattle. It supported ONLY ANSI standard C and issued > fatal errors for violations/extensions of the standard. We (DEC > mainstream compiler group) called it the Rush Limbaugh > compiler--extremely conservative, and you can't argue with it. > I'm curious about this. As far as I know the development of the released OS for the Alpha went this way: (OSF/1 reference) -> (OSF/1 for MIPS) -> OSF/1 V[1.2, 2, 3.0] -> Digital UNIX [3.2, 4] -> Tru64[5]. Was there ever a branch of this for the VAX? And was the frontend for the compiler for the Alpha not the same as for the DECstations? That had the -std options to switch between K&R, "compatibility," and pure ANSI. My DECstation isn't up right now but I believe its compiler under OSF/1 could even take the Sun compiler options, -Xc, -Xa, etc. -Henry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Sun Dec 31 15:20:06 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 31 Dec 2017 12:20:06 +0700 Subject: [TUHS] Why did PDPs become so popular? Message-ID: A bit off the PDPs, but to do a minor correction on mail below The commercial version of 'UNIX' on Alpha was maybe first called Digital Unix OSF/1, but quickly changed to Digital Unix at least with v3 and v4.0 (A - G). From there we had a 'break' which only in part was due to take over by Compaq and we had Tru64 UNIX v5.1A and V5.1B. The V5.1B saw updates till B-6. As for the Digital C compiler, I'm still using DTCCMPLR650 installed Compaq C Version 6.5 for Compaq Tru64 UNIX Systems When I get some old source (some even developed on SCO UNIX 3.2V4.2) I like to run it through all compiler /OS-es I got handy. With the Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a few errors. By the time I 'corrected' what I think is relevant some nasty coredumps tend to disappear :-) Compile for a better 2018, uncle rubl >Date: Fri, 29 Dec 2017 21:30:11 -0500. >From: Paul Winalski >To: Ron Natalie >Cc: TUHS main list >Subject: Re: [TUHS] Why did PDPs become so popular? >Message-ID: Content-Type: text/plain; charset="UTF-8" > >On 12/29/17, Ron Natalie wrote: > The Alpha was hot > stuff for about nine months. Ran OSF/1 formerly DigitalUnix formerly > OSF/1. >Digital UNIX for the VAX was indeed derived from OSF/1. The port to >Alpha was called Tru64 UNIX. >Tru64 UNIX was initially a pure 64-bit system, with no provision for >building or running 32-bit program images. This turned out to be a >mistake . DEC found out that a lot of ISVs had code that implicitly >"knew" that sizeof() a pointer was the same as sizeof(int) was the >same as 4 bytes. Tru64 was forced to implement a 32-bit compatibility >mode. >There was also a problem with the C compiler initially developed at >DECwest in Seattle. It supported ONLY ANSI standard C and issued >fatal errors for violations/extensions of the standard. We (DEC >mainstream compiler group) called it the Rush Limbaugh >compiler--extremely conservative, and you can't argue with it. From arrigo at alchemistowl.org Sun Dec 31 19:59:12 2017 From: arrigo at alchemistowl.org (Arrigo Triulzi) Date: Sun, 31 Dec 2017 10:59:12 +0100 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: <20171229163832.GA17231@mcvoy.com> <091301d3810a$9df2d6b0$d9d88410$@ronnatalie.com> Message-ID: <0890C038-B442-4F57-86AD-243D17D43F77@alchemistowl.org> On 31 Dec 2017, at 04:00, Henry Bent wrote: > I'm curious about this. As far as I know the development of the released OS for the Alpha went this way: > (OSF/1 reference) -> (OSF/1 for MIPS) -> OSF/1 V[1.2, 2, 3.0] -> Digital UNIX [3.2, 4] -> Tru64[5]. Was there ever a branch of this for the VAX? Actually OSF/1 T1.0 was shipped to customers. I know because it was on the three Alphas we received at Imperial College in the UK. It also came with an early version of MX, the 32-bit MIPS to 64-bit Alpha translator which we used to get Ghostscript working (essential for our Mathematicians, after getting TeX to compile). We tried to get Ghostscript ported as soon as the machines were up but failed miserably and were (still am, actually) grateful for MX saving the day. Arrigo From clemc at ccc.com Sun Dec 31 22:56:06 2017 From: clemc at ccc.com (Clement T. Cole) Date: Sun, 31 Dec 2017 07:56:06 -0500 Subject: [TUHS] Why did PDPs become so popular? In-Reply-To: References: Message-ID: <456D24C3-022E-4D04-92A4-31496B408E7A@ccc.com> > On Dec 31, 2017, at 12:20 AM, Rudi Blom wrote: > > .With the > Compaq C compiler and HP-UX ANSI C I mostly get pages of warning and a > few errors. By the time I 'corrected' what I think is relevant some > nasty coredumps tend to disappear :-) I had to chuckle when we read these two lines. As Paul I’m sure also remembers and mentioned about the 32/64 bit issues, when we released Alpha there we very few to zero tools available to help find errors in ISV or customer created C code that was caused by assumptions of size. As you point out with the new ‘Gem’ compilers a great deal of work was spent by Paul and his brothers and sisters in the compiler group putting in just those messages. For C++ it was worse than C because the language was so new at the time few tools for it existed. So one of our engineers, Judy Ward, lead the effort to make the C++ front end be extremely useful and offered extremely good errors and warnings (she also had worked on the C FE before that). When people complained about the compiler before no so “noisy” my response was “Listen to Judy’s advise. She’s seeing something you are not and she knows more about C and C++ that all of the rest of us.” We discovered a curious thing. The ISVs reported way fewer bugs after the Alpha port because Judy’s messages forced them to clean up long standing issues that were silently causing problem on other systems. I’ve always said Alpha C and C++ compilers was the greatest gift to the Sparc ISVs there was. Like you to this day, except for possibly Gimple’s Flexilint product, the old DEC compilers are still the best tools I have ever used to clean up code. I’ve reminded and thanked Judy for this many times when I seen her. That was a labor of love by some folks that really cared to make a great product as useful as it could be. Clem