From clemc at ccc.com Wed Feb 1 00:19:33 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 31 Jan 2017 09:19:33 -0500 Subject: [TUHS] PDP-10 in the news today In-Reply-To: <20170131081255.GA30074@server.rulingia.com> References: <867f5b8yn9.fsf@molnjunk.nocrew.org> <20170131081255.GA30074@server.rulingia.com> Message-ID: On Tue, Jan 31, 2017 at 3:12 AM, Peter Jeremy wrote: > I suspect this would be more on-topic in PUPS than TUH ​Warren - please correct me if I am mistaken/changed this since the last time I checked up on these things, the PUPS mailing list was retired as the URL for the PUPS mailing list on the PDP Unix Preservation Society Home Page says it is out of date and tells people to go to TUHS and the mailing list URL Subscribe to the PUPS mailing list comes back as "No such list: *pups*" -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Wed Feb 1 05:33:03 2017 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 1 Feb 2017 05:33:03 +1000 Subject: [TUHS] PDP-10 in the news today In-Reply-To: References: <867f5b8yn9.fsf@molnjunk.nocrew.org> <20170131081255.GA30074@server.rulingia.com> Message-ID: <20170131193303.GA30737@minnie.tuhs.org> On Tue, Jan 31, 2017 at 3:12 AM, Peter Jeremy wrote: > I suspect this would be more on-topic in PUPS than TUH On Tue, Jan 31, 2017 at 09:19:33AM -0500, Clem Cole wrote: > Warren - please correct me if I am mistaken/changed this since the > last time I checked up on these things, the PUPS mailing list was > retired. Yes, a while back I merged the two mailing lists so we have only TUHS now. I don't mind a bit of off-topic posting, but an on-going thread which isn't related to Unix isn't so good. Cheers all, Warren From nw at retrocomputingtasmania.com Wed Feb 1 07:07:05 2017 From: nw at retrocomputingtasmania.com (Nigel Williams) Date: Wed, 1 Feb 2017 08:07:05 +1100 Subject: [TUHS] PDP-10 in the news today In-Reply-To: <20170131193303.GA30737@minnie.tuhs.org> References: <867f5b8yn9.fsf@molnjunk.nocrew.org> <20170131081255.GA30074@server.rulingia.com> <20170131193303.GA30737@minnie.tuhs.org> Message-ID: In the wikipedia entry on the DEC PDP-10, it has this comment: "The PDP-10 is the machine that made time-sharing common, and this and other features made it a common fixture in many university computing facilities and research labs during the 1970s..." Is it a reasonable claim that the PDP-10 made time-sharing "common" (note it says "the machine")? I'm presuming that "common" should be read as ubiquitous and accessible (as in lower-cost than competing/alternative options from other manufacturers or even DEC). I'm wondering if it was really the combination of the PDP-11 (lower-cost more models) and Unix ("free" license to universities) that propelled time-sharing, at least at universities. From beebe at math.utah.edu Wed Feb 1 07:17:16 2017 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Tue, 31 Jan 2017 14:17:16 -0700 Subject: [TUHS] PDP-10 in the news today Message-ID: Nigel Williams asks on the TUHS list today: >> ... >> Is it a reasonable claim that the PDP-10 made time-sharing "common" >> (note it says "the machine")? I'm presuming that "common" should be >> read as ubiquitous and accessible (as in lower-cost than >> competing/alternative options from other manufacturers or even DEC). >> >> I'm wondering if it was really the combination of the PDP-11 >> (lower-cost more models) and Unix ("free" license to universities) >> that propelled time-sharing, at least at universities. >> ... I worked on the IBM ATS (Administrative Terminal System) for text processing in the early 1970s, and for several years, on the CDC 6400 under both SCOPE and KRONOS operating systems. Those were mainframe environments, but users scattered around campus accessed them via glass terminals, so that was certainly time sharing. Later, for 12 years (1978--1990), I also worked on TOPS-20 on the PDP-10, and that too was time sharing, with most users having a terminal on their desks. We also had PDP-11 and LSI-11 systems, but they ran DEC proprietary operating systems, and were generally dedicated to particular research hardware. It was only in the early 1980s that my institution also began to run Unix systems, initially Wollongong BSD on VAX 750s, and then in 1987, with our first Sun workstations running SunOS. Thus, for me at least, Unix time sharing came a dozen years late (though it was still welcome, and remains so today). ------------------------------------------------------------------------------- - 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 jnc at mercury.lcs.mit.edu Wed Feb 1 07:33:40 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 31 Jan 2017 16:33:40 -0500 (EST) Subject: [TUHS] PDP-10 in the news today Message-ID: <20170131213340.65D3A18C0D7@mercury.lcs.mit.edu> > From: Nigel Williams > Is it a reasonable claim that the PDP-10 made time-sharing "common" > ... I'm presuming that "common" should be read as ubiquitous and > accessible > I'm wondering if it was really the combination of the PDP-11 Good question; I think a case can be made both ways. > (lower-cost more models) One observation I will make: the two don't have identical time-lines; the earliest PDP-10 models predate the PDP-11 by a good chunk, and the PDP-11 out-lasted the PDP-10. So that has a big influence, I think, on the question above. The first PDP-10 (the KA - we'll leave aside the even earlier PDP-6) was made out of small cards with individual transistors (B-series Flip Chips), whereas the earliest PDP-11 model (the -11/20) used SSI TTL on much larger cards. Ditto on the other end: the last PDP-10 sold used 29xx bit-slice technology, whereas the PDP-11 lasted through three generations of microprocessor (the LSI-11, Fonz, and Jaws). Noel From clemc at ccc.com Wed Feb 1 09:23:27 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 31 Jan 2017 18:23:27 -0500 Subject: [TUHS] PDP-10 in the news today In-Reply-To: <20170131213340.65D3A18C0D7@mercury.lcs.mit.edu> References: <20170131213340.65D3A18C0D7@mercury.lcs.mit.edu> Message-ID: On Tue, Jan 31, 2017 at 4:33 PM, Noel Chiappa wrote: > > From: Nigel Williams > > Is it a reasonable claim that the PDP-10 made time-sharing "common" > ​ ​ > ... I'm presuming that "common" should be read as ubiquitous and accessible > > I'm wondering if it was really the combination of the PDP-11 > > Good question; I think a case can be made both ways. ​I agree. ​ > > > > (lower-cost more models) > > One observation I will make: the two don't have identical time-lines; the > ​ ​ > earliest PDP-10 models predate the PDP-11 by a good chunk, and the PDP-11 > ​ ​ > out-lasted the PDP-10. So that has a big influence, I think, on the > ​q​ > uestion > ​ ​ > above. ​Certainly if you include the virtual address extension - aka VAX to the PDP-11 family - which was birthed in '76.​ Then I would agree the PDP11/VAX/UNIX combo had case for a larger *footprint* for making timesharing "common" from 70-79 -- which is the time period mentioned in the Wikipedia article. But I do think to fair to the Wikipedia authors, the 10 and 20 families during the 1970s were the pretty much the machines that defined the idea of timesharing to most small colleges and smaller universities until UNIX takes its stride. CDC and IBM had a footprint in large and well funded places. But even in those schools, the 10/20 was still king in the CS Dept, until UNIX displaced it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From helbig at mailbox.org Wed Feb 1 20:34:48 2017 From: helbig at mailbox.org (Wolfgang Helbig) Date: Wed, 1 Feb 2017 11:34:48 +0100 (CET) Subject: [TUHS] v6 lecture notes Message-ID: <20170201103449.CF41916F4996@mac.korb> Hi, my site at the ba-stuttgart was removed. It hosted course ware for my unix v6 lecture. This includes: Unix Programmer's Manual (aka man pages) Documents for use with the Unix Time-Sharing System prepared as postscript files. I provided the man pages as HTML-pages with the references replaced by links. The lecture notes contain tips for installing v6 on the simh emulator, a description of the pdp11 instruction set and hardware as well as a description of unix v6, including booting, kernel and user land software. So if anyone is interested let me know. Greetings Wolfgang Helbig Stauferstr. 22 71334 Waiblingen Germany From pnr at planet.nl Thu Feb 2 00:18:56 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 1 Feb 2017 15:18:56 +0100 Subject: [TUHS] shared memory on Unix Message-ID: The presence of some sort of shared memory facility in the BBN V6 Unix kernel got me thinking about the origins of shared memory on Unix. I had a vague recollection that primordial versions were present in either PWB or CB3, but a quick glance at the source indicates that this is not correct. What are the origins of shared memory on Unix, i.e. what came before mmap() and SysV IPC? Was the BBN kernel the first to implement such a facility on Unix? Paul From mah at mhorton.net Thu Feb 2 02:21:46 2017 From: mah at mhorton.net (Mary Ann Horton) Date: Wed, 1 Feb 2017 08:21:46 -0800 Subject: [TUHS] shared memory on Unix In-Reply-To: References: Message-ID: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> I*'m not sure what you mean by CB3, but these features (shared memory, semaphores, IPC) were added to CB-UNIX (Bell Labs, Columbus) precisely because they were needed in real time telco systems and not preset in the versions from New Jersey. This would have been in the early 1980s. When I got there in 1981 I think CB-UNIX was already well established and had these features. (These would show up, ironically, in /usr/ucb, which did not stand for Berkeley.) Mary Ann On 02/01/2017 06:18 AM, Paul Ruizendaal wrote: > The presence of some sort of shared memory facility in the > BBN V6 Unix kernel got me thinking about the origins of > shared memory on Unix. > > I had a vague recollection that primordial versions were present > in either PWB or CB3, but a quick glance at the source indicates > that this is not correct. > > What are the origins of shared memory on Unix, i.e. what came > before mmap() and SysV IPC? Was the BBN kernel the first to > implement such a facility on Unix? > > Paul > From clemc at ccc.com Thu Feb 2 03:18:47 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 12:18:47 -0500 Subject: [TUHS] shared memory on Unix In-Reply-To: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> Message-ID: ​I do not remember the BBN share memory code, but the Columbus shared memory and semaphore changes were certainly known in 1978 and 1979. I remember seeing a man page for them from one of the OYOC types - Phil Karn maybe, but its possible it was tjk. As quick scan of my paper archives, did not turn anything up; and I do not remember any system at CMU that had the code, only looking at a hard copy of the man pages. My memory is that the API changed a little by the time they became the System V API; as I remember thinking that the IPC was "new" when I first saw it in a system that had all three. On Wed, Feb 1, 2017 at 11:21 AM, Mary Ann Horton wrote: > I*'m not sure what you mean by CB3, but these features (shared memory, > semaphores, IPC) were added to CB-UNIX (Bell Labs, Columbus) precisely > because they were needed in real time telco systems and not preset in the > versions from New Jersey. This would have been in the early 1980s. When I > got there in 1981 I think CB-UNIX was already well established and had > these features. (These would show up, ironically, in /usr/ucb, which did > not stand for Berkeley.) > > Mary Ann > > > > On 02/01/2017 06:18 AM, Paul Ruizendaal wrote: > >> The presence of some sort of shared memory facility in the >> BBN V6 Unix kernel got me thinking about the origins of >> shared memory on Unix. >> >> I had a vague recollection that primordial versions were present >> in either PWB or CB3, but a quick glance at the source indicates >> that this is not correct. >> >> What are the origins of shared memory on Unix, i.e. what came >> before mmap() and SysV IPC? Was the BBN kernel the first to >> implement such a facility on Unix? >> >> Paul >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schily at schily.net Thu Feb 2 03:24:01 2017 From: schily at schily.net (Joerg Schilling) Date: Wed, 01 Feb 2017 18:24:01 +0100 Subject: [TUHS] shared memory on Unix In-Reply-To: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> Message-ID: <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Mary Ann Horton wrote: > I*'m not sure what you mean by CB3, but these features (shared memory, > semaphores, IPC) were added to CB-UNIX (Bell Labs, Columbus) precisely > because they were needed in real time telco systems and not preset in > the versions from New Jersey. This would have been in the early 1980s. > When I got there in 1981 I think CB-UNIX was already well established > and had these features. (These would show up, ironically, in /usr/ucb, > which did not stand for Berkeley.) Wasn't shmget() and friends added vor SysV past 1982? Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From rochkind at basepath.com Thu Feb 2 03:39:23 2017 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 1 Feb 2017 10:39:23 -0700 Subject: [TUHS] shared memory on Unix In-Reply-To: <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Message-ID: The so-called Columbus shared memory feature was in their system in the mid-1970s, along with a few other things such as semaphores and inter-process messages. I seem to recall the acronym MAUG, but I may have a letter or two wrong. Something like Multi Access User ____. The much later System V features had a completely different API. Hey, Doug, do you remember this? In the early 1970s, there were a couple of UNIX meetings at Murray Hill, at which various Bell Labs groups presented on what they were doing with UNIX, and a group, perhaps Columbus, said that UNIX wasn't capable of doing what they wanted, so they had modified it. You asked the question, "Why are you using UNIX?" To my knowledge, having witnessed another decade or so of groups trying to bend UNIX to their will, it was the last time the question was asked. --Marc On Wed, Feb 1, 2017 at 10:24 AM, Joerg Schilling wrote: > Mary Ann Horton wrote: > > > I*'m not sure what you mean by CB3, but these features (shared memory, > > semaphores, IPC) were added to CB-UNIX (Bell Labs, Columbus) precisely > > because they were needed in real time telco systems and not preset in > > the versions from New Jersey. This would have been in the early 1980s. > > When I got there in 1981 I think CB-UNIX was already well established > > and had these features. (These would show up, ironically, in /usr/ucb, > > which did not stand for Berkeley.) > > Wasn't shmget() and friends added vor SysV past 1982? > > Jörg > > -- > EMail:joerg at schily.net (home) Jörg Schilling D-13353 > Berlin > joerg.schilling at fokus.fraunhofer.de (work) Blog: > http://schily.blogspot.com/ > URL: http://cdrecord.org/private/ http://sourceforge.net/ > projects/schilytools/files/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 04:01:44 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 13:01:44 -0500 Subject: [TUHS] shared memory on Unix In-Reply-To: <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Message-ID: On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling wrote: > Wasn't shmget() and friends added vor SysV past 1982? ​AT&T Unix naming get's weird as they hire marketing people that don't quite get it. V6 -> PWB [1.0 ~77] ---| | | + UNIX/TS[~79] -- +​ PWB 2.0 [~79] ----- PWB 3.0[~80] <-- internal name of release The "UNIX Support Group" - aka Summit - is supposed to be creating UNIX flavors for the different labs and operating companies and Research is to go back to doing research. Thus PWB 3.0 is supposed to start to be a "superset" of the features added by the different labs, Columbus, IH, *etc*... But it took a few spins before all the different hacks, additions were agreed too and added. There was much fighting inside of BTL as we see outside. IIRC an unreleased version of PWB 4.0 had the Columbus features in it as Horton points out. Note that AT&T Marketing renames PWB 3.0 -- System III thinking that "Programmer's Workbench" would be a bad name to sell against IBM, and this it the first non-research system for License outside of the the labs. If you look at the documentation set, et al - it all says PWB 3.0 on the cover and throughout Also, the BSD vs AT&T wars basically start around this time.... Roll the clock forward and here is an new problem the PWB 4.0 moniker was used internally, but AT&T marketing want to get rid of the PWB term - so the decree comes down the next release is to be called System V. Certainly by this point, the Columbus changes had been folded into the main line kernel in Summit by then. But as I said, my memory is what made it into SystemV and what was in CB-UNIX were similar but a little different. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 04:04:30 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 13:04:30 -0500 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Message-ID: On Wed, Feb 1, 2017 at 12:39 PM, Marc Rochkind wrote: > The so-called Columbus shared memory feature was in their system in the > mid-1970s, along with a few other things such as semaphores and > inter-process messages. I seem to recall the acronym MAUG, but I may have a > letter or two wrong. Something like Multi Access User ____. The much later > System V features had a completely different API. > ​This is in sync with my memory of the time.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochkind at basepath.com Thu Feb 2 04:07:12 2017 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 1 Feb 2017 11:07:12 -0700 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Message-ID: OK, just remembered. That acronym for the Columbus shared memory was MAUS, pronounced "mouse". Multi Access User Space. --Marc On Wed, Feb 1, 2017 at 11:01 AM, Clem Cole wrote: > > On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling > wrote: > >> Wasn't shmget() and friends added vor SysV past 1982? > > > ​AT&T Unix naming get's weird as they hire marketing people that don't > quite get it. > > V6 -> PWB [1.0 ~77] ---| > | | > + UNIX/TS[~79] -- +​ PWB 2.0 [~79] ----- PWB 3.0[~80] <-- > internal name of release > > > The "UNIX Support Group" - aka Summit - is supposed to be creating UNIX > flavors for the different labs and operating companies and Research is to > go back to doing research. Thus PWB 3.0 is supposed to start to be a > "superset" of the features added by the different labs, Columbus, IH, > *etc*... But it took a few spins before all the different hacks, > additions were agreed too and added. There was much fighting inside of > BTL as we see outside. > > IIRC an unreleased version of PWB 4.0 had the Columbus features in it as > Horton points out. > > Note that AT&T Marketing renames PWB 3.0 -- System III thinking that > "Programmer's Workbench" would be a bad name to sell against IBM, and this > it the first non-research system for License outside of the the labs. If > you look at the documentation set, et al - it all says PWB 3.0 on the cover > and throughout Also, the BSD vs AT&T wars basically start around this > time.... > > Roll the clock forward and here is an new problem the PWB 4.0 moniker was > used internally, but AT&T marketing want to get rid of the PWB term - so > the decree comes down the next release is to be called System V. > > Certainly by this point, the Columbus changes had been folded into the > main line kernel in Summit by then. But as I said, my memory is what made > it into SystemV and what was in CB-UNIX were similar but a little different. > > Clem > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schily at schily.net Thu Feb 2 04:15:14 2017 From: schily at schily.net (Joerg Schilling) Date: Wed, 01 Feb 2017 19:15:14 +0100 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Message-ID: <589225b2.YZDGL8idi2AuxrxR%schily@schily.net> Clem Cole wrote: > On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling wrote: > > > Wasn't shmget() and friends added vor SysV past 1982? > > > ???AT&T Unix naming get's weird as they hire marketing people that don't > quite get it. > > V6 -> PWB [1.0 ~77] ---| > | | > + UNIX/TS[~79] -- +??? PWB 2.0 [~79] ----- PWB 3.0[~80] <-- > internal name of release > > > The "UNIX Support Group" - aka Summit - is supposed to be creating UNIX > flavors for the different labs and operating companies and Research is to > go back to doing research. Thus PWB 3.0 is supposed to start to be a BTW: Is this: /*--------------------------------------------------------------------------*/ PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB) TO: All BISP Programmer's Workbench (PWB) Users SUBJECT: Release 4.0 of SCCS/PWB /*--------------------------------------------------------------------------*/ Release 4.0 of SCCS or release 4.0 of PWB? From rochkind at basepath.com Thu Feb 2 04:32:29 2017 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 1 Feb 2017 11:32:29 -0700 Subject: [TUHS] shared memory on Unix In-Reply-To: <589225b2.YZDGL8idi2AuxrxR%schily@schily.net> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> <589225b2.YZDGL8idi2AuxrxR%schily@schily.net> Message-ID: First, to explain a bit, BISP stood for Business Information System Programs (or something like that), and referred to a part of Bell Labs at Piscataway that was originally staffed by Telephone Company personnel, for the purpose of writing software for use by the Companies. The idea is that they would send people on temporary assignment, they would code up the programs, and then return home, job done. When I got to Bell Labs, in 1970 the operation was alive, but by 1972 it was obvious that it was a failure, so the organization was grafted onto Bell Labs (department numbers 9xxx), the temporaries were sent home, and Bell Labs people were moved in or hired. That gave me a great opportunity, so I transferred there. Vic Vyssotsky, a real blue-blood Bell Labs guy, went over to run it. My department head was Rudd Canaday, another genuine Bell Labs guy. That's where I did SCCS. I'm almost sure that SCCS/PWB refers to SCCS, not to the OS. By the time of this memo (1977) I was long-gone from SCCS, and was working under Rudd on a new system to produce telephone directories. --Marc On Wed, Feb 1, 2017 at 11:15 AM, Joerg Schilling wrote: > Clem Cole wrote: > > > On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling > wrote: > > > > > Wasn't shmget() and friends added vor SysV past 1982? > > > > > > ???AT&T Unix naming get's weird as they hire marketing people that don't > > quite get it. > > > > V6 -> PWB [1.0 ~77] ---| > > | | > > + UNIX/TS[~79] -- +??? PWB 2.0 [~79] ----- PWB 3.0[~80] <-- > > internal name of release > > > > > > The "UNIX Support Group" - aka Summit - is supposed to be creating UNIX > > flavors for the different labs and operating companies and Research is to > > go back to doing research. Thus PWB 3.0 is supposed to start to be a > > BTW: Is this: > > /*---------------------------------------------------------- > ----------------*/ > PY-77-05(PWB PIB) 2/22/77 PY-77-05(PWB PIB) > > > TO: > > All BISP Programmer's Workbench (PWB) Users > > SUBJECT: > > Release 4.0 of SCCS/PWB > /*---------------------------------------------------------- > ----------------*/ > > Release 4.0 of SCCS or release 4.0 of PWB? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Feb 2 04:33:05 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 01 Feb 2017 11:33:05 -0700 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> Message-ID: <201702011833.v11IX5Yu017326@freefriends.org> Clem Cole wrote: > Note that AT&T Marketing renames PWB 3.0 -- System III thinking that > "Programmer's Workbench" would be a bad name to sell against IBM, and this > it the first non-research system for License outside of the the labs. If > you look at the documentation set, et al - it all says PWB 3.0 on the cover > and throughout Also, the BSD vs AT&T wars basically start around this > time.... > > Roll the clock forward and here is an new problem the PWB 4.0 moniker was > used internally, but AT&T marketing want to get rid of the PWB term - so > the decree comes down the next release is to be called System V. Sort of. I did some contract work for Southern Bell circa 1983. They were still part of the Bell System then. I worked on a PDP-11 running Unix 4.0. At the time, the policy was to release externally one version behind what was being run internally, so System III was released to the world while the Bell System was using Unix 4.0. I still have the manual; I'm pretty sure "PWB" and "Programmer's Workbench" are not on the cover, it was just called "UNIX". As UNIX 5.0 was approaching, someone decided that to be one release behind on the outside was dumb, thus the jump from System III to System V. The doc I have describes UNIX as an operating system for the PDP-11, the VAX 11/780 *and* the IBM S/370 series of systems and the source code directory had the machine dependent bits for the IBM. Too bad that stuff never made it out. It's too bad that all I have is just the paper, but that's all I could get. That was a fun job, I learned a lot. Over lunch every day I read a few more pages of the manual, basically reading it from cover to cover by the time I was done. What a great way to learn the system! Arnold From schily at schily.net Thu Feb 2 04:35:50 2017 From: schily at schily.net (Joerg Schilling) Date: Wed, 01 Feb 2017 19:35:50 +0100 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> <589225b2.YZDGL8idi2AuxrxR%schily@schily.net> Message-ID: <58922a86.5PutwR+d+Mom82Bd%schily@schily.net> Marc Rochkind wrote: > I'm almost sure that SCCS/PWB refers to SCCS, not to the OS. By the time of > this memo (1977) I was long-gone from SCCS, and was working under Rudd on a > new system to produce telephone directories. Interesting.... does this mean that you did not do the rework that defined the new ASCII based history file format? Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From scj at yaccman.com Thu Feb 2 05:11:35 2017 From: scj at yaccman.com (Steve Johnson) Date: Wed, 01 Feb 2017 11:11:35 -0800 Subject: [TUHS] shared memory on Unix In-Reply-To: <201702011833.v11IX5Yu017326@freefriends.org> Message-ID: I can't speak for the dates, but Ken did a hack to the OS to interface with his Chess machine.  Recall that all the I/O on the PDP-11 was memory mapped, so as I recall he simply mapped a piece of kernel memory into user space.  Was never privvy to the details. I do remember a conversation with Dennis about semaphores, though.  He mentioned that no less than five groups inside of Bell Labs had hacked semaphores into the kernel.  Each group did it differently.  He thought they were all a bad idea -- his argument was, "what do you do if a process sets a semaphore and then dies?  It's pretty clear that either releasing the semaphore or leaving it set would be catastrophic in some cases."  (Of course there were other similar problems, such as a process closing its files and dying, and then the kernel discovering that the disc was full.   Luckily, these days, the disc rarely gets full...) Also, a comment from my own experience with AT&T marketing.  When I was responsible for the System V languages in Summit, I was told that a marketing group was staffed and that there was a person in charge of marketing the language products (at the time, C, Cfront (becoming C++), Fortran, Pascal, and Ada).  I set up a monthly meeting with this person.  The meetings went on for over a year, but _I NEVER MET WITH THE SAME PERSON TWICE!_   It seemed that the only thing the marketing group knew how to do was reorganize the marketing group... At the time, a lot of people buying VAXes were running VMS because its FORTRAN was far better than UNIX F77 -- in particular, it had an optimizer.  I started a project to build an optimizer for FORTRAN, and staffed it with several very good people.  Every six weeks there would be an attempt to kill the project.  Each time I'd repeat the argument for doing it, and it would be saved.  We almost started to put these attempts to kill it on the calendar.  At no time did I get any feedback, positive or negative, from AT&T marketing.   When I left AT&T in early 1986, the optimizer, by now almost complete, was immediately killed again.    I was later told by one of my former team members that it was revived several months later and finally made it out.  And that the next year it was the best-selling add-on to System V. Steve ----- Original Message ----- From: arnold at skeeve.com To:, Cc: Sent:Wed, 01 Feb 2017 11:33:05 -0700 Subject:Re: [TUHS] shared memory on Unix Clem Cole wrote: > Note that AT&T Marketing renames PWB 3.0 -- System III thinking that > "Programmer's Workbench" would be a bad name to sell against IBM, and this > it the first non-research system for License outside of the the labs. If > you look at the documentation set, et al - it all says PWB 3.0 on the cover > and throughout Also, the BSD vs AT&T wars basically start around this > time.... > > Roll the clock forward and here is an new problem the PWB 4.0 moniker was > used internally, but AT&T marketing want to get rid of the PWB term - so > the decree comes down the next release is to be called System V. Sort of. I did some contract work for Southern Bell circa 1983. They were still part of the Bell System then. I worked on a PDP-11 running Unix 4.0. At the time, the policy was to release externally one version behind what was being run internally, so System III was released to the world while the Bell System was using Unix 4.0. I still have the manual; I'm pretty sure "PWB" and "Programmer's Workbench" are not on the cover, it was just called "UNIX". As UNIX 5.0 was approaching, someone decided that to be one release behind on the outside was dumb, thus the jump from System III to System V. The doc I have describes UNIX as an operating system for the PDP-11, the VAX 11/780 *and* the IBM S/370 series of systems and the source code directory had the machine dependent bits for the IBM. Too bad that stuff never made it out. It's too bad that all I have is just the paper, but that's all I could get. That was a fun job, I learned a lot. Over lunch every day I read a few more pages of the manual, basically reading it from cover to cover by the time I was done. What a great way to learn the system! Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochkind at basepath.com Thu Feb 2 05:24:36 2017 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 1 Feb 2017 12:24:36 -0700 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <201702011833.v11IX5Yu017326@freefriends.org> Message-ID: @Joerg: "Interesting.... does this mean that you did not do the rework that defined the new ASCII based history file format?" I'm sure it does, as I have no idea what that is/was. I stopped working on SCCS around 1975 or 1976, about when the IEEE paper was presented. --Marc On Wed, Feb 1, 2017 at 12:11 PM, Steve Johnson wrote: > I can't speak for the dates, but Ken did a hack to the OS to interface > with his Chess machine. Recall that all the I/O on the PDP-11 was memory > mapped, so as I recall he simply mapped a piece of kernel memory into user > space. Was never privvy to the details. > > I do remember a conversation with Dennis about semaphores, though. He > mentioned that no less than five groups inside of Bell Labs had hacked > semaphores into the kernel. Each group did it differently. He thought > they were all a bad idea -- his argument was, "what do you do if a process > sets a semaphore and then dies? It's pretty clear that either releasing > the semaphore or leaving it set would be catastrophic in some cases." > > (Of course there were other similar problems, such as a process closing > its files and dying, and then the kernel discovering that the disc was > full. Luckily, these days, the disc rarely gets full...) > > Also, a comment from my own experience with AT&T marketing. When I was > responsible for the System V languages in Summit, I was told that a > marketing group was staffed and that there was a person in charge of > marketing the language products (at the time, C, Cfront (becoming C++), > Fortran, Pascal, and Ada). I set up a monthly meeting with this person. > The meetings went on for over a year, but *I never met with the same > person twice!* It seemed that the only thing the marketing group knew > how to do was reorganize the marketing group... > > At the time, a lot of people buying VAXes were running VMS because its > FORTRAN was far better than UNIX F77 -- in particular, it had an > optimizer. I started a project to build an optimizer for FORTRAN, and > staffed it with several very good people. Every six weeks there would be > an attempt to kill the project. Each time I'd repeat the argument for > doing it, and it would be saved. We almost started to put these attempts > to kill it on the calendar. At no time did I get any feedback, positive or > negative, from AT&T marketing. When I left AT&T in early 1986, the > optimizer, by now almost complete, was immediately killed again. I was > later told by one of my former team members that it was revived several > months later and finally made it out. And that the next year it was the > best-selling add-on to System V. > > Steve > > > ----- Original Message ----- > From: > arnold at skeeve.com > > To: > , > Cc: > > Sent: > Wed, 01 Feb 2017 11:33:05 -0700 > Subject: > Re: [TUHS] shared memory on Unix > > > > Clem Cole wrote: > > > Note that AT&T Marketing renames PWB 3.0 -- System III thinking that > > "Programmer's Workbench" would be a bad name to sell against IBM, and > this > > it the first non-research system for License outside of the the labs. If > > you look at the documentation set, et al - it all says PWB 3.0 on the > cover > > and throughout Also, the BSD vs AT&T wars basically start around this > > time.... > > > > Roll the clock forward and here is an new problem the PWB 4.0 moniker was > > used internally, but AT&T marketing want to get rid of the PWB term - so > > the decree comes down the next release is to be called System V. > > Sort of. I did some contract work for Southern Bell circa 1983. They > were still part of the Bell System then. I worked on a PDP-11 running > Unix 4.0. At the time, the policy was to release externally one version > behind what was being run internally, so System III was released to the > world while the Bell System was using Unix 4.0. I still have the manual; > I'm pretty sure "PWB" and "Programmer's Workbench" are not on the cover, > it was just called "UNIX". > > As UNIX 5.0 was approaching, someone decided that to be one release > behind on the outside was dumb, thus the jump from System III to System V. > > The doc I have describes UNIX as an operating system for the PDP-11, > the VAX 11/780 *and* the IBM S/370 series of systems and the source > code directory had the machine dependent bits for the IBM. Too bad > that stuff never made it out. > > It's too bad that all I have is just the paper, but that's all I > could get. > > That was a fun job, I learned a lot. Over lunch every day I read a few > more pages of the manual, basically reading it from cover to cover > by the time I was done. What a great way to learn the system! > > Arnold > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 05:30:43 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 14:30:43 -0500 Subject: [TUHS] shared memory on Unix In-Reply-To: <201702011833.v11IX5Yu017326@freefriends.org> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> <201702011833.v11IX5Yu017326@freefriends.org> Message-ID: On Wed, Feb 1, 2017 at 1:33 PM, wrote: > ​.. > At the time, the policy was to release externally one version > behind what was being run internally, so System III was released to the > world while the Bell System was using Unix 4.0. I still have the manual; > I'm pretty sure "PWB" and "Programmer's Workbench" are not on the cover, > ​ ​ > it was just called "UNIX". > ​Could be.... the "System III" manual cover I have says PWB 3.0​ I never had a 4.0 doc, although I saw it at some point. > > As UNIX 5.0 was approaching, someone decided that to be one release > behind on the outside was dumb, thus the jump from System III to System > ​​ > V. > ​Making the outside and inside system in sync makes sense and I think I remember some of that. But the name was definitely forced by the Marketing types in NC. I somewhere have a memo that they sent to all licenses about the term UNIX and how it could be used and what could be called same. It was clear that was all part of the UNIX wars and they were trying to make System xxx have some sort of halo. As a side note, what is funny is when it all went down, I remember having an argument with some of the Masscomp (and ex-DEC) marketing types. The geeks (like me) just could not get through to them that what mattered was how it worked and what was inside (which BSD was pretty much superior technology by most accounts). It was not that Sys III/V was bad, it was just unadorned and claiming it was cool and trying to give it a cool name was not going to make it cool.​ Around this time we came up with the Universes hack, so you can have it both ways; but our kernel was more BSD that AT&T. As I said, funny, because a few years later with Stellar, the same group of people would >>start<< with a System V kernel and fold in BSD interfaces as needed. We wrote our own FS (which was UFS-externally - i.e. BSD user api) but kernel insides completely new (extent based, more like VMS). We had decided that by then the AT&T code base was *cleaner to make scale on a multiprocessor*, as we had already lived the BSD MP nightmare once with the Masscomp kernel. But the key was that even thought we used System V, we made darned sure the user mode API's (such as sockets, mmap, signals, namespaces etc) were the BSD APIs and that the BSD user code from UNIX and that VMS/FORTRAN sources would pretty much compile out of the box. We were at that point targeting Sun, Apollo & VMS customers so we knew it name meant nothing, it was all about how easy it was going to be for the code recompile and "just work". Back to the main point, AT&T Marketing was still chasing IBM at this time. It was amazing to many of us watching the ship sink. They really did not see where the future was and that they owned the SW technology that was going to dive it, but it was going to be sold to people other than whom IBM had traditionally sold. They also made the fatal mistake of trying to grip it too tight and in doing so, it slipped through their fingers. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Feb 2 05:44:34 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Feb 2017 14:44:34 -0500 (EST) Subject: [TUHS] shared memory on Unix Message-ID: <20170201194434.C5DE118C0E8@mercury.lcs.mit.edu> > From: "Steve Johnson" > The meetings went on for over a year, but _I NEVER MET WITH THE SAME > PERSON TWICE!_ It seemed that the only thing the marketing group knew > how to do was reorganize the marketing group... Shades of SI:Electric-Marketing (I _think_ that was its name) on the Symbolics LISP Machine... (For those who never had the joy of seeing this, it randomly drew a bunch of boxes with people in them on the screen in a hierarchy, connected them, and then started randomly moving the boxes around... I wonder if the source still exists - or, better yet, a video of it running? Probably not, alas.) Noel From rminnich at gmail.com Thu Feb 2 05:55:02 2017 From: rminnich at gmail.com (ron minnich) Date: Wed, 01 Feb 2017 19:55:02 +0000 Subject: [TUHS] shared memory on Unix In-Reply-To: <20170201194434.C5DE118C0E8@mercury.lcs.mit.edu> References: <20170201194434.C5DE118C0E8@mercury.lcs.mit.edu> Message-ID: Speaking of this, I remember at the 1980 usenix the discussion of how UCB folks had done a one wire change to allow MFPU (move from previous user space) to function in user mode, thus allowing a kind of weird not quite shared memory IPC. Good times, when you could rip open the machine and make it better ... ron On Wed, Feb 1, 2017 at 11:44 AM Noel Chiappa wrote: > > From: "Steve Johnson" > > > The meetings went on for over a year, but _I NEVER MET WITH THE SAME > > PERSON TWICE!_ It seemed that the only thing the marketing group knew > > how to do was reorganize the marketing group... > > Shades of SI:Electric-Marketing (I _think_ that was its name) on the > Symbolics > LISP Machine... > > (For those who never had the joy of seeing this, it randomly drew a bunch > of > boxes with people in them on the screen in a hierarchy, connected them, and > then started randomly moving the boxes around... I wonder if the source > still exists - or, better yet, a video of it running? Probably not, alas.) > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Thu Feb 2 06:43:27 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 1 Feb 2017 20:43:27 +0000 Subject: [TUHS] Names of famous, historical UNIX machines? Message-ID: <20170201204327.GU21797@yeono.kjorling.se> I hope this isn't too far off topic here. I've been meaning to rename the few systems I administer with names that reference famous (or at least somewhat well-known in the proper circles) historical UNIX systems, but I have been unable to find any lists of such names so have no real place to start. About the closest I _was_ able to find is the ARPANET map[1] of the late 1970s that is on Wikipedia and is occasionally circulated, but which gives mostly architecture, location and links, not any system (host) names. Short of unimaginative things like calling my home router IMP[2] or things like that, can anyone either suggest names with a bit of background (where they were, what hardware, what time period, etc.), or point me toward online resources where I can find lists of those? [1]: https://en.wikipedia.org/wiki/File:Arpanet_logical_map,_march_1977.png [2]: https://en.wikipedia.org/wiki/Interface_Message_Processor -- 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 clemc at ccc.com Thu Feb 2 06:46:21 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 15:46:21 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201204327.GU21797@yeono.kjorling.se> References: <20170201204327.GU21797@yeono.kjorling.se> Message-ID: Do you have access to "the Matrix" by John Quarterman. There are the UUCP maps in there with >>tons<< of host names - like ihnp4, decvax, etc... On Wed, Feb 1, 2017 at 3:43 PM, Michael Kjörling wrote: > I hope this isn't too far off topic here. > > I've been meaning to rename the few systems I administer with names > that reference famous (or at least somewhat well-known in the proper > circles) historical UNIX systems, but I have been unable to find any > lists of such names so have no real place to start. About the closest > I _was_ able to find is the ARPANET map[1] of the late 1970s that is > on Wikipedia and is occasionally circulated, but which gives mostly > architecture, location and links, not any system (host) names. > > Short of unimaginative things like calling my home router IMP[2] or > things like that, can anyone either suggest names with a bit of > background (where they were, what hardware, what time period, etc.), > or point me toward online resources where I can find lists of those? > > > [1]: https://en.wikipedia.org/wiki/File:Arpanet_logical_map,_ > march_1977.png > > [2]: https://en.wikipedia.org/wiki/Interface_Message_Processor > > -- > 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) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 06:50:14 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 15:50:14 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201204327.GU21797@yeono.kjorling.se> References: <20170201204327.GU21797@yeono.kjorling.se> Message-ID: BTW: Many of the systems from the Arpanet days had very unimaginative host names: CMUA, "MIT-AI" are examples. CMMP was CMU's C.mmp, Vision was the Vision system and Audio was the language system so don't expect a lot of wild and crazy names. Clem On Wed, Feb 1, 2017 at 3:43 PM, Michael Kjörling wrote: > I hope this isn't too far off topic here. > > I've been meaning to rename the few systems I administer with names > that reference famous (or at least somewhat well-known in the proper > circles) historical UNIX systems, but I have been unable to find any > lists of such names so have no real place to start. About the closest > I _was_ able to find is the ARPANET map[1] of the late 1970s that is > on Wikipedia and is occasionally circulated, but which gives mostly > architecture, location and links, not any system (host) names. > > Short of unimaginative things like calling my home router IMP[2] or > things like that, can anyone either suggest names with a bit of > background (where they were, what hardware, what time period, etc.), > or point me toward online resources where I can find lists of those? > > > [1]: https://en.wikipedia.org/wiki/File:Arpanet_logical_map,_ > march_1977.png > > [2]: https://en.wikipedia.org/wiki/Interface_Message_Processor > > -- > 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) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Feb 2 07:11:19 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Wed, 01 Feb 2017 22:11:19 +0100 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: (Clem Cole's message of "Wed, 1 Feb 2017 15:50:14 -0500") References: <20170201204327.GU21797@yeono.kjorling.se> Message-ID: <867f5939c8.fsf@molnjunk.nocrew.org> Michael Kjörling wrote: > can anyone either suggest names with a bit of background (where they > were, what hardware, what time period, etc.), MIT-EDDIE, early distrbution point for GNU software. More details here: http://www.driver-aces.com/ronnie.html Clem Cole writes: > BTW: Many of the systems from the Arpanet days had very unimaginative > host names: CMUA, "MIT-AI" are examples. Better add that those are not Unix machines. From jnc at mercury.lcs.mit.edu Thu Feb 2 07:20:40 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Feb 2017 16:20:40 -0500 (EST) Subject: [TUHS] Names of famous, historical UNIX machines? Message-ID: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> > From: Clem Cole > don't expect a lot of wild and crazy names Yeah, those arrived when places started to get lots of identical machines, and needed a theme to name them. So I remember MIT-LCS had VAX 750's called Tide, Borax, etc (cleaners); MIT-AI had Suns called Grape-Nuts, Wheaties, etc (cereals). I know other places had similar name sets, but I can't recall the themes of any of them - although looking at an old HOSTS.TXT, I see CMU had systems called Faraday, Gauss, etc, while Purdue had Fermat, Newton, etc; U-Texas had Disney characters, BBN had fish, U-Washington had South Pacific islands - the list just goes on and on. Google for a old Host file, that's a good source if you want to know more. Noel From lm at mcvoy.com Thu Feb 2 07:33:31 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Feb 2017 13:33:31 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201204327.GU21797@yeono.kjorling.se> References: <20170201204327.GU21797@yeono.kjorling.se> Message-ID: <20170201213331.GD880@mcvoy.com> Oh, I've got some. Not that old, 80's. UW-Madison slovax - 11/750 that had the BSD sources on it. Spent many a happy hour reading there and I've always had a personal machine called slovax ever since. mcvoy.com internally is slovax. speedy - 8600 that was the main research/faculty machine. Also ...!uwisc!rsch Tokoyo Institute of Technology (TIT) So the back story here is I was one of the Unix geeks doing a Unix port to the ETA-10. TIT was taking delivery of a big liquid cooled machine and of course we weren't ready. I got sent over with 3 tapes, one was the baseline that was sort of checked in, one was my port of Lachman (who bought it from I think Convergent)'s TCP/IP stack, and one was some VM thing, I think big pages but I'm not sure. They sent me over there with a small replica of our development environment (Sun 3/260 file / compute server and 2 3/50 workstations) and told me "Merge this stuff and install it, TIT wants all of it". So I get to Tokoyo and the machines show up and I'm installing SunOS and I have to name them: 3/260: BigTIT 3/50: LeftTIT 3/50: RightTIT and I even put them physically how you would imagine. It only lasted until they figured out what it meant but I didn't get in trouble. Because a different story had just happened that had made the Japanese sales guys bust up in laughter and they had taken me out we all got shit faced a few days before I had to rename the machines. Happy to share that story if anyone is still reading :) Sun The source machines that held the SCCS history before they went to NSE/NSElite/Teamware: Argon Radon Krypton That's all I can think of for now, not sure if any of it is actually that all interesting. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Thu Feb 2 07:40:11 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Feb 2017 13:40:11 -0800 Subject: [TUHS] shared memory on Unix In-Reply-To: <20170201194434.C5DE118C0E8@mercury.lcs.mit.edu> References: <20170201194434.C5DE118C0E8@mercury.lcs.mit.edu> Message-ID: <20170201214011.GG880@mcvoy.com> On Wed, Feb 01, 2017 at 02:44:34PM -0500, Noel Chiappa wrote: > > From: "Steve Johnson" > > > The meetings went on for over a year, but _I NEVER MET WITH THE SAME > > PERSON TWICE!_ It seemed that the only thing the marketing group knew > > how to do was reorganize the marketing group... > > Shades of SI:Electric-Marketing (I _think_ that was its name) on the Symbolics > LISP Machine... > > (For those who never had the joy of seeing this, it randomly drew a bunch of > boxes with people in them on the screen in a hierarchy, connected them, and > then started randomly moving the boxes around... I wonder if the source > still exists - or, better yet, a video of it running? Probably not, alas.) Sun had reorgtool (orgtool) that had all the high up people down to directors I think and you pushed a button and it reshuffled them. It was a Xview app, anyone remember that toolkit (I sorta miss it). --lm From michael at kjorling.se Thu Feb 2 07:42:08 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 1 Feb 2017 21:42:08 +0000 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> Message-ID: <20170201214208.GV21797@yeono.kjorling.se> On 1 Feb 2017 16:20 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > Google for a old Host file, that's a good source if you want to know more. That's a good idea, I'll definitely give that a try later. Thanks for the tip! (Oh, and I didn't mean to imply a restriction to the 1970s; that was only to indicate what little I'd been able to find.) -- 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 pechter at gmail.com Thu Feb 2 07:50:49 2017 From: pechter at gmail.com (William Pechter) Date: Wed, 1 Feb 2017 16:50:49 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201214208.GV21797@yeono.kjorling.se> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201214208.GV21797@yeono.kjorling.se> Message-ID: Another source was the comp.mail.maps newsgroup for UUCP maps. I loved the Pyramid Technologies names pace - - all host names started with pyr. Pyramid->pyrnj->pyrite to my home in get. The one that killed me was pyrgynt. Bill -----Original Message----- From: "Michael Kjörling" To: tuhs at minnie.tuhs.org Sent: Wed, 01 Feb 2017 16:42 Subject: Re: [TUHS] Names of famous, historical UNIX machines? On 1 Feb 2017 16:20 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > Google for a old Host file, that's a good source if you want to know more. That's a good idea, I'll definitely give that a try later. Thanks for the tip! (Oh, and I didn't mean to imply a restriction to the 1970s; that was only to indicate what little I'd been able to find.) -- 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 b4 at gewt.net Thu Feb 2 07:43:32 2017 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 1 Feb 2017 13:43:32 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201214208.GV21797@yeono.kjorling.se> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201214208.GV21797@yeono.kjorling.se> Message-ID: 90s too late? Everyone needs sun-lamp and some of DEC's ULTRIX boxes. ;) Sent from my iPhone > On Feb 1, 2017, at 13:42, Michael Kjörling wrote: > > On 1 Feb 2017 16:20 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): >> Google for a old Host file, that's a good source if you want to know more. > > That's a good idea, I'll definitely give that a try later. Thanks for > the tip! > > (Oh, and I didn't mean to imply a restriction to the 1970s; that was > only to indicate what little I'd been able to find.) > > -- > 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 clemc at ccc.com Thu Feb 2 07:57:58 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 16:57:58 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201213331.GD880@mcvoy.com> References: <20170201204327.GU21797@yeono.kjorling.se> <20170201213331.GD880@mcvoy.com> Message-ID: On Wed, Feb 1, 2017 at 4:33 PM, Larry McVoy wrote: > It only lasted until they figured out what it meant but I didn't get > in trouble. Because a different story had just happened that had > made the Japanese sales guys bust up in laughter and they had taken > me out we all got shit faced a few days before I had to rename the > machines. Happy to share that story if anyone is still reading :) > ​Outstanding -- and yes please do.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 08:06:38 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 17:06:38 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 1, 2017 at 4:20 PM, Noel Chiappa wrote: > I know other places had similar name sets, but I can't recall the themes of > any of them - although looking at an old HOSTS.TXT, I see CMU had systems > ​ ​ > called Faraday, Gauss, etc, while Purdue had Fermat, Newton, etc; U-Texas > had > ​ ​ > Disney characters, BBN had fish, U-Washington had South Pacific islands - > the > ​ ​ > list just goes on and on. > ​Indeed....​ ​UCB's CSRG was naming ​after dead artists .. Monet, Degauss, *etc*.. The CAD group was a beverages theme: Cone, Sprite and Pepsi for the 3 780's - then the workstation were named after beer we drank. Masscomp used the Rogue monsters to start (until we ran out of the original 26 - then it was sort was all over the place). Yeti was the build server, Eye was the system we did the original MP UNIX work on, and Xorn was mine own [I've forgotten the names of the others]. In fact, when I got married by English-Lit major brother-in-law thought the idea of naming computers was so cute he wrote a song for Xorn in the key of the cowboy's horse losing its master to another more important person. And the monster theme was kept on my home network to this day, although my printers have often been named after chainsaws [for chewing up wood], and first color laser was called crayon for my then young daughter who used it to print her artwork. @ Stellar I had astronomical index of stars on the top of my file cabinet and people to come to me to get names. We keep that pretty consistent for all the SW systems for the first 2-3 years. I even reduxed the index at Ammasso a few years later. @ DEC we were pretty free to use what we wanted and some were themed, most were boring. But I'm sad to say, Intel seems to have little sense of humor with regards to what name I might set the system too locally. I can set to anything I want, but the moment I connect it to the internal network, the IT network gods rename in the form: {WWUSERNAME}-{SYSTEMTYPE}{GENERATION#} - no exceptions. My new system due in a sometime this spring will named: ctcole-mac05 So an arp on my home network shows all these interesting names, then one really, boring one ... and its mine. sigh.... so, so, sad.... Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 2 08:08:48 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Feb 2017 14:08:48 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201204327.GU21797@yeono.kjorling.se> <20170201213331.GD880@mcvoy.com> Message-ID: <20170201220848.GH880@mcvoy.com> On Wed, Feb 01, 2017 at 04:57:58PM -0500, Clem Cole wrote: > On Wed, Feb 1, 2017 at 4:33 PM, Larry McVoy wrote: > > > It only lasted until they figured out what it meant but I didn't get > > in trouble. Because a different story had just happened that had > > made the Japanese sales guys bust up in laughter and they had taken > > me out we all got shit faced a few days before I had to rename the > > machines. Happy to share that story if anyone is still reading :) > > > ???Outstanding -- and yes please do.??? OK. So the ETA was in the machine room, the Sun machines were just outside in sort of a lobby that was my office. I was frequently in the machine room to do something, I dunno what, it was cold and loud in there, I hated it, but I was in there all the time. Probably doing a hard reset on the machine I just screwed up. The Japanese sales guys were there constantly, watching, they wanted the sale to go through so they could collect their commission I guess. There was a phone in there and it would ring and a sales guy would pick it up saying "Moshi, Moshi" which I took to mean "Hi" or "hello". It was always corporate calling to see how things were going. So one day I'm in there by myself and the phone rings and without thinking about it (I don't speak Japanese so WTF was I thinking?), I pick it up and say "Mushi, Mushi". Too which I get a stream of horrified Japanense and I just hang up. The sales guys show later and I say "I answered a call for you". "Oh, yeah, what did you say?" "Mushi, mushi". Stunned silence and then they are rolling on the floor laughing. I'm going "What? What did I do?". They say "Corporate called to find out how things are going and the software guy said 'bug, bug' and hung up". We all went out drinking that night, those sales guys were all right. Seemed sort of cold before that but we were buds from there forward. I'll bet you a pile of money somewhere there is a sales guy in Japan who tells this story, probably not in a way that is flattering to me :) (Note this about 30 years ago and I can't remember if Moshi is hi or if it is Mushi that is hi, but you get the idea). --larry "bug, bug" mcvoy From lm at mcvoy.com Thu Feb 2 08:11:12 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 1 Feb 2017 14:11:12 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> Message-ID: <20170201221112.GI880@mcvoy.com> On Wed, Feb 01, 2017 at 05:06:38PM -0500, Clem Cole wrote: > But I'm sad to say, Intel seems to have little sense of humor with regards > to what name I might set the system too locally. I can set to anything I > want, but the moment I connect it to the internal network, the IT network > gods rename in the form: {WWUSERNAME}-{SYSTEMTYPE}{GENERATION#} - no > exceptions. My new system due in a sometime this spring will named: > ctcole-mac05 Intel was a major customer of ours for years and I can vouch for their lack of sense of humor. I visited Portland and Santa Clara and I have never seen a more grey cubicle farm in my life. > So an arp on my home network shows all these interesting names, then one > really, boring one ... and its mine. sigh.... so, so, sad.... Indeed. Though bigtit might have been a step too far :) --lm From jnc at mercury.lcs.mit.edu Thu Feb 2 08:16:00 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 1 Feb 2017 17:16:00 -0500 (EST) Subject: [TUHS] Names of famous, historical UNIX machines? Message-ID: <20170201221600.2AD3B18C0E5@mercury.lcs.mit.edu> > From: Clem Cole > my printers have often been named after chainsaws Yeah, MIT (or was it Proteon, I forget - a long time ago :-) had that theme going for a while for printers... > @ DEC we were pretty free to use what we wanted and some were themed, > most were boring. Hah! I do have a cosmically great computer naming story from DEC, though. So DECNet host names were limited to N characters (where N=8, or some such). So one day they get this complaint from some DEC user in the UK: "Grumble, grumble, grumble, N-character limit in DECNet host names, we want to name our host 'Slartibartfast'." So, this being before a certain radio play had hit the US from the UK, the people at DEC were like: "What's a 'Slartibartfast'???" Instantly, the reply shot back (and perhaps some of you saw this coming): "Boy, you guys are so unhip it's a wonder your pants down fall down!" :-) :-) Noel From b4 at gewt.net Thu Feb 2 08:16:18 2017 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 01 Feb 2017 14:16:18 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201214208.GV21797@yeono.kjorling.se> Message-ID: <1485987378.210652.867316536.34838522@webmail.messagingengine.com> On Wed, Feb 1, 2017, at 13:43, Cory Smelosky wrote: > 90s too late? Everyone needs sun-lamp and some of DEC's ULTRIX boxes. ;) > > Sent from my iPhone > > > On Feb 1, 2017, at 13:42, Michael Kjörling wrote: > > > > On 1 Feb 2017 16:20 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > >> Google for a old Host file, that's a good source if you want to know more. > > > > That's a good idea, I'll definitely give that a try later. Thanks for > > the tip! > > > > (Oh, and I didn't mean to imply a restriction to the 1970s; that was > > only to indicate what little I'd been able to find.) > > > > -- > > 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) > sys/conf for Ultrix 4.3 I believe ./ CHASM EVERYTHING LIMBO MY730 NOWISE SAS.gen TRIBBLE WISPER files param.c ../ DECVAX GENERIC LINT MY750 RAGTIME SAS.net UTMOST YAWN files.vax touch.c ABYSS EREHWON HOLLOW MONET MY780 RAVINE SAS.rx01 VACUUM defines makefile.vax BINARY.vax ERNIE KIM MVAX NFS SALT SAS.tu58 VAPOR devices.vax newvers.sh -- Cory Smelosky b4 at gewt.net From usotsuki at buric.co Thu Feb 2 08:20:47 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 1 Feb 2017 17:20:47 -0500 (EST) Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201220848.GH880@mcvoy.com> References: <20170201204327.GU21797@yeono.kjorling.se> <20170201213331.GD880@mcvoy.com> <20170201220848.GH880@mcvoy.com> Message-ID: On Wed, 1 Feb 2017, Larry McVoy wrote: > There was a phone in there and it would ring and a sales guy would pick > it up saying "Moshi, Moshi" which I took to mean "Hi" or "hello". > > It was always corporate calling to see how things were going. > > So one day I'm in there by myself and the phone rings and without thinking > about it (I don't speak Japanese so WTF was I thinking?), I pick it up > and say "Mushi, Mushi". Too which I get a stream of horrified Japanense > and I just hang up. > > The sales guys show later and I say "I answered a call for you". "Oh, > yeah, what did you say?" "Mushi, mushi". Stunned silence and then they > are rolling on the floor laughing. > > I'm going "What? What did I do?". > > They say "Corporate called to find out how things are going and the > software guy said 'bug, bug' and hung up". > > We all went out drinking that night, those sales guys were all right. > Seemed sort of cold before that but we were buds from there forward. > I'll bet you a pile of money somewhere there is a sales guy in Japan > who tells this story, probably not in a way that is flattering to me :) > > (Note this about 30 years ago and I can't remember if Moshi is hi or if it > is Mushi that is hi, but you get the idea). > > --larry "bug, bug" mcvoy > You were right - "moshi-moshi" is "hello" and "mushi" is bug. (I picked up a little bit of Japanese from 20 years of watching anime... lol) -uso. From clemc at ccc.com Thu Feb 2 08:21:16 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 17:21:16 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201221112.GI880@mcvoy.com> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > Indeed. Though bigtit might have been a step too far :) Just call it GrandTeton and they will probably not know.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Thu Feb 2 08:26:45 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 1 Feb 2017 17:26:45 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> Message-ID: https://emaillab.jp/pub/hosts/19840210/HOSTS.TXT This is a version of the HOSTS file that I found in some of my old floppies that was (sadly) truncated because of a bad sector (or twenty). This was from my teens when I was floating around the ARPANET. Some very interesting stuff here at the base site: https://emaillab.jp/dns/hosts/ On 2/1/2017 4:20 PM, Noel Chiappa wrote: > > From: Clem Cole > > > don't expect a lot of wild and crazy names > > Yeah, those arrived when places started to get lots of identical machines, > and needed a theme to name them. So I remember MIT-LCS had VAX 750's called > Tide, Borax, etc (cleaners); MIT-AI had Suns called Grape-Nuts, Wheaties, etc > (cereals). > > I know other places had similar name sets, but I can't recall the themes of > any of them - although looking at an old HOSTS.TXT, I see CMU had systems > called Faraday, Gauss, etc, while Purdue had Fermat, Newton, etc; U-Texas had > Disney characters, BBN had fish, U-Washington had South Pacific islands - the > list just goes on and on. > > Google for a old Host file, that's a good source if you want to know more. > > Noel > From berny at berwynlodge.com Thu Feb 2 08:27:37 2017 From: berny at berwynlodge.com (Berny Goodheart) Date: Wed, 1 Feb 2017 22:27:37 +0000 Subject: [TUHS] Names of famous, historical UNIX machines? Message-ID: <95DE698C-924C-4DA8-AD22-681A612D0421@berwynlodge.com> You might find this interesting reading: http://www.livinginternet.com/u/ui_netexplodes.htm In particular inhp4. I used to have a UUCP map that linked me into this network back in the mid 80s. I was based in the UK doing some work for Henry Spencer at Microport Systems if any of you recall their iX286 System V port, which was pretty cool. Anyway, there are some interesting machine names mentioned. From: smb at ulysses.att.com Subject: Re: IHNP4 Date: Thu, 25 Oct 90 20:48:42 EDT > Thus, ihnp4 was Indian Hill Network Processor #4 > mh was Murray Hill. ak was the Atlanta Wire Works, sb was Southern > Bell, cb was Columbus (Mark Horton was mark at cbosgd for a long time) > plus others. Yup, Columbus Operating Systems Group D, as I recall. > Then there were the machines in the lab that had (and have) names like > bonnie, clyde, ulysses, research, allegra, lento, harpo, chico, etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 08:28:08 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 17:28:08 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201221112.GI880@mcvoy.com> References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > I visited Portland and Santa Clara and I have never > seen a more grey cubicle farm in my life. > ​I don't remember which comic it was, but about 8-10 years ago one the late night comedy guys brought a film crew to SC and made that same exact observation.​ While Intel does do many things well, this one is part of company culture and I'm not in a position to change it. I wish I could. I think the place would be a small bit happier if it did not take itself quite so seriously, but that's just my personal opinion. As the late Roger Gourd used to say: *"Bring me to a sacred cow, and I'll start up the sacred bbq." ;-) * -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Thu Feb 2 08:44:15 2017 From: pechter at gmail.com (William Pechter) Date: Wed, 1 Feb 2017 17:44:15 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: One of the best things about DEC was the lack of taking itself too seriously. 11/730 product announcement for the Solar Horologue... See the above in Google and Slashdot. Wish I had a pdf to post. Bill -----Original Message----- From: Clem Cole To: Larry McVoy Cc: TUHS main list , Noel Chiappa Sent: Wed, 01 Feb 2017 17:28 Subject: Re: [TUHS] Names of famous, historical UNIX machines? On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > I visited Portland and Santa Clara and I have never > seen a more grey cubicle farm in my life. > ​I don't remember which comic it was, but about 8-10 years ago one the late night comedy guys brought a film crew to SC and made that same exact observation.​ While Intel does do many things well, this one is part of company culture and I'm not in a position to change it. I wish I could. I think the place would be a small bit happier if it did not take itself quite so seriously, but that's just my personal opinion. As the late Roger Gourd used to say: *"Bring me to a sacred cow, and I'll start up the sacred bbq." ;-) * From dugo at xs4all.nl Thu Feb 2 08:54:38 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Wed, 01 Feb 2017 17:54:38 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201204327.GU21797@yeono.kjorling.se> References: <20170201204327.GU21797@yeono.kjorling.se> Message-ID: <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> On 2017-02-01 15:43, Michael Kjörling wrote: > Short of unimaginative things like calling my home router IMP[2] or > things like that, can anyone either suggest names with a bit of > background (where they were, what hardware, what time period, etc.), > or point me toward online resources where I can find lists of those? I could drop names, but at some point the labels became quite uniform. To illustrate that, look at the labels in an old top1000 of USENET sites. http://top1000.anthologeek.net/2000/12/full.txt They bore quickly. The largest secondary tld nameserver ever was simply called ns (ns.EU.net), I don't recall the internal hostname, but it was probably some norse god like balder or buri. Some stuff that randomply pops up in my mind: - anon and penet Reference to anon.penet.fi, early to mid '90s, a generic 386/486 box at Julfs house and at undisclosed locations later on. Suitable for naming mail relays, outgoing mail servers and anonymity realetd services. - kremvax Fictional machine. Suitable for jokes, routers related to anything in the east. - mcvax, mcsun Suitable for anything related to europe. - sunsite A 90s thing. Suitable for sharing software, and, as a pun on Sun, java related stuff maybe. - gatekeeper Again, labels became boring, ftp.uu.net was famous as ftp site, but gatekeeper.dec.com had a cool hostname. - chronos chronos.eu.net was a go to time server in europe, replaced by rolex.ripe.net. - agate After agate.berkeley.edu, where BSD escaped the university until the lawyers stepped in. From pnr at planet.nl Thu Feb 2 09:11:02 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 2 Feb 2017 00:11:02 +0100 Subject: [TUHS] shared memory on Unix In-Reply-To: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> Message-ID: <82F3421B-9EF3-4752-B4E6-E2F15529FCDE@planet.nl> Many thanks to all for that helpful info! OK, so my vague recollection was more correct than my quick code inspection... With CB3 I meant CB Unix 3.0. I had a look at the "pdp11v" code in the Unix Tree archive and it has a system call "maus". Its implementation is here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=pdp11v/usr/src/uts/pdp11/os/maus.c There is also a CB Unix 2.1 manual and source code listing in the archive. The manual page for maus says it stands for "multiple access user space" (http://www.tuhs.org/Archive/PDP-11/Distributions/other/CB_Unix/cbunix_man2_02.pdf) At first glance 'maus' looks a bit like mmap. I did not find a print of the maus implementation yet in the source print, but I haven't exaustively searched yet (it is mentioned in the index, so it probably is there somewhere). In any case, the man page for maus is from November 1979, so it goes back at least as far as that. When was CB Unix 1.0 put together? -- It will be interesting to see how the BBN and CB approaches compare. Noel wrote: "Yes, there are two module in 'ken', map_page.c and set_lcba.c (I was unable to work out what 'LCBA' stood for) which seem to do something with mapping." How about "Local Common Block Access"? :^) Paul > The so-called Columbus shared memory feature was in their system in the > mid-1970s, along with a few other things such as semaphores and > inter-process messages. I seem to recall the acronym MAUG, but I may have a > letter or two wrong. Something like Multi Access User ____. The much later > System V features had a completely different API. > > Hey, Doug, do you remember this? In the early 1970s, there were a couple of > UNIX meetings at Murray Hill, at which various Bell Labs groups presented > on what they were doing with UNIX, and a group, perhaps Columbus, said that > UNIX wasn't capable of doing what they wanted, so they had modified it. You > asked the question, "Why are you using UNIX?" > > To my knowledge, having witnessed another decade or so of groups trying to > bend UNIX to their will, it was the last time the question was asked. > > --Marc > > > > Mary Ann Horton > wrote: > > > > I*'m not sure what you mean by CB3, but these features (shared memory, > > > semaphores, IPC) were added to CB-UNIX (Bell Labs, Columbus) precisely > > > because they were needed in real time telco systems and not preset in > > > the versions from New Jersey. This would have been in the early 1980s. > > > When I got there in 1981 I think CB-UNIX was already well established > > > and had these features. (These would show up, ironically, in /usr/ucb, > > > which did not stand for Berkeley.) From fair-tuhs at netbsd.org Thu Feb 2 09:32:20 2017 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Wed, 01 Feb 2017 15:32:20 -0800 Subject: [TUHS] Questions for TUHS great minds In-Reply-To: References: <512ABFFE-C238-45CA-9C43-CF9A84E4DE49@tfeb.org> Message-ID: <11178.1485991940@cesium.clock.org> Steve, you're probably aware of this but I'll chip in for everyone else: Ivan Sutherland has been working on "clockless" computing for the last many years - he's at Portland State University these days. I've had the privilege of listening to him talk just a little about this subject even though I'm not an EE. Erik Fair From downing.nick at gmail.com Thu Feb 2 10:25:56 2017 From: downing.nick at gmail.com (Nick Downing) Date: Thu, 2 Feb 2017 11:25:56 +1100 Subject: [TUHS] shared memory on Unix In-Reply-To: References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net> <201702011833.v11IX5Yu017326@freefriends.org> Message-ID: A very incisive post Clem and to everyone generally I am fascinated to hear about PWB, Unix 3/4/5 history, System V, choice of codebases, featuresets and APIs. The thread made a good read on a long boring drive and I'm not even finished reading yet. :) Nick On 02/02/2017 6:31 AM, "Clem Cole" wrote: > > On Wed, Feb 1, 2017 at 1:33 PM, wrote: > >> ​.. >> At the time, the policy was to release externally one version >> behind what was being run internally, so System III was released to the >> world while the Bell System was using Unix 4.0. I still have the manual; >> I'm pretty sure "PWB" and "Programmer's Workbench" are not on the cover, >> ​ ​ >> it was just called "UNIX". >> > ​Could be.... the "System III" manual cover I have says PWB 3.0​ > > I never had a 4.0 doc, although I saw it at some point. > > > > >> >> As UNIX 5.0 was approaching, someone decided that to be one release >> behind on the outside was dumb, thus the jump from System III to System >> ​​ >> V. >> > > ​Making the outside and inside system in sync makes sense and I think I > remember some of that. But the name was definitely forced by the > Marketing types in NC. I somewhere have a memo that they sent to all > licenses about the term UNIX and how it could be used and what could be > called same. It was clear that was all part of the UNIX wars and they > were trying to make System xxx have some sort of halo. > > > As a side note, what is funny is when it all went down, I remember having > an argument with some of the Masscomp (and ex-DEC) marketing types. The > geeks (like me) just could not get through to them that what mattered was > how it worked and what was inside (which BSD was pretty much superior > technology by most accounts). It was not that Sys III/V was bad, it was > just unadorned and claiming it was cool and trying to give it a cool name > was not going to make it cool.​ > > Around this time we came up with the Universes hack, so you can have it > both ways; but our kernel was more BSD that AT&T. > > > As I said, funny, because a few years later with Stellar, the same group > of people would >>start<< with a System V kernel and fold in BSD interfaces > as needed. We wrote our own FS (which was UFS-externally - i.e. BSD user > api) but kernel insides completely new (extent based, more like VMS). > > We had decided that by then the AT&T code base was *cleaner to make scale > on a multiprocessor*, as we had already lived the BSD MP nightmare once > with the Masscomp kernel. But the key was that even thought we used > System V, we made darned sure the user mode API's (such as sockets, mmap, > signals, namespaces etc) were the BSD APIs and that the BSD user code from > UNIX and that VMS/FORTRAN sources would pretty much compile out of the box. > > We were at that point targeting Sun, Apollo & VMS customers so we knew it > name meant nothing, it was all about how easy it was going to be for the > code recompile and "just work". > > Back to the main point, AT&T Marketing was still chasing IBM at this > time. It was amazing to many of us watching the ship sink. They really > did not see where the future was and that they owned the SW technology that > was going to dive it, but it was going to be sold to people other than whom > IBM had traditionally sold. They also made the fatal mistake of trying to > grip it too tight and in doing so, it slipped through their fingers. > > Clem > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 11:10:04 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 20:10:04 -0500 Subject: [TUHS] shared memory on Unix In-Reply-To: <82F3421B-9EF3-4752-B4E6-E2F15529FCDE@planet.nl> References: <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net> <82F3421B-9EF3-4752-B4E6-E2F15529FCDE@planet.nl> Message-ID: On Wed, Feb 1, 2017 at 6:11 PM, Paul Ruizendaal wrote: > In any case, the man page for maus is from November 1979, so it goes back > at > least as far as that. When was CB Unix 1.0 put together? > That man page is much more like I remember, not the system V stuff of a few years later. Since, I would've seen it no later than fall 1978, so I would date it as being available most likely in the 77-78 timeframe. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From rp at servium.ch Thu Feb 2 11:14:03 2017 From: rp at servium.ch (Rico Pajarola) Date: Thu, 2 Feb 2017 02:14:03 +0100 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: On Wed, Feb 1, 2017 at 11:44 PM, William Pechter wrote: > One of the best things about DEC was the lack of taking itself too > seriously. > > 11/730 product announcement for the Solar Horologue... > > See the above in Google and Slashdot. > > Wish I had a pdf to post. > > Bill > this one? http://www.computerhistory.org/collections/catalog/102672049 the story: https://slashdot.org/comments.pl?sid=76256&cid=6805264 This is awesome. Now I really want to build one ;) Does anyone have that data sheet and would be so kind to scan it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 11:18:27 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 20:18:27 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: The creator of that little gem was Dick Hustvedt, a brilliant engineer with a wicked sense of humor. He was one of the inventors of VAXclusters, as well as of the SD730 Solar Horologue Option - see end of this post. When in the VMS SYSGEN utility, and you asked for a list of the parameters, the list included the units. The TIMEPROMPTWAIT parameter was unusual in that values in one range did one thing, while values in another range did something else. Dick wanted to encourage users to go read the manual for the full explanation, so he had the units listed as microfortnights, hoping that puzzled readers would go search out the details. Sadly, Dick suffered severe brain injury in a car accident many years ago, and was unable to return to work. The VMS team named a conference room in his honor at the Nashua, NH facility where VMS engineering lives, and if you visit it, you can see the prototype SD730, which was introduced as an April Fools joke one year. Here's the text from the "Product Information Sheet" for the SD730. VAX-11/730 SD730 Fixed Head Solar Horologue Overview The SD730 is an option for the VAX-11/730(TM) that provides an inexpensive solution to the problem of setting system time correctly following a power failure. An astronomical reference is used to assure accuracy. Reliability is assured by the simple, elegant design which employs well-proven technology. Description The SD730 is a gnomonic high noon detector that provides a simple, but elegant solution to the problem of setting system time correctly following a power failure. This option is particularly valuable for processors lacking battery backup for their time-of-year (TOY) clock. Highlights - Gnomonic interference high noon detector - High accuracy assured by low-drift astronomical reference - Connects to existing DR-11C port on VAX-11/730 - Proprietary high-moon rejection design - Offline mode for standalone time measurement - User installable and maintainable - Reliability assured by minimal component count and proven technology - Heavy duty construction resists solar wind - Anti-corrosion coating prevents gnomonic plague Description The SD730 provides a single bit of data via the DR-11C port of the VAX-11/730 that encodes all of its sensory information. Decoding is accomplished by measuring the on/off intervals of this sensor channel. Derivation of the time and date is accomplished by the SD730 Shadow Processing Support Software. Accurate high-noon sensing is obtained by measuring the solar transit time and computing the midpoint. This algorithm also corrects for variations in gnomon width, latitude and season. In the event that a cloudless night permits a high full moon to be seen, it will be differentiated from an authentic high noon by comparing observed transit time against a reference solar transit time. Within 24 hours following power restoration, the SD730 driver software will restore the correct system time. Power outages in excess of 24 hours can be accomodated once a reference year has been accumulated. Day length, solar transit time and their rates of change are used to recognize the day within the year. Installation The SD730 is user installable and comes complete with an installation kit consisting of a lensatic compass. All software is self-installing and self-calibrating. The only requirement is that system time be set correctly and that at least one clear day be allowed for self calibration. The SD730 will not operate reliably when installed at latitudes greater than 60 degrees. Maintenance While the SD730 is simple and reliable, some environments may necessitate periodic cleaning of the gnomon and photo-detector. Although the gnomon shields the photo-detector from debris, this may not be sufficient for particularly hazardous locations subject to overflights by large flocks of migratory birds. To assist in problem detection, error log entries will be made for days without sunshine and weeks without a high noon. Support Software A driver and other support software are supplied with the SD730. All software runs on VAX/VMS. An optional package is available to produce a local almanac sprinkled liberally with gnomic sayings and weather predictions, all derived from one year's solar date. Options For severe or hostile environments, a conversion kit consisting of a fiber-optic cable and adapters is available to convert the SD730 to an SD730-Tempest. Specifications I/O Adapter DR-11C Connector (single bit) Power Requirements 9 volt battery (alkaline recommended) Battery not included Optional solar cells available Physical Characteristics Packaging Free Standing Unit Weight 4.5kg (10 lbs) Height 86cm (34 inches) Width 32cm (12.5 inches) Depth 32cm (12.5 inches) Operating Environment Temperature 5 to 32 degrees C (41 to 90 F) Relative Humidity 0 to 90% Maximum Altitude 4.5km (15000 ft) Latitude 0 to 60 degrees North (*) Performance Long Term Accuracy 1 second per year Operational Reliability Consult your local weather service *NOTE For installation in the southern hemisphere, order model SL730-SL. On Wed, Feb 1, 2017 at 5:44 PM, William Pechter wrote: > One of the best things about DEC was the lack of taking itself too > seriously. > > 11/730 product announcement for the Solar Horologue... > > See the above in Google and Slashdot. > > Wish I had a pdf to post. > > Bill > > -----Original Message----- > From: Clem Cole > To: Larry McVoy > Cc: TUHS main list , Noel Chiappa < > jnc at mercury.lcs.mit.edu> > Sent: Wed, 01 Feb 2017 17:28 > Subject: Re: [TUHS] Names of famous, historical UNIX machines? > > On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > > > I visited Portland and Santa Clara and I have never > > seen a more grey cubicle farm in my life. > > > > ​I don't remember which comic it was, but about 8-10 years ago one the late > night comedy guys brought a film crew to SC and made that same exact > observation.​ > > While Intel does do many things well, this one is part of company culture > and I'm not in a position to change it. I wish I could. I think the place > would be a small bit happier if it did not take itself quite so seriously, > but that's just my personal opinion. > > > As the late Roger Gourd used to say: *"Bring me to a sacred cow, and I'll > start up the sacred bbq." ;-) * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 11:29:20 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 20:29:20 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: Sorry -- I Hit send too soon - cut/pasted from slashdot. Bill - if I can find a hardcopy. I'll scan it. Clem On Wed, Feb 1, 2017 at 8:18 PM, Clem Cole wrote: > The creator of that little gem was Dick Hustvedt, a brilliant engineer > with a wicked sense of humor. He was one of the inventors of VAXclusters, > as well as of the SD730 Solar Horologue Option - see end of this post. > > When in the VMS SYSGEN utility, and you asked for a list of the > parameters, the list included the units. The TIMEPROMPTWAIT parameter was > unusual in that values in one range did one thing, while values in another > range did something else. Dick wanted to encourage users to go read the > manual for the full explanation, so he had the units listed as > microfortnights, hoping that puzzled readers would go search out the > details. > > Sadly, Dick suffered severe brain injury in a car accident many years ago, > and was unable to return to work. The VMS team named a conference room in > his honor at the Nashua, NH facility where VMS engineering lives, and if > you visit it, you can see the prototype SD730, which was introduced as an > April Fools joke one year. Here's the text from the "Product Information > Sheet" for the SD730. > > VAX-11/730 > > SD730 Fixed Head Solar Horologue > > Overview > > The SD730 is an option for the VAX-11/730(TM) that provides an inexpensive > solution to the problem of setting system time correctly following a power > failure. An astronomical reference is used to assure accuracy. Reliability > is assured by the simple, elegant design which employs well-proven > technology. > > Description > > The SD730 is a gnomonic high noon detector that provides a simple, but > elegant solution to the problem of setting system time correctly following > a power failure. This option is particularly valuable for processors > lacking battery backup for their time-of-year (TOY) clock. > > Highlights > > - Gnomonic interference high noon detector > - High accuracy assured by low-drift astronomical reference > - Connects to existing DR-11C port on VAX-11/730 > - Proprietary high-moon rejection design > - Offline mode for standalone time measurement > - User installable and maintainable > - Reliability assured by minimal component count and proven technology > - Heavy duty construction resists solar wind > - Anti-corrosion coating prevents gnomonic plague > > Description > > The SD730 provides a single bit of data via the DR-11C port of the > VAX-11/730 that encodes all of its sensory information. Decoding is > accomplished by measuring the on/off intervals of this sensor channel. > Derivation of the time and date is accomplished by the SD730 Shadow > Processing Support Software. > > Accurate high-noon sensing is obtained by measuring the solar transit time > and computing the midpoint. This algorithm also corrects for variations in > gnomon width, latitude and season. In the event that a cloudless night > permits a high full moon to be seen, it will be differentiated from an > authentic high noon by comparing observed transit time against a reference > solar transit time. > > Within 24 hours following power restoration, the SD730 driver software > will restore the correct system time. > > Power outages in excess of 24 hours can be accomodated once a reference > year has been accumulated. Day length, solar transit time and their rates > of change are used to recognize the day within the year. > > Installation > > The SD730 is user installable and comes complete with an installation kit > consisting of a lensatic compass. All software is self-installing and > self-calibrating. The only requirement is that system time be set correctly > and that at least one clear day be allowed for self calibration. > > The SD730 will not operate reliably when installed at latitudes greater > than 60 degrees. > > Maintenance > > While the SD730 is simple and reliable, some environments may necessitate > periodic cleaning of the gnomon and photo-detector. Although the gnomon > shields the photo-detector from debris, this may not be sufficient for > particularly hazardous locations subject to overflights by large flocks of > migratory birds. To assist in problem detection, error log entries will be > made for days without sunshine and weeks without a high noon. > > Support Software > > A driver and other support software are supplied with the SD730. All > software runs on VAX/VMS. > > An optional package is available to produce a local almanac sprinkled > liberally with gnomic sayings and weather predictions, all derived from one > year's solar date. > > Options > > For severe or hostile environments, a conversion kit consisting of a > fiber-optic cable and adapters is available to convert the SD730 to an > SD730-Tempest. > > Specifications > > I/O Adapter > > DR-11C Connector (single bit) > > Power Requirements > > 9 volt battery (alkaline recommended) > Battery not included > Optional solar cells available > > Physical Characteristics > > Packaging Free Standing Unit > Weight 4.5kg (10 lbs) > Height 86cm (34 inches) > Width 32cm (12.5 inches) > Depth 32cm (12.5 inches) > > Operating Environment > > Temperature 5 to 32 degrees C (41 to 90 F) > Relative Humidity 0 to 90% > Maximum Altitude 4.5km (15000 ft) > Latitude 0 to 60 degrees North (*) > > Performance > > Long Term Accuracy 1 second per year > Operational Reliability Consult your local weather service > > *NOTE For installation in the southern hemisphere, order model SL730-SL. > > On Wed, Feb 1, 2017 at 5:44 PM, William Pechter wrote: > >> One of the best things about DEC was the lack of taking itself too >> seriously. >> >> 11/730 product announcement for the Solar Horologue... >> >> See the above in Google and Slashdot. >> >> Wish I had a pdf to post. >> >> Bill >> >> -----Original Message----- >> From: Clem Cole >> To: Larry McVoy >> Cc: TUHS main list , Noel Chiappa < >> jnc at mercury.lcs.mit.edu> >> Sent: Wed, 01 Feb 2017 17:28 >> Subject: Re: [TUHS] Names of famous, historical UNIX machines? >> >> On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: >> >> > I visited Portland and Santa Clara and I have never >> > seen a more grey cubicle farm in my life. >> > >> >> ​I don't remember which comic it was, but about 8-10 years ago one the >> late >> night comedy guys brought a film crew to SC and made that same exact >> observation.​ >> >> While Intel does do many things well, this one is part of company culture >> and I'm not in a position to change it. I wish I could. I think the >> place >> would be a small bit happier if it did not take itself quite so seriously, >> but that's just my personal opinion. >> >> >> As the late Roger Gourd used to say: *"Bring me to a sacred cow, and I'll >> start up the sacred bbq." ;-) * >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 2 11:34:38 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 1 Feb 2017 20:34:38 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: On Wed, Feb 1, 2017 at 8:14 PM, Rico Pajarola wrote: > this one? http://www.computerhistory.org/collections/catalog/102672049 > That be the one and only implementation of same. I'm glad to see it was saved from ZK03 and hope its now safely at the museum. I was worried when HP sold the place, a number of the things in the old conference rooms were lost. Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars at nocrew.org Thu Feb 2 17:38:33 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 02 Feb 2017 08:38:33 +0100 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: (Arthur Krewat's message of "Wed, 1 Feb 2017 17:26:45 -0500") References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> Message-ID: <86wpd911qe.fsf@molnjunk.nocrew.org> Arthur Krewat wrote: > https://emaillab.jp/pub/hosts/19840210/HOSTS.TXT > This is a version of the HOSTS file that I found in some of my old > floppies Two observations: - There were many Foonlies around the net. - WAITS wasn't just running at SAIL, but also at S-1. But this is off topic, so I'll shut up now. From rudi.j.blom at gmail.com Thu Feb 2 19:59:13 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 2 Feb 2017 16:59:13 +0700 Subject: [TUHS] Names of famous, historical UNIX machines? Message-ID: Slartibartfast brings back fond memories of THHGTTG. Of course those in IT simply know that with a Guide and a towel there's no need to panic :-) Cheers, rudi From arnold at skeeve.com Thu Feb 2 23:11:23 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Thu, 02 Feb 2017 06:11:23 -0700 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu> <20170201221112.GI880@mcvoy.com> Message-ID: <201702021311.v12DBNoa004846@freefriends.org> Clem Cole wrote: > On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > > > I visited Portland and Santa Clara and I have never > > seen a more grey cubicle farm in my life. > > I don't remember which comic it was, but about 8-10 years ago one the late > night comedy guys brought a film crew to SC and made that same exact > observation. It was Conan O'Brien. You can find it on YouTube. > While Intel does do many things well, this one is part of company culture > and I'm not in a position to change it. I wish I could. It's a huge blind spot for Intel. They tout it as "everyone is equal" but they miss that noone who needs peace and quiet to work can work productively. > I think the place > would be a small bit happier if it did not take itself quite so seriously, > but that's just my personal opinion. Yes, as a fellow Intel employee, I'd have to agree. Sigh. Arnold From david at kdbarto.org Fri Feb 3 03:57:25 2017 From: david at kdbarto.org (David) Date: Thu, 2 Feb 2017 09:57:25 -0800 Subject: [TUHS] How Unix brings people together, or it's a small world In-Reply-To: References: Message-ID: Side story on Unix related to Xview. I go to a conference in San Jose for Sun users in the mid 80’s and am discussing Xview with a few folks (names lost to memory). A very nice person named Nancy Blackman walks up and joins the discussion. We get to talking and she has a weird memory bug and I’m willing to help her look at it. So we go to ‘her place’ which is her lab at Moffet field. We discuss her bug, find a fix and I go back home to San Diego. I mention that I met this very nice lady named Nancy Blackman at the conference to my wife. Turns out my wife went to school with Nancy before she moved to San Diego. So, who else has weird stories of how Unix development or Unix conferences had the side effect of making the world a smaller place. If this is too off topic, drop the conversation here. David > On Feb 1, 2017, at 1:52 PM, tuhs-request at minnie.tuhs.org wrote: > > Date: Wed, 1 Feb 2017 13:40:11 -0800 > From: Larry McVoy > To: Noel Chiappa > Cc: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] shared memory on Unix > Message-ID: <20170201214011.GG880 at mcvoy.com> > Content-Type: text/plain; charset=us-ascii > > On Wed, Feb 01, 2017 at 02:44:34PM -0500, Noel Chiappa wrote: >>> From: "Steve Johnson" >> >>> The meetings went on for over a year, but _I NEVER MET WITH THE SAME >>> PERSON TWICE!_ It seemed that the only thing the marketing group knew >>> how to do was reorganize the marketing group... >> >> Shades of SI:Electric-Marketing (I _think_ that was its name) on the Symbolics >> LISP Machine... >> >> (For those who never had the joy of seeing this, it randomly drew a bunch of >> boxes with people in them on the screen in a hierarchy, connected them, and >> then started randomly moving the boxes around... I wonder if the source >> still exists - or, better yet, a video of it running? Probably not, alas.) > > Sun had reorgtool (orgtool) that had all the high up people down to > directors I think and you pushed a button and it reshuffled them. > It was a Xview app, anyone remember that toolkit (I sorta miss it). > > --lm From dave at horsfall.org Fri Feb 3 11:51:43 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 3 Feb 2017 12:51:43 +1100 (EST) Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201213331.GD880@mcvoy.com> References: <20170201204327.GU21797@yeono.kjorling.se> <20170201213331.GD880@mcvoy.com> Message-ID: On Wed, 1 Feb 2017, Larry McVoy wrote: > So I get to Tokoyo and the machines show up and I'm installing SunOS > and I have to name them: > > 3/260: BigTIT > 3/50: LeftTIT > 3/50: RightTIT Back at UNSW/USyd we had some sypware (to keep an eye upon the kiddies breaking SUID programs) named /etc/lefttit (the monitor) and /etc/righttit (the reporting program); a bra was under construction... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From doug at cs.dartmouth.edu Fri Feb 3 13:36:49 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 02 Feb 2017 22:36:49 -0500 Subject: [TUHS] TUHS Digest, Vol 15, Issue 13 In-Reply-To: References: Message-ID: <201702030336.v133anB6146009@tahoe.cs.Dartmouth.EDU> Charmant. 75k more on your next Loire chateaux tour. Poor Margate Lucy, rooted in (mostly) one place for 135 years. d From doug at cs.dartmouth.edu Fri Feb 3 14:04:44 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 02 Feb 2017 23:04:44 -0500 Subject: [TUHS] How Unix brings people together, or it's a small world Message-ID: <201702030404.v1344iDQ000839@tahoe.cs.Dartmouth.EDU> As a tourist in Christchurch NZ in 1982, I saw a notice of a student piano recital at the university. Free, why not? The fellow who sat next to me turned out to be a phyicist. On learning that I was a computer scientist, he proudly described his wonderful new computer and operating system--the first of its kind in the university, if I remember correctly. I let on that I was familiar with it, so we both left the recital with a small-world story to tell. Doug From lars at nocrew.org Fri Feb 3 15:50:24 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 03 Feb 2017 06:50:24 +0100 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170201204327.GU21797@yeono.kjorling.se> ("Michael \=\?utf-8\?Q\?Kj\=C3\=B6rling\=22's\?\= message of "Wed, 1 Feb 2017 20:43:27 +0000") References: <20170201204327.GU21797@yeono.kjorling.se> Message-ID: <86zii3zuu7.fsf@molnjunk.nocrew.org> By the way, telehack.com is a great place to discover historical machines. At first glance, it just appears to be a plain prompt with a few commands and games available. But it's MUCH MORE than that, so stick it out for a few minutes. From tfb at tfeb.org Fri Feb 3 22:59:04 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Fri, 3 Feb 2017 12:59:04 +0000 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> References: <20170201204327.GU21797@yeono.kjorling.se> <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> Message-ID: I am not sure if I remember this or if I was told it later, but mcvax was a very important machine for people in Europe (like me) as it was a big gateway (for usenet? I forget). Its name was in lots of people's heads and probably lots of scripts &c. So at some point they got a new machine which, obviously, was a Sun. So, at that point they had two choices: - keep the old name, even though it wasn't a VAX any more; - rename it to something which was platform-neutral so the pain would only happen once. And they took the third option: rename it, but wire-in the platform *again* thus causing pain now and more pain later. Oh dear. On the subject of hostnames, has anyone mentioned prep / prep.ai.mit.edu? All the GNU software came from that in the mid 1980s, anyway. I think 'prep' meant 'document preparation', I don't know what it was. --tim > On 1 Feb 2017, at 22:54, Jacob Goense wrote: > > - mcvax, mcsun > Suitable for anything related to europe. From dave at horsfall.org Sat Feb 4 00:04:37 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 4 Feb 2017 01:04:37 +1100 (EST) Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> References: <20170201204327.GU21797@yeono.kjorling.se> <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> Message-ID: On Wed, 1 Feb 2017, Jacob Goense wrote: > - kremvax > Fictional machine. Suitable for jokes, routers related to anything in the > east. The most famous spoofed address would be moscvax!kremvax!kgbvax!gorby ... I think KRE posted from there back one April 1st (alas, I never saved it). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dugo at xs4all.nl Sat Feb 4 00:11:54 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Fri, 03 Feb 2017 09:11:54 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <20170201204327.GU21797@yeono.kjorling.se> <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> Message-ID: <67b5fc0baf200260db0f035f858929ed@xs4all.nl> On 2017-02-03 09:04, Dave Horsfall wrote: > On Wed, 1 Feb 2017, Jacob Goense wrote: > >> - kremvax >> Fictional machine. Suitable for jokes, routers related to anything in >> the >> east. > > The most famous spoofed address would be moscvax!kremvax!kgbvax!gorby > ... > > I think KRE posted from there back one April 1st (alas, I never saved > it). Piet saved it at http://godfatherof.nl/kremvax.html From krewat at kilonet.net Sat Feb 4 01:12:20 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Fri, 3 Feb 2017 10:12:20 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <67b5fc0baf200260db0f035f858929ed@xs4all.nl> References: <20170201204327.GU21797@yeono.kjorling.se> <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> <67b5fc0baf200260db0f035f858929ed@xs4all.nl> Message-ID: <268ca806-3c70-5f2e-13dc-f8f54f7393a3@kilonet.net> owl% nslookup kremvax.demos.su Server: 199.89.231.20 Address: 199.89.231.20#53 Non-authoritative answer: Name: kremvax.demos.su Address: 194.87.0.20 owl% whois -h whois.ripe.net 194.87.0.20 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '194.87.0.0 - 194.87.3.255' % Abuse contact for '194.87.0.0 - 194.87.3.255' is 'abuse at relcom.net' inetnum: 194.87.0.0 - 194.87.3.255 netname: DEMOS-CORP descr: DEMOS Corporate Network descr: Demos Plus Co. Ltd. descr: Moscow, Russia country: RU admin-c: DNOC-ORG tech-c: DNOC-ORG status: ASSIGNED PA mnt-by: AS2578-MNT created: 2002-05-24T05:47:32Z last-modified: 2006-10-19T12:41:45Z source: RIPE http://kremvax.demos.su/ kremvax.demos.su 1992-1995-2016 R.I.P. On 2/3/2017 9:11 AM, Jacob Goense wrote: > On 2017-02-03 09:04, Dave Horsfall wrote: >> On Wed, 1 Feb 2017, Jacob Goense wrote: >> >>> - kremvax >>> Fictional machine. Suitable for jokes, routers related to anything >>> in the >>> east. >> >> The most famous spoofed address would be moscvax!kremvax!kgbvax!gorby >> ... >> >> I think KRE posted from there back one April 1st (alas, I never saved >> it). > > Piet saved it at http://godfatherof.nl/kremvax.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Sat Feb 4 06:00:56 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 4 Feb 2017 07:00:56 +1100 (EST) Subject: [TUHS] Happy birthday, Ken Thompson! Message-ID: Co-inventor of Unix, he was born on this day in 1943. Just think: without those two, we'd all be running M$ Windoze and thinking that it's wonderful. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From scj at yaccman.com Sat Feb 4 13:46:47 2017 From: scj at yaccman.com (Steve Johnson) Date: Fri, 03 Feb 2017 19:46:47 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <201702021311.v12DBNoa004846@freefriends.org> Message-ID: About a decade ago, I attended a workshop at an Intel location in Mass.  There were about 50 outside people.  We were in a rather nice room across from a break room which provided coffee and sodas. Just as we were about to start, someone showed up and informed us all that the break room was for the exclusive use of Intel Employees, and outside visitors were not permitted to use it.  And then they left.  The Intel hosts rolled their eyes and set up a system whereby we could ask an Intel employee to get us whatever we wanted from the break room.  The workshop was pretty good anyway... ----- Original Message ----- From: arnold at skeeve.com To:, Cc:, Sent:Thu, 02 Feb 2017 06:11:23 -0700 Subject:Re: [TUHS] Names of famous, historical UNIX machines? Clem Cole wrote: > On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > > > I visited Portland and Santa Clara and I have never > > seen a more grey cubicle farm in my life. > > I don't remember which comic it was, but about 8-10 years ago one the late > night comedy guys brought a film crew to SC and made that same exact > observation. It was Conan O'Brien. You can find it on YouTube. > While Intel does do many things well, this one is part of company culture > and I'm not in a position to change it. I wish I could. It's a huge blind spot for Intel. They tout it as "everyone is equal" but they miss that noone who needs peace and quiet to work can work productively. > I think the place > would be a small bit happier if it did not take itself quite so seriously, > but that's just my personal opinion. Yes, as a fellow Intel employee, I'd have to agree. Sigh. Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Sat Feb 4 13:56:13 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 3 Feb 2017 19:56:13 -0800 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: References: <201702021311.v12DBNoa004846@freefriends.org> Message-ID: <20170204035613.GC28573@mcvoy.com> Intel was a big customer of ours and we found it highly amusing how secretive they were about CPU code names and product plans. You could go to Wikipedia and see all that stuff. At the time they thought it was a secret. They were just as secretive about their employees. Yet you could look up any one of them on Linkedin and see what they've been doing at Intel. Strange culture. Seems to generate some good CPUs but I wonder if that is because of that culture or in spite of it? On Fri, Feb 03, 2017 at 07:46:47PM -0800, Steve Johnson wrote: > About a decade ago, I attended a workshop at an Intel location in > Mass.?? There were about 50 outside people.?? We were in a rather nice > room across from a break room which provided coffee and sodas. > > Just as we were about to start, someone showed up and informed us all > that the break room was for the exclusive use of Intel Employees, and > outside visitors were not permitted to use it.?? And then they left.?? > The Intel hosts rolled their eyes and set up a system whereby we could > ask an Intel employee to get us whatever we wanted from the break > room.?? The workshop was pretty good anyway... > > ----- Original Message ----- > From: arnold at skeeve.com > To:, > Cc:, > Sent:Thu, 02 Feb 2017 06:11:23 -0700 > Subject:Re: [TUHS] Names of famous, historical UNIX machines? > > Clem Cole wrote: > > > On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy wrote: > > > > > I visited Portland and Santa Clara and I have never > > > seen a more grey cubicle farm in my life. > > > > I don't remember which comic it was, but about 8-10 years ago one > the late > > night comedy guys brought a film crew to SC and made that same > exact > > observation. > > It was Conan O'Brien. You can find it on YouTube. > > > While Intel does do many things well, this one is part of company > culture > > and I'm not in a position to change it. I wish I could. > > It's a huge blind spot for Intel. They tout it as "everyone is equal" > but they miss that noone who needs peace and quiet to work can work > productively. > > > I think the place > > would be a small bit happier if it did not take itself quite so > seriously, > > but that's just my personal opinion. > > Yes, as a fellow Intel employee, I'd have to agree. > > Sigh. > > Arnold > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From michael at kjorling.se Sat Feb 4 22:38:51 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 4 Feb 2017 12:38:51 +0000 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: Message-ID: <20170204123851.GF21797@yeono.kjorling.se> On 4 Feb 2017 07:00 +1100, from dave at horsfall.org (Dave Horsfall): > Just think: without those two, we'd all be running M$ Windoze and > thinking that it's wonderful. I wouldn't be so sure that claim should stand uncontested, given that PC-DOS 2.0 (long before Windows) largely copied the concept of directories from UNIX. Just think how wonderful Windows would be if it was running on top of a file system that lacked the concept of directories. Then again IIRC the original Macintosh file system had no concept of directories, but they somehow faked them in software. Makes you wonder why they went through all that trouble instead of implementing _proper_ support for directories/folders/filing cabinets/drawers/etc. -- 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 usotsuki at buric.co Sat Feb 4 22:44:22 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 4 Feb 2017 07:44:22 -0500 (EST) Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: <20170204123851.GF21797@yeono.kjorling.se> References: <20170204123851.GF21797@yeono.kjorling.se> Message-ID: On Sat, 4 Feb 2017, Michael Kjörling wrote: > On 4 Feb 2017 07:00 +1100, from dave at horsfall.org (Dave Horsfall): >> Just think: without those two, we'd all be running M$ Windoze and >> thinking that it's wonderful. > > I wouldn't be so sure that claim should stand uncontested, given that > PC-DOS 2.0 (long before Windows) largely copied the concept of > directories from UNIX. Just think how wonderful Windows would be if it > was running on top of a file system that lacked the concept of > directories. MS-DOS 2 took an OS that was largely inspired by CP/M and replaced the file API *with that of Xenix* just to add directory support. Best change they ever made. Now if only IBM hadn't forced them to use \ as the path separator instead of /, it would've been slightly better. Still, MS-DOS was probably the most C-friendly system out there that wasn't a Unix or Unix clone. Bit hackish how they emulated piping, though didn't "Mini Unix" do the same thing? > Then again IIRC the original Macintosh file system had no concept of > directories, but they somehow faked them in software. Makes you wonder > why they went through all that trouble instead of implementing > _proper_ support for directories/folders/filing cabinets/drawers/etc. I believe this is correct. -uso. From michael at kjorling.se Sat Feb 4 23:15:43 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sat, 4 Feb 2017 13:15:43 +0000 Subject: [TUHS] Happy birthday, Ken Thompson! In-Reply-To: References: <20170204123851.GF21797@yeono.kjorling.se> Message-ID: <20170204131543.GG21797@yeono.kjorling.se> On 4 Feb 2017 07:44 -0500, from usotsuki at buric.co (Steve Nickolas): > Bit hackish how they emulated piping, Well, I suppose there's only so much you can really do in an inherently single-tasking OS that needs to be able to do useful work on a system with a single 160 KB floppy drive, no virtual memory capability, and 64 KiB RAM. All things told, I regularly look back at what people were able to make computers of days yonder _do_, and am often amazed at how well they were able to get things to work _in spite of_ the limitations of the hardware of the time. -- 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 cym224 at gmail.com Sun Feb 5 08:48:42 2017 From: cym224 at gmail.com (Nemo) Date: Sat, 4 Feb 2017 17:48:42 -0500 Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <20170204035613.GC28573@mcvoy.com> References: <201702021311.v12DBNoa004846@freefriends.org> <20170204035613.GC28573@mcvoy.com> Message-ID: On 3 February 2017 at 22:56, Larry McVoy wrote: [...] > Strange culture. Seems to generate some good CPUs but I wonder if that > is because of that culture or in spite of it? Well, there are stories such as this -> http://www.theregister.co.uk/2003/07/10/intels_tanglewood_pumped_full/ N. From markhare at buffalo.edu Mon Feb 6 06:03:10 2017 From: markhare at buffalo.edu (Mark Hare) Date: Sun, 5 Feb 2017 15:03:10 -0500 Subject: [TUHS] PDP 11/34a Serial Communications Problem Message-ID: Hello all, This is my first time emailing the list, so please let me know if this doesn't belong here of if I'm breaking any rules. A few months ago, I rescued a PDP 11/34a with 2 RL01 drives from the scrap heap. The unit appears to work fine based on my limited front-panel testing. I haven't gotten the drives running yet since someone cut the power cords when the cabinet was being removed. There is a DL11-W serial line unit/realtime clock (M7856) installed in the 11/34 that I want to use for serial input/output. I have configured the card for 9600 baud, 8N1. Using some jumper wires, I carefully connected the card to a serial cable and a computer running a terminal and I was able to send some characters back and forth successfully. For a more permanent solution, I designed a simple adapter board that connects to the BERG 40 connector on the DL11-W and converts it to a DB9 serial port (In restrospect, this product was already available at https://oshpark.com/shared_projects/uTMf3v08 but I didn't know about that at the time). I also ordered a 40-pin (non-IDE) ribbon cable to connect the DL11-W to my adapter. When I connected everything, the 11/34 would start but no lights would appear on the front panel. I tried disconnecting the adapter but leaving the ribbon cable plugged into the BERG connector, but the problem persisted. When I removed the ribbon cable entirely, the unit powered on with no problems. Since this is a straight-through ribbon cable, I don't see what could be causing this problem. I have checked the continuity of each wire in the cable, and there doesn't appear to be a problem. I'd appreciate any advice that anyone has to offer. Yours, Mark D. Hare markhare at buffalo.edu University at Buffalo B. S. Civil Engineering '16 M. S. Structural/Earthquake Engineering Student -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Mon Feb 6 06:36:38 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 5 Feb 2017 20:36:38 +0000 Subject: [TUHS] PDP 11/34a Serial Communications Problem In-Reply-To: References: Message-ID: <20170205203638.GJ21797@yeono.kjorling.se> On 5 Feb 2017 15:03 -0500, from markhare at buffalo.edu (Mark Hare): > Since this is a straight-through ribbon cable, I don't see what could be > causing this problem. I have checked the continuity of each wire in the > cable, and there doesn't appear to be a problem. I'd appreciate any advice > that anyone has to offer. Have you checked to make sure that there aren't any connections between the individual wires? I'm not particularly familiar with the hardware of the PDP-11, but a signal going out on one wire and showing up also on some should-be unrelated wire could conceivably cause all kinds of weird behavior depending on exactly which wires are involved and what they are used for. The fact that merely leaving the ribbon cable connected causes the problem to appear definitely points to the PDP-11 not agreeing with the cable (or connections) for some reason. My first suspect in that case would be an electrical problem with the cable itself _versus what the PDP-11 wants it like_. Maybe the cable is operating to specifications, but the '11 wants something different. -- 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 jnc at mercury.lcs.mit.edu Mon Feb 6 06:38:28 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 5 Feb 2017 15:38:28 -0500 (EST) Subject: [TUHS] PDP 11/34a Serial Communications Problem Message-ID: <20170205203828.2A5F918C0BE@mercury.lcs.mit.edu> > From: Mark Hare > For a more permanent solution, I designed a simple adapter board that > connects to the BERG 40 connector on the DL11-W and converts it to a DB9 > serial port ... I also ordered a 40-pin (non-IDE) ribbon cable to > connect the DL11-W to my adapter. > When I connected everything, the 11/34 would start but no lights would > appear on the front panel. I tried disconnecting the adapter but leaving > the ribbon cable plugged into the BERG connector, but the problem > persisted. When I removed the ribbon cable entirely, the unit powered on > with no problems. That's extremely odd. There isn't a pin on the DL11-W Berg connector which should be able to cause anything like that kind of behaviour. The only _possible_ thing I can think of, looking at the list of signals on the Berg, is that you are grounding +5 (TT). Either that, or your DL11-W has some serious issue? > Since this is a straight-through ribbon cable, I don't see what could be > causing this problem. Me either. But clearly it's not just a straight-through ribbon cable.... I myself wouldn't have gone that route; one can obtain 40-pin IDE/DuPont (they are all .1" spacing pins, and basically interchangeable, module keying) connector shells, and female pins for same; I would have made a custom cable to plug into the Berg with that, to a DE-9S or DB-9P connector (depending on whether one wanted one wired as a DCE or DTE). (I myself make such cables, but to a DB-25S connector, and then use a commercial DB-25P to DE-9S adapter when needed.) Oh well... Does the DL11-W still work, using the jumper cables kludge? Noel From markhare at buffalo.edu Mon Feb 6 06:58:49 2017 From: markhare at buffalo.edu (Mark Hare) Date: Sun, 5 Feb 2017 15:58:49 -0500 Subject: [TUHS] PDP 11/34a Serial Communications Problem In-Reply-To: <20170205203828.2A5F918C0BE@mercury.lcs.mit.edu> References: <20170205203828.2A5F918C0BE@mercury.lcs.mit.edu> Message-ID: I believe I have found the problem. Upon closer inspection, I noticed that the ribbon cable that I am using is terminated in such a way that the conductors are exposed on the outside of the top of the female connector. Looking at the DL11-W, I saw that there is an uncovered trace on the circuit board just below the pins of the BERG connector. It appears that the exposed conductor ends of the cable were making contact with this trace, which shorted the entire cable together. I covered the exposed ends with a piece of electrical tape and the whole setup now works precisely as intended. Frankly, I'm just glad that there doesn't appear to be any lasting damage. Thank you Michael and Noel for your help; I'm sure I'll be back with more questions as I make progress with this machine. Yours, Mark D. Hare markhare at buffalo.edu University at Buffalo B. S. Civil Engineering '16 M. S. Structural/Earthquake Engineering Student On Sun, Feb 5, 2017 at 3:38 PM, Noel Chiappa wrote: > > From: Mark Hare > > > For a more permanent solution, I designed a simple adapter board that > > connects to the BERG 40 connector on the DL11-W and converts it to a DB9 > > serial port ... I also ordered a 40-pin (non-IDE) ribbon cable to > > connect the DL11-W to my adapter. > > > When I connected everything, the 11/34 would start but no lights would > > appear on the front panel. I tried disconnecting the adapter but leaving > > the ribbon cable plugged into the BERG connector, but the problem > > persisted. When I removed the ribbon cable entirely, the unit powered on > > with no problems. > > That's extremely odd. There isn't a pin on the DL11-W Berg connector which > should be able to cause anything like that kind of behaviour. The only > _possible_ thing I can think of, looking at the list of signals on the Berg, > is that you are grounding +5 (TT). Either that, or your DL11-W has some > serious issue? > > > Since this is a straight-through ribbon cable, I don't see what could be > > causing this problem. > > Me either. But clearly it's not just a straight-through ribbon cable.... > > I myself wouldn't have gone that route; one can obtain 40-pin IDE/DuPont (they > are all .1" spacing pins, and basically interchangeable, module keying) > connector shells, and female pins for same; I would have made a custom cable > to plug into the Berg with that, to a DE-9S or DB-9P connector (depending on > whether one wanted one wired as a DCE or DTE). (I myself make such cables, but > to a DB-25S connector, and then use a commercial DB-25P to DE-9S adapter when > needed.) Oh well... > > Does the DL11-W still work, using the jumper cables kludge? > > Noel From jnc at mercury.lcs.mit.edu Mon Feb 6 08:01:06 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 5 Feb 2017 17:01:06 -0500 (EST) Subject: [TUHS] PDP 11/34a Serial Communications Problem Message-ID: <20170205220106.3443518C0C7@mercury.lcs.mit.edu> > From: Mark Hare > I believe I have found the problem. Excellent! > Looking at the DL11-W, I saw that there is an uncovered trace on the > circuit board just below the pins of the BERG connector. It appears > that the exposed conductor ends of the cable were making contact with > this trace, which shorted the entire cable together. Shorting any set of DL11-W pins together still shouldn't have caused that symptom, AFAICS. I'm too lazy to pull out a DL11-W, and prints thereof, to check, but I suspect that what actually happened is that trace carries some 'interesting' signal, and it got grounded 'or something' by the exposed ends of the flat cable. > I'm just glad that there doesn't appear to be any lasting damage. Indeed! I was worried about that... Noel From dave at horsfall.org Mon Feb 6 08:10:44 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Feb 2017 09:10:44 +1100 (EST) Subject: [TUHS] How Unix brings people together, or it's a small world In-Reply-To: References: Message-ID: On Thu, 2 Feb 2017, David wrote: [ Great story!] > So, who else has weird stories of how Unix development or Unix > conferences had the side effect of making the world a smaller place. Unix itself pretty much changed the world; without those two bods we'd all be running M$ Windoze, and believing that it's wonderful ('cuz Billy told us so). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Mon Feb 6 15:41:48 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 6 Feb 2017 16:41:48 +1100 (EST) Subject: [TUHS] Names of famous, historical UNIX machines? In-Reply-To: <67b5fc0baf200260db0f035f858929ed@xs4all.nl> References: <20170201204327.GU21797@yeono.kjorling.se> <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl> <67b5fc0baf200260db0f035f858929ed@xs4all.nl> Message-ID: On Fri, 3 Feb 2017, Jacob Goense wrote: > Piet saved it at http://godfatherof.nl/kremvax.html Thank you! Thank you! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jsteve at superglobalmegacorp.com Tue Feb 7 02:07:28 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 7 Feb 2017 00:07:28 +0800 Subject: [TUHS] How Unix brings people together, or it's a small world In-Reply-To: References: Message-ID: <3101539A-0E7A-4AF8-B290-5E00252E4CB0@superglobalmegacorp.com> I doubt Microsoft would have made it without Xenix on their backoffice, and it was not only UNIX that inspired the changes in MS-DOS 3 and OS/2 to make it more UNIX like, but had inspired Cutler to make the next VMS written in C to be portable. Maybe we'd be in a far more Vax dominated world with more Digital inspired mid range kit, or something else would have filled the void to deliver us from a single vendor. On February 6, 2017 6:10:44 AM GMT+08:00, Dave Horsfall wrote: >On Thu, 2 Feb 2017, David wrote: > >[ Great story!] > >> So, who else has weird stories of how Unix development or Unix >> conferences had the side effect of making the world a smaller place. > >Unix itself pretty much changed the world; without those two bods we'd >all >be running M$ Windoze, and believing that it's wonderful ('cuz Billy >told >us so). > >-- >Dave Horsfall DTM (VK2KFU) "Those who don't understand security will >suffer." -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Tue Feb 7 02:42:11 2017 From: rminnich at gmail.com (ron minnich) Date: Mon, 06 Feb 2017 16:42:11 +0000 Subject: [TUHS] How Unix brings people together, or it's a small world In-Reply-To: References: Message-ID: On Sun, Feb 5, 2017 at 2:11 PM Dave Horsfall wrote: > > > Unix itself pretty much changed the world; without those two bods we'd all > be running M$ Windoze, and believing that it's wonderful ('cuz Billy told > us so). > > -- > yes and no. Yes, because the ideas made it out. No, because, well ... In 1976 or so bwk came to udel as we had just set up a Unix V6 at that point. He gave a great talk. One example was looking up all the words in the dictionary that could be created with the upside down characters form a calculator (left as an exercise for the reader). He ran a standard dictionary tool, and pointed out that o it could not run in a pipe o it had a prompt, meaning even if run in a pipe there'd be output we did not wan o it was wordy, telling us "when it was compiled (like we care) ..." I always loved that 'like we care" part. he pointed out the core concept: small simple tools that do one thing well, and that you compose with | operators. What a long strange trip it's been. Lots of commands are now little shells: git --help go help bash --help and many interns I now work with are astonished when I point out that bash can be part of a processing pipeline. Further, back then, processes were cheap. You used them and tossed them. I saw a talk a few years back about why you should use i3 instead of wmii; one reason was that starting processes was so expensive that i3 did things much faster (this is actually true now; people tell me all the time how expensive it is to start a process). Why are process slow to start? LD_DEBUG=all date strace date and count the system calls "modern" software techniques have completely forgotten all the lessons of Unix. It's been sad to watch. Linux today is much more like the systems Unix displaced than it is like Unix. So, yes, the world changed, but not as much as we might think. Meet the new boss, same as the old boss. ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Tue Feb 7 13:03:52 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 06 Feb 2017 22:03:52 -0500 Subject: [TUHS] How Unix brings people together, or it's a small Message-ID: <201702070303.v1733qvF011648@coolidge.cs.Dartmouth.EDU> > Lots of commands are now little shells ... > Linux today is much more like the systems > Unix displaced than it is like Unix So depressingly true! Doug From rochkind at basepath.com Tue Feb 7 14:06:35 2017 From: rochkind at basepath.com (Marc Rochkind) Date: Mon, 6 Feb 2017 21:06:35 -0700 Subject: [TUHS] How Unix brings people together, or it's a small In-Reply-To: <201702070303.v1733qvF011648@coolidge.cs.Dartmouth.EDU> References: <201702070303.v1733qvF011648@coolidge.cs.Dartmouth.EDU> Message-ID: Of course. Linux is: 1. old, 2. designed by a huge group, 3. intended to serve many purposes UNIX was, at least in its early days, the opposite in all three ways. But, after 15 years or so, it also was numbers 1 - 3. (Speaking of System V here.) There have been OSes that remained beautifully sleek and uncluttered forever. Such as BeOS. However, all such systems failed to achieve critical mass. Which is why they remained true. No way out of this trap. --Marc On Mon, Feb 6, 2017 at 8:03 PM, Doug McIlroy wrote: > > > Lots of commands are now little shells > ... > > Linux today is much more like the systems > > Unix displaced than it is like Unix > > So depressingly true! > > Doug > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 8 09:10:52 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 7 Feb 2017 18:10:52 -0500 Subject: [TUHS] How Unix brings people together, or it's a small In-Reply-To: References: <201702070303.v1733qvF011648@coolidge.cs.Dartmouth.EDU> Message-ID: And I think it has been peed on by many different people trying to leave their own mark on it along the way. On Mon, Feb 6, 2017 at 11:06 PM, Marc Rochkind wrote: > Of course. Linux is: > > 1. old, > 2. designed by a huge group, > 3. intended to serve many purposes > > UNIX was, at least in its early days, the opposite in all three ways. But, > after 15 years or so, it also was numbers 1 - 3. (Speaking of System V > here.) > > There have been OSes that remained beautifully sleek and uncluttered > forever. Such as BeOS. However, all such systems failed to achieve critical > mass. Which is why they remained true. > > No way out of this trap. > > --Marc > > On Mon, Feb 6, 2017 at 8:03 PM, Doug McIlroy > wrote: > >> >> > Lots of commands are now little shells >> ... >> > Linux today is much more like the systems >> > Unix displaced than it is like Unix >> >> So depressingly true! >> >> Doug >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scj at yaccman.com Wed Feb 8 09:38:40 2017 From: scj at yaccman.com (Steve Johnson) Date: Tue, 07 Feb 2017 15:38:40 -0800 Subject: [TUHS] How Unix brings people together, or it's a small In-Reply-To: Message-ID: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> Looking back, the social dynamics of the Unix group helped a lot in keeping the bloat small.   The rule was, whoever touches something last becomes its owner.  Of course, we were all free to complain about things, and did, but the amalgamation of tinkerings that characterizes most of the Linux commands just didn't happen.  At times this hot-potato activity worked very well.  In a moment of inspiration I thought up the syntax for the 'at' command  (  "at 3am cc -o *.c", etc. ).  I implemented it as a shell script and it was pretty feeble.  My implementation lasted about a week -- I came in on a Monday and Dennis had plugged the majority of the holes -- got the permissions right, saved the search path and current directory, etc.  I think we were both happy with the process... I think the other thing we understood was that if you added an on/off option to your application you had a choice of either doing twice as much testing as previously, or testing both configurations of the code half as much.   If you look at the gcc manual, you can see the result -- many dozen pages just listing the options.  It's probably up around the age of the universe now to reliably test the whole thing.   And it seems like if you set the options differently than usual, thing break, can't be debugged reliably, or something else surprising.  One rule with Linux: do it vanilla or go home... Steve ----- Original Message ----- From: "Clem Cole" To: "Marc Rochkind" Cc: "TUHS main list" Sent: Tue, 7 Feb 2017 18:10:52 -0500 Subject: Re: [TUHS] How Unix brings people together, or it's a small And I think it has been peed on by many different people trying to leave their own mark on it along the way. On Mon, Feb 6, 2017 at 11:06 PM, Marc Rochkind wrote: Of course. Linux is: 1. old, 2. designed by a huge group, 3. intended to serve many purposes UNIX was, at least in its early days, the opposite in all three ways. But, after 15 years or so, it also was numbers 1 - 3. (Speaking of System V here.) There have been OSes that remained beautifully sleek and uncluttered forever. Such as BeOS. However, all such systems failed to achieve critical mass. Which is why they remained true. No way out of this trap. --Marc On Mon, Feb 6, 2017 at 8:03 PM, Doug McIlroy wrote: >  Lots of commands are now little shells ... > Linux today is much more like the systems > Unix displaced than it is like Unix So depressingly true! Doug Links: ------ [1] mailto:rochkind at basepath.com [2] mailto:doug at cs.dartmouth.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Wed Feb 8 12:55:38 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Wed, 8 Feb 2017 13:55:38 +1100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> Message-ID: <20170208025538.GE65698@eureka.lemis.com> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: > Looking back, the social dynamics of the Unix group helped a lot in > keeping the bloat small.   The rule was, whoever touches something > last becomes its owner.  Of course, we were all free to complain > about things, and did, but the amalgamation of tinkerings that > characterizes most of the Linux commands just didn't happen.  Out of interest: where do you (or others) consider that the current BSD projects it in this comparison? 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 downing.nick at gmail.com Wed Feb 8 13:47:03 2017 From: downing.nick at gmail.com (Nick Downing) Date: Wed, 8 Feb 2017 14:47:03 +1100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <20170208025538.GE65698@eureka.lemis.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: This is an issue that interests me quite a bit, since I was running FreeBSD in an effort to get around Linux bloat problems discussed. Well not that I really mind Linux as a user interface / runtime environment / main development machine, but I think it probably shouldn't be used as a "least common denominator" for development since you end up introducing unwanted dependencies on a whole lot of stuff. So I was running FreeBSD as a more minimal *nix. I did quite a lot of interesting stuff with FreeBSD such as setting up diskless workstations in my home, etc. I spent a lot of time tinkering around in the kernel code. I was planning to do some serious development on 4.4BSDLite or FreeBSD to create an operating system more to my liking. So, I was looking carefully at differences since ancient *nixes. And, I can say that FreeBSD is pretty bloated. Umm well they've added SMP, at the time it was using the Giant Lock although that could be fixed by now. They've added VFS and NFS of course. They've added an entire subsystem for block devices IIRC that handles partitioning and possibly some other sophisticated stuff, which I believe is their own design. Umm the kqueues and I believe they have their own implementation of kernel threading or lightweight processes including some sort of idle daemon. The network stack is heavily upgraded, to the extent I looked into it, the added features are things you would want (syncookies = DOS protection, etc) but also could not possibly be called minimal, and would preclude running it on other than a multi-megabyte machine. They have multiple ABIs so the kernel can accept Linux or BSD syscalls or whatever else (I used it to run Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they have kernel modules ala Linux. Lots and lots and lots of stuff... and that's only considering the kernel. If you look in the ports collection you see they have incredible amounts of bloat there too... for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm denigrating these tools, since they do invaluable work and I use them every day, but the point is, you CANNOT call them minimal. The quest for a clean minimal system goes on ->. FreeBSD is not the answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. cheers, Nick On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey wrote: > On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: >> Looking back, the social dynamics of the Unix group helped a lot in >> keeping the bloat small. The rule was, whoever touches something >> last becomes its owner. Of course, we were all free to complain >> about things, and did, but the amalgamation of tinkerings that >> characterizes most of the Linux commands just didn't happen. > > Out of interest: where do you (or others) consider that the current > BSD projects it in this comparison? > > 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 From jsteve at superglobalmegacorp.com Wed Feb 8 13:56:37 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 8 Feb 2017 11:56:37 +0800 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: What about NetBSD 1.1 or even 386BSD? There never was a 4.2 or 4.3 for i386 was there? I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly reducing its footprint. On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing wrote: >This is an issue that interests me quite a bit, since I was running >FreeBSD in an effort to get around Linux bloat problems discussed. >Well not that I really mind Linux as a user interface / runtime >environment / main development machine, but I think it probably >shouldn't be used as a "least common denominator" for development >since you end up introducing unwanted dependencies on a whole lot of >stuff. > >So I was running FreeBSD as a more minimal *nix. I did quite a lot of >interesting stuff with FreeBSD such as setting up diskless >workstations in my home, etc. I spent a lot of time tinkering around >in the kernel code. I was planning to do some serious development on >4.4BSDLite or FreeBSD to create an operating system more to my liking. >So, I was looking carefully at differences since ancient *nixes. > >And, I can say that FreeBSD is pretty bloated. Umm well they've added >SMP, at the time it was using the Giant Lock although that could be >fixed by now. They've added VFS and NFS of course. They've added an >entire subsystem for block devices IIRC that handles partitioning and >possibly some other sophisticated stuff, which I believe is their own >design. Umm the kqueues and I believe they have their own >implementation of kernel threading or lightweight processes including >some sort of idle daemon. The network stack is heavily upgraded, to >the extent I looked into it, the added features are things you would >want (syncookies = DOS protection, etc) but also could not possibly be >called minimal, and would preclude running it on other than a >multi-megabyte machine. They have multiple ABIs so the kernel can >accept Linux or BSD syscalls or whatever else (I used it to run >Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they >have kernel modules ala Linux. Lots and lots and lots of stuff... and >that's only considering the kernel. If you look in the ports >collection you see they have incredible amounts of bloat there too... >for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm >denigrating these tools, since they do invaluable work and I use them >every day, but the point is, you CANNOT call them minimal. > >The quest for a clean minimal system goes on ->. FreeBSD is not the >answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. > >cheers, Nick > >On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey >wrote: >> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: >>> Looking back, the social dynamics of the Unix group helped a lot in >>> keeping the bloat small. The rule was, whoever touches something >>> last becomes its owner. Of course, we were all free to complain >>> about things, and did, but the amalgamation of tinkerings that >>> characterizes most of the Linux commands just didn't happen. >> >> Out of interest: where do you (or others) consider that the current >> BSD projects it in this comparison? >> >> 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Wed Feb 8 13:58:45 2017 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 8 Feb 2017 14:58:45 +1100 (EST) Subject: [TUHS] Early Internet work (Was: History of select(2)) In-Reply-To: References: <20170130025003.1CAEA18C0BA@mercury.lcs.mit.edu> Message-ID: My gripe with BDS C was that it wasn't ANSI (HiTech was), such as no function prototypes, no static initialisations, etc. As Henry Spencer once said, "To be called a C compiler it ought to at least compile C". -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From peter at rulingia.com Wed Feb 8 15:37:52 2017 From: peter at rulingia.com (Peter Jeremy) Date: Wed, 8 Feb 2017 16:37:52 +1100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: <20170208053752.GA6039@server.rulingia.com> On 2017-Feb-08 14:47:03 +1100, Nick Downing wrote: [FreeBSD bloat] >that's only considering the kernel. If you look in the ports >collection you see they have incredible amounts of bloat there too... Note the the ports system is not a core part of FreeBSD - it's for bits that have deliberately been left out of the core/base system. >The quest for a clean minimal system goes on ->. FreeBSD is not the >answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. I believe someone has ported 2.11BSD to the x86 -- 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 wes.parish at paradise.net.nz Wed Feb 8 18:25:44 2017 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Wed, 08 Feb 2017 21:25:44 +1300 (NZDT) Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: <1486542344.589ad6086611d@www.paradise.net.nz> IIRC, 386BSD was based on 4.3BSD, though I forget which one. Anyone have a better memory than me? Again, IIRC, Bill Jolitz in his DDJ articles mentions how the 386BSD kernel is smaller than the Mach microkernel. Thanks Wesley Parish Quoting Jason Stevens : > What about NetBSD 1.1 or even 386BSD? > > There never was a 4.2 or 4.3 for i386 was there? > > I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 > greatly reducing its footprint. > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn From usotsuki at buric.co Wed Feb 8 19:57:06 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 8 Feb 2017 04:57:06 -0500 (EST) Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <1486542344.589ad6086611d@www.paradise.net.nz> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <1486542344.589ad6086611d@www.paradise.net.nz> Message-ID: On Wed, 8 Feb 2017, Wesley Parish wrote: > IIRC, 386BSD was based on 4.3BSD, though I forget which one. Anyone have a > better memory than me? > > Again, IIRC, Bill Jolitz in his DDJ articles mentions how the 386BSD kernel is > smaller than the Mach microkernel. Net/2, wasn't it? I suppose if it's close to any complete release of BSD it's probably 4.3-Reno... -uso. From downing.nick at gmail.com Wed Feb 8 21:21:36 2017 From: downing.nick at gmail.com (Nick Downing) Date: Wed, 8 Feb 2017 22:21:36 +1100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: Yes, NetBSD and 386BSD are interesting. They could well form a good basis for a minimal but fully functional OS for a modern platform. One reservation I have though, is as follows: When 386BSD and its derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still encumbered and thus they had to be based on 4.4BSD Lite (not even NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or even NET/2, even though it was theoretically possible, by examining what had to be taken out/added to produce 4.4BSD Lite. Given that Unix is now unencumbered I believe there is no point adopting 4.4, or even 4.3Reno, because the main thing done in those releases as far as I know, is to add partial POSIX compliance. But if you want POSIX compliance you will not achieve minimality. As an example consider the BSD sigvec() routine. POSIX calls this sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old integer mask becomes a sigset_t and so on... and in any reasonable POSIX compliant BSD the two calls are gonna have to coexist, etc. As to 32V, I appreciate your idea, as I was having some similar thoughts myself. However I personally wouldn't use 32V as a basis for any serious porting work, because I would assume V7 and 4.3 are much more stable and well tested, since they ran in a lot of installations over a long time. That's not to denigrate the huge achievement in porting V7 to the VAX and producing 32V, but it probably has some rough edges that were smoothed out over time to produce the 4BSDs. The situation is a bit different for kernel/toolchain/other userspace. As to the kernel I have been trying to make a detailed comparison between 32V and the BSDs, but have been a bit put off by the fact that all files moved around and may have been renamed, I will figure it all out eventually though. As to the toolchain I have compared it quite carefully with 4.3BSD, and I conclude you should use the later toolchain as there is no disadvantage and some advantages to doing so. As to the rest of the userspace, I BELIEVE that it's stock V7 with any 32-bit issues fixed, but I suspect somewhat hastily and superficially. Producing a 32V-like kernel from 4.3BSD sources would probably be quite difficult, it would be relatively easy to disable added system calls, but harder to disable things like setpgrp() or the associated support in the TTY drivers. More seriously the memory management would have to change, I am planning however to make virtual memory optional in the 4.3BSD kernel, by maybe putting the 32V code back in, protected by #ifndef VM or some such (somewhat like Steven Schultz has done in porting 4.3BSD to PDP-11 to produce 2.11BSD). On the other hand producing a 32V-like userland from the 4.3BSD sources would be pretty easy, I think just delete the sources for any executables that weren't distributed with 32V and possibly, if any of the tools seem particularly bloated, comment out any command line switches or features that weren't in 32V. Going to this level of effort would likely be pointless though. Another option would be taking V7 and re-porting it (except the toolchain) over to a 32-bit environment and kernel. I have developed over the past months, tools that make this relatively straightforward, and in the process would rediscover any 32-bit issues that were fixed in creating 32V. So I wouldn't use 32V. On a slightly different tack, I also have been for some time investigating the idea of an Apple II port of Unix, there are massive technical issues to be solved, but I think I got a bit closer the other night when I decided to collect all information and resources I could find about Mini-Unix and LSX (LSI Unix). Both are self-supporting V6-based environments, the compiler can only compile small programs but it is nonetheless possible for each Unix to recomple itself. LSX I believe could run from floppies (dunno about 140K floppies) in less than 64K. So, you know, true minimality is a relative term. We want something LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to know more), something 4.3BSD-like for a VAX or 386... something a bit more fully featured for a modern 64-bit multi-gigabyte system... but just not as bloated as what we currently rely on. Hmm well it's hard. What I do know, is that I have a lot of old hardware with <16M RAM and Linux won't run on it anymore, and this annoys me very greatly. In talking about FreeBSD/Linux bloat I forgot to mention the packet filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience with this, since I regularly used to put 2 Ethernet cards in my home server and make it Internet facing through one of them and share the connection using NAT through the other card. But I've come to the conclusion this is stupid, and moreover, that putting a complete mini-language into the kernel just for this purpose is utterly stupid. Programming the thing from userspace is incredibly intricate, and all this complexity serves no purpose. I recently found out about SLIRP (userspace packet rewriting) and I think this would be a good way to implement NAT on servers or routers that actually need to do NAT -- just make a userspace process that runs something SLIRP-like and has a raw socket to the second Ethernet card, and Bob's your uncle. But this got me thinking along pretty productive lines in terms of the tiny Apple II port -- I have been wanting to put the 2.11BSD network stack into an Apple II for a long time, but I've now realized this is not necessary. A much better approach for those Mini-Unix or LSX or even V7 systems, would be to have a userspace library that does SLIP and contains its own TCP, UDP, IP drivers, resolver and so on. Then if you run a userspace program like say, ftp, which is linked to the userspace TCP library, it would basically just open /dev/ttyXX, bring up the SLIP link itself, do any necessary downloads etc, then close the TTY and stop responding to any IP stuff coming over the SLIP link whilst you quit to the prompt, until another program reopens it. cheers, Nick On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens wrote: > What about NetBSD 1.1 or even 386BSD? > > There never was a 4.2 or 4.3 for i386 was there? > > I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly > reducing its footprint. > > > > > On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing > wrote: >> >> This is an issue that interests me quite a bit, since I was running >> FreeBSD in an effort to get around Linux bloat problems discussed. >> Well not that I really mind Linux as a user interface / runtime >> environment / main development machine, but I think it probably >> shouldn't be used as a "least common denominator" for development >> since you end up introducing unwanted dependencies on a whole lot of >> stuff. >> >> So I was running FreeBSD as a more minimal *nix. I did quite a lot of >> interesting stuff with FreeBSD such as setting up diskless >> workstations in my home, etc. I spent a lot of time tinkering around >> in the kernel code. I was planning to do some serious development on >> 4.4BSDLite or FreeBSD to create an operating system more to my liking. >> So, I was looking carefully at differences since ancient *nixes. >> >> And, I can say that FreeBSD is pretty bloated. Umm well they've added >> SMP, at the time it was using the Giant Lock although that could be >> fixed by now. They've added VFS and NFS of course. They've added an >> entire subsystem for block devices IIRC that handles partitioning and >> possibly some other sophisticated stuff, which I believe is their own >> design. Umm the kqueues and I believe they have their own >> implementation of kernel threading or lightweight processes including >> some sort of idle daemon. The network stack is heavily upgraded, to >> the extent I looked into it, the added features are things you would >> want (syncookies = DOS protection, etc) but also could not possibly be >> called minimal, and would preclude running it on other than a >> multi-megabyte machine. They have multiple ABIs so the kernel can >> accept Linux or BSD syscalls or whatever else (I used it to run >> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they >> have kernel modules ala Linux. Lots and lots and lots of stuff... and >> that's only considering the kernel. If you look in the ports >> collection you see they have incredible amounts of bloat there too... >> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm >> denigrating these tools, since they do invaluable work and I use them >> every day, but the point is, you CANNOT call them minimal. >> >> The quest for a clean minimal system goes on ->. FreeBSD is not the >> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. >> >> cheers, Nick >> >> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey >> wrote: >>> >>> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: >>>> >>>> Looking back, the social dynamics of the Unix group helped a lot in >>>> keeping the bloat small. The rule was, whoever touches something >>>> last becomes its owner. Of course, we were all free to complain >>>> about things, and did, but the amalgamation of tinkerings that >>>> characterizes most of the Linux commands just didn't happen. >>> >>> >>> Out of interest: where do you (or others) consider that the current >>> BSD projects it in this comparison? >>> >>> 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 > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From jsteve at superglobalmegacorp.com Wed Feb 8 21:59:09 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Wed, 8 Feb 2017 19:59:09 +0800 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: <609dee92-753d-4d9b-8586-97839620c8d2@SG2APC01FT012.eop-APC01.prod.protection.outlook.com> I love SLiRP, it’s insanely easy to integrate into other programs/emulators to get that fun TCP/IP networking with no device drivers... I’ve put it into all kinds of fun things. My latest one was integrating with a cisco router via IPIP tunnelling. Just slap on a MAC frame from the encapsulated packet, and feed it into SLiRP, and likewise, strip the MAC frame, and feed it back to IPIP. Where I live I get throttled across international links all the time, SSH/PPTP/IPSEC/OpenVPN all seem to be detected and throttled down to 64kb/sec or less which is really disappointing, meanwhile I can pull files via HTTP for a good 10Mb/sec. So eventually Im going to try to mix it in with .net remoting so I can host SLiRP on Windows/IIS and have a Windows machine on my LAN grab the IPIP tunnel from my cisco and send it off via HTTP... That way the packet inspectors see proper HTTP traffic.. Then add in some compression and encryption and I’ve made yet another VPN, although one that’ll interface a router to SLiRP. But I’ve plugged it into SIMH, although they use a much more involved, and newer one now, PCem, Previous, Basilisk II, and I got the ball rolling on WinUAE. I may have left a few off, but yes, it’s an incredibly versatile library. From: Nick Downing Sent: Thursday, 9 February 2017 7:35 PM To: Jason Stevens Cc: TUHS main list; Greg 'groggy' Lehey Subject: Re: [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) Yes, NetBSD and 386BSD are interesting. They could well form a good basis for a minimal but fully functional OS for a modern platform. One reservation I have though, is as follows: When 386BSD and its derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still encumbered and thus they had to be based on 4.4BSD Lite (not even NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or even NET/2, even though it was theoretically possible, by examining what had to be taken out/added to produce 4.4BSD Lite. Given that Unix is now unencumbered I believe there is no point adopting 4.4, or even 4.3Reno, because the main thing done in those releases as far as I know, is to add partial POSIX compliance. But if you want POSIX compliance you will not achieve minimality. As an example consider the BSD sigvec() routine. POSIX calls this sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old integer mask becomes a sigset_t and so on... and in any reasonable POSIX compliant BSD the two calls are gonna have to coexist, etc. As to 32V, I appreciate your idea, as I was having some similar thoughts myself. However I personally wouldn't use 32V as a basis for any serious porting work, because I would assume V7 and 4.3 are much more stable and well tested, since they ran in a lot of installations over a long time. That's not to denigrate the huge achievement in porting V7 to the VAX and producing 32V, but it probably has some rough edges that were smoothed out over time to produce the 4BSDs. The situation is a bit different for kernel/toolchain/other userspace. As to the kernel I have been trying to make a detailed comparison between 32V and the BSDs, but have been a bit put off by the fact that all files moved around and may have been renamed, I will figure it all out eventually though. As to the toolchain I have compared it quite carefully with 4.3BSD, and I conclude you should use the later toolchain as there is no disadvantage and some advantages to doing so. As to the rest of the userspace, I BELIEVE that it's stock V7 with any 32-bit issues fixed, but I suspect somewhat hastily and superficially. Producing a 32V-like kernel from 4.3BSD sources would probably be quite difficult, it would be relatively easy to disable added system calls, but harder to disable things like setpgrp() or the associated support in the TTY drivers. More seriously the memory management would have to change, I am planning however to make virtual memory optional in the 4.3BSD kernel, by maybe putting the 32V code back in, protected by #ifndef VM or some such (somewhat like Steven Schultz has done in porting 4.3BSD to PDP-11 to produce 2.11BSD). On the other hand producing a 32V-like userland from the 4.3BSD sources would be pretty easy, I think just delete the sources for any executables that weren't distributed with 32V and possibly, if any of the tools seem particularly bloated, comment out any command line switches or features that weren't in 32V. Going to this level of effort would likely be pointless though. Another option would be taking V7 and re-porting it (except the toolchain) over to a 32-bit environment and kernel. I have developed over the past months, tools that make this relatively straightforward, and in the process would rediscover any 32-bit issues that were fixed in creating 32V. So I wouldn't use 32V. On a slightly different tack, I also have been for some time investigating the idea of an Apple II port of Unix, there are massive technical issues to be solved, but I think I got a bit closer the other night when I decided to collect all information and resources I could find about Mini-Unix and LSX (LSI Unix). Both are self-supporting V6-based environments, the compiler can only compile small programs but it is nonetheless possible for each Unix to recomple itself. LSX I believe could run from floppies (dunno about 140K floppies) in less than 64K. So, you know, true minimality is a relative term. We want something LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to know more), something 4.3BSD-like for a VAX or 386... something a bit more fully featured for a modern 64-bit multi-gigabyte system... but just not as bloated as what we currently rely on. Hmm well it's hard. What I do know, is that I have a lot of old hardware with <16M RAM and Linux won't run on it anymore, and this annoys me very greatly. In talking about FreeBSD/Linux bloat I forgot to mention the packet filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience with this, since I regularly used to put 2 Ethernet cards in my home server and make it Internet facing through one of them and share the connection using NAT through the other card. But I've come to the conclusion this is stupid, and moreover, that putting a complete mini-language into the kernel just for this purpose is utterly stupid. Programming the thing from userspace is incredibly intricate, and all this complexity serves no purpose. I recently found out about SLIRP (userspace packet rewriting) and I think this would be a good way to implement NAT on servers or routers that actually need to do NAT -- just make a userspace process that runs something SLIRP-like and has a raw socket to the second Ethernet card, and Bob's your uncle. But this got me thinking along pretty productive lines in terms of the tiny Apple II port -- I have been wanting to put the 2.11BSD network stack into an Apple II for a long time, but I've now realized this is not necessary. A much better approach for those Mini-Unix or LSX or even V7 systems, would be to have a userspace library that does SLIP and contains its own TCP, UDP, IP drivers, resolver and so on. Then if you run a userspace program like say, ftp, which is linked to the userspace TCP library, it would basically just open /dev/ttyXX, bring up the SLIP link itself, do any necessary downloads etc, then close the TTY and stop responding to any IP stuff coming over the SLIP link whilst you quit to the prompt, until another program reopens it. cheers, Nick On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens wrote: > What about NetBSD 1.1 or even 386BSD? > > There never was a 4.2 or 4.3 for i386 was there? > > I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly > reducing its footprint. > > > > > On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing > wrote: >> >> This is an issue that interests me quite a bit, since I was running >> FreeBSD in an effort to get around Linux bloat problems discussed. >> Well not that I really mind Linux as a user interface / runtime >> environment / main development machine, but I think it probably >> shouldn't be used as a "least common denominator" for development >> since you end up introducing unwanted dependencies on a whole lot of >> stuff. >> >> So I was running FreeBSD as a more minimal *nix. I did quite a lot of >> interesting stuff with FreeBSD such as setting up diskless >> workstations in my home, etc. I spent a lot of time tinkering around >> in the kernel code. I was planning to do some serious development on >> 4.4BSDLite or FreeBSD to create an operating system more to my liking. >> So, I was looking carefully at differences since ancient *nixes. >> >> And, I can say that FreeBSD is pretty bloated. Umm well they've added >> SMP, at the time it was using the Giant Lock although that could be >> fixed by now. They've added VFS and NFS of course. They've added an >> entire subsystem for block devices IIRC that handles partitioning and >> possibly some other sophisticated stuff, which I believe is their own >> design. Umm the kqueues and I believe they have their own >> implementation of kernel threading or lightweight processes including >> some sort of idle daemon. The network stack is heavily upgraded, to >> the extent I looked into it, the added features are things you would >> want (syncookies = DOS protection, etc) but also could not possibly be >> called minimal, and would preclude running it on other than a >> multi-megabyte machine. They have multiple ABIs so the kernel can >> accept Linux or BSD syscalls or whatever else (I used it to run >> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they >> have kernel modules ala Linux. Lots and lots and lots of stuff... and >> that's only considering the kernel. If you look in the ports >> collection you see they have incredible amounts of bloat there too... >> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm >> denigrating these tools, since they do invaluable work and I use them >> every day, but the point is, you CANNOT call them minimal. >> >> The quest for a clean minimal system goes on ->. FreeBSD is not the >> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. >> >> cheers, Nick >> >> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey >> wrote: >>> >>> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: >>>> >>>> Looking back, the social dynamics of the Unix group helped a lot in >>>> keeping the bloat small. The rule was, whoever touches something >>>> last becomes its owner. Of course, we were all free to complain >>>> about things, and did, but the amalgamation of tinkerings that >>>> characterizes most of the Linux commands just didn't happen. >>> >>> >>> Out of interest: where do you (or others) consider that the current >>> BSD projects it in this comparison? >>> >>> 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 > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ches at cheswick.com Wed Feb 8 22:16:47 2017 From: ches at cheswick.com (ches@Cheswick.com) Date: Wed, 8 Feb 2017 07:16:47 -0500 Subject: [TUHS] How Unix brings people together, or it's a small In-Reply-To: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> Message-ID: These modern systems desperately need a Doug-like editor for their low-bit rate man pages. Also, it would be nice to see people throwing away code, especially in the kernel. And the netpbm library, which tried to follow the unix filter module, still has programs which write useless stuff to stderr. ches From downing.nick at gmail.com Wed Feb 8 22:24:49 2017 From: downing.nick at gmail.com (Nick Downing) Date: Wed, 8 Feb 2017 23:24:49 +1100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it'sa small...) In-Reply-To: <609dee92-753d-4d9b-8586-97839620c8d2@SG2APC01FT012.eop-APC01.prod.protection.outlook.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <609dee92-753d-4d9b-8586-97839620c8d2@SG2APC01FT012.eop-APC01.prod.protection.outlook.com> Message-ID: I have done something like that in order to access internet through uni wireless that only allowed HTTP. I used the htc/hts tools which are apparently from a package called httptunnel that's pretty popular, when I searched just now most of the top results involved httptunnel. When I did it (about 5 years ago) I found these tools incredibly basic and not very convenient to use, however they did work. What I would suggest for you is to buy a virtual server, I have one, it costs $4 per quarter (in Hong Kong but this provider also has US locations for the same price). I think the amount of data per month is pretty decent but you might have to pay extra depending on usage. Anyway, you run hts on it, so you connect from home through your broken ISP that throttles non-HTTP traffic, and have it download and forward you stuff. cheers, Nick On Wed, Feb 8, 2017 at 10:59 PM, wrote: > I love SLiRP, it’s insanely easy to integrate into other programs/emulators > to get that fun TCP/IP networking with no device drivers... I’ve put it into > all kinds of fun things. > > > > My latest one was integrating with a cisco router via IPIP tunnelling. Just > slap on a MAC frame from the encapsulated packet, and feed it into SLiRP, > and likewise, strip the MAC frame, and feed it back to IPIP. Where I live I > get throttled across international links all the time, > SSH/PPTP/IPSEC/OpenVPN all seem to be detected and throttled down to > 64kb/sec or less which is really disappointing, meanwhile I can pull files > via HTTP for a good 10Mb/sec. So eventually Im going to try to mix it in > with .net remoting so I can host SLiRP on Windows/IIS and have a Windows > machine on my LAN grab the IPIP tunnel from my cisco and send it off via > HTTP... That way the packet inspectors see proper HTTP traffic.. Then add > in some compression and encryption and I’ve made yet another VPN, although > one that’ll interface a router to SLiRP. > > > > But I’ve plugged it into SIMH, although they use a much more involved, and > newer one now, PCem, Previous, Basilisk II, and I got the ball rolling on > WinUAE. I may have left a few off, but yes, it’s an incredibly versatile > library. > > > > From: Nick Downing > Sent: Thursday, 9 February 2017 7:35 PM > To: Jason Stevens > Cc: TUHS main list; Greg 'groggy' Lehey > Subject: Re: [TUHS] Code bloat (was: How Unix brings people together, or > it'sa small...) > > > > Yes, NetBSD and 386BSD are interesting. They could well form a good > > basis for a minimal but fully functional OS for a modern platform. One > > reservation I have though, is as follows: When 386BSD and its > > derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still > > encumbered and thus they had to be based on 4.4BSD Lite (not even > > NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or > > even NET/2, even though it was theoretically possible, by examining > > what had to be taken out/added to produce 4.4BSD Lite. > > > > Given that Unix is now unencumbered I believe there is no point > > adopting 4.4, or even 4.3Reno, because the main thing done in those > > releases as far as I know, is to add partial POSIX compliance. But if > > you want POSIX compliance you will not achieve minimality. As an > > example consider the BSD sigvec() routine. POSIX calls this > > sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old > > integer mask becomes a sigset_t and so on... and in any reasonable > > POSIX compliant BSD the two calls are gonna have to coexist, etc. > > > > As to 32V, I appreciate your idea, as I was having some similar > > thoughts myself. However I personally wouldn't use 32V as a basis for > > any serious porting work, because I would assume V7 and 4.3 are much > > more stable and well tested, since they ran in a lot of installations > > over a long time. That's not to denigrate the huge achievement in > > porting V7 to the VAX and producing 32V, but it probably has some > > rough edges that were smoothed out over time to produce the 4BSDs. The > > situation is a bit different for kernel/toolchain/other userspace. > > > > As to the kernel I have been trying to make a detailed comparison > > between 32V and the BSDs, but have been a bit put off by the fact that > > all files moved around and may have been renamed, I will figure it all > > out eventually though. As to the toolchain I have compared it quite > > carefully with 4.3BSD, and I conclude you should use the later > > toolchain as there is no disadvantage and some advantages to doing so. > > As to the rest of the userspace, I BELIEVE that it's stock V7 with any > > 32-bit issues fixed, but I suspect somewhat hastily and superficially. > > > > Producing a 32V-like kernel from 4.3BSD sources would probably be > > quite difficult, it would be relatively easy to disable added system > > calls, but harder to disable things like setpgrp() or the associated > > support in the TTY drivers. More seriously the memory management would > > have to change, I am planning however to make virtual memory optional > > in the 4.3BSD kernel, by maybe putting the 32V code back in, protected > > by #ifndef VM or some such (somewhat like Steven Schultz has done in > > porting 4.3BSD to PDP-11 to produce 2.11BSD). > > > > On the other hand producing a 32V-like userland from the 4.3BSD > > sources would be pretty easy, I think just delete the sources for any > > executables that weren't distributed with 32V and possibly, if any of > > the tools seem particularly bloated, comment out any command line > > switches or features that weren't in 32V. Going to this level of > > effort would likely be pointless though. Another option would be > > taking V7 and re-porting it (except the toolchain) over to a 32-bit > > environment and kernel. I have developed over the past months, tools > > that make this relatively straightforward, and in the process would > > rediscover any 32-bit issues that were fixed in creating 32V. So I > > wouldn't use 32V. > > > > On a slightly different tack, I also have been for some time > > investigating the idea of an Apple II port of Unix, there are massive > > technical issues to be solved, but I think I got a bit closer the > > other night when I decided to collect all information and resources I > > could find about Mini-Unix and LSX (LSI Unix). Both are > > self-supporting V6-based environments, the compiler can only compile > > small programs but it is nonetheless possible for each Unix to > > recomple itself. LSX I believe could run from floppies (dunno about > > 140K floppies) in less than 64K. > > > > So, you know, true minimality is a relative term. We want something > > LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or > > 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to > > know more), something 4.3BSD-like for a VAX or 386... something a bit > > more fully featured for a modern 64-bit multi-gigabyte system... but > > just not as bloated as what we currently rely on. Hmm well it's hard. > > What I do know, is that I have a lot of old hardware with <16M RAM and > > Linux won't run on it anymore, and this annoys me very greatly. > > > > In talking about FreeBSD/Linux bloat I forgot to mention the packet > > filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience > > with this, since I regularly used to put 2 Ethernet cards in my home > > server and make it Internet facing through one of them and share the > > connection using NAT through the other card. But I've come to the > > conclusion this is stupid, and moreover, that putting a complete > > mini-language into the kernel just for this purpose is utterly stupid. > > Programming the thing from userspace is incredibly intricate, and all > > this complexity serves no purpose. > > > > I recently found out about SLIRP (userspace packet rewriting) and I > > think this would be a good way to implement NAT on servers or routers > > that actually need to do NAT -- just make a userspace process that > > runs something SLIRP-like and has a raw socket to the second Ethernet > > card, and Bob's your uncle. > > > > But this got me thinking along pretty productive lines in terms of the > > tiny Apple II port -- I have been wanting to put the 2.11BSD network > > stack into an Apple II for a long time, but I've now realized this is > > not necessary. A much better approach for those Mini-Unix or LSX or > > even V7 systems, would be to have a userspace library that does SLIP > > and contains its own TCP, UDP, IP drivers, resolver and so on. Then if > > you run a userspace program like say, ftp, which is linked to the > > userspace TCP library, it would basically just open /dev/ttyXX, bring > > up the SLIP link itself, do any necessary downloads etc, then close > > the TTY and stop responding to any IP stuff coming over the SLIP link > > whilst you quit to the prompt, until another program reopens it. > > > > cheers, Nick > > > > On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens > > wrote: > >> What about NetBSD 1.1 or even 386BSD? > >> > >> There never was a 4.2 or 4.3 for i386 was there? > >> > >> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 >> greatly > >> reducing its footprint. > >> > >> > >> > >> > >> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing > >> wrote: > >>> > >>> This is an issue that interests me quite a bit, since I was running > >>> FreeBSD in an effort to get around Linux bloat problems discussed. > >>> Well not that I really mind Linux as a user interface / runtime > >>> environment / main development machine, but I think it probably > >>> shouldn't be used as a "least common denominator" for development > >>> since you end up introducing unwanted dependencies on a whole lot of > >>> stuff. > >>> > >>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of > >>> interesting stuff with FreeBSD such as setting up diskless > >>> workstations in my home, etc. I spent a lot of time tinkering around > >>> in the kernel code. I was planning to do some serious development on > >>> 4.4BSDLite or FreeBSD to create an operating system more to my liking. > >>> So, I was looking carefully at differences since ancient *nixes. > >>> > >>> And, I can say that FreeBSD is pretty bloated. Umm well they've added > >>> SMP, at the time it was using the Giant Lock although that could be > >>> fixed by now. They've added VFS and NFS of course. They've added an > >>> entire subsystem for block devices IIRC that handles partitioning and > >>> possibly some other sophisticated stuff, which I believe is their own > >>> design. Umm the kqueues and I believe they have their own > >>> implementation of kernel threading or lightweight processes including > >>> some sort of idle daemon. The network stack is heavily upgraded, to > >>> the extent I looked into it, the added features are things you would > >>> want (syncookies = DOS protection, etc) but also could not possibly be > >>> called minimal, and would preclude running it on other than a > >>> multi-megabyte machine. They have multiple ABIs so the kernel can > >>> accept Linux or BSD syscalls or whatever else (I used it to run > >>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they > >>> have kernel modules ala Linux. Lots and lots and lots of stuff... and > >>> that's only considering the kernel. If you look in the ports > >>> collection you see they have incredible amounts of bloat there too... > >>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm > >>> denigrating these tools, since they do invaluable work and I use them > >>> every day, but the point is, you CANNOT call them minimal. > >>> > >>> The quest for a clean minimal system goes on ->. FreeBSD is not the > >>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. > >>> > >>> cheers, Nick > >>> > >>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey > >>> wrote: > >>>> > >>>> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: > >>>>> > >>>>> Looking back, the social dynamics of the Unix group helped a lot in > >>>>> keeping the bloat small. The rule was, whoever touches something > >>>>> last becomes its owner. Of course, we were all free to complain > >>>>> about things, and did, but the amalgamation of tinkerings that > >>>>> characterizes most of the Linux commands just didn't happen. > >>>> > >>>> > >>>> Out of interest: where do you (or others) consider that the current > >>>> BSD projects it in this comparison? > >>>> > >>>> 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 > >> > >> > >> -- > >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > From dugo at xs4all.nl Wed Feb 8 22:29:08 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Wed, 08 Feb 2017 13:29:08 +0100 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: <90190d89aaeefbf0b540a28436468835@xs4all.nl> On 2017-02-08 12:21, Nick Downing wrote: > Yes, NetBSD and 386BSD are interesting. They could well form a good > basis for a minimal but fully functional OS for a modern platform. One > reservation I have though, is as follows: When 386BSD and its > derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still > encumbered and thus they had to be based on 4.4BSD Lite (not even > NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or > even NET/2, even though it was theoretically possible, by examining > what had to be taken out/added to produce 4.4BSD Lite. The 386BSD porting started on 4.3BSD-Reno with patches being fed back to BSD. Stuff was being thrown out of BSD at the same time for the Net releases. Must have been difficult. First release was Net/2 + missing bits and pieces. ftp://ftp.funet.fi/pub/unix/4.3bsd/i386-jolitz/diffs/ Note that Jolitz was never sued for using Net/2 ;) NetBSD and FreeBSD started as 386bsd 0.1 + patchkits. To "unencumber" NetBSD the 0.8 release was scrubbed from the net and a pile of files in cvs were replaced with the text "revision x.y intentionally removed" and rewritten or taken from a cleaner BSD release. List of files at http://oldbsd.org/removed.txt FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction. I could be wrong, but it is far more likely they did it the same way as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook claims that is what they did for the 2.0 release. From downing.nick at gmail.com Wed Feb 8 22:57:13 2017 From: downing.nick at gmail.com (Nick Downing) Date: Wed, 8 Feb 2017 23:57:13 +1100 Subject: [TUHS] Code bloat In-Reply-To: <90190d89aaeefbf0b540a28436468835@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: Yes, thanks Jacob, I realized after posting that I had oversimplified things since definitely 386BSD was based on NET/2 as you say. Anyway, it's a very good thing that all is now unencumbered, I remember working on 2.11BSD 6~8yrs back and always having a strong concern in the back of my mind that it would be enormously complicated to sort out the licensing should I ever have an actual release. Warren, I hadn't realized that DoctorWkt = Dr Warren K. Toomey haha. Yes well actually I was aware of Xinu although I didn't realize there was an already-done Apple II port or that you had created it. I will certainly load it up. However the idea in my mind is to have the OS written in C, since I have some ideas for a simple but globally optimizing compiler which I hope makes 6502 a bit more C-friendly. I hadn't heard of xv6 but I will look into it. However, for me, compatibility is a huge concern, and there are so many little corner cases -- what happens if XXX signal arrives during YYY, does it ERESTART or EINTR... what happens if a directory is setgid and sticky and XXX operation is performed... I guess for V7 these kinds of questions are not too vexing, but when you get to BSD with process groups and job control and EUIDS and so on... it's just too hard to try to recreate it and have it still be compatible in all these tiny details. If I was happy with that, I would have persevered with UZI (Unix Z-80 Implementation), but I kept finding little bugs and/or differences. As to Contiki, yes it's quite an amazing piece of software, I picked it up when I first got into 2.11BSD (maybe 6~8 yrs ago) which is also when I started to realize UZI would be too much work to make acceptably Unix-like. I briefly got excited about Contiki. The reason I did not persevere with Contiki, was to do with its proto-threads concept. It's basically event-driven, a task proceeds through the system by receiving callbacks in which it does a bit of processing and then goes to sleep by registering for some other callback at a later time. But, there's a compatibility issue, since you have to rewrite all your software. Ordinary code like say, an ftp client with a main() function that calls socket() and read() and write(), doesn't work under this model, and can't be made to work without a complete rewrite. More seriously though, it's a pretty unfriendly way to write code, at least without significant compiler support. I know this because as a teenager I used to do work for local SysOps running TheMajorBBS, which was also stackless in order to serve hundreds of incoming modem connections on 286 or (later on) 386 hardware. Every MajorBBS app or menu was written like a state machine and it got really tedious after a while. Thinking about it, Ken Thompson and Dennis Ritchie could certainly have chosen this model for implementing the Unix syscalls, to save on the space required for the kernel stack, however they did not, and as a result the system is vastly simplified. However, given the TCP/IP stack is nearly always implemented as a state machine, the Contiki TCP/IP stack could be useful to my project. Thanks a lot for the alert. I am not even sure if it had TCP/IP at all when I last looked at it, although it definitely had windowing. cheers, Nick On Wed, Feb 8, 2017 at 11:29 PM, Jacob Goense wrote: > On 2017-02-08 12:21, Nick Downing wrote: >> >> Yes, NetBSD and 386BSD are interesting. They could well form a good >> basis for a minimal but fully functional OS for a modern platform. One >> reservation I have though, is as follows: When 386BSD and its >> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still >> encumbered and thus they had to be based on 4.4BSD Lite (not even >> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or >> even NET/2, even though it was theoretically possible, by examining >> what had to be taken out/added to produce 4.4BSD Lite. > > > The 386BSD porting started on 4.3BSD-Reno with patches being fed back > to BSD. Stuff was being thrown out of BSD at the same time for the Net > releases. Must have been difficult. First release was Net/2 + missing > bits and pieces. ftp://ftp.funet.fi/pub/unix/4.3bsd/i386-jolitz/diffs/ > Note that Jolitz was never sued for using Net/2 ;) > > NetBSD and FreeBSD started as 386bsd 0.1 + patchkits. To "unencumber" > NetBSD the 0.8 release was scrubbed from the net and a pile of files > in cvs were replaced with the text "revision x.y intentionally removed" > and rewritten or taken from a cleaner BSD release. > List of files at http://oldbsd.org/removed.txt > > FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction. > I could be wrong, but it is far more likely they did it the same way > as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they > restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook > claims that is what they did for the 2.0 release. From jsteve at superglobalmegacorp.com Wed Feb 8 23:10:52 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Wed, 8 Feb 2017 21:10:52 +0800 Subject: [TUHS] Code bloat In-Reply-To: <90190d89aaeefbf0b540a28436468835@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> After I had pasted a bunch of 386BSD pl0.24 + a CVS export of 0.8 I did get a booting system. Then I found an old ftp site that had 0.8 I made a mirror of it, then it disappeared. So I mirrored it here: http://vpsland.superglobalmegacorp.com/ install/NetBSD/NetBSD-0.8/Original/NetBSD-0.8/ Although I had some idiot saying that hosting nethack was a virus had I was then blacklisted for a while so if you try to browse or download you’ll have to input a username password.. It’s on the 404 page. I did some minor work on installing it on Bochs years ago, and VMware, from what I recall, NetBSD 1.0/1.1 can boot 386BSD’s kernel, while the 386BSD boot diskette didn’t work under emulation, NetBSD’s does, and I used that to kickstart an installation. Same with the boot blocks on the harddisk image. From: Jacob Goense Sent: Thursday, 9 February 2017 8:43 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Code bloat On 2017-02-08 12:21, Nick Downing wrote: > Yes, NetBSD and 386BSD are interesting. They could well form a good > basis for a minimal but fully functional OS for a modern platform. One > reservation I have though, is as follows: When 386BSD and its > derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still > encumbered and thus they had to be based on 4.4BSD Lite (not even > NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or > even NET/2, even though it was theoretically possible, by examining > what had to be taken out/added to produce 4.4BSD Lite. The 386BSD porting started on 4.3BSD-Reno with patches being fed back to BSD. Stuff was being thrown out of BSD at the same time for the Net releases. Must have been difficult. First release was Net/2 + missing bits and pieces. ftp://ftp.funet.fi/pub/unix/4.3bsd/i386-jolitz/diffs/ Note that Jolitz was never sued for using Net/2 ;) NetBSD and FreeBSD started as 386bsd 0.1 + patchkits. To "unencumber" NetBSD the 0.8 release was scrubbed from the net and a pile of files in cvs were replaced with the text "revision x.y intentionally removed" and rewritten or taken from a cleaner BSD release. List of files at http://oldbsd.org/removed.txt FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction. I could be wrong, but it is far more likely they did it the same way as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook claims that is what they did for the 2.0 release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Wed Feb 8 23:56:21 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 8 Feb 2017 14:56:21 +0100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: Nick, If you want to work with LSX, you might have a look at the LSX port I did for the TI990 mini computer: http://1587660.websites.xs4all.nl/cgi-bin/9995/dir?ci=1c38b1fc8792c80b&name=lsx It is a further development from the work that was done for BKUNIX by Leonid Broukhis (https://sourceforge.net/p/bkunix/code/HEAD/tree/). You get stuff converted to a dialect of C acceptable by modern compilers, and some kludges like using 'char*' for 'unsigned' and 'int a[2]' for 'long a' are cleaned up. The repository also has a V6 kernel with similar clean up and some V7 compatibility ('lseek' instead of 'seek', etc.). My next step would be to move to a V7 kernel and add TCP/IP capability. This is how I got interested in the history of sockets and TCP/IP. I have found that the BSD stack (as found in e.g. ULTRIX-11) will not fit in 64KB (note: just the network stack). The BBN stack appears to fit in 56KB, with 15KB of buffers available; I think it could be integrated with a V7 kernel as a second kernel process. Paul On 8 Feb 2017, at 12:21 , Nick Downing wrote: > Yes, NetBSD and 386BSD are interesting. They could well form a good > basis for a minimal but fully functional OS for a modern platform. One > reservation I have though, is as follows: When 386BSD and its > derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still > encumbered and thus they had to be based on 4.4BSD Lite (not even > NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or > even NET/2, even though it was theoretically possible, by examining > what had to be taken out/added to produce 4.4BSD Lite. > > Given that Unix is now unencumbered I believe there is no point > adopting 4.4, or even 4.3Reno, because the main thing done in those > releases as far as I know, is to add partial POSIX compliance. But if > you want POSIX compliance you will not achieve minimality. As an > example consider the BSD sigvec() routine. POSIX calls this > sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old > integer mask becomes a sigset_t and so on... and in any reasonable > POSIX compliant BSD the two calls are gonna have to coexist, etc. > > As to 32V, I appreciate your idea, as I was having some similar > thoughts myself. However I personally wouldn't use 32V as a basis for > any serious porting work, because I would assume V7 and 4.3 are much > more stable and well tested, since they ran in a lot of installations > over a long time. That's not to denigrate the huge achievement in > porting V7 to the VAX and producing 32V, but it probably has some > rough edges that were smoothed out over time to produce the 4BSDs. The > situation is a bit different for kernel/toolchain/other userspace. > > As to the kernel I have been trying to make a detailed comparison > between 32V and the BSDs, but have been a bit put off by the fact that > all files moved around and may have been renamed, I will figure it all > out eventually though. As to the toolchain I have compared it quite > carefully with 4.3BSD, and I conclude you should use the later > toolchain as there is no disadvantage and some advantages to doing so. > As to the rest of the userspace, I BELIEVE that it's stock V7 with any > 32-bit issues fixed, but I suspect somewhat hastily and superficially. > > Producing a 32V-like kernel from 4.3BSD sources would probably be > quite difficult, it would be relatively easy to disable added system > calls, but harder to disable things like setpgrp() or the associated > support in the TTY drivers. More seriously the memory management would > have to change, I am planning however to make virtual memory optional > in the 4.3BSD kernel, by maybe putting the 32V code back in, protected > by #ifndef VM or some such (somewhat like Steven Schultz has done in > porting 4.3BSD to PDP-11 to produce 2.11BSD). > > On the other hand producing a 32V-like userland from the 4.3BSD > sources would be pretty easy, I think just delete the sources for any > executables that weren't distributed with 32V and possibly, if any of > the tools seem particularly bloated, comment out any command line > switches or features that weren't in 32V. Going to this level of > effort would likely be pointless though. Another option would be > taking V7 and re-porting it (except the toolchain) over to a 32-bit > environment and kernel. I have developed over the past months, tools > that make this relatively straightforward, and in the process would > rediscover any 32-bit issues that were fixed in creating 32V. So I > wouldn't use 32V. > > On a slightly different tack, I also have been for some time > investigating the idea of an Apple II port of Unix, there are massive > technical issues to be solved, but I think I got a bit closer the > other night when I decided to collect all information and resources I > could find about Mini-Unix and LSX (LSI Unix). Both are > self-supporting V6-based environments, the compiler can only compile > small programs but it is nonetheless possible for each Unix to > recomple itself. LSX I believe could run from floppies (dunno about > 140K floppies) in less than 64K. > > So, you know, true minimality is a relative term. We want something > LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or > 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to > know more), something 4.3BSD-like for a VAX or 386... something a bit > more fully featured for a modern 64-bit multi-gigabyte system... but > just not as bloated as what we currently rely on. Hmm well it's hard. > What I do know, is that I have a lot of old hardware with <16M RAM and > Linux won't run on it anymore, and this annoys me very greatly. > > In talking about FreeBSD/Linux bloat I forgot to mention the packet > filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience > with this, since I regularly used to put 2 Ethernet cards in my home > server and make it Internet facing through one of them and share the > connection using NAT through the other card. But I've come to the > conclusion this is stupid, and moreover, that putting a complete > mini-language into the kernel just for this purpose is utterly stupid. > Programming the thing from userspace is incredibly intricate, and all > this complexity serves no purpose. > > I recently found out about SLIRP (userspace packet rewriting) and I > think this would be a good way to implement NAT on servers or routers > that actually need to do NAT -- just make a userspace process that > runs something SLIRP-like and has a raw socket to the second Ethernet > card, and Bob's your uncle. > > But this got me thinking along pretty productive lines in terms of the > tiny Apple II port -- I have been wanting to put the 2.11BSD network > stack into an Apple II for a long time, but I've now realized this is > not necessary. A much better approach for those Mini-Unix or LSX or > even V7 systems, would be to have a userspace library that does SLIP > and contains its own TCP, UDP, IP drivers, resolver and so on. Then if > you run a userspace program like say, ftp, which is linked to the > userspace TCP library, it would basically just open /dev/ttyXX, bring > up the SLIP link itself, do any necessary downloads etc, then close > the TTY and stop responding to any IP stuff coming over the SLIP link > whilst you quit to the prompt, until another program reopens it. > > cheers, Nick > > On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens > wrote: >> What about NetBSD 1.1 or even 386BSD? >> >> There never was a 4.2 or 4.3 for i386 was there? >> >> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly >> reducing its footprint. >> >> >> >> >> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing >> wrote: >>> >>> This is an issue that interests me quite a bit, since I was running >>> FreeBSD in an effort to get around Linux bloat problems discussed. >>> Well not that I really mind Linux as a user interface / runtime >>> environment / main development machine, but I think it probably >>> shouldn't be used as a "least common denominator" for development >>> since you end up introducing unwanted dependencies on a whole lot of >>> stuff. >>> >>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of >>> interesting stuff with FreeBSD such as setting up diskless >>> workstations in my home, etc. I spent a lot of time tinkering around >>> in the kernel code. I was planning to do some serious development on >>> 4.4BSDLite or FreeBSD to create an operating system more to my liking. >>> So, I was looking carefully at differences since ancient *nixes. >>> >>> And, I can say that FreeBSD is pretty bloated. Umm well they've added >>> SMP, at the time it was using the Giant Lock although that could be >>> fixed by now. They've added VFS and NFS of course. They've added an >>> entire subsystem for block devices IIRC that handles partitioning and >>> possibly some other sophisticated stuff, which I believe is their own >>> design. Umm the kqueues and I believe they have their own >>> implementation of kernel threading or lightweight processes including >>> some sort of idle daemon. The network stack is heavily upgraded, to >>> the extent I looked into it, the added features are things you would >>> want (syncookies = DOS protection, etc) but also could not possibly be >>> called minimal, and would preclude running it on other than a >>> multi-megabyte machine. They have multiple ABIs so the kernel can >>> accept Linux or BSD syscalls or whatever else (I used it to run >>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they >>> have kernel modules ala Linux. Lots and lots and lots of stuff... and >>> that's only considering the kernel. If you look in the ports >>> collection you see they have incredible amounts of bloat there too... >>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm >>> denigrating these tools, since they do invaluable work and I use them >>> every day, but the point is, you CANNOT call them minimal. >>> >>> The quest for a clean minimal system goes on ->. FreeBSD is not the >>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. >>> >>> cheers, Nick >>> >>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey >>> wrote: >>>> >>>> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: >>>>> >>>>> Looking back, the social dynamics of the Unix group helped a lot in >>>>> keeping the bloat small. The rule was, whoever touches something >>>>> last becomes its owner. Of course, we were all free to complain >>>>> about things, and did, but the amalgamation of tinkerings that >>>>> characterizes most of the Linux commands just didn't happen. >>>> >>>> >>>> Out of interest: where do you (or others) consider that the current >>>> BSD projects it in this comparison? >>>> >>>> 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 >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. From dugo at xs4all.nl Thu Feb 9 00:10:24 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Wed, 08 Feb 2017 15:10:24 +0100 Subject: [TUHS] Code bloat In-Reply-To: <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> Message-ID: <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> On 2017-02-08 14:10, jsteve at superglobalmegacorp.com wrote: > After I had pasted a bunch of 386BSD pl0.24 + a CVS export of 0.8 I > did get a booting system. I remember that Victor Frankenstein ;) Proved how close these 2 were. > Then I found an old ftp site that had 0.8 > I made a mirror of it, then it disappeared. Very glad that piece of history got unearthed. > I did some minor work on installing it on Bochs years ago, and VMware, > from what I recall, NetBSD 1.0/1.1 can boot 386BSD’s kernel, while > the 386BSD boot diskette didn’t work under emulation, NetBSD’s > does, and I used that to kickstart an installation. Same with the > boot blocks on the harddisk image. 386BSD is now bootable in Bochs, with very, very specific settings. One that works at: https://raw.githubusercontent.com/dugoh/tobochs/master/bochsrc Back then it required a patch against bochs too as the boot blocks do some truly weird stuff with the PIC (polling OCW3?), something most emulators don't implement or even barf on. These 2 little marvels didn't have much bloat, but the Bostification had already set in. My idea of a true diet x86 UNIX system would be a report of Tahoe without resorting to gcc/gas or anything else that smells like RMS. From ron at ronnatalie.com Thu Feb 9 00:34:34 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 8 Feb 2017 09:34:34 -0500 Subject: [TUHS] Code bloat In-Reply-To: <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> Message-ID: <03f901d28218$78ad6060$6a082120$@ronnatalie.com> Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper? From crossd at gmail.com Thu Feb 9 01:09:19 2017 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Feb 2017 10:09:19 -0500 Subject: [TUHS] Code bloat In-Reply-To: <03f901d28218$78ad6060$6a082120$@ronnatalie.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> <03f901d28218$78ad6060$6a082120$@ronnatalie.com> Message-ID: Here you are: http://harmful.cat-v.org/cat-v/unix_prog_design.pdf On Wed, Feb 8, 2017 at 9:34 AM, Ron Natalie wrote: > Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Thu Feb 9 01:18:21 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Wed, 8 Feb 2017 23:18:21 +0800 Subject: [TUHS] Code bloat In-Reply-To: <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> Message-ID: I had a bizarre side project to re-host old GCC 1.x on Windows so I could cross compile early Linux kernels (it actually works too!) I was going down the path of cross compiling 386BSD when I ran into the boot block hell of it being really inconvenient to stage any kernel in a way to boot test. Anyway PCC is more or less alive these days, and supports both i386 and AMDx64. I'd suppose cross compiling from that may be doable. I'd shoved Tahoe through GCC 1.42 for the i386, and most of the C actually built. Of course no assembly, no boot/stand and I gave up just as quickly as the low stuff is well over my head. But my point being that it ought to be something that could be done, there was even that Quasijarous VAX which was Tahoe with POSIX removed..... On February 8, 2017 10:10:24 PM GMT+08:00, Jacob Goense wrote: >On 2017-02-08 14:10, jsteve at superglobalmegacorp.com wrote: >> After I had pasted a bunch of 386BSD pl0.24 + a CVS export of 0.8 I >> did get a booting system. > >I remember that Victor Frankenstein ;) Proved how close these 2 were. > >> Then I found an old ftp site that had 0.8 >> I made a mirror of it, then it disappeared. > >Very glad that piece of history got unearthed. > >> I did some minor work on installing it on Bochs years ago, and >VMware, >> from what I recall, NetBSD 1.0/1.1 can boot 386BSD’s kernel, while >> the 386BSD boot diskette didn’t work under emulation, NetBSD’s >> does, and I used that to kickstart an installation. Same with the >> boot blocks on the harddisk image. > >386BSD is now bootable in Bochs, with very, very specific settings. >One that works at: >https://raw.githubusercontent.com/dugoh/tobochs/master/bochsrc > >Back then it required a patch against bochs too as the boot blocks >do some truly weird stuff with the PIC (polling OCW3?), something >most emulators don't implement or even barf on. > >These 2 little marvels didn't have much bloat, but the Bostification >had already set in. My idea of a true diet x86 UNIX system would be >a report of Tahoe without resorting to gcc/gas or anything else that >smells like RMS. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From downing.nick at gmail.com Thu Feb 9 01:26:57 2017 From: downing.nick at gmail.com (Nick Downing) Date: Thu, 9 Feb 2017 02:26:57 +1100 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> <03f901d28218$78ad6060$6a082120$@ronnatalie.com> Message-ID: Interesting, in my 4.3BSD experiments recently I have missed readline.so a lot, but in my implementation I was thinking of building it into the kernel or the TTY driver (well actually I was thinking of making it a filter driver, but that's another story). I thought I was possibly being a bit of a crank (deliberately swimming against the current to "prove" the current way of doing things is wrong) but this paper basically suggests the same thing. That's really encouraging. And, I often find it really annoying that programs like gdb don't have readline ability. cheers, Nick On Thu, Feb 9, 2017 at 2:09 AM, Dan Cross wrote: > Here you are: http://harmful.cat-v.org/cat-v/unix_prog_design.pdf > > On Wed, Feb 8, 2017 at 9:34 AM, Ron Natalie wrote: >> >> Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper? >> >> > From brantleycoile at me.com Thu Feb 9 00:43:39 2017 From: brantleycoile at me.com (Brantley Coile) Date: Wed, 08 Feb 2017 09:43:39 -0500 Subject: [TUHS] Code bloat In-Reply-To: <03f901d28218$78ad6060$6a082120$@ronnatalie.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com> <72f15b962c85b6e584ef1f15965af55b@xs4all.nl> <03f901d28218$78ad6060$6a082120$@ronnatalie.com> Message-ID: <2F0E28D1-8196-4AF1-A6BD-EB7F204EFD46@me.com> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0ahUKEwivluKK3oDSAhVKgiYKHeDFD3kQFgghMAI&url=http%3A%2F%2Fharmful.cat-v.org%2Fcat-v%2Funix_prog_design.pdf&usg=AFQjCNGKqCcaE00loEzM9pR_IafihhfqbQ&bvm=bv.146496531,d.eWE > On Feb 8, 2017, at 9:34 AM, Ron Natalie wrote: > > Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper? > > From dot at dotat.at Thu Feb 9 02:25:30 2017 From: dot at dotat.at (Tony Finch) Date: Wed, 8 Feb 2017 16:25:30 +0000 Subject: [TUHS] Code bloat In-Reply-To: <90190d89aaeefbf0b540a28436468835@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: Jacob Goense wrote: > > FreeBSD claiming to be 4.4BSD-Lite based is, I think, a legal fiction. > I could be wrong, but it is far more likely they did it the same way > as NetBSD after the FreeBSD 1.1.5.1 release. I don't believe they > restarted with a clean 4.4BSD-Lite tape, but the FreeBSD handbook > claims that is what they did for the 2.0 release. The history is slightly harder to see now than it used to be. When FreeBSD was developed in CVS, the repository only went back to the 4.4BSD import, basically around what is now https://github.com/freebsd/freebsd/commit/8b2b31265d61a703f6043fef964fcf90bec23fcd The FreeBSD 1.x changes were re-imported on top of 4.4BSD, instead of 4.4BSD being incorporated into the previous repo (which is what NetBSD did). The previous CVS repo from the 386BSD+patchkit days was hidden away because of old copyright worries, though some time after 2000 it became available to most committers. (I have a copy in my home directory on freefall.freebsd.org which I stashed away in 2007 because at that time I think there still wasn't a conveniently accessible copy.) It looks like after the uplift to SVN the two repositories were combined, so you can now see the 386BSD import at https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67 Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet, Irish Sea: Variable 3 or 4 at first in Lundy and Irish Sea, otherwise south or southeast 5 or 6, occasionally 7 later. Moderate or rough, occasionally very rough. Mainly fair. Good. From jnc at mercury.lcs.mit.edu Thu Feb 9 04:00:43 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Feb 2017 13:00:43 -0500 (EST) Subject: [TUHS] Early Internet work Message-ID: <20170208180043.C278518C11A@mercury.lcs.mit.edu> > From: Nick Downing > is it possible for you to read the other tapes also? Hi, we just read the second tape, which read without error. It appears to be mostly the same stuff as the first, except that for some not-now-understood reason, a lot of the sub-directories in /src/src (the directory that held most of the sources) weren't there on the _first_ tape, but _are_ there on the _second_. So at this point we have access to everything that was on that machine. It's too long a list to go through, but here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/csr2_edfiles.txt is an edited list of the files on the machine. Most of /usr/ has been deleted, since it contains a lot of personal files, the names of which I don't wish to make public. Alas, some of the code (e.g. the much of the MIT TCP/IP) was in some personal directories; it will take me a while to curate all that. Also, this machine did not contain everything that was done at MIT: one particularly saddening lacuna is that the Algol-60 (written for the 'Intro to programming for CS majors' course, 6.031 to those for whom that means anything) isn't there, along with its documentation. With that being _such_ an incredibly influential language, I'd really wanted to see a PDP-11 version made available. There's also an APL, and some missing subdirectories in the BCPL source directory ('henke', 'richards' and 'tenex'). Etc, etc. I have reached out to people at MIT, to see if a tape backup from the machine where all that was can be found; I will keep you all posted if anything shows up. > I would be particularly interested in the early 8080 compiler Yes, that's there ('c8080'), but object-only - it may have been something that was purchased from an outside vendor. There does seem like there might be an 8080-back end for the BCPL compiler. Noel From rminnich at gmail.com Thu Feb 9 04:06:53 2017 From: rminnich at gmail.com (ron minnich) Date: Wed, 08 Feb 2017 18:06:53 +0000 Subject: [TUHS] // comment in C++ Message-ID: I've always wondered if this was done in honor of JCL, as sort of a riff on the dd command. Anyone know? ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.phillip.garcia at gmail.com Thu Feb 9 04:08:52 2017 From: a.phillip.garcia at gmail.com (A. P. Garcia) Date: Wed, 8 Feb 2017 12:08:52 -0600 Subject: [TUHS] // comment in C++ In-Reply-To: References: Message-ID: On 2/8/17, ron minnich wrote: > I've always wondered if this was done in honor of JCL, as sort of a riff on > the dd command. Anyone know? > > ron it's from bcpl... From arnold at skeeve.com Thu Feb 9 04:17:28 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 08 Feb 2017 11:17:28 -0700 Subject: [TUHS] // comment in C++ In-Reply-To: References: Message-ID: <201702081817.v18IHShk031735@freefriends.org> ron minnich wrote: > I've always wondered if this was done in honor of JCL, as sort of a riff on > the dd command. Anyone know? > > ron I'm fairly certain it was originally in BCPL. You could just drop a note to Bjarne Stroustrup and ask. :-) Arnold From grog at lemis.com Thu Feb 9 08:45:56 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 9 Feb 2017 09:45:56 +1100 Subject: [TUHS] // comment in C++ In-Reply-To: References: Message-ID: <20170208224556.GG65698@eureka.lemis.com> On Wednesday, 8 February 2017 at 18:06:53 +0000, ron minnich wrote: > I've always wondered if this was done in honor of JCL, as sort of a riff on > the dd command. Anyone know? // had a very different meaning in IBM JCL. It's a sequence indicating that a command follows, and I have a suspicion that it's related to a prompt. In JCL (on punched cards) you had to punch it with the rest, but interactive programs printed it for you, usually a single character. UNIVAC OS/1100 used @, and OMEGA used #, for example. Does anybody else have input? 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 ron at ronnatalie.com Thu Feb 9 08:50:57 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Wed, 8 Feb 2017 17:50:57 -0500 Subject: [TUHS] // comment in C++ In-Reply-To: <20170208224556.GG65698@eureka.lemis.com> References: <20170208224556.GG65698@eureka.lemis.com> Message-ID: <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> Amusingly in the UNIVAC FIELDDATA character set. The @ had the value zero (and was called the master space). It's sort of like making NUL the command character :) Amusingly UNIVAC had their own punched card format (same size card, which was by the way, the size of a dollar bill in Hollerith's day) but used two banks of 45 round holes for 90 columns. -Ron "I had a cat named @FURPUR" Natalie From rminnich at gmail.com Thu Feb 9 08:51:12 2017 From: rminnich at gmail.com (ron minnich) Date: Wed, 08 Feb 2017 22:51:12 +0000 Subject: [TUHS] // comment in C++ In-Reply-To: <20170208224556.GG65698@eureka.lemis.com> References: <20170208224556.GG65698@eureka.lemis.com> Message-ID: On Wed, Feb 8, 2017 at 2:45 PM Greg 'groggy' Lehey wrote: > > // had a very different meaning in IBM JCL. It's a sequence > indicating that a command follows, and I have a suspicion that it's > related to a prompt. > oh, believe me, I typed enough JCL to know. I was always just so amused by the dd command that when I first saw // in C++, I had to wonder. It's a question that's been banging around in my head for several decades ... thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Thu Feb 9 09:16:33 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Feb 2017 18:16:33 -0500 (EST) Subject: [TUHS] Early Internet work Message-ID: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu> > Hi, we just read the second tape, which read without error. > ... > So at this point we have access to everything that was on that machine. So, in the process of transferring this all to a TAR file, we found a bug in BSD 4.1b. (The length of some directories whose last sector held only one entry was being incorrectly set to the actual length of the directory, not a multiple of the sector size.) Anyone know where I can report a BSD 4.1b bug? :-) Noel PS: Although the Algol-60 isn't there, there is a nice LISP (good enough to run The Doctor ... :-) From grog at lemis.com Thu Feb 9 09:22:13 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 9 Feb 2017 10:22:13 +1100 Subject: [TUHS] // comment in C++ In-Reply-To: <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> Message-ID: <20170208232213.GH65698@eureka.lemis.com> On Wednesday, 8 February 2017 at 17:50:57 -0500, Ron Natalie wrote: > Amusingly in the UNIVAC FIELDDATA character set. The @ had the value zero > (and was called the master space). > It's sort of like making NUL the command character :) Well, except that there were no non-printing characters in Fieldata. > Amusingly UNIVAC had their own punched card format (same size card, > which was by the way, the size of a dollar bill in Hollerith's day) > but used two banks of 45 round holes for 90 columns. Yes, I heard of them, but they didn't seem to be a commercial success. I worked with UNIVAC kit from 1973 to 1977, on the 1108/1106 and the 494, but I never saw any card like that. They also had a very nice card punch, the VIP, that buffered a card content and only punched when you released the card, thus enabling erasures. But it used standard IBM format cards. > -Ron "I had a cat named @FURPUR" Natalie :-) 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 Feb 9 09:22:59 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Thu, 9 Feb 2017 10:22:59 +1100 Subject: [TUHS] // comment in C++ In-Reply-To: References: <20170208224556.GG65698@eureka.lemis.com> Message-ID: <20170208232259.GI65698@eureka.lemis.com> On Wednesday, 8 February 2017 at 22:51:12 +0000, ron minnich wrote: > On Wed, Feb 8, 2017 at 2:45 PM Greg 'groggy' Lehey wrote: > >> // had a very different meaning in IBM JCL. It's a sequence >> indicating that a command follows, and I have a suspicion that it's >> related to a prompt. >> > > oh, believe me, I typed enough JCL to know. I was always just so amused by > the dd command that when I first saw // in C++, I had to wonder. It's a > question that's been banging around in my head for several decades ... I suppose one argument might be that JCL also had a /* 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 scj at yaccman.com Thu Feb 9 09:39:13 2017 From: scj at yaccman.com (Steve Johnson) Date: Wed, 08 Feb 2017 15:39:13 -0800 Subject: [TUHS] // comment in C++ In-Reply-To: <201702081817.v18IHShk031735@freefriends.org> Message-ID: <10bc76e824e441f031dc541ab4d50a51bfb89638@webmail.yaccman.com> I remember some discussion about this.  In reality, a C comment really requires you to type 8 characters, because putting anything adjacent to the /* or */ looks terrible.  Many languages used single characters (e.g., # for make).  The argument was "if you make comments easier to type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm guessing Bjarne was aware of these discussions, although I don't remember specifically that he was... Steve ----- Original Message ----- From: arnold at skeeve.com To:, Cc: Sent:Wed, 08 Feb 2017 11:17:28 -0700 Subject:Re: [TUHS] // comment in C++ ron minnich wrote: > I've always wondered if this was done in honor of JCL, as sort of a riff on > the dd command. Anyone know? > > ron I'm fairly certain it was originally in BCPL. You could just drop a note to Bjarne Stroustrup and ask. :-) Arnold -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Thu Feb 9 09:47:28 2017 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Wed, 8 Feb 2017 15:47:28 -0800 Subject: [TUHS] Early Internet work In-Reply-To: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu> References: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 8, 2017 at 3:16 PM, Noel Chiappa wrote: > > Hi, we just read the second tape, which read without error. > > ... > > So at this point we have access to everything that was on that > machine. > > So, in the process of transferring this all to a TAR file, we found a bug > in > BSD 4.1b. (The length of some directories whose last sector held only one > entry was being incorrectly set to the actual length of the directory, not > a > multiple of the sector size.) > > Anyone know where I can report a BSD 4.1b bug? :-) > > Sigh. That tops my Multics bug report. -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at mcjones.org Thu Feb 9 10:03:19 2017 From: paul at mcjones.org (Paul McJones) Date: Wed, 8 Feb 2017 16:03:19 -0800 Subject: [TUHS] // comment in C++ In-Reply-To: References: Message-ID: > I'm fairly certain it was originally in BCPL. > > You could just drop a note to Bjarne Stroustrup and ask. :-) On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994), Stroustrup says: “However, only C, Simula, Algol68, an in one case BCPL left noticeable traces in C++ as released in 1985. Simula gave classes, Algol68 operating overloading, references, and the ability to declare variables anywhere in a block, and BCPL gave // comments.” He says a bit more about // comments on page 93, including an example of how they introduced an incompatibility with C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Thu Feb 9 10:37:40 2017 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Wed, 8 Feb 2017 16:37:40 -0800 Subject: [TUHS] Early Internet work In-Reply-To: References: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu> Message-ID: On Wed, Feb 8, 2017 at 3:47 PM, Charles Anthony wrote: > > > On Wed, Feb 8, 2017 at 3:16 PM, Noel Chiappa > wrote: > >> > Hi, we just read the second tape, which read without error. >> > ... >> > So at this point we have access to everything that was on that >> machine. >> >> So, in the process of transferring this all to a TAR file, we found a bug >> in >> BSD 4.1b. (The length of some directories whose last sector held only one >> entry was being incorrectly set to the actual length of the directory, >> not a >> multiple of the sector size.) >> >> Anyone know where I can report a BSD 4.1b bug? :-) >> >> Sigh. That tops my Multics bug report. > > Maybe not. The Multics segment containing the error is marked "WRITTEN 03/26/76". BSD4.1 is circa 1890? (Sorry for drifting off-topic) -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Feb 9 11:31:18 2017 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 8 Feb 2017 20:31:18 -0500 Subject: [TUHS] Early Internet work In-Reply-To: References: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu> Message-ID: On 2/8/17 7:37 PM, Charles Anthony wrote: > BSD4.1 is circa 1890? I'm guessing 20th century at least. -- ``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://cnswww.cns.cwru.edu/~chet/ From jnc at mercury.lcs.mit.edu Thu Feb 9 11:32:04 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Feb 2017 20:32:04 -0500 (EST) Subject: [TUHS] Early Internet work Message-ID: <20170209013204.E2FB918C11A@mercury.lcs.mit.edu> > From: Charles Anthony > Sigh. That tops my Multics bug report. No way! You actually got the fix approved by an MCB! Much cooler! :-) > BSD4.1 is circa 1890? Well, it's old, but not _that_ old!! :-) Noel From dave at horsfall.org Thu Feb 9 09:52:30 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Feb 2017 10:52:30 +1100 (EST) Subject: [TUHS] // comment in C++ In-Reply-To: <10bc76e824e441f031dc541ab4d50a51bfb89638@webmail.yaccman.com> References: <10bc76e824e441f031dc541ab4d50a51bfb89638@webmail.yaccman.com> Message-ID: On Wed, 8 Feb 2017, Steve Johnson wrote: > I remember some discussion about this.  In reality, a C comment really > requires you to type 8 characters, because putting anything adjacent to > the /* or */ looks terrible.  Many languages used single characters > (e.g., # for make).  The argument was "if you make comments easier to > type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm > guessing Bjarne was aware of these discussions, although I don't > remember specifically that he was... My favourite C /* */ style is this: /* * foo * bar */ Is that what you meant? And recent C also accepts // as a comment, which I use like this: /* * This is where we do some neat stuff. */ foo(); weird_function(); // Yes, we need to call this here... bar(); I'm quite taken by BIND, though, which accepts /* this */ // this # and this. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From crossd at gmail.com Thu Feb 9 11:46:35 2017 From: crossd at gmail.com (Dan Cross) Date: Wed, 8 Feb 2017 20:46:35 -0500 Subject: [TUHS] Early Internet work In-Reply-To: <20170209013204.E2FB918C11A@mercury.lcs.mit.edu> References: <20170209013204.E2FB918C11A@mercury.lcs.mit.edu> Message-ID: Sorry, I can't resist: https://youtu.be/0_HGqPGp9iY On Feb 8, 2017 8:32 PM, "Noel Chiappa" wrote: > > From: Charles Anthony > > > Sigh. That tops my Multics bug report. > > No way! You actually got the fix approved by an MCB! Much cooler! :-) > > > BSD4.1 is circa 1890? > > Well, it's old, but not _that_ old!! :-) > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rochkind at basepath.com Thu Feb 9 12:28:16 2017 From: rochkind at basepath.com (Marc Rochkind) Date: Wed, 8 Feb 2017 19:28:16 -0700 Subject: [TUHS] // comment in C++ In-Reply-To: References: Message-ID: Those were JCL COMMANDS??? Damn! I thought they were comments. No wonder nothing ever worked. --Marc On Wed, Feb 8, 2017 at 5:03 PM, Paul McJones wrote: > I'm fairly certain it was originally in BCPL. > > You could just drop a note to Bjarne Stroustrup and ask. :-) > > > On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994), > Stroustrup says: > > “However, only C, Simula, Algol68, an in one case BCPL left noticeable > traces in C++ as released in 1985. Simula gave classes, Algol68 operating > overloading, references, and the ability to declare variables anywhere in a > block, and BCPL gave // comments.” > > He says a bit more about // comments on page 93, including an example of > how they introduced an incompatibility with C. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at lod.com Thu Feb 9 12:11:36 2017 From: corey at lod.com (Corey Lindsly) Date: Wed, 8 Feb 2017 18:11:36 -0800 (PST) Subject: [TUHS] // comment in C++ In-Reply-To: Message-ID: <20170209021136.9BDEA40B9@lod.com> > > I'm quite taken by BIND, though, which accepts > > /* this */ > // this > # and this. Not that. ; But this. Cheers, --corey From dave at horsfall.org Thu Feb 9 12:46:10 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 9 Feb 2017 13:46:10 +1100 (EST) Subject: [TUHS] // comment in C++ In-Reply-To: <20170209021136.9BDEA40B9@lod.com> References: <20170209021136.9BDEA40B9@lod.com> Message-ID: On Wed, 8 Feb 2017, Corey Lindsly wrote: > > I'm quite taken by BIND, though, which accepts > > > > /* this */ > > // this > > # and this. > > Not that. > > ; But this. Perhaps I meant named.conf (part of BIND): named.conf is the configuration file for named. Statements are enclosed in braces and terminated with a semi-colon. Clauses in the statements are also semi-colon terminated. The usual comment styles are supported: C style: /* */ C++ style: // to end of line Unix style: # to end of line Where did you get ; But this? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From usotsuki at buric.co Thu Feb 9 12:47:49 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 8 Feb 2017 21:47:49 -0500 (EST) Subject: [TUHS] // comment in C++ In-Reply-To: References: <10bc76e824e441f031dc541ab4d50a51bfb89638@webmail.yaccman.com> Message-ID: On Thu, 9 Feb 2017, Dave Horsfall wrote: > On Wed, 8 Feb 2017, Steve Johnson wrote: > >> I remember some discussion about this.  In reality, a C comment really >> requires you to type 8 characters, because putting anything adjacent to >> the /* or */ looks terrible.  Many languages used single characters >> (e.g., # for make).  The argument was "if you make comments easier to >> type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm >> guessing Bjarne was aware of these discussions, although I don't >> remember specifically that he was... > > My favourite C /* */ style is this: > > /* > * foo > * bar > */ This is the way I usually write my comments, too. > Is that what you meant? And recent C also accepts // as a comment, which > I use like this: > > /* > * This is where we do some neat stuff. > */ > foo(); > weird_function(); // Yes, we need to call this here... > bar(); > > I'm quite taken by BIND, though, which accepts > > /* this */ > // this > # and this. Unrealircd likewise accepts those 3 different types of comments. -uso. From corey at lod.com Thu Feb 9 12:53:37 2017 From: corey at lod.com (Corey Lindsly) Date: Wed, 8 Feb 2017 18:53:37 -0800 (PST) Subject: [TUHS] // comment in C++ In-Reply-To: Message-ID: <20170209025337.C8A9240F7@lod.com> > Perhaps I meant named.conf (part of BIND): > > named.conf is the configuration file for named. Statements are enclosed > in braces and terminated with a semi-colon. Clauses in the statements > are also semi-colon terminated. The usual comment styles are supported: > > C style: /* */ > > C++ style: // to end of line > > Unix style: # to end of line > > Where did you get > > ; But this? Ah, yes, you're correct for named.conf. I was referring to the zone files. --corey From downing.nick at gmail.com Thu Feb 9 13:02:55 2017 From: downing.nick at gmail.com (Nick Downing) Date: Thu, 9 Feb 2017 14:02:55 +1100 Subject: [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: Thanks a lot for the tip Paul. It's great that others are working in this area. Although I must say that as a kind of a "historian" I try to go to primary sources where possible. Although I had already converted a fair bit of code in the manner you describe, I am actually re-converting a fair bit of it since I now have a semi-automated system for doing so, that way I get pretty consistent results that aren't reliant on ad-hoc decisions made during porting. Well, good judgement is still needed, but I have a set of mental algorithms for fixing exactly the kinds of questionable constructs you describe, which lead to pretty consistent results. Using my scripts I converted bin, usr.bin and lib of 4.3BSD in a few weeks, although a fair bit of that time was spent on "bin/as" and "bin/sh" and "bin/csh" and other pathological cases. When I have time I will proceed to ucb. I did all subdirectories of bin (things like sed which are multi-module programs) but not usr.bin yet. So what I'll probably do when I get to looking at LSX is to re-convert and then compare against your work, since either of us could quite well have found questionable constructs missed by the other. Also, earlier today I was looking at Noel's page about improving V6: http://mercury.lcs.mit.edu/~jnc/tech/ImprovingV6.html Anyway, I'm much more of a V7 guy and I think I would find V6 strange and compromised, so I am thinking I will definitely have to apply some of these patches, or at least check how much they increase the code size by. At the very least, lseek() and mdate() have to go in, I'm not sure about stdio since having a suite of the standard commands that don't use stdio and hence are smaller/slower might be OK. But probably my preferred approach is to calculate a patch V6 -> Mini Unix or V6 -> LSX and then try to apply that on top of V7. Hmm. As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this is adviseable, as I was saying earlier I think it might be best to keep that functionality outboard from the kernel. The question in my mind is (1) does the Mini Unix / LSX system have to be a fully participating node on the network or can it be a leaf node without any routing, and (2) does it have to respond to ping or incoming connections at any time. Since my scenario is a simple SLIP link to my home server, (1)=No for me. As to (2), I see two scenarios, (a) the machine is used as a development machine, where I run "ed" and "cc" and so on, and occasionally "ftp" or "rcp" as a client only, or (b) the machine is used as a remote node for something like say data logging or web serving, where it runs the same application all the time, and I connect to it to retrieve results and/or download software updates. In case (a) there are only outgoing connections. In case (b) there are incoming connections, but the machine runs the same application all the time, so there's no disadvantage to having TCP in userspace. I don't envisage a more complicated scenario where it runs inetd in the background and a console in the foreground, due to RAM limits. cheers, Nick On Thu, Feb 9, 2017 at 12:56 AM, Paul Ruizendaal wrote: > Nick, > > If you want to work with LSX, you might have a look at the LSX port I did for the TI990 mini computer: http://1587660.websites.xs4all.nl/cgi-bin/9995/dir?ci=1c38b1fc8792c80b&name=lsx > It is a further development from the work that was done for BKUNIX by Leonid Broukhis (https://sourceforge.net/p/bkunix/code/HEAD/tree/). > > You get stuff converted to a dialect of C acceptable by modern compilers, and some kludges like using 'char*' for 'unsigned' and 'int a[2]' for 'long a' are cleaned up. > > The repository also has a V6 kernel with similar clean up and some V7 compatibility ('lseek' instead of 'seek', etc.). My next step would be to move to a V7 kernel and add TCP/IP capability. This is how I got interested in the history of sockets and TCP/IP. I have found that the BSD stack (as found in e.g. ULTRIX-11) will not fit in 64KB (note: just the network stack). The BBN stack appears to fit in 56KB, with 15KB of buffers available; I think it could be integrated with a V7 kernel as a second kernel process. > > Paul > > On 8 Feb 2017, at 12:21 , Nick Downing wrote: > >> Yes, NetBSD and 386BSD are interesting. They could well form a good >> basis for a minimal but fully functional OS for a modern platform. One >> reservation I have though, is as follows: When 386BSD and its >> derivatives like OpenBSD, NetBSD, FreeBSD came out, Unix was still >> encumbered and thus they had to be based on 4.4BSD Lite (not even >> NET/2 was safe). Nobody made an unencumbered version of say 4.3BSD or >> even NET/2, even though it was theoretically possible, by examining >> what had to be taken out/added to produce 4.4BSD Lite. >> >> Given that Unix is now unencumbered I believe there is no point >> adopting 4.4, or even 4.3Reno, because the main thing done in those >> releases as far as I know, is to add partial POSIX compliance. But if >> you want POSIX compliance you will not achieve minimality. As an >> example consider the BSD sigvec() routine. POSIX calls this >> sigaction(), the old SV_ONSTACK flag becomes SA_ONSTACK, the old >> integer mask becomes a sigset_t and so on... and in any reasonable >> POSIX compliant BSD the two calls are gonna have to coexist, etc. >> >> As to 32V, I appreciate your idea, as I was having some similar >> thoughts myself. However I personally wouldn't use 32V as a basis for >> any serious porting work, because I would assume V7 and 4.3 are much >> more stable and well tested, since they ran in a lot of installations >> over a long time. That's not to denigrate the huge achievement in >> porting V7 to the VAX and producing 32V, but it probably has some >> rough edges that were smoothed out over time to produce the 4BSDs. The >> situation is a bit different for kernel/toolchain/other userspace. >> >> As to the kernel I have been trying to make a detailed comparison >> between 32V and the BSDs, but have been a bit put off by the fact that >> all files moved around and may have been renamed, I will figure it all >> out eventually though. As to the toolchain I have compared it quite >> carefully with 4.3BSD, and I conclude you should use the later >> toolchain as there is no disadvantage and some advantages to doing so. >> As to the rest of the userspace, I BELIEVE that it's stock V7 with any >> 32-bit issues fixed, but I suspect somewhat hastily and superficially. >> >> Producing a 32V-like kernel from 4.3BSD sources would probably be >> quite difficult, it would be relatively easy to disable added system >> calls, but harder to disable things like setpgrp() or the associated >> support in the TTY drivers. More seriously the memory management would >> have to change, I am planning however to make virtual memory optional >> in the 4.3BSD kernel, by maybe putting the 32V code back in, protected >> by #ifndef VM or some such (somewhat like Steven Schultz has done in >> porting 4.3BSD to PDP-11 to produce 2.11BSD). >> >> On the other hand producing a 32V-like userland from the 4.3BSD >> sources would be pretty easy, I think just delete the sources for any >> executables that weren't distributed with 32V and possibly, if any of >> the tools seem particularly bloated, comment out any command line >> switches or features that weren't in 32V. Going to this level of >> effort would likely be pointless though. Another option would be >> taking V7 and re-porting it (except the toolchain) over to a 32-bit >> environment and kernel. I have developed over the past months, tools >> that make this relatively straightforward, and in the process would >> rediscover any 32-bit issues that were fixed in creating 32V. So I >> wouldn't use 32V. >> >> On a slightly different tack, I also have been for some time >> investigating the idea of an Apple II port of Unix, there are massive >> technical issues to be solved, but I think I got a bit closer the >> other night when I decided to collect all information and resources I >> could find about Mini-Unix and LSX (LSI Unix). Both are >> self-supporting V6-based environments, the compiler can only compile >> small programs but it is nonetheless possible for each Unix to >> recomple itself. LSX I believe could run from floppies (dunno about >> 140K floppies) in less than 64K. >> >> So, you know, true minimality is a relative term. We want something >> LSX-like for an Apple II, something 2.11BSD-like for an IBM PC/XT or >> 286 (as Peter Jeremy noted, it's a good fit, and I'd be interested to >> know more), something 4.3BSD-like for a VAX or 386... something a bit >> more fully featured for a modern 64-bit multi-gigabyte system... but >> just not as bloated as what we currently rely on. Hmm well it's hard. >> What I do know, is that I have a lot of old hardware with <16M RAM and >> Linux won't run on it anymore, and this annoys me very greatly. >> >> In talking about FreeBSD/Linux bloat I forgot to mention the packet >> filter, iptables (Linux) or pf (FreeBSD). I have a bit of experience >> with this, since I regularly used to put 2 Ethernet cards in my home >> server and make it Internet facing through one of them and share the >> connection using NAT through the other card. But I've come to the >> conclusion this is stupid, and moreover, that putting a complete >> mini-language into the kernel just for this purpose is utterly stupid. >> Programming the thing from userspace is incredibly intricate, and all >> this complexity serves no purpose. >> >> I recently found out about SLIRP (userspace packet rewriting) and I >> think this would be a good way to implement NAT on servers or routers >> that actually need to do NAT -- just make a userspace process that >> runs something SLIRP-like and has a raw socket to the second Ethernet >> card, and Bob's your uncle. >> >> But this got me thinking along pretty productive lines in terms of the >> tiny Apple II port -- I have been wanting to put the 2.11BSD network >> stack into an Apple II for a long time, but I've now realized this is >> not necessary. A much better approach for those Mini-Unix or LSX or >> even V7 systems, would be to have a userspace library that does SLIP >> and contains its own TCP, UDP, IP drivers, resolver and so on. Then if >> you run a userspace program like say, ftp, which is linked to the >> userspace TCP library, it would basically just open /dev/ttyXX, bring >> up the SLIP link itself, do any necessary downloads etc, then close >> the TTY and stop responding to any IP stuff coming over the SLIP link >> whilst you quit to the prompt, until another program reopens it. >> >> cheers, Nick >> >> On Wed, Feb 8, 2017 at 2:56 PM, Jason Stevens >> wrote: >>> What about NetBSD 1.1 or even 386BSD? >>> >>> There never was a 4.2 or 4.3 for i386 was there? >>> >>> I'd guess the 32v userland could be built on early 4.4BSD Lite/NET2 greatly >>> reducing its footprint. >>> >>> >>> >>> >>> On February 8, 2017 11:47:03 AM GMT+08:00, Nick Downing >>> wrote: >>>> >>>> This is an issue that interests me quite a bit, since I was running >>>> FreeBSD in an effort to get around Linux bloat problems discussed. >>>> Well not that I really mind Linux as a user interface / runtime >>>> environment / main development machine, but I think it probably >>>> shouldn't be used as a "least common denominator" for development >>>> since you end up introducing unwanted dependencies on a whole lot of >>>> stuff. >>>> >>>> So I was running FreeBSD as a more minimal *nix. I did quite a lot of >>>> interesting stuff with FreeBSD such as setting up diskless >>>> workstations in my home, etc. I spent a lot of time tinkering around >>>> in the kernel code. I was planning to do some serious development on >>>> 4.4BSDLite or FreeBSD to create an operating system more to my liking. >>>> So, I was looking carefully at differences since ancient *nixes. >>>> >>>> And, I can say that FreeBSD is pretty bloated. Umm well they've added >>>> SMP, at the time it was using the Giant Lock although that could be >>>> fixed by now. They've added VFS and NFS of course. They've added an >>>> entire subsystem for block devices IIRC that handles partitioning and >>>> possibly some other sophisticated stuff, which I believe is their own >>>> design. Umm the kqueues and I believe they have their own >>>> implementation of kernel threading or lightweight processes including >>>> some sort of idle daemon. The network stack is heavily upgraded, to >>>> the extent I looked into it, the added features are things you would >>>> want (syncookies = DOS protection, etc) but also could not possibly be >>>> called minimal, and would preclude running it on other than a >>>> multi-megabyte machine. They have multiple ABIs so the kernel can >>>> accept Linux or BSD syscalls or whatever else (I used it to run >>>> Acrobat Reader Linux on my FreeBSD desktop). Umm I am pretty sure they >>>> have kernel modules ala Linux. Lots and lots and lots of stuff... and >>>> that's only considering the kernel. If you look in the ports >>>> collection you see they have incredible amounts of bloat there too... >>>> for instance GNOME, Libreoffice, LATEX, gcc, python... not that I'm >>>> denigrating these tools, since they do invaluable work and I use them >>>> every day, but the point is, you CANNOT call them minimal. >>>> >>>> The quest for a clean minimal system goes on ->. FreeBSD is not the >>>> answer. In fact I believe 4.3BSD-Reno and 4.4 go strongly offtrack. >>>> >>>> cheers, Nick >>>> >>>> On Wed, Feb 8, 2017 at 1:55 PM, Greg 'groggy' Lehey >>>> wrote: >>>>> >>>>> On Tuesday, 7 February 2017 at 15:38:40 -0800, Steve Johnson wrote: >>>>>> >>>>>> Looking back, the social dynamics of the Unix group helped a lot in >>>>>> keeping the bloat small. The rule was, whoever touches something >>>>>> last becomes its owner. Of course, we were all free to complain >>>>>> about things, and did, but the amalgamation of tinkerings that >>>>>> characterizes most of the Linux commands just didn't happen. >>>>> >>>>> >>>>> Out of interest: where do you (or others) consider that the current >>>>> BSD projects it in this comparison? >>>>> >>>>> 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 >>> >>> >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. > From jnc at mercury.lcs.mit.edu Thu Feb 9 14:14:45 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 8 Feb 2017 23:14:45 -0500 (EST) Subject: [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) Message-ID: <20170209041445.9E6FD18C11A@mercury.lcs.mit.edu> > From: Nick Downing > I'm much more of a V7 guy and I think I would find V6 strange and > compromised De gustibus. I used it for many years, and am quite at home in it. I think it's a marvel of functionality/size - at the time it came out, not much bigger than DEC PDP-11 OS's, but with a 'big system' feel to it (which they _definitely_ did not) - in fact, _better_ than most big systems of the day. But I can see it would be rather too simple (and in the kernel inelegant, code-wise, by today's standards - see below) for many. V7 is not that different, in terms of user experience, from V6, though. > I am thinking I will definitely have to apply some of these patches, or > at least check how much they increase the code size by. Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about there is for user commands, not the kernel. There are only a few kernel changes (lseek() and mdate(), and param.c so that the new 'si' command can get thing from param.h without having to have it compiled in), and they are all small. > But probably my preferred approach is to calculate a patch V6 -> Mini > Unix or V6 -> LSX and then try to apply that on top of V7. I'm a little confused as to what your goal is here. Get V6 running on some other architecture? Upgrade V6 for some goal which I am not aware of? I know you probably said something in an earlier email, sorry, I don't recall. Anyway, if you're going to do anything with V6 kernel code, you need to be aware that it's really idiosyncratic - a lot of its written in a very early dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int a = 1' are pretty easy to fix, there are lots of intances of int's being used as pointers to several different kinds of structures, etc, etc. If you want to move an early, small Unix to something other than a PDP-11, V7 is probably a much better bet. > As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this > is adviseable, as I was saying earlier I think it might be best to keep > that functionality outboard from the kernel. There are a couple of early TCP/IP's which ran outside the kernel, but I think the standard Berkeley one might be a handful to move out. Noel From imp at bsdimp.com Thu Feb 9 14:38:52 2017 From: imp at bsdimp.com (Warner Losh) Date: Wed, 8 Feb 2017 21:38:52 -0700 Subject: [TUHS] // comment in C++ In-Reply-To: References: <20170209021136.9BDEA40B9@lod.com> Message-ID: On Wed, Feb 8, 2017 at 7:46 PM, Dave Horsfall wrote: > On Wed, 8 Feb 2017, Corey Lindsly wrote: > >> > I'm quite taken by BIND, though, which accepts >> > >> > /* this */ >> > // this >> > # and this. >> >> Not that. >> >> ; But this. > > Perhaps I meant named.conf (part of BIND): > > named.conf is the configuration file for named. Statements are enclosed > in braces and terminated with a semi-colon. Clauses in the statements > are also semi-colon terminated. The usual comment styles are supported: > > C style: /* */ > > C++ style: // to end of line > > Unix style: # to end of line > > Where did you get > > ; But this? Old School assembler comments. This found its way into a number of config files long after most uses of Old School assembler had moved on... Macro-16 is where I first encountered it, but it is much older. It is common in DEC syntax, and some others. Warner From scj at yaccman.com Thu Feb 9 14:55:21 2017 From: scj at yaccman.com (Steve Johnson) Date: Wed, 08 Feb 2017 20:55:21 -0800 Subject: [TUHS] // comment in C++ In-Reply-To: Message-ID: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> Well, personally I use // for almost all comments in C/C++.  I reserve /* */ for commenting out blocks of code.   Since, for some reason, /* */ doesn't nest, if I stick to this style life is good. Steve ----- Original Message ----- From: "Steve Nickolas" To:"The Eunuchs Hysterical Society" Cc: Sent:Wed, 8 Feb 2017 21:47:49 -0500 (EST) Subject:Re: [TUHS] // comment in C++ On Thu, 9 Feb 2017, Dave Horsfall wrote: > On Wed, 8 Feb 2017, Steve Johnson wrote: > >> I remember some discussion about this.  In reality, a C comment really >> requires you to type 8 characters, because putting anything adjacent to >> the /* or */ looks terrible.  Many languages used single characters >> (e.g., # for make).  The argument was "if you make comments easier to >> type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm >> guessing Bjarne was aware of these discussions, although I don't >> remember specifically that he was... > > My favourite C /* */ style is this: > > /* > * foo > * bar > */ This is the way I usually write my comments, too. > Is that what you meant? And recent C also accepts // as a comment, which > I use like this: > > /* > * This is where we do some neat stuff. > */ > foo(); > weird_function(); // Yes, we need to call this here... > bar(); > > I'm quite taken by BIND, though, which accepts > > /* this */ > // this > # and this. Unrealircd likewise accepts those 3 different types of comments. -uso. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Feb 9 19:19:27 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 9 Feb 2017 10:19:27 +0100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: On 9 Feb 2017, at 4:02 , Nick Downing wrote: > As to moving to a V7 kernel and then adding TCP/IP I'm not sure if > this is adviseable, as I was saying earlier I think it might be best > to keep that functionality outboard from the kernel. That approach was taken in various early implementations, with varying degrees of success. The best one seems to have been the 3Com stack, which puts IP in the kernel and TCP in a daemon. By the way, this implementation is also where SLIP seems to have originated. http://bitsavers.informatik.uni-stuttgart.de/pdf/3Com/3Com_UNET_Nov80.pdf > and (2) does it have to respond to ping or incoming > connections at any time. I'm not sure economizing on ICMP support is the best approach. Perhaps economizing on fragmentation and and window management is better. For example, the 1979 Wingfield implementation discards out of order packets and simply waits for retransmission of the expected packet; this simplifies the code and greatly reduces the need for buffer space. Arguably, the handling of incoming connections does not require much code or data. --- A TCP connection spends most of its time in the 'established' state. I wonder if just putting the code for this state in the kernel and handling only the state changes and other states in a daemon is perhaps the best split on constrained hardware. I'm not aware of any historical implementation having that design, so perhaps it is flawed thinking. Paul From brantleycoile at me.com Thu Feb 9 19:36:20 2017 From: brantleycoile at me.com (Brantley Coile) Date: Thu, 09 Feb 2017 04:36:20 -0500 Subject: [TUHS] Fwd: Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <20170209041445.9E6FD18C11A@mercury.lcs.mit.edu> References: <20170209041445.9E6FD18C11A@mercury.lcs.mit.edu> Message-ID: <6D29294E-CC6F-483B-B4EE-D3DBB7A23E65@me.com> Regarding putting TCP/IP Into V7, I found it not that hard. First, it's not that hard to implement Dennis' streams in V7, and then, using the streams structure, do a straight forward TCP right from the pseudocode from the appendix of the RFC. I still have it around somewhere. If you're interested I can share it with you. Brantley Sent from my iPad On Feb 8, 2017, at 11:14 PM, Noel Chiappa wrote: >> From: Nick Downing > >> I'm much more of a V7 guy and I think I would find V6 strange and >> compromised > > De gustibus. I used it for many years, and am quite at home in it. I think > it's a marvel of functionality/size - at the time it came out, not much bigger > than DEC PDP-11 OS's, but with a 'big system' feel to it (which they > _definitely_ did not) - in fact, _better_ than most big systems of the day. > > But I can see it would be rather too simple (and in the kernel inelegant, > code-wise, by today's standards - see below) for many. V7 is not that > different, in terms of user experience, from V6, though. > > >> I am thinking I will definitely have to apply some of these patches, or >> at least check how much they increase the code size by. > > Sorry, that page is kind of a mish-mosh. Most of the stuff that's talked about > there is for user commands, not the kernel. > > There are only a few kernel changes (lseek() and mdate(), and param.c so that > the new 'si' command can get thing from param.h without having to have it > compiled in), and they are all small. > > >> But probably my preferred approach is to calculate a patch V6 -> Mini >> Unix or V6 -> LSX and then try to apply that on top of V7. > > I'm a little confused as to what your goal is here. Get V6 running on some > other architecture? Upgrade V6 for some goal which I am not aware of? I know > you probably said something in an earlier email, sorry, I don't recall. > > Anyway, if you're going to do anything with V6 kernel code, you need to be > aware that it's really idiosyncratic - a lot of its written in a very early > dialect of C, and while things like 'a =+ b' -> 'a += b' and 'int a 1' -> 'int > a = 1' are pretty easy to fix, there are lots of intances of int's being used > as pointers to several different kinds of structures, etc, etc. > > If you want to move an early, small Unix to something other than a PDP-11, V7 > is probably a much better bet. > > >> As to moving to a V7 kernel and then adding TCP/IP I'm not sure if this >> is adviseable, as I was saying earlier I think it might be best to keep >> that functionality outboard from the kernel. > > There are a couple of early TCP/IP's which ran outside the kernel, but I think > the standard Berkeley one might be a handful to move out. > > Noel From michael at kjorling.se Thu Feb 9 19:58:03 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 9 Feb 2017 09:58:03 +0000 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: <20170209095803.GF5418@yeono.kjorling.se> On 9 Feb 2017 10:19 +0100, from pnr at planet.nl (Paul Ruizendaal): > A TCP connection spends most of its time in the 'established' state. I > wonder if just putting the code for this state in the kernel and handling > only the state changes and other states in a daemon is perhaps the best > split on constrained hardware. I'm not aware of any historical > implementation having that design, so perhaps it is flawed thinking. Wouldn't the state change code need to be executable, even if it technically isn't in the kernel? I can see no _obvious_ reason why you _couldn't_ have a daemon handling state changes and non-established TCP connections, but I'm having a hard time seeing what it would save you in terms of code size. If anything, it seems like the code would need to be a little larger in total, because now you have two components interacting where previously there was just one component doing all of the work. One benefit I can see though would be to reduce the incidence of bugs in the established-state code; less code running privileged means less things to screw up so badly that the system panics (or scribbles over the wrong data). A crashed TCP daemon would be an annoyance, but would at least allow you to restart it or to reboot the system at leisure rather than having the whole system come to a screeching halt. You'd need some amount of synchronization either way, to prevent two connections changing state at the same time from stepping on each other's toes, but that would hardly be unheard of in the kernel of a multitasking OS... -- 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 pnr at planet.nl Thu Feb 9 20:08:31 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 9 Feb 2017 11:08:31 +0100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <20170209095803.GF5418@yeono.kjorling.se> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <20170209095803.GF5418@yeono.kjorling.se> Message-ID: <27C502B1-AA4F-470B-A0F7-8A8E7950C5C8@planet.nl> On 9 Feb 2017, at 10:58 , Michael Kjörling wrote: > [...] but I'm having a hard time seeing what it would save > you in terms of code size. The main benefit would be that one would not have to copy all data packets into the daemon and then back into the kernel again. Normal data packets would flow straight to the user process. Paul From michael at kjorling.se Thu Feb 9 21:59:22 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 9 Feb 2017 11:59:22 +0000 Subject: [TUHS] // comment in C++ In-Reply-To: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> Message-ID: <20170209115922.GH5418@yeono.kjorling.se> On 8 Feb 2017 20:55 -0800, from scj at yaccman.com (Steve Johnson): > Well, personally I use // for almost all comments in C/C++.  I > reserve /* */ for commenting out blocks of code.   Since, for some > reason, /* */ doesn't nest, if I stick to this style life is good. #if 0 ... #endif also works, and nests if needed. I didn't know that // was now accepted to begin a comment in C, but I strongly suspect that any compiler modern enough to know about that will know just as well about #if 0. -- 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 michael at kjorling.se Thu Feb 9 22:12:04 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Thu, 9 Feb 2017 12:12:04 +0000 Subject: [TUHS] // comment in C++ In-Reply-To: <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> Message-ID: <20170209121204.GJ5418@yeono.kjorling.se> On 8 Feb 2017 17:50 -0500, from ron at ronnatalie.com (Ron Natalie): > Amusingly in the UNIVAC FIELDDATA character set. The @ had the value zero > (and was called the master space). That wouldn't have anything to do with how ^@ is a somewhat common representation of 000, would it? (Yes, using octal on purpose.) I've always kind of wondered where that notation came from. That ^A through ^Z were representations of 001 through 032 makes more sense. -- 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 Feb 9 22:26:54 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Thu, 09 Feb 2017 13:26:54 +0100 Subject: [TUHS] // comment in C++ In-Reply-To: <20170209121204.GJ5418@yeono.kjorling.se> ("Michael \=\?utf-8\?Q\?Kj\=C3\=B6rling\=22's\?\= message of "Thu, 9 Feb 2017 12:12:04 +0000") References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> <20170209121204.GJ5418@yeono.kjorling.se> Message-ID: <86inojsg6p.fsf@molnjunk.nocrew.org> Michael Kjörling writes: > That wouldn't have anything to do with how ^@ is a somewhat common > representation of 000, would it? (Yes, using octal on purpose.) I've > always kind of wondered where that notation came from. That ^A > through ^Z were representations of 001 through 032 makes more sense. Look at two slices of the ASCII table: 0 ^@ 64 @ 1 ^A 65 A 2 ^B 66 B 3 ^C 67 C 4 ^D 68 D 5 ^E 69 E 6 ^F 70 F 7 ^G 71 G 8 ^H 72 H 9 ^I 73 I 10 ^J 74 J 11 ^K 75 K 12 ^L 76 L 13 ^M 77 M 14 ^N 78 N 15 ^O 79 O 16 ^P 80 P 17 ^Q 81 Q 18 ^R 82 R 19 ^S 83 S 20 ^T 84 T 21 ^U 85 U 22 ^V 86 V 23 ^W 87 W 24 ^X 88 X 25 ^Y 89 Y 26 ^Z 90 Z 27 ^[ 91 [ 28 ^\ 92 \ 29 ^] 93 ] 30 ^^ 94 ^ 31 ^_ 95 _ From pnr at planet.nl Thu Feb 9 22:31:22 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 9 Feb 2017 13:31:22 +0100 Subject: [TUHS] // comment in C++ In-Reply-To: <20170209121204.GJ5418@yeono.kjorling.se> References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> <20170209121204.GJ5418@yeono.kjorling.se> Message-ID: <9E957EE0-DC6F-4B39-9AF9-CFAE68616CF8@planet.nl> > On 9 Feb 2017, at 13:12, Michael Kjörling wrote: > > On 8 Feb 2017 17:50 -0500, from ron at ronnatalie.com (Ron Natalie): >> Amusingly in the UNIVAC FIELDDATA character set. The @ had the value zero >> (and was called the master space). > > That wouldn't have anything to do with how ^@ is a somewhat common > representation of 000, would it? (Yes, using octal on purpose.) I've > always kind of wondered where that notation came from. > > That ^A through ^Z were representations of 001 through 032 makes more > sense. Isn’t it because it is simply the control code + 0100 to arrive at the capitals column of the ascii table? (http://www.asciitable.com) Hence ^@ for NULL and ^[ for ESC. From steffen at sdaoden.eu Thu Feb 9 23:07:04 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 14:07:04 +0100 Subject: [TUHS] // comment in C++ In-Reply-To: <9E957EE0-DC6F-4B39-9AF9-CFAE68616CF8@planet.nl> References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> <20170209121204.GJ5418@yeono.kjorling.se> <9E957EE0-DC6F-4B39-9AF9-CFAE68616CF8@planet.nl> Message-ID: <20170209130704.XIzNK%steffen@sdaoden.eu> Paul Ruizendaal wrote: |> On 9 Feb 2017, at 13:12, Michael Kjörling wrote: |> On 8 Feb 2017 17:50 -0500, from ron at ronnatalie.com (Ron Natalie): |>> Amusingly in the UNIVAC FIELDDATA character set. The @ had the \ |>> value zero |>> (and was called the master space). |> |> That wouldn't have anything to do with how ^@ is a somewhat common |> representation of 000, would it? (Yes, using octal on purpose.) I've |> always kind of wondered where that notation came from. |> |> That ^A through ^Z were representations of 001 through 032 makes more |> sense. | |Isn’t it because it is simply the control code + 0100 to arrive at the |capitals column of the ascii table? (http://www.asciitable.com) | |Hence ^@ for NULL and ^[ for ESC. That is also what i thought and think. The MUA i maintain now documents (in the next release): ‘\cX’ A mechanism that allows usage of the non-printable (ASCII and compatible) control codes 0 to 31: to cre‐ ate the printable representation of a control code the numeric value 64 is added, and the resulting ASCII character set code point is then printed, e.g., BEL is ‘7 + 64 = 71 = G’. Whereas historically circumflex notation has often been used for visualization pur‐ poses of control codes, e.g., ‘^G’, the reverse solidus notation has been standardized: ‘\cG’. Some control codes also have standardized (ISO 10646, ISO C) alias representations, as shown above (e.g., ‘\a’, ‘\n’, ‘\t’): whenever such an alias exists S-nail will use it for display purposes. The control code NUL (‘\c@’) ends argument processing without producing further output. I hope this is correct. --steffen From dot at dotat.at Thu Feb 9 23:11:27 2017 From: dot at dotat.at (Tony Finch) Date: Thu, 9 Feb 2017 13:11:27 +0000 Subject: [TUHS] // comment in C++ In-Reply-To: References: Message-ID: Paul McJones wrote: > > I'm fairly certain it was originally in BCPL. > > > > You could just drop a note to Bjarne Stroustrup and ask. :-) > > On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994), > Stroustrup says: > > “However, only C, Simula, Algol68, an in one case BCPL left noticeable > traces in C++ as released in 1985. Simula gave classes, Algol68 > operating overloading, references, and the ability to declare variables > anywhere in a block, and BCPL gave // comments.” > > He says a bit more about // comments on page 93, including an example of > how they introduced an incompatibility with C. There's more in Stroustrup's paper for the second History of Programming Languages conference, http://www.stroustrup.com/hopl2.pdf See especially the prehistory section 2.1 on page 3 where he talks about the painful tooling he was faced with in Cambridge, where Simula was nice for program design but had a woefully slow implementation, whereas BCPL was fast but grievously unsafe. The quote above is repeated in the HOPL2 paper on page 12 in section 2.4.4 on "Why C?" and there's a bit more about comment syntax in section 3.3.1 on page 21. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Wight, Portland: East or northeast 4 or 5, increasing 6 at times. Slight or moderate, occasionally rough in Portland. Showers. Moderate or good. From brantleycoile at me.com Thu Feb 9 22:18:20 2017 From: brantleycoile at me.com (Brantley Coile) Date: Thu, 09 Feb 2017 07:18:20 -0500 Subject: [TUHS] // comment in C++ In-Reply-To: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> Message-ID: <306BEA6F-6E6C-4470-AC6C-DF6D848CBBFF@me.com> That’s a good convention. I use the convention that the permanent comments use the slash-splat form and the slash-slash from is used for temporary comment that will need attention later. They are TODO comments. I also use empty comments in the first column to note debugging stuff to remove laters. For example: void main(int argc, char **argv) { ARGBEGIN { default: usage(); } ARGEND /**/ print(“argc=%d argv=%p\n”, argc, argv); /**/ if (argc == 3) /**/ print(“that funny number again\n”); if (argc == 0) { usestdin(); … } This lets the flow of the test logic clear yet is easy to find and remove the code later. I also use “#ifdef notdef” to comment out blocks of code. Have done since v7 days. Once I worked with a guy who saw the ifdefs and wondered what the function was that was def’ed out. He added -Dnotdef and all hell broke out! Brantley > On Feb 8, 2017, at 11:55 PM, Steve Johnson wrote: > > Well, personally I use // for almost all comments in C/C++. I reserve /* */ for commenting out blocks of code. Since, for some reason, /* */ doesn't nest, if I stick to this style life is good. > > Steve > > > > ----- Original Message ----- > From: > "Steve Nickolas" > > To: > "The Eunuchs Hysterical Society" > Cc: > > Sent: > Wed, 8 Feb 2017 21:47:49 -0500 (EST) > Subject: > Re: [TUHS] // comment in C++ > > > On Thu, 9 Feb 2017, Dave Horsfall wrote: > > > On Wed, 8 Feb 2017, Steve Johnson wrote: > > > >> I remember some discussion about this. In reality, a C comment really > >> requires you to type 8 characters, because putting anything adjacent to > >> the /* or */ looks terrible. Many languages used single characters > >> (e.g., # for make). The argument was "if you make comments easier to > >> type, you'll get more of them in the code" (viz. the Unix kernel). I'm > >> guessing Bjarne was aware of these discussions, although I don't > >> remember specifically that he was... > > > > My favourite C /* */ style is this: > > > > /* > > * foo > > * bar > > */ > > This is the way I usually write my comments, too. > > > Is that what you meant? And recent C also accepts // as a comment, which > > I use like this: > > > > /* > > * This is where we do some neat stuff. > > */ > > foo(); > > weird_function(); // Yes, we need to call this here... > > bar(); > > > > I'm quite taken by BIND, though, which accepts > > > > /* this */ > > // this > > # and this. > > Unrealircd likewise accepts those 3 different types of comments. > > -uso. From downing.nick at gmail.com Thu Feb 9 23:31:18 2017 From: downing.nick at gmail.com (Nick Downing) Date: Fri, 10 Feb 2017 00:31:18 +1100 Subject: [TUHS] // comment in C++ In-Reply-To: <306BEA6F-6E6C-4470-AC6C-DF6D848CBBFF@me.com> References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <306BEA6F-6E6C-4470-AC6C-DF6D848CBBFF@me.com> Message-ID: Haha well I never liked that idiom but I recently found out that #ifdef was present in the first CPPs whereas #if was much later. So that's why #ifdef notdef is seen a lot in old code. Anyway, personally I use #if 0 and #if 1 quite a lot for debugging or questionable stuff. For a while, I was quite into the idea of doing compile time options like #define SOME_OPTION 1 and then using #if SOME_OPTION, as I felt it was nicer than #ifdef SOME_OPTION. But I've changed my mind, as this is pretty nonstandard usage and can be misleading. It's also not really safer than #ifdef, since for some reason CPP accepts undefined symbols and treats them as 0 in a #if statement. Go figure. cheers, Nick On Thu, Feb 9, 2017 at 11:18 PM, Brantley Coile wrote: > That’s a good convention. I use the convention that the permanent comments use the slash-splat form and the slash-slash from is used for temporary comment that will need attention later. They are TODO comments. > > I also use empty comments in the first column to note debugging stuff to remove laters. For example: > > void > main(int argc, char **argv) > { > ARGBEGIN { > default: > usage(); > } ARGEND > /**/ print(“argc=%d argv=%p\n”, argc, argv); > /**/ if (argc == 3) > /**/ print(“that funny number again\n”); > if (argc == 0) { > usestdin(); > … > } > > This lets the flow of the test logic clear yet is easy to find and remove the code later. > > I also use “#ifdef notdef” to comment out blocks of code. Have done since v7 days. Once I worked with a guy who saw the ifdefs and wondered what the function was that was def’ed out. He added -Dnotdef and all hell broke out! > > Brantley > >> On Feb 8, 2017, at 11:55 PM, Steve Johnson wrote: >> >> Well, personally I use // for almost all comments in C/C++. I reserve /* */ for commenting out blocks of code. Since, for some reason, /* */ doesn't nest, if I stick to this style life is good. >> >> Steve >> >> >> >> ----- Original Message ----- >> From: >> "Steve Nickolas" >> >> To: >> "The Eunuchs Hysterical Society" >> Cc: >> >> Sent: >> Wed, 8 Feb 2017 21:47:49 -0500 (EST) >> Subject: >> Re: [TUHS] // comment in C++ >> >> >> On Thu, 9 Feb 2017, Dave Horsfall wrote: >> >> > On Wed, 8 Feb 2017, Steve Johnson wrote: >> > >> >> I remember some discussion about this. In reality, a C comment really >> >> requires you to type 8 characters, because putting anything adjacent to >> >> the /* or */ looks terrible. Many languages used single characters >> >> (e.g., # for make). The argument was "if you make comments easier to >> >> type, you'll get more of them in the code" (viz. the Unix kernel). I'm >> >> guessing Bjarne was aware of these discussions, although I don't >> >> remember specifically that he was... >> > >> > My favourite C /* */ style is this: >> > >> > /* >> > * foo >> > * bar >> > */ >> >> This is the way I usually write my comments, too. >> >> > Is that what you meant? And recent C also accepts // as a comment, which >> > I use like this: >> > >> > /* >> > * This is where we do some neat stuff. >> > */ >> > foo(); >> > weird_function(); // Yes, we need to call this here... >> > bar(); >> > >> > I'm quite taken by BIND, though, which accepts >> > >> > /* this */ >> > // this >> > # and this. >> >> Unrealircd likewise accepts those 3 different types of comments. >> >> -uso. > From steffen at sdaoden.eu Thu Feb 9 23:46:28 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 14:46:28 +0100 Subject: [TUHS] Unix stories In-Reply-To: <1483547711.1607300.837230857.4B111F27@webmail.messagingengine.com> References: <5257291ca0a0e1d80c646cab730129d589c5d707@webmail.yaccman.com> <42922C34-342F-4E86-83E2-3618129139B2@tfeb.org> <20170103004959.GA29088@mcvoy.com> <20170104130434.NQFzLGpVU%steffen@sdaoden.eu> <1483538831.1573798.837053385.2EB8CAC9@webmail.messagingengine.com> <20170104162238.qUWzAcIu7%steffen@sdaoden.eu> <1483547711.1607300.837230857.4B111F27@webmail.messagingengine.com> Message-ID: <20170209134628.99Q--%steffen@sdaoden.eu> Hello, Random832 wrote: |On Wed, Jan 4, 2017, at 11:22, Steffen Nurpmeso wrote: |> Random832 wrote: |>|On Wed, Jan 4, 2017, at 08:04, Steffen Nurpmeso wrote: |>|> terrible aliasing and "sequence point" rules, where i think it is |>|> clear what i mean when i write "i = j + ++i" (i believe this is |>|> undefined behaviour). |>| |>|I assume you're imagining it as being equivalent to i = j + i + 1, with |>|a redundant store operation. |>| |>|But why couldn't it equally well mean |> |> No i don't, | |Then I guessed wrong. Again. (So much for "clear", I suppose). But |you're the one who "think[s] it's clear what [you] mean by it"; so you |simply *must* have a meaning in mind. Why not explain what it is? so now i really got this a few minute ago after adding negative history number support (to count from history top): tty.c: In function 'c_history': tty.c:4157:13: warning: operation on 'entry' may be undefined [-Wsequence-point] entry = isneg ? --entry : (siz_t)a_tty.tg_hist_size - entry; ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ And in my opinion this is just plain terrible? I think it is absolutely clear what i intend, there is not even a dereferenced pointer involved, the lhv is either a register or if all fails a stack location. I don't understand why i have to write if(isneg) --entry; else entry = (siz_t)a_tty.tg_hist_size - entry; to get over this, it is exactly the same? And it is not that easy as blaming the compiler (except that gcc often comes over with terrible warnings, but this is a different issue, and of course, these are huge codebases and i guess you stumble along and fix the test warnings that occur when a step turned on some red lights somewhere else; ok, but while i am in rant mode, i recently had to introduce a useless enum to turn #ifdef HAVE_DEVEL /* Avoid gcc warn cascade since n_ignore is defined locally */ -n_CTAV(-(uintptr_t)n_IGNORE_TYPE - n__IGNORE_ADJUST == 0); into +n_CTAV(-n__IGNORE_TYPE - n__IGNORE_ADJUST == 0); where n_IGNORE_TYPE was '#define n_IGNORE_TYPE ((struct n_ignore*)-3)', and if that is not an integer then, what). No, in my opinion this is because of overly construed standard text of an increasingly unclean standard. Digging in the dirt is my whole life anyway, even i don't read newspapers, and i really would like to see C not becoming just an equal soup of muddy waters. Just my one cent. --steffen From dugo at xs4all.nl Fri Feb 10 00:03:34 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Thu, 09 Feb 2017 15:03:34 +0100 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: On 2017-02-08 17:25, Tony Finch wrote: > The previous CVS repo from the 386BSD+patchkit days was hidden away > because of old copyright worries, though some time after 2000 it became > available to most committers. (I have a copy in my home directory on > freefall.freebsd.org which I stashed away in 2007 because at that time > I > think there still wasn't a conveniently accessible copy.) Does that have eg. sys/kern/tty.c in it? Or is also missing piles of files? > It looks like after the uplift to SVN the two repositories were > combined, > so you can now see the 386BSD import at > https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67 Not without being butchered first. A lot of essential source files are missing from the start until they magically appear in the 4.4BSD-Lite upload. I'll take another look if I can make sense of how Lite was folded in. From jnc at mercury.lcs.mit.edu Fri Feb 10 00:31:06 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 9 Feb 2017 09:31:06 -0500 (EST) Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) Message-ID: <20170209143106.0304B18C11C@mercury.lcs.mit.edu> > From: Paul Ruizendaal > The best one seems to have been the 3Com stack, which puts IP in the > kernel and TCP in a daemon. I've gotta get the MIT V6 one online. Incoming demux is in the kernel; all of the TCP, and everything else, is in processes along with the application - one process per application instance. It sounds like it might be clunky, but it's not: there are a couple of different TCP's (a small, low performance one for things like User TELNET, timer servers, yadda-yadda; a bigger, higher-performance one for things like FTP), and the application just calls them as subroutine libraries (effectively). Since there's no IPC overhead, the performance is pretty good. Unfortumately, a lot of the stuff never migrated from personal directories to the system folder, so I have to go curate out the personal files (or, more likely, move them all to a system folder) before I can release it all. > Perhaps economizing on fragmentation and and window management is > better. Fragmentation, perhaps - but good window management is a must. > I wonder if just putting the code for this state in the kernel and > handling only the state changes and other states in a daemon is perhaps > the best split on constrained hardware. I don't think that's a good idea; cutting the TCP in two parts, which have to communicate over an interface is going to be _really_ ugly: do you have one copy of the connection state data (in which case one them has to go through an interface to get to it), or two (synchronization issues). If you want a small kernel footprint, take the MIT approach. Noel From random832 at fastmail.com Fri Feb 10 00:37:34 2017 From: random832 at fastmail.com (Random832) Date: Thu, 09 Feb 2017 09:37:34 -0500 Subject: [TUHS] // comment in C++ In-Reply-To: <86inojsg6p.fsf@molnjunk.nocrew.org> References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> <20170209121204.GJ5418@yeono.kjorling.se> <86inojsg6p.fsf@molnjunk.nocrew.org> Message-ID: <1486651054.1665917.875659504.05C3D685@webmail.messagingengine.com> On Thu, Feb 9, 2017, at 07:26, Lars Brinkhoff wrote: > Michael Kjörling writes: > > That wouldn't have anything to do with how ^@ is a somewhat common > > representation of 000, would it? (Yes, using octal on purpose.) I've > > always kind of wondered where that notation came from. That ^A > > through ^Z were representations of 001 through 032 makes more sense. > > Look at two slices of the ASCII table: And for where ^? for DEL comes from, (0377 + 0100) & 0377 == 0077 [where the first 0377 is the control character of interest.] I am sure I've seen code that calculates the character to be displayed in precisely this way, but I can't remember where. In fact, this is exactly how the control key worked on early terminals (I recently had reason to look up an ASR-33 manual). The Shift key toggled the 0020 bit (so shift-2 is " - if you look at the relevant slice of an ASCII table), resulting in shift-K is [ (which did not have a dedicated key) and shift-ctrl-K is ESC (which did have a dedicated key as well, but the other non-letter control characters did not, and were on shift-ctrl-LMNOP). There was a mechanical lockout for keys that shift didn't make sense with - all other letters and zero (which would otherwise have produced a space), and one for ctrl (which locked out all the number and symbol keys) From jsteve at superglobalmegacorp.com Fri Feb 10 00:41:40 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Thu, 9 Feb 2017 22:41:40 +0800 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: 386BSD is available here: http://oldlinux.org/Linux.old/distributions/386BSD/ The 0.0 distribution tree is there, and files for 0.1 , and the few patchkits that survived. I’m 99% sure this is that I took to take 0.1 to 0.1-p23 to 0.1-p24 and used that to fill in the missing CVS from NetBSD 0.8 ... before finding it. From: Jacob Goense Sent: Friday, 10 February 2017 10:18 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Code bloat On 2017-02-08 17:25, Tony Finch wrote: > The previous CVS repo from the 386BSD+patchkit days was hidden away > because of old copyright worries, though some time after 2000 it became > available to most committers. (I have a copy in my home directory on > freefall.freebsd.org which I stashed away in 2007 because at that time > I > think there still wasn't a conveniently accessible copy.) Does that have eg. sys/kern/tty.c in it? Or is also missing piles of files? > It looks like after the uplift to SVN the two repositories were > combined, > so you can now see the 386BSD import at > https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67 Not without being butchered first. A lot of essential source files are missing from the start until they magically appear in the 4.4BSD-Lite upload. I'll take another look if I can make sense of how Lite was folded in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Fri Feb 10 00:44:15 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Thu, 9 Feb 2017 09:44:15 -0500 (EST) Subject: [TUHS] // comment in C++ Message-ID: <20170209144415.65AB418C11C@mercury.lcs.mit.edu> > From: Michael Kjorling > That wouldn't have anything to do with how ^@ is a somewhat common > representation of 000, would it? .. I've always kind of wondered where > that notation came from. Well, CTRL-<*> is usually just the <*> character with the high bits cleared. So, to have a printing representation of NULL, you have two character choices - SPACE, and '@'. Printing "^ " is not so hot, so "^@" is better. Also, if you look at an ASCII table, usually people just take the @-_ column, and use that, since every character in that column has a printing representation. The ' '-? column is missing the ' ', and `- is missing the DEL. So if you just take a CTRL character and set the 0100 bit, and print it as "^", you get something readable. (Note that CTRL-' ' _is_ usually used when one needs to _input_ a NUL character.) Noel From random832 at fastmail.com Fri Feb 10 00:49:03 2017 From: random832 at fastmail.com (Random832) Date: Thu, 09 Feb 2017 09:49:03 -0500 Subject: [TUHS] // comment in C++ In-Reply-To: <1486651054.1665917.875659504.05C3D685@webmail.messagingengine.com> References: <20170208224556.GG65698@eureka.lemis.com> <04c401d2825d$d0758da0$7160a8e0$@ronnatalie.com> <20170209121204.GJ5418@yeono.kjorling.se> <86inojsg6p.fsf@molnjunk.nocrew.org> <1486651054.1665917.875659504.05C3D685@webmail.messagingengine.com> Message-ID: <1486651743.1668079.875678360.741E7756@webmail.messagingengine.com> On Thu, Feb 9, 2017, at 09:37, Random832 wrote: > And for where ^? for DEL comes from, > In fact, this is exactly how the control key worked on early terminals I should clarify, these are two separate comments. Ctrl-? did *not* generate DEL on physical terminals (which typically had a dedicated key for it), from the documentation that I've read it seems those that allowed the combination at all tended to generate ^_. Which is something that persists in modern terminal emulators for Ctrl-/, though I think some do support Ctrl-? as DEL. From random832 at fastmail.com Fri Feb 10 00:55:48 2017 From: random832 at fastmail.com (Random832) Date: Thu, 09 Feb 2017 09:55:48 -0500 Subject: [TUHS] Unix stories In-Reply-To: <20170209134628.99Q--%steffen@sdaoden.eu> References: <5257291ca0a0e1d80c646cab730129d589c5d707@webmail.yaccman.com> <42922C34-342F-4E86-83E2-3618129139B2@tfeb.org> <20170103004959.GA29088@mcvoy.com> <20170104130434.NQFzLGpVU%steffen@sdaoden.eu> <1483538831.1573798.837053385.2EB8CAC9@webmail.messagingengine.com> <20170104162238.qUWzAcIu7%steffen@sdaoden.eu> <1483547711.1607300.837230857.4B111F27@webmail.messagingengine.com> <20170209134628.99Q--%steffen@sdaoden.eu> Message-ID: <1486652148.1670510.875683520.3DDF9622@webmail.messagingengine.com> On Thu, Feb 9, 2017, at 08:46, Steffen Nurpmeso wrote: > so now i really got this a few minute ago after adding negative > history number support (to count from history top): > > tty.c: In function 'c_history': > tty.c:4157:13: warning: operation on 'entry' may be undefined > [-Wsequence-point] > entry = isneg ? --entry : (siz_t)a_tty.tg_hist_size - entry; > ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > And in my opinion this is just plain terrible? I think it is > absolutely clear what i intend, there is not even a dereferenced > pointer involved, the lhv is either a register or if all fails > a stack location. I don't understand why i have to write > > if(isneg) > --entry; > else > entry = (siz_t)a_tty.tg_hist_size - entry; > > to get over this, it is exactly the same? What's wrong with entry = isneg ? entry-1 : (siz_t)a_tty.tg_hist_size - entry; Same number of characters (two more if you put spaces around the minus sign, but hardly a huge burden in any case). You're basically asking for the standard to carve out an exception for the cases, and precisely only those cases, where the meaning can be seen to be 100% unambiguous (i.e. that the two values being assigned to a variable are provably the same value, and there are no other reads) - which would limit it exclusively to the prefix operator (and assignment operators, I suppose, "x = x += 1" is as unambiguous as it is pointless), and only when there is no other expression involved except for the conditionals (you couldn't have "--entry + x", for example). From dugo at xs4all.nl Fri Feb 10 01:03:17 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Thu, 09 Feb 2017 16:03:17 +0100 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: On 2017-02-09 15:41, jsteve at superglobalmegacorp.com wrote: > I’m 99% sure this is that I took to take 0.1 to 0.1-p23 to 0.1-p24 > and used that to fill in the missing CVS from NetBSD 0.8 ... before > finding it. Looking at FreeBSD here. From jsteve at superglobalmegacorp.com Fri Feb 10 01:08:08 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Thu, 9 Feb 2017 23:08:08 +0800 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: <9F884E81-1A42-4F0D-9C1B-31F32DBDEC36@superglobalmegacorp.com> Oops sorry. Haven't gotten around to hunting that one down yet... I was always under the impression that it also diverged from pl24, then rebased from 4.4BSD Lite 2, post lawsuit... On February 9, 2017 11:03:17 PM GMT+08:00, Jacob Goense wrote: >On 2017-02-09 15:41, jsteve at superglobalmegacorp.com wrote: >> I’m 99% sure this is that I took to take 0.1 to 0.1-p23 to 0.1-p24 >> and used that to fill in the missing CVS from NetBSD 0.8 ... before >> finding it. > >Looking at FreeBSD here. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Fri Feb 10 01:30:35 2017 From: dot at dotat.at (Tony Finch) Date: Thu, 9 Feb 2017 15:30:35 +0000 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: Jacob Goense wrote: > On 2017-02-08 17:25, Tony Finch wrote: > > The previous CVS repo from the 386BSD+patchkit days was hidden away > > because of old copyright worries, though some time after 2000 it became > > available to most committers. (I have a copy in my home directory on > > freefall.freebsd.org which I stashed away in 2007 because at that time I > > think there still wasn't a conveniently accessible copy.) > > Does that have eg. sys/kern/tty.c in it? Or is also missing piles of files? Yes, rev 1.1 has a comment in the header * PATCHES MAGIC LEVEL PATCH THAT GOT US HERE * -------------------- ----- ---------------------- * CURRENT PATCH LEVEL: 3 00163 * -------------------- ----- ---------------------- * * 11 Dec 92 Williams Jolitz Fixed tty handling * 28 Nov 1991 Warren Toomey Cleaned up the use of COMPAT_43 * in the 386BSD kernel. * 27 May 93 Bruce Evans Sign Ext fix for TIOCSTI from the net * Kludge to hook in RTS/CTS flow control * Avoid sleeping on lbolt, it slows down * output unnecessarily. > > It looks like after the uplift to SVN the two repositories were combined, > > so you can now see the 386BSD import at > > https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67 > > Not without being butchered first. A lot of essential source files are missing > from the start until they magically appear in the 4.4BSD-Lite upload. Ah, I see you are right :-/ The early commits are not very easy to dig through because of a combination of broken-up commits and source control conversion artefacts, and SVN being incredibly slow. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Sole: Southeast 6 to gale 8, occasionally severe gale 9 at first, backing east 5 or 6 later. Very rough or high. Occasional rain. Good, occasionally moderate. From ron at ronnatalie.com Fri Feb 10 01:50:52 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Thu, 9 Feb 2017 10:50:52 -0500 Subject: [TUHS] ASCII and UNIX and Model 37 teletypes Message-ID: <055601d282ec$4b10f160$e132d420$@ronnatalie.com> DEL, sometimes labeled RUBOUT has a very important feature. It's all ones. When punching a paper tape, if you make a mistake you can mechanically backspace the tape (there's a button on the punch rather than the actual backspace key), you can then press RUBOUT which overpunches the incorrect character. Presumably, whatever system that this was designed for disregards those characters when encountered. Amusingly, we though the HERE IS key was just to generate leaders because none of our teletypes had the drum programmed. Later I found out that you could break the tabs on the drum and have HERE IS send a short string of characters. ^E (called ENQ or sometimes WRU ...for who are you) triggers this to be sent in response. To get back to the UNIX tie in, I actually had for years a Model 37 teletype. This was one of the few terminals that you didn't have to set the nl mode mapping for. It had a large key marked NEWLINE where RETURN usually is and sent ^J (\n) and responded to it the way UNIX expected. In addition it handles all the ESC-8 ESC-9 etc... codes that nroff sent by default without needing a filter. Mine was an ASR so it had the tape unit. It lacked the "greek box" that the one at JHU had to print greek characters after an ^N (shift in). The thing was amusing as it didn't turn on the motor until the modem came ready and when carrier detect was asserted a big green PROCEED light lit on the front. It was quaint, but when I finally got a higher speed modem, I switched back to using a CRT. The Model 37 was a screaming 150 baud. I finally "donated" it to RS who dumped the thing behind someone's car somewhere. From imp at bsdimp.com Fri Feb 10 02:14:36 2017 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Feb 2017 09:14:36 -0700 Subject: [TUHS] Code bloat In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: I thought someone had posted a github project to merge the history of all publicly available sources of unix. Ah, yes, here it is https://github.com/dspinellis/unix-history-repo Maybe that would be easier to follow than dealing with svn... I'll note that searching the TUHS archives throws all kinds of ugly errors: Failed to seek to properties located at 222966803301099891 for file number 8645 : Invalid argument Warner On Thu, Feb 9, 2017 at 8:30 AM, Tony Finch wrote: > Jacob Goense wrote: >> On 2017-02-08 17:25, Tony Finch wrote: >> > The previous CVS repo from the 386BSD+patchkit days was hidden away >> > because of old copyright worries, though some time after 2000 it became >> > available to most committers. (I have a copy in my home directory on >> > freefall.freebsd.org which I stashed away in 2007 because at that time I >> > think there still wasn't a conveniently accessible copy.) >> >> Does that have eg. sys/kern/tty.c in it? Or is also missing piles of files? > > Yes, rev 1.1 has a comment in the header > > * PATCHES MAGIC LEVEL PATCH THAT GOT US HERE > * -------------------- ----- ---------------------- > * CURRENT PATCH LEVEL: 3 00163 > * -------------------- ----- ---------------------- > * > * 11 Dec 92 Williams Jolitz Fixed tty handling > * 28 Nov 1991 Warren Toomey Cleaned up the use of COMPAT_43 > * in the 386BSD kernel. > * 27 May 93 Bruce Evans Sign Ext fix for TIOCSTI from the net > * Kludge to hook in RTS/CTS flow control > * Avoid sleeping on lbolt, it slows down > * output unnecessarily. > >> > It looks like after the uplift to SVN the two repositories were combined, >> > so you can now see the 386BSD import at >> > https://github.com/freebsd/freebsd/commit/f131f027b47937d651804c243cde86ec0bf87e67 >> >> Not without being butchered first. A lot of essential source files are missing >> from the start until they magically appear in the 4.4BSD-Lite upload. > > Ah, I see you are right :-/ The early commits are not very easy to dig > through because of a combination of broken-up commits and source control > conversion artefacts, and SVN being incredibly slow. > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > Sole: Southeast 6 to gale 8, occasionally severe gale 9 at first, backing east > 5 or 6 later. Very rough or high. Occasional rain. Good, occasionally > moderate. From lm at mcvoy.com Fri Feb 10 02:36:58 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Feb 2017 08:36:58 -0800 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: <20170209163658.GO25691@mcvoy.com> > The best one seems to have been the 3Com stack, which puts IP in the > kernel and TCP in a daemon. By the way, this implementation is also > where SLIP seems to have originated. As much as I love all the nostalgia, and as cool as SLIP was, if I never have to experience the pain of trying to run TCP/IP over a modem again, I'll be happy. For me, SLIP was just not worth it. Too much overhead when bandwidth was too precious. A dial up terminal emulator was a better answer in my experience. Don't get me wrong, SLIP was cool. Modems were slow. From imp at bsdimp.com Fri Feb 10 02:42:09 2017 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Feb 2017 09:42:09 -0700 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <20170209163658.GO25691@mcvoy.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <20170209163658.GO25691@mcvoy.com> Message-ID: On Thu, Feb 9, 2017 at 9:36 AM, Larry McVoy wrote: >> The best one seems to have been the 3Com stack, which puts IP in the >> kernel and TCP in a daemon. By the way, this implementation is also >> where SLIP seems to have originated. > > As much as I love all the nostalgia, and as cool as SLIP was, if I never > have to experience the pain of trying to run TCP/IP over a modem again, > I'll be happy. For me, SLIP was just not worth it. Too much overhead > when bandwidth was too precious. A dial up terminal emulator was a > better answer in my experience. > > Don't get me wrong, SLIP was cool. Modems were slow. Let's not forget the latency. 128ms of latency over modems was awesomely low... That changed relatively little, even as the speeds went from 1200 baud up to 57.6k. While I am nostalgic for my early coding days on a 1200 baud video screen and a 300 baud printer, I do not miss the speed or the latency issues... Warner From lm at mcvoy.com Fri Feb 10 02:49:53 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Feb 2017 08:49:53 -0800 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <20170208025538.GE65698@eureka.lemis.com> <20170209163658.GO25691@mcvoy.com> Message-ID: <20170209164953.GQ25691@mcvoy.com> On Thu, Feb 09, 2017 at 09:42:09AM -0700, Warner Losh wrote: > On Thu, Feb 9, 2017 at 9:36 AM, Larry McVoy wrote: > >> The best one seems to have been the 3Com stack, which puts IP in the > >> kernel and TCP in a daemon. By the way, this implementation is also > >> where SLIP seems to have originated. > > > > As much as I love all the nostalgia, and as cool as SLIP was, if I never > > have to experience the pain of trying to run TCP/IP over a modem again, > > I'll be happy. For me, SLIP was just not worth it. Too much overhead > > when bandwidth was too precious. A dial up terminal emulator was a > > better answer in my experience. > > > > Don't get me wrong, SLIP was cool. Modems were slow. > > Let's not forget the latency. 128ms of latency over modems was > awesomely low... That changed relatively little, even as the speeds > went from 1200 baud up to 57.6k. > > While I am nostalgic for my early coding days on a 1200 baud video > screen and a 300 baud printer, I do not miss the speed or the latency > issues... Exactly. I live in the Santa Cruz mountains, which is awesome (well, mostly, right now we're having tons of mudlsides, too much rain). I'm quite remote, we have a mountain lion that comes through here nightly (I know because I lost a dog to it and they showed me the radio collar tracking, on a map it looks like someone took a pencil and scribbled back and forth as hard as they could through our place). In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 (Google's dns server). Go wireless. It's pretty remarkable to be here and have decent net connectivity. I do not yearn for the days of SLIP. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From steffen at sdaoden.eu Fri Feb 10 02:51:31 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 17:51:31 +0100 Subject: [TUHS] // comment in C++ In-Reply-To: <20170209144415.65AB418C11C@mercury.lcs.mit.edu> References: <20170209144415.65AB418C11C@mercury.lcs.mit.edu> Message-ID: <20170209165131.r156l%steffen@sdaoden.eu> jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: |> From: Michael Kjorling |> That wouldn't have anything to do with how ^@ is a somewhat common |> representation of 000, would it? .. I've always kind of wondered where |> that notation came from. | |Well, CTRL-<*> is usually just the <*> character with the high bits \ |cleared. |So, to have a printing representation of NULL, you have two character \ |choices |- SPACE, and '@'. Printing "^ " is not so hot, so "^@" is better. | |Also, if you look at an ASCII table, usually people just take the @-_ \ |column, |and use that, since every character in that column has a printing |representation. The ' '-? column is missing the ' ', and `- is missing |the DEL. So if you just take a CTRL character and set the 0100 bit, \ |and print |it as "^", you get something readable. You xor it via toupper(X)^0x40, yes of course. My code is right, it is just the manual that is incomplete or even false: i will clarify it. It is just that i know that many people which use free software don't know what a xor operation is, at least without looking into Wikipedia. (And even though i use it frequently myself, that is often contaminated by politics, just yesterday i had a hard time with some paragraphs on the German Wikipedia page on intellectual properties.) |(Note that CTRL-' ' _is_ usually used when one needs to _input_ a NUL |character.) | | Noel --steffen From pechter at gmail.com Fri Feb 10 02:58:31 2017 From: pechter at gmail.com (William Pechter) Date: Thu, 9 Feb 2017 11:58:31 -0500 Subject: [TUHS] Code bloat In-Reply-To: <20170209163658.GO25691@mcvoy.com> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <20170209163658.GO25691@mcvoy.com> Message-ID: <090cfaa0-f2da-e16d-1e96-8776b8db4e45@gmail.com> Larry McVoy wrote: >> The best one seems to have been the 3Com stack, which puts IP in the >> kernel and TCP in a daemon. By the way, this implementation is also >> where SLIP seems to have originated. > As much as I love all the nostalgia, and as cool as SLIP was, if I never > have to experience the pain of trying to run TCP/IP over a modem again, > I'll be happy. For me, SLIP was just not worth it. Too much overhead > when bandwidth was too precious. A dial up terminal emulator was a > better answer in my experience. > > Don't get me wrong, SLIP was cool. Modems were slow. Back in the day when slip was just starting to get traction (and before PPP) I was happy with a dial-up connection to read news and work remotely and a 9600 baud telebit for UUCP file transfer to home for work that could be sent home and done off-line. Bill -- Digital had it then. Don't you wish you could buy it now! pechter-at-gmail.com http://xkcd.com/705/ From steffen at sdaoden.eu Fri Feb 10 03:15:59 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 18:15:59 +0100 Subject: [TUHS] Unix stories In-Reply-To: <1486652148.1670510.875683520.3DDF9622@webmail.messagingengine.com> References: <5257291ca0a0e1d80c646cab730129d589c5d707@webmail.yaccman.com> <42922C34-342F-4E86-83E2-3618129139B2@tfeb.org> <20170103004959.GA29088@mcvoy.com> <20170104130434.NQFzLGpVU%steffen@sdaoden.eu> <1483538831.1573798.837053385.2EB8CAC9@webmail.messagingengine.com> <20170104162238.qUWzAcIu7%steffen@sdaoden.eu> <1483547711.1607300.837230857.4B111F27@webmail.messagingengine.com> <20170209134628.99Q--%steffen@sdaoden.eu> <1486652148.1670510.875683520.3DDF9622@webmail.messagingengine.com> Message-ID: <20170209171559.K5qcB%steffen@sdaoden.eu> Random832 wrote: |On Thu, Feb 9, 2017, at 08:46, Steffen Nurpmeso wrote: |> so now i really got this a few minute ago after adding negative |> history number support (to count from history top): |> |> tty.c: In function 'c_history': |> tty.c:4157:13: warning: operation on 'entry' may be undefined |> [-Wsequence-point] |> entry = isneg ? --entry : (siz_t)a_tty.tg_hist_size - entry; |> ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |> |> And in my opinion this is just plain terrible? I think it is ... |What's wrong with entry = isneg ? entry-1 : (siz_t)a_tty.tg_hist_size - |entry; Another example: spam.c: In function '_spam_rate2score': spam.c:1137:38: warning: to be safe all intermediate pointers in cast from 'char **' to 'const char **' must be 'const' qualified [-Wcast-qual] ids = n_idec_ui32_cp(&m, buf, 10, (char const**)&buf); To satisfy we need in fact a temporary variable, since you cannot apply cast operators on non-lvalues: spam.c: In function '_spam_rate2score': spam.c:1137:38: error: lvalue required as unary '&' operand ids = n_idec_ui32_cp(&m, buf, 10, &(char const*)buf); And yeah, you need to do something about: spam.c: In function '_spam_rate2score': spam.c:1137:38: warning: passing argument 6 of 'n_idec_buf' from incompatible pointer type [-Wincompatible-pointer-types] ids = n_idec_ui32_cp(&m, buf, 10, &buf); ^ nailfuns.h:319:63: note: in definition of macro 'n_idec_ui32_cp' n_idec_buf(RP, CBP, UIZ_MAX, B, (n_IDEC_MODE_LIMIT_32BIT), CLP) ^~~ nailfuns.h:303:22: note: expected 'const char **' but argument is of type 'char **' FL enum n_idec_state n_idec_buf(void *resp, char const *cbuf, uiz_t clen, I would buy that the other way around, i.e., if "buf" would be constant and the function expects something non-constant. |Same number of characters (two more if you put spaces around the minus |sign, but hardly a huge burden in any case). Ok you're right, this special case is not a huge burden. With a good font l-1-i may also be no problem, but could. I mean, some people even use garbage collectors because they are afraid of memory holes and such, and then such l-1-i problems which are known to outperform human visual capabilities except at eleven thirty in the morning are good to go? This! Come on. |You're basically asking for the standard to carve out an exception for |the cases, and precisely only those cases, where the meaning can be seen |to be 100% unambiguous (i.e. that the two values being assigned to a |variable are provably the same value, and there are no other reads) - |which would limit it exclusively to the prefix operator (and assignment |operators, I suppose, "x = x += 1" is as unambiguous as it is |pointless), and only when there is no other expression involved except |for the conditionals (you couldn't have "--entry + x", for example). Oh yes, i do. To me the above basically looks like a reassignment, a creation of a completely new variable. The value is assigned after it has been computed. The compiler may be clever enough to realize that in certain cases this can end up as something like "inc eax" or the like. But all this surely off-topic. --steffen From steffen at sdaoden.eu Fri Feb 10 03:24:12 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 18:24:12 +0100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <20170209164953.GQ25691@mcvoy.com> References: <20170208025538.GE65698@eureka.lemis.com> <20170209163658.GO25691@mcvoy.com> <20170209164953.GQ25691@mcvoy.com> Message-ID: <20170209172412.se1JH%steffen@sdaoden.eu> Larry McVoy wrote: |Exactly. I live in the Santa Cruz mountains, which is awesome (well, ... |quite remote, we have a mountain lion that comes through here nightly That is pretty cool! Some are still alive!! |(I know because I lost a dog to it and they showed me the radio collar That is .. not so cool. There is quite some sympathy from Darmstadt, Germany. (But, mind you, these are all street pissers!) |tracking, on a map it looks like someone took a pencil and scribbled |back and forth as hard as they could through our place). | |In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 |(Google's dns server). Go wireless. It's pretty remarkable to be here |and have decent net connectivity. America is first world. This statement declassifies most of Germanies countryside as second world, at maximum. I for one am happy if i get a constant stream equivalent to ISDN. In the outer region of a city in one of the richest parts of Germany, that is. --steffen From lm at mcvoy.com Fri Feb 10 03:27:52 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Feb 2017 09:27:52 -0800 Subject: [TUHS] offtopic: broadband (redirect from bloat) In-Reply-To: <20170209172412.se1JH%steffen@sdaoden.eu> References: <20170209163658.GO25691@mcvoy.com> <20170209164953.GQ25691@mcvoy.com> <20170209172412.se1JH%steffen@sdaoden.eu> Message-ID: <20170209172752.GY25691@mcvoy.com> On Thu, Feb 09, 2017 at 06:24:12PM +0100, Steffen Nurpmeso wrote: > Larry McVoy wrote: > |Exactly. I live in the Santa Cruz mountains, which is awesome (well, > ... > |quite remote, we have a mountain lion that comes through here nightly > > That is pretty cool! Some are still alive!! Good lord, tons and tons are alive. I wanted the one that got my dog moved and Fish & Game flat out told me there was no place to move it that didn't already have other mountain lions. > |In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 > |(Google's dns server). Go wireless. It's pretty remarkable to be here > |and have decent net connectivity. > > America is first world. This statement declassifies most of > Germanies countryside as second world, at maximum. I for one am > happy if i get a constant stream equivalent to ISDN. In the outer > region of a city in one of the richest parts of Germany, that is. Really? I thought that America was trailing in broadband. And in Germany? I'm stunned, usually we're looking at Germany and sighing about how much better run it is than our country. You guys are very efficient. How is it possible that you have crappy internet, are you sure that's normal? From steffen at sdaoden.eu Fri Feb 10 05:05:34 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 20:05:34 +0100 Subject: [TUHS] offtopic: broadband (redirect from bloat) In-Reply-To: <20170209172752.GY25691@mcvoy.com> References: <20170209163658.GO25691@mcvoy.com> <20170209164953.GQ25691@mcvoy.com> <20170209172412.se1JH%steffen@sdaoden.eu> <20170209172752.GY25691@mcvoy.com> Message-ID: <20170209190534.UrJ6L%steffen@sdaoden.eu> Larry McVoy wrote: |On Thu, Feb 09, 2017 at 06:24:12PM +0100, Steffen Nurpmeso wrote: |> Larry McVoy wrote: |>|Exactly. I live in the Santa Cruz mountains, which is awesome (well, |> ... |>|quite remote, we have a mountain lion that comes through here nightly |> |> That is pretty cool! Some are still alive!! | |Good lord, tons and tons are alive. I wanted the one that got my dog |moved and Fish & Game flat out told me there was no place to move it |that didn't already have other mountain lions. At least it didn't get you. Very frightening. It surely will not help you or your dog, we even loose our last little wildcats these days... For cameras of the white some african bushmen steal fresh meat directly from Lions, which can be fooled so much, completely bewildered. Also that young French girl which simply talked to all animals and became accepted, in Africa that is, i forgot her name. Your dog did not know all that.. i am really sorry. |>|In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 |>|(Google's dns server). Go wireless. It's pretty remarkable to be here |>|and have decent net connectivity. |> |> America is first world. This statement declassifies most of |> Germanies countryside as second world, at maximum. I for one am |> happy if i get a constant stream equivalent to ISDN. In the outer |> region of a city in one of the richest parts of Germany, that is. | |Really? I thought that America was trailing in broadband. And in |Germany? I'm stunned, usually we're looking at Germany and sighing |about how much better run it is than our country. You guys are very |efficient. How is it possible that you have crappy internet, are you |sure that's normal? Clean Diesel is only a paper moon. To quote Monty Python, and that piece of shit that life is, if you look at it. [Smile] But this is an everlasting story it seems, already at ISDN times some villages connected themselves via privately funded fast point-to-point wireless, for example. Just recently (one or two years ago) a complete region not more than about 10 kilometres away (eastwards) from the "hot" north-south line Frankfurt / Darmstadt / Mannheim|Ludwigshafen / Heidelberg had to use private money in order to become connected to i think DSL. Must be two years, i remember seeing a lot of advertisment posters plastered all over the region last summer, where the telecom companies now offered pretty cheap service even in this region! But running on environment payed by people has always been the base, anyway. But that on top of normal taxes, that makes you feel second-class it seems to me: votes show up which suggest just that. Have i told this already, by the way? Uh, i hope not. All this is nothing against the worldwide phenomenon of urbanisation, of course. Here we have villages which ran out of doctors, and even bakeries. Very much of a problem given that many villages consist only of old people. In Spain and Italy many small villages even turned to ghost towns. Well, so it is. And at least most of us still have enough freshwater for plants, animals and humans. How about that, where will i get my almonds from if California has no more water nor these brown-skinned farm workers? I am also in fear for this excellent organic olive oil from Crete, it will become a desert hopefully not to soon. Oh what a life you had, with those six meter Cadillacs without a roof, and then the Californian sun. grrrrrrrr. Hm. Wireless will get better (i am ~550 msec away from my -- right now), and lesser people can steal copper cable from out of the grounds. What will they do. --steffen From steffen at sdaoden.eu Fri Feb 10 05:36:44 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 09 Feb 2017 20:36:44 +0100 Subject: [TUHS] // comment in C++ In-Reply-To: <20170209165131.r156l%steffen@sdaoden.eu> References: <20170209144415.65AB418C11C@mercury.lcs.mit.edu> <20170209165131.r156l%steffen@sdaoden.eu> Message-ID: <20170209193644.T3jtw%steffen@sdaoden.eu> Steffen Nurpmeso wrote: |jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: ||> From: Michael Kjorling ... |You xor it via toupper(X)^0x40, yes of course. My code is right, To be exact, it is c = upperconv(c2) ^ 0x40; if((ui8_t)c > 0x1F && c != 0x7F){ /* ASCII C0: 0..1F, 7F */ and converts from \cX notation to the actual control character. That is, we do test the result in advance, which i wanted to add. Ciao. --steffen From clemc at ccc.com Fri Feb 10 05:50:37 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 9 Feb 2017 14:50:37 -0500 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> Message-ID: On Thu, Feb 9, 2017 at 4:19 AM, Paul Ruizendaal wrote: > > The best one seems to have been the 3Com stack, which puts IP in the > kernel and TCP in a daemon. ​This is true.​ > By the way, this implementation is also > ​ ​ > where SLIP seems to have originated. ​hmmm... I'm not so sure I see that leap/where you came to that conclusion. I'm guessing you are thinking same from the picture on page 37 where Bob shows an RS-232 driver in the architectural diagram. FYI: The code base came with a 3Cxxx driver for their Ethernet board only and as I said, the Steve Glaser wrote the second driver for the Unibus HyperChannel and I think there was a driver for the Xerox 3Meg ethernet controller but I don't remember ever seeing it in the source kit. FYI: If my memory serves me, the first SLIP implementations for any IP stack were done I thought for some reason at Harvard with some hacks to the BBN/MIT tcp stack on the DZ drivers as an alternative to the Berknet stack (not IP). FYI: Berknet was very low costs, 9600baud serial point to point to links, primarily for moving mail and small files, we can take this off line if you need to know more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corey at lod.com Fri Feb 10 05:54:57 2017 From: corey at lod.com (Corey Lindsly) Date: Thu, 9 Feb 2017 11:54:57 -0800 (PST) Subject: [TUHS] Code bloat (was: How Unix brings people together, In-Reply-To: <20170209164953.GQ25691@mcvoy.com> Message-ID: <20170209195457.373C940B9@lod.com> > In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 > (Google's dns server). Go wireless. It's pretty remarkable to be here > and have decent net connectivity. > > I do not yearn for the days of SLIP. > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer directly with Google and I get 4-5ms. Do share. [root at daytona ~]# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=5.43 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=5.39 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=5.43 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=5.02 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=5.30 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=5.35 ms Pittock7206A#trace 8.8.8.8 Type escape sequence to abort. Tracing the route to 8.8.8.8 1 198.32.195.34 4 msec 4 msec 4 msec 2 108.170.245.113 [AS 15169] 4 msec 108.170.245.97 [AS 15169] 8 msec 4 msec 3 209.85.246.217 [AS 15169] 4 msec 209.85.246.219 [AS 15169] 4 msec 209.85.245.67 [AS 15169] 8 msec 4 8.8.8.8 [AS 15169] 4 msec 4 msec 4 msec Pittock7206A# --corey From pechter at gmail.com Fri Feb 10 06:08:04 2017 From: pechter at gmail.com (pechter at gmail.com) Date: Thu, 9 Feb 2017 15:08:04 -0500 Subject: [TUHS] Code bloat (was: How Unix brings people together, In-Reply-To: <20170209195457.373C940B9@lod.com> References: <20170209164953.GQ25691@mcvoy.com> <20170209195457.373C940B9@lod.com> Message-ID: 7.9 ms to my wifi in FIOS in NJ. It's not the ping time... It's the throughput that is often lacking in real world use. No matter the pipe size. Bill Sent from my android device. -----Original Message----- From: Corey Lindsly To: Larry McVoy Cc: TUHS main list Sent: Thu, 09 Feb 2017 14:55 Subject: Re: [TUHS] Code bloat (was: How Unix brings people together, > In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 > (Google's dns server). Go wireless. It's pretty remarkable to be here > and have decent net connectivity. > > I do not yearn for the days of SLIP. > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer directly with Google and I get 4-5ms. Do share. [root at daytona ~]# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=5.43 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=5.39 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=5.43 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=5.02 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=5.30 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=5.35 ms Pittock7206A#trace 8.8.8.8 Type escape sequence to abort. Tracing the route to 8.8.8.8 1 198.32.195.34 4 msec 4 msec 4 msec 2 108.170.245.113 [AS 15169] 4 msec 108.170.245.97 [AS 15169] 8 msec 4 msec 3 209.85.246.217 [AS 15169] 4 msec 209.85.246.219 [AS 15169] 4 msec 209.85.245.67 [AS 15169] 8 msec 4 8.8.8.8 [AS 15169] 4 msec 4 msec 4 msec Pittock7206A# --corey -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Fri Feb 10 06:30:05 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 9 Feb 2017 15:30:05 -0500 Subject: [TUHS] Code bloat (was: How Unix brings people together, In-Reply-To: <20170209195457.373C940B9@lod.com> References: <20170209195457.373C940B9@lod.com> Message-ID: WAY off-topic. Sorry. On 2/9/2017 2:54 PM, Corey Lindsly wrote: > 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer > directly with Google and I get 4-5ms. Do share. > > Two fiber connections here to Verizon FIOS, one business, one residential: FIOS business fiber 50M/50M in New York, Long Island to be exact, low 4's, high 3's: root at hnet1:/data/tmp# ping -s 8.8.8.8 PING 8.8.8.8: 56 data bytes 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=0. time=4.167 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=1. time=3.871 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=2. time=4.062 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=3. time=4.093 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=4. time=4.050 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=5. time=3.900 ms root at hnet1:/data/tmp# traceroute -t 2 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets 1 () 0.598 ms 0.615 ms 0.559 ms 2 B3384.NYCMNY-LCR-22.verizon-gni.net (100.41.217.224) 2.884 ms 3.137 ms 3.903 ms 3 * * * 4 0.ae11.GW13.NYC1.ALTER.NET (140.222.234.191) 2.719 ms 0.ae13.GW13.NYC1.ALTER.NET (140.222.234.193) 2.560 ms 0.ae11.GW13.NYC1.ALTER.NET (140.222.234.191) 2.377 ms 5 google-gw.customer.alter.net (204.148.18.206) 62.332 ms 56.885 ms 55.203 ms 6 209.85.247.33 (209.85.247.33) 2.885 ms 2.771 ms 2.735 ms 7 108.170.233.235 (108.170.233.235) 2.936 ms 108.170.235.13 (108.170.235.13) 3.490 ms 108.170.233.233 (108.170.233.233) 3.152 ms 8 google-public-dns-a.google.com (8.8.8.8) 3.495 ms * * FIOS residential 150/150M, low 3's: medusa# ping -s 8.8.8.8 PING 8.8.8.8: 56 data bytes 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=0. time=3.497 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=1. time=3.286 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=2. time=3.368 ms 64 bytes from google-public-dns-a.google.com (8.8.8.8): icmp_seq=3. time=3.315 ms Traceroute not available without altering my Cisco ASA config. I think it's entirely possible that 8.8.8.8 is more than one host, and depending on geographical location you're being routed to any of a number of actual hosts ;) Speed of light from New York to California is approximately 1.3ms. I can't imagine all these routers don't add SOMETHING to do the latency... so I can't see how I can ping a California hosts in the low 3 ms area. From schily at schily.net Fri Feb 10 07:02:51 2017 From: schily at schily.net (Joerg Schilling) Date: Thu, 09 Feb 2017 22:02:51 +0100 Subject: [TUHS] Code bloat (was: How Unix brings people together, or it's a small...) In-Reply-To: <20170209164953.GQ25691@mcvoy.com> References: <20170208025538.GE65698@eureka.lemis.com> <20170209163658.GO25691@mcvoy.com> <20170209164953.GQ25691@mcvoy.com> Message-ID: <589cd8fb.vc2jul9CHdiubSCD%schily@schily.net> Larry McVoy wrote: > In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 > (Google's dns server). Go wireless. It's pretty remarkable to be here > and have decent net connectivity. Is this a one way time or a ping roundtrip time? What kind of technology is this based on? My VDSL connection offers a ping round trip time of 15ms to the next hop. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From lm at mcvoy.com Fri Feb 10 07:06:26 2017 From: lm at mcvoy.com (Larry McVoy) Date: Thu, 9 Feb 2017 13:06:26 -0800 Subject: [TUHS] Code bloat (was: How Unix brings people together, In-Reply-To: <20170209195457.373C940B9@lod.com> References: <20170209164953.GQ25691@mcvoy.com> <20170209195457.373C940B9@lod.com> Message-ID: <20170209210626.GB22105@mcvoy.com> > 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer > directly with Google and I get 4-5ms. Do share. My kids are home and watching netflix or something so right now it is 4-50ms, just varies. When I said 3, it was 3.something, I didn't really look. Here's some pings (couple of 2.somethings in there): 64 bytes from 8.8.8.8: icmp_seq=60 ttl=57 time=3.67 ms 64 bytes from 8.8.8.8: icmp_seq=61 ttl=57 time=37.6 ms 64 bytes from 8.8.8.8: icmp_seq=62 ttl=57 time=3.88 ms 64 bytes from 8.8.8.8: icmp_seq=63 ttl=57 time=3.40 ms 64 bytes from 8.8.8.8: icmp_seq=64 ttl=57 time=3.81 ms 64 bytes from 8.8.8.8: icmp_seq=65 ttl=57 time=11.6 ms 64 bytes from 8.8.8.8: icmp_seq=66 ttl=57 time=48.4 ms 64 bytes from 8.8.8.8: icmp_seq=67 ttl=57 time=14.6 ms 64 bytes from 8.8.8.8: icmp_seq=68 ttl=57 time=2.85 ms 64 bytes from 8.8.8.8: icmp_seq=69 ttl=57 time=3.19 ms 64 bytes from 8.8.8.8: icmp_seq=70 ttl=57 time=3.78 ms 64 bytes from 8.8.8.8: icmp_seq=71 ttl=57 time=2.94 ms traceroute: My traceroute [v0.86] slovax.mcvoy.com (0.0.0.0) Thu Feb 9 13:05:52 2017 Resolver: Received error response 2. (server failure)er of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. pf-lm.mcvoy.com 0.0% 9 0.2 0.2 0.2 0.2 0.0 2. 192.169.23.249.static.etheric.ne 0.0% 9 0.5 0.6 0.4 0.9 0.0 3. 208.74.178.193.static.etheric.ne 0.0% 9 6.2 15.6 3.9 52.8 16.6 4. 10.10.112.1 0.0% 9 2.3 8.6 1.8 28.3 8.0 5. 10.11.109.1 0.0% 9 2.7 5.4 2.5 16.5 4.7 6. 10.11.110.6 0.0% 8 9.8 12.0 3.0 36.0 10.7 7. eqixsj-google-gige.google.com 0.0% 8 7.3 8.0 2.8 27.3 7.8 8. 108.170.242.81 0.0% 8 5.9 5.5 3.1 10.4 2.2 9. 216.239.49.93 0.0% 8 7.8 9.2 3.6 22.6 6.7 10. google-public-dns-a.google.com 0.0% 8 4.0 8.1 3.3 18.3 4.9 From bqt at update.uu.se Fri Feb 10 07:13:06 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Thu, 9 Feb 2017 22:13:06 +0100 Subject: [TUHS] Ping times (was: Code bloat) In-Reply-To: References: Message-ID: <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se> On 2017-02-09 20:55, corey at lod.com (Corey Lindsly) wrote: > >> In spite of that, I'm typing away to you all, I'm 3ms away from 8.8.8.8 >> (Google's dns server). Go wireless. It's pretty remarkable to be here >> and have decent net connectivity. >> >> I do not yearn for the days of SLIP. >> -- >> --- >> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > 3ms? Really? I'm impressed, and I'd like to see your traceroute. We peer > directly with Google and I get 4-5ms. Do share. Meh. From Uppsala in Sweden I seem to have about 2ms ping time to 8.8.8.8... Psilocybe:update/bqt> ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_req=1 ttl=56 time=2.10 ms 64 bytes from 8.8.8.8: icmp_req=2 ttl=56 time=1.93 ms 64 bytes from 8.8.8.8: icmp_req=3 ttl=56 time=2.05 ms 64 bytes from 8.8.8.8: icmp_req=4 ttl=56 time=1.89 ms 64 bytes from 8.8.8.8: icmp_req=5 ttl=56 time=2.02 ms 64 bytes from 8.8.8.8: icmp_req=6 ttl=56 time=2.05 ms 64 bytes from 8.8.8.8: icmp_req=7 ttl=56 time=2.00 ms 64 bytes from 8.8.8.8: icmp_req=8 ttl=56 time=1.97 ms 64 bytes from 8.8.8.8: icmp_req=9 ttl=56 time=2.03 ms 64 bytes from 8.8.8.8: icmp_req=10 ttl=56 time=2.10 ms ^C --- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9011ms rtt min/avg/max/mdev = 1.894/2.020/2.108/0.067 ms Psilocybe:update/bqt> traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 r1.n.it.uu.se (130.238.19.254) 1.986 ms 2.324 ms 2.717 ms 2 l-uu-1-b1.uu.se (130.238.6.251) 0.288 ms 0.680 ms 0.646 ms 3 uu-r1.sunet.se (130.242.6.148) 0.686 ms 0.685 ms 0.673 ms 4 uppsala-upa-r1.sunet.se (130.242.4.138) 0.672 ms 0.661 ms 0.657 ms 5 stockholm-fre-r1.sunet.se (130.242.4.26) 3.503 ms 3.468 ms 3.483 ms 6 se-fre.nordu.net (109.105.102.9) 24.456 ms 24.532 ms 24.153 ms 7 se-kst2.nordu.net (109.105.97.27) 1.934 ms 1.902 ms 1.891 ms 8 as15169-te-tc1.sthix.net (192.121.80.47) 2.204 ms 2.189 ms 72.14.196.42 (72.14.196.42) 1.872 ms 9 216.239.40.29 (216.239.40.29) 1.862 ms 1.941 ms 216.239.40.27 (216.239.40.27) 1.995 ms 10 209.85.251.233 (209.85.251.233) 2.398 ms 209.85.245.61 (209.85.245.61) 2.778 ms 72.14.234.85 (72.14.234.85) 2.385 ms 11 google-public-dns-a.google.com (8.8.8.8) 2.372 ms 2.366 ms 2.337 ms Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From doug at cs.dartmouth.edu Fri Feb 10 07:14:30 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Thu, 09 Feb 2017 16:14:30 -0500 Subject: [TUHS] // comment in C++ Message-ID: <201702092114.v19LEUgJ091850@tahoe.cs.Dartmouth.EDU> With no offense intended, I can't help noting the irony of the following paragraph appearing in a message in the company of others that address Unix "bloat". >'\cX' A mechanism that allows usage of the non-printable > (ASCII and compatible) control codes 0 to 31: to cre- > ate the printable representation of a control code the > numeric value 64 is added, and the resulting ASCII > character set code point is then printed, e.g., BEL is > '7 + 64 = 71 = G'. Whereas historically circumflex > notation has often been used for visualization pur- > poses of control codes, e.g., '^G', the reverse > solidus notation has been standardized: '\cG'. Some > control codes also have standardized (ISO 10646, ISO > C) alias representations, as shown above (e.g., '\a', > '\n', '\t'): whenever such an alias exists S-nail will > use it for display purposes. The control code NUL > ('\c@') ends argument processing without producing > further output. Except for the ISO citations, this paragraph says the same thing more succinctly. '\cX' represents a nonprintable character Y in terms of the printable character X whose binary code is obtained by adding 0x40 (decimal 64) to that for Y. (In some historical contexts, '^' plays the role of '\c'.) Alternative standard representations for certain nonprinting characters, e.g. '\a', '\n', '\t' above, are preferred by S-nail. '\c@' (NUL) serves as a string terminator regardless of following characters. And this version, 1/3 the length of the original, tells all one really needs to know. '\cX' represents a nonprintable character Y in terms of the printable character X whose binary code is obtained by adding 0x40 (decimal 64) to that for Y. '\c@' (NUL) serves as a string terminator regardless of following characters. Doug] From dave at horsfall.org Fri Feb 10 07:56:52 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 10 Feb 2017 08:56:52 +1100 (EST) Subject: [TUHS] // comment in C++ In-Reply-To: <20170209115922.GH5418@yeono.kjorling.se> References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: On Thu, 9 Feb 2017, Michael Kjörling wrote: > I didn't know that // was now accepted to begin a comment in C, but I > strongly suspect that any compiler modern enough to know about that will > know just as well about #if 0. // isn't in ANSI C, but I've been using it for years on quite a few platforms (I see that even M$ supports it); I don't know where I first saw it. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Fri Feb 10 08:29:23 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 10 Feb 2017 09:29:23 +1100 (EST) Subject: [TUHS] ASCII and UNIX and Model 37 teletypes In-Reply-To: <055601d282ec$4b10f160$e132d420$@ronnatalie.com> References: <055601d282ec$4b10f160$e132d420$@ronnatalie.com> Message-ID: On Thu, 9 Feb 2017, Ron Natalie wrote: > Amusingly, we though the HERE IS key was just to generate leaders > because none of our teletypes had the drum programmed. Later I found > out that you could break the tabs on the drum and have HERE IS send a > short string of characters. ^E (called ENQ or sometimes WRU ...for who > are you) triggers this to be sent in response. Quite common in the Amateur RTTY (radio teletype) world. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From schily at schily.net Fri Feb 10 08:48:36 2017 From: schily at schily.net (Joerg Schilling) Date: Thu, 09 Feb 2017 23:48:36 +0100 Subject: [TUHS] offtopic: broadband (redirect from bloat) In-Reply-To: <20170209172752.GY25691@mcvoy.com> References: <20170209163658.GO25691@mcvoy.com> <20170209164953.GQ25691@mcvoy.com> <20170209172412.se1JH%steffen@sdaoden.eu> <20170209172752.GY25691@mcvoy.com> Message-ID: <589cf1c4.kBD9YOKLENXfOL4u%schily@schily.net> Larry McVoy wrote: > > America is first world. This statement declassifies most of > > Germanies countryside as second world, at maximum. I for one am > > happy if i get a constant stream equivalent to ISDN. In the outer > > region of a city in one of the richest parts of Germany, that is. > > Really? I thought that America was trailing in broadband. And in > Germany? I'm stunned, usually we're looking at Germany and sighing > about how much better run it is than our country. You guys are very > efficient. How is it possible that you have crappy internet, are you > sure that's normal? What technology is available depends on where you are located. Around 1980, I designed and build a 300 Baud modem and used it together with a VT50a (12x80 uppercase only) from home. Then in 1991 we designed and build an ISDN adaptor for a Sun-3/50 with some friends (I had plenty of them from H.Berthold AG at that time). We installed some of them in the TU-Berlin and this way could use the internet from home. I got my own ISDN at home in 1992 and switched from DSL to VDSL in march 2008. >From an offer from German Telekom, I could get ADSL with 16Mbit even in my weekend house 60 km from the center of Berlin. The property is in a nature conservation area. 5km from this place, wolves have been seen..... German Telekom will shut down ISDN in Germany to the end of this year and my ISDN connection has been converted into SIP two months ago... But hey, on November 12 1877, the worlds first phone company started their services in Berlin and in 1923 the first auto-dial phone system opened in Berlin. I am not sure where Steffen exactly lives and why he has problems. What is hard to get and expensive (iff) in Germany is internet over optical. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From schily at schily.net Fri Feb 10 09:03:59 2017 From: schily at schily.net (Joerg Schilling) Date: Fri, 10 Feb 2017 00:03:59 +0100 Subject: [TUHS] Ping times (was: Code bloat) In-Reply-To: <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se> References: <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se> Message-ID: <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net> Johnny Billquist wrote: > Meh. From Uppsala in Sweden I seem to have about 2ms ping time to 8.8.8.8... > > Psilocybe:update/bqt> ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. > 64 bytes from 8.8.8.8: icmp_req=1 ttl=56 time=2.10 ms You seem to live in a location where the light speed is higher than usual ;-) 1ms = 300 km in my area. Berlin <-> SF is aprox. 9100 km Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From bqt at update.uu.se Fri Feb 10 09:09:03 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 10 Feb 2017 00:09:03 +0100 Subject: [TUHS] Ping times In-Reply-To: <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net> References: <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se> <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net> Message-ID: On 2017-02-10 00:03, Joerg Schilling wrote: > Johnny Billquist wrote: > >> Meh. From Uppsala in Sweden I seem to have about 2ms ping time to 8.8.8.8... >> >> Psilocybe:update/bqt> ping 8.8.8.8 >> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. >> 64 bytes from 8.8.8.8: icmp_req=1 ttl=56 time=2.10 ms > > You seem to live in a location where the light speed is higher than usual ;-) > > 1ms = 300 km in my area. > > Berlin <-> SF is aprox. 9100 km :-) Well, it should be obvious that Google is not serving everything from SF. In fact, pretty much nothing is served from there... They have many datacenters, and they also want their egress traffic to come out as close as possible to the destination. My traceroute was still 11 hops, but nowhere near SF... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From dugo at xs4all.nl Fri Feb 10 09:38:41 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Thu, 09 Feb 2017 18:38:41 -0500 Subject: [TUHS] Free/NetBSD revision history (was Code bloat) In-Reply-To: References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> Message-ID: <59edd244efc6fca1609f5707dd39833e@xs4all.nl> On 2017-02-09 11:14, Warner Losh wrote: > I thought someone had posted a github project to merge the history of > all publicly available sources of unix. That's the thing, it banks on what is publicly available. NetBSD and FreeBSD both started out from 386BSD + patchkits. They threw it is cvs, and engineered a release. This was all, in essence, Net/2 based, then the USL vs. BSDi lawsuit kicked in and was settled by a.o. "encumbering" Net/2 by agreement. Panic ensued and the NetBSD and FreeBSD teams took a chainsaw against what they had released until then. The publicly available repos from that period are butchered. The number of people on earth trying to curate stuff like the history of locore.s/tty.c between 386BSD and the reboots of Net/FreeBSD is a handfull, and I'm being optimistic here. This stuff has been deliberately purged and hard to find. Jason Stevens went as far as reconstructing a NetBSD 0.8 kernel because the complete sources where nowhere to be found. Then he ran into the proverbial coughing, chain smoking guy in a raincoat in a parking garage with a manilla folder of a CD-ROM of ftp://agate.berkeley.edu/pub/NetBSD/NetBSD-0.8, or was it a forgotten ftp site? Anyway, the revision history of the "encumbered" pieces in NetBSD is probably lost, but at least the 0.8 checkpoint was unearthed. If you take a close look at the publicly available revision history of FreeBSD you'll notice some serious gaps as well. Someone went through that cvs with an axe or surgical knife for legal reasons (and made a mess teleporting AMD64 to the early 90s). What dspinellis did with git is truly awesome. But I see the scars the USL vs. BSDi lawsuit made. I have no idea why I care, but I do. I respect that not everything can be made publicly available, but I pray stuff such as an original FreeBSD revision history is at least dumped into hidden archives like Warren and friends keep until the time is right. From dugo at xs4all.nl Fri Feb 10 09:47:10 2017 From: dugo at xs4all.nl (Jacob Goense) Date: Thu, 09 Feb 2017 18:47:10 -0500 Subject: [TUHS] Code bloat (was: How Unix brings people together, In-Reply-To: References: <20170209195457.373C940B9@lod.com> Message-ID: <9dd636e8a1303f1cb093eaea511950fb@xs4all.nl> On 2017-02-09 15:30, Arthur Krewat wrote: > I think it's entirely possible that 8.8.8.8 is more than one host, and > depending on geographical location you're being routed to any of a > number of actual hosts ;) This is an old trick, no!? Spread out a bunch of boxen w/ the same IP and let them announce using eg. routed/zebra. BGP takes care of the rest. From crossd at gmail.com Fri Feb 10 10:17:31 2017 From: crossd at gmail.com (Dan Cross) Date: Thu, 9 Feb 2017 19:17:31 -0500 Subject: [TUHS] // comment in C++ In-Reply-To: References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: On Thu, Feb 9, 2017 at 4:56 PM, Dave Horsfall wrote: > On Thu, 9 Feb 2017, Michael Kjörling wrote: > > I didn't know that // was now accepted to begin a comment in C, but I > > strongly suspect that any compiler modern enough to know about that will > > know just as well about #if 0. > > // isn't in ANSI C, but I've been using it for years on quite a few > platforms (I see that even M$ supports it); I don't know where I first saw > it. Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20 years! - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at horsfall.org Fri Feb 10 11:58:43 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 10 Feb 2017 12:58:43 +1100 (EST) Subject: [TUHS] // comment in C++ In-Reply-To: References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: On Thu, 9 Feb 2017, Dan Cross wrote: > Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20 > years! Not in my C book 2nd ed. (ANSI), it isn't... A2.2 Comments The characters /* introduce a comment, which terminates with the characters */. Comments do not not nest, and they do not occur within string or character literals. There is no mention of "//"; I have the 51st printing, August 2013. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From jsteve at superglobalmegacorp.com Fri Feb 10 12:07:21 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 10 Feb 2017 10:07:21 +0800 Subject: [TUHS] Ping times (was: Code bloat) In-Reply-To: <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net> References: <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se> <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net> Message-ID: <2993F3BB-9286-4523-A7D6-FDFE57A6D2BD@superglobalmegacorp.com> 8.8.8.8 is a multicast. Google has these servers all over the world so it's no surprise that everyone has good timing to them.... Try 4.2.2.2 or 4.2.2.4 for some old easy to remember DNS servers On February 10, 2017 7:03:59 AM GMT+08:00, Joerg Schilling wrote: >Johnny Billquist wrote: > >> Meh. From Uppsala in Sweden I seem to have about 2ms ping time to >8.8.8.8... >> >> Psilocybe:update/bqt> ping 8.8.8.8 >> PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. >> 64 bytes from 8.8.8.8: icmp_req=1 ttl=56 time=2.10 ms > >You seem to live in a location where the light speed is higher than >usual ;-) > >1ms = 300 km in my area. > >Berlin <-> SF is aprox. 9100 km > >Jörg > >-- >EMail:joerg at schily.net (home) Jörg Schilling D-13353 >Berlin >joerg.schilling at fokus.fraunhofer.de (work) Blog: >http://schily.blogspot.com/ >URL: http://cdrecord.org/private/ >http://sourceforge.net/projects/schilytools/files/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Fri Feb 10 12:46:25 2017 From: cym224 at gmail.com (Nemo) Date: Thu, 9 Feb 2017 21:46:25 -0500 Subject: [TUHS] // comment in C++ In-Reply-To: References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: On 9 February 2017 at 20:58, Dave Horsfall wrote: > On Thu, 9 Feb 2017, Dan Cross wrote: > >> Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20 >> years! > > Not in my C book 2nd ed. (ANSI), it isn't... > > A2.2 Comments > > The characters /* introduce a comment, which terminates with the > characters */. Comments do not not nest, and they do not occur within > string or character literals. > > There is no mention of "//"; I have the 51st printing, August 2013. Hhmmm... I do not have ANSI C99 (or C11) but ISO/IEC 9899:TC3 states (in Para. 6.4.9): Except within a character constant, a string literal, or a comment, the characters // introduce a comment that includes all multibyte characters up to, but not including, the next new-line character. N. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Fri Feb 10 12:49:57 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 10 Feb 2017 13:49:57 +1100 (EST) Subject: [TUHS] // comment in C++ In-Reply-To: References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: On Thu, 9 Feb 2017, Nemo wrote: > Hhmmm... I do not have ANSI C99 (or C11) but ISO/IEC 9899:TC3 states > (in Para. 6.4.9): [...] Yeah; someone told me in private. My mistake... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From imp at bsdimp.com Fri Feb 10 14:11:19 2017 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Feb 2017 21:11:19 -0700 Subject: [TUHS] Free/NetBSD revision history (was Code bloat) In-Reply-To: <59edd244efc6fca1609f5707dd39833e@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <59edd244efc6fca1609f5707dd39833e@xs4all.nl> Message-ID: On Thu, Feb 9, 2017 at 4:38 PM, Jacob Goense wrote: > On 2017-02-09 11:14, Warner Losh wrote: >> >> I thought someone had posted a github project to merge the history of >> all publicly available sources of unix. > > > That's the thing, it banks on what is publicly available. > > NetBSD and FreeBSD both started out from 386BSD + patchkits. They threw > it is cvs, and engineered a release. > > This was all, in essence, Net/2 based, then the USL vs. BSDi lawsuit > kicked in and was settled by a.o. "encumbering" Net/2 by agreement. > > Panic ensued and the NetBSD and FreeBSD teams took a chainsaw against > what they had released until then. That was actually part of the agreement with AT&T to end the hostilities. NetBSD did it by butchery. FreeBSD did it by reimporting from 4.4lite, basically (the basically part is a bit messy). > The publicly available repos from that period are butchered. True. I had thought the original FreeBSD 1 repo was now publicly available. I know I can get copies of it as a FreeBSD project member. > The number of people on earth trying to curate stuff like the history > of locore.s/tty.c between 386BSD and the reboots of Net/FreeBSD is a > handfull, and I'm being optimistic here. Yea, the FreeBSD CVS tree I think has that history. It started out life trying to make the patch-kit to 386BSD make sense as dealing with a boatload of patches soon grew unwieldy as the number proliferated and you started getting patches on patches. > This stuff has been deliberately purged and hard to find. Jason Stevens > went as far as reconstructing a NetBSD 0.8 kernel because the complete > sources where nowhere to be found. Then he ran into the proverbial > coughing, chain smoking guy in a raincoat in a parking garage with > a manilla folder of a CD-ROM of > ftp://agate.berkeley.edu/pub/NetBSD/NetBSD-0.8, > or was it a forgotten ftp site? Don't know anything about that... But the Truth is Out There. > Anyway, the revision history of the "encumbered" pieces in NetBSD is > probably lost, but at least the 0.8 checkpoint was unearthed. I thought it was just shielded from public view and many of the NetBSD folks had copies. Could be wrong though. > If you take a close look at the publicly available revision history of > FreeBSD you'll notice some serious gaps as well. Someone went through > that cvs with an axe or surgical knife for legal reasons (and made a mess > teleporting AMD64 to the early 90s). Yea, CVS doesn't support repo-copying for crap. But it was done to go from i386 to amd64. > What dspinellis did with git is truly awesome. But I see the scars the > USL vs. BSDi lawsuit made. I have no idea why I care, but I do. I respect > that not everything can be made publicly available, but I pray stuff > such as an original FreeBSD revision history is at least dumped into > hidden archives like Warren and friends keep until the time is right. The old CTM archives might have stuff, it that was up and running before the lawsuit. I know that the FreeBSD 1 archive exists in multiple places. Compressed it is 18MB, or 185MB uncompressed (clang's history is bigger than that, though checked out it is only about 131MB). Warner From corey at lod.com Fri Feb 10 14:15:26 2017 From: corey at lod.com (Corey Lindsly) Date: Thu, 9 Feb 2017 20:15:26 -0800 (PST) Subject: [TUHS] Ping times (was: Code bloat) In-Reply-To: <2993F3BB-9286-4523-A7D6-FDFE57A6D2BD@superglobalmegacorp.com> Message-ID: <20170210041526.D3C1140B9@lod.com> > 8.8.8.8 is a multicast. Google has these servers all over the world so > it's no surprise that everyone has good timing to them.... Well, technically it's anycast, which is conceptually similar to multicast but a distinct routing protocol. Anycast is one-to-nearest while multicast is one-to-many (selected). --corey From imp at bsdimp.com Fri Feb 10 14:17:28 2017 From: imp at bsdimp.com (Warner Losh) Date: Thu, 9 Feb 2017 21:17:28 -0700 Subject: [TUHS] Free/NetBSD revision history (was Code bloat) In-Reply-To: <59edd244efc6fca1609f5707dd39833e@xs4all.nl> References: <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com> <20170208025538.GE65698@eureka.lemis.com> <90190d89aaeefbf0b540a28436468835@xs4all.nl> <59edd244efc6fca1609f5707dd39833e@xs4all.nl> Message-ID: On Thu, Feb 9, 2017 at 4:38 PM, Jacob Goense wrote: > That's the thing, it banks on what is publicly available. A google search finds https://github.com/jonathangray?tab=repositories has CVS trees from the 1.1.5 FreeBSD CD-ROM, 386BSD + patchkit and the csrg sources converted from SCCS to git. Are any of these useful in filling in the gaps? Warner From bqt at update.uu.se Fri Feb 10 18:05:26 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Fri, 10 Feb 2017 09:05:26 +0100 Subject: [TUHS] Ping times In-Reply-To: <2993F3BB-9286-4523-A7D6-FDFE57A6D2BD@superglobalmegacorp.com> References: <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se> <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net> <2993F3BB-9286-4523-A7D6-FDFE57A6D2BD@superglobalmegacorp.com> Message-ID: <8df0fe1f-6624-2648-6a03-9475b858d3cd@update.uu.se> On 2017-02-10 03:07, Jason Stevens wrote: > 8.8.8.8 is a multicast. Google has these servers all > over the world so it's no surprise that everyone has good timing to them.... It's not a multicast in the traditional sense. But it is hosted in many locations, yes. Johnny > Try 4.2.2.2 or 4.2.2.4 for some old > easy to remember DNS servers > > On February 10, 2017 7:03:59 AM GMT+08:00, Joerg Schilling > wrote: > > Johnny Billquist wrote: > > Meh. From Uppsala in Sweden I seem to have about 2ms ping time > to 8.8.8.8 ... > > Psilocybe:update/bqt> ping 8.8.8.8 > PING 8.8.8.8 (8.8.8.8 ) 56(84) > bytes of data. > 64 bytes from 8.8.8.8 : icmp_req=1 ttl=56 > time=2.10 ms > > > You seem to live in a location where the light speed is higher than usual ;-) > > 1ms = 300 km in my area. > > Berlin <-> SF is aprox. 9100 km > > Jörg > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From arnold at skeeve.com Fri Feb 10 19:19:08 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 10 Feb 2017 02:19:08 -0700 Subject: [TUHS] // comment in C++ In-Reply-To: References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: <201702100919.v1A9J8xo016639@freefriends.org> > On Thu, 9 Feb 2017, Michael Kjörling wrote: > > > I didn't know that // was now accepted to begin a comment in C, but I > > strongly suspect that any compiler modern enough to know about that will > > know just as well about #if 0. Dave Horsfall wrote: > // isn't in ANSI C, but I've been using it for years on quite a few > platforms (I see that even M$ supports it); I don't know where I first saw > it. It was added in C99. Arnold From arnold at skeeve.com Fri Feb 10 19:30:40 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 10 Feb 2017 02:30:40 -0700 Subject: [TUHS] // comment in C++ In-Reply-To: References: <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com> <20170209115922.GH5418@yeono.kjorling.se> Message-ID: <201702100930.v1A9Ueds017224@freefriends.org> Dave Horsfall wrote: > On Thu, 9 Feb 2017, Dan Cross wrote: > > > Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20 > > years! > > Not in my C book 2nd ed. (ANSI), it isn't... > > A2.2 Comments > > The characters /* introduce a comment, which terminates with the > characters */. Comments do not not nest, and they do not occur within > string or character literals. > > There is no mention of "//"; I have the 51st printing, August 2013. Sadly, although it's a recent printing, the contents date from 1989, only covering the first standard for C. C99 is the second, and C11 is the third. (My first printing of the 2nd edition from 1989 has "draft ANSI" or some such on the cover. :-) Arnold From steffen at sdaoden.eu Sat Feb 11 03:39:32 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 10 Feb 2017 18:39:32 +0100 Subject: [TUHS] // comment in C++ In-Reply-To: <201702092114.v19LEUgJ091850@tahoe.cs.Dartmouth.EDU> References: <201702092114.v19LEUgJ091850@tahoe.cs.Dartmouth.EDU> Message-ID: <20170210173932.xRFc0%steffen@sdaoden.eu> That is an honour to me, Mr. Doug McIlroy. Doug McIlroy wrote: |With no offense intended, I can't help noting the irony of the |following paragraph appearing in a message in the company of |others that address Unix "bloat". To me writing documentation is an enormous pain. I find it extraordinary hard to find the words to describe some technical aspect to an imaginery broad audience of human beings. It requires many iterations until i am somewhat satisfied, and, as something like an excuse, this specific part is very fresh. |Except for the ISO citations, this paragraph says the same |thing more succinctly. | |'\cX' represents a nonprintable character Y in terms of the | printable character X whose binary code is obtained | by adding 0x40 (decimal 64) to that for Y. (In some | historical contexts, '^' plays the role of '\c'.) | Alternative standard representations for certain | nonprinting characters, e.g. '\a', '\n', '\t' above, | are preferred by S-nail. '\c@' (NUL) serves as a | string terminator regardless of following characters. | |And this version, 1/3 the length of the original, tells all |one really needs to know. | |'\cX' represents a nonprintable character Y in terms of the | printable character X whose binary code is obtained | by adding 0x40 (decimal 64) to that for Y. '\c@' | (NUL) serves as a string terminator regardless of | following characters. This is brief and concise. The last sentence could not be used like that, because the \c@ is an extension that, different to \0*, \x0*, \[uU]0*, really terminates the entire argument list, not "further output for the quoted argument". I have to mark it as a non-standard extension. Thanks for pointing this out. I am wondering. Chekhov said: Ich glaube nicht an unsere Intelligenz, die heuchlerisch, falsch, hysterisch, ungebildet und faul ist, ich glaube ihr sogar dann nicht, wenn sie leidet und klagt, denn ihre Unterdrücker kommen doch aus ihrem eigenen Schoß. Ich glaube an den einzelnen Menschen, ich sehe die Rettung in den Einzelpersönlichkeiten[.] I don't believe in our Intelligence, that is insincere, false, hysterical, illiterate and lazy, i don't believe in it even when she [it] suffers and laments, because her [its] suppressors still come from her [its] own womb. I believe in the individual Human, i see the Salvage in the Individual. I know for sure that this last example of yours is too concise for a broad audience, a "nonprintable character" without a describing context is an anachronism. To me the question is, in a world of increasingly omnipresent trivialism, where the human being remains just as hormone driven, and not in only a small propertion somewhat unreflected, as it always has been, but becomes more and more de-facto controllable, far, far beyond the purging sunday morning thunderstorm from the pulpit (and here being optimistic, and wearing western world glasses), faster, much faster than most souls, and here the story of the African Expedition which was beaten along by the white master, until after some days the bearers refused to march on at any cost, to "wait for their souls to catch up", are, so how to strengthen the individual with its, that is my believe, as a Buddhist, sole obligation of doing that step towards reflection, of self-awareness in a holistic whole. I know the software i maintain is by far not where i want to see it, also regarding the documentation. For one we are by far not powerful enough, other aspects are much too bloated. We do not yet fully comply to the POSIX standard. But we slowly become more reliable, also for non-interactive use cases. And correct. And i refer to the not yet released version, which will be a step forward, after one year and a half of what i call full-time development. I want us to move to a place where even an inexperienced user can teach her- or himself, and gain -- hopefully -- satisfying results simply by reading the manual. To get a notion of what actually happens, or at least a notion of the problems that are involved. Or, at the very least, to get some hints to keep in mind for the next time Internet is accessible or an experienced user can be talked to etc. I think that, and i want to see and have a lower hurdle on the documentation side. I get frustrated when i really have to go Google, and cannot get any help, but see a nice and stylish link asking whether "this page was helpful". Or HTMLized GNU info pages, with a paragraph per HTML page. I think that such behaviour increases aggression, increases the feeling of inferiority, and if its under the surface. It will at least try to rise to the surface, one way or the other, that is programmed in the afterbrain, or at a not too much higher level. Some intellegent millionairs and other alpha leaders may even think it is funny to play with that, but i, for myself, reject that direction. It is a little bit ridiculous. For now i end up with ‘\cX’ Emits the non-printable (ASCII and compatible) C0 con‐ trol codes 0 (NUL) to 31 (US), and 127 (DEL). Print‐ able representations of ASCII control codes can be created by mapping them to a different part of the ASCII character set, which is possible by adding the number 64 for the codes 0 to 31, e.g., 7 (BEL) is ‘7 + 64 = 71 = G’. The real operation is a bitwise logical XOR with 64 (bit 7 set, see vexpr[253]), thus also covering code 127 (DEL), which is mapped to 63 (ques- tion mark): ‘vexpr ^ 127 64’. Whereas historically circumflex notation has often been used for visualization purposes of control codes, e.g., ‘^G’, the reverse solidus notation has been standardized: ‘\cG’. Some control codes also have standardized (ISO 10646, ISO C) aliases, as shown above (e.g., ‘\a’, ‘\n’, ‘\t’): whenever such an alias exists it will be used for display purposes. The con‐ trol code NUL (‘\c@’, a non-standard extension) ends argument processing without producing further output. The vexpr[253] is an active link. (In a capable less(1). And to yet another new builtin command which performs arithmetic and string operations, but we now have macros with arguments, and even though we do not yet have loop control statements, managing counters etc. may already be useful. As an overall question, if we would have a multi-process approach, like sam has, maybe we could simply use a communication channel to some arbitrary shell or awk script to perform such things. But this software will see its 39th birthday in six weeks and one day from now on, and it was not designed that way. So it is easier to have a 483 line `vexpr' implementation. It also does have saturated signed 64-bit arithmetic. And it provides the right error messages. I do hope the future will bring some size reduction again nonetheless, while also providing better message access. Or any access at all. In the end, it does not make sense to provide a clean program if it is of no use at all, nor can be plugged together with other programs to form a Unix pipe that provides something useful. I hope for both, and that increasingly reliable.) --steffen From jnc at mercury.lcs.mit.edu Tue Feb 14 09:20:42 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 13 Feb 2017 18:20:42 -0500 (EST) Subject: [TUHS] Early Internet work Message-ID: <20170213232042.459BD18C09E@mercury.lcs.mit.edu> > we just read the second tape, which read without error. ... at this > point we have access to everything that was on that machine. OK, we're starting to get through all the clearances needed to release the non-MIT Unix systems on the machine. (The MIT one is going to take more work - I have to curate out all the personal files.) We have now completed the OK's for the 'Network Unix' (the one done at the University of Illinois for use on the ARPANET, with NCP). A tarball is available here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/nosc.tar (It's called 'nosc.tar' because it came through NOSC, and then SRI, on the way to MIT.) In addition to all the UIllinois code, it also contains early versions of the MH mail reader (from Rand) and the MMDF mailer (from UDel). Enjoy! Noel From spedraja at gmail.com Tue Feb 14 17:37:28 2017 From: spedraja at gmail.com (SPC) Date: Tue, 14 Feb 2017 08:37:28 +0100 Subject: [TUHS] Early Internet work In-Reply-To: <20170213232042.459BD18C09E@mercury.lcs.mit.edu> References: <20170213232042.459BD18C09E@mercury.lcs.mit.edu> Message-ID: Great work. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- Sergio Pedraja -- twitter: @sergio_pedraja | skype: Sergio Pedraja -- http://plus.google.com/u/0/101292256663392735405 http://www.linkedin.com/in/sergiopedraja http://www.quora.com/Sergio-Pedraja http://spedraja.wordpress.com ----- No crea todo lo que ve, ni crea que está viéndolo todo ----- "El estado de una Copia de Seguridad es desconocido hasta que intentas restaurarla" (- nixCraft) 2017-02-14 0:20 GMT+01:00 Noel Chiappa : > > we just read the second tape, which read without error. ... at this > > point we have access to everything that was on that machine. > > OK, we're starting to get through all the clearances needed to release the > non-MIT Unix systems on the machine. (The MIT one is going to take more > work - I have to curate out all the personal files.) > > We have now completed the OK's for the 'Network Unix' (the one done at the > University of Illinois for use on the ARPANET, with NCP). A tarball is > available here: > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/nosc.tar > > (It's called 'nosc.tar' because it came through NOSC, and then SRI, > on the way to MIT.) > > In addition to all the UIllinois code, it also contains early versions of the > MH mail reader (from Rand) and the MMDF mailer (from UDel). > > Enjoy! > > Noel From pnr at planet.nl Tue Feb 14 18:46:36 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 14 Feb 2017 09:46:36 +0100 Subject: [TUHS] Another odd comment in V6 Message-ID: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> There's an odd comment in V6, in tty.c, just above ttread(): /* * Called from device's read routine after it has * calculated the tty-structure given as argument. * The pc is backed up for the duration of this call. * In case of a caught interrupt, an RTI will re-execute. */ That comment is strange, because it does not describe what the code does. The comment isn't there in V5 or V7. I wonder if there is a link to the famous Gabriel paper about "worse is better" (http://dreamsongs.com/RiseOfWorseIsBetter.html). In arguing its points, the paper includes this story: --- Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing because the PC is being coerced into loser mode, where loser is the affectionate name for user at MIT. The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing. The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix -- namely, implementation simplicity was more important than interface simplicity. --- Actually, research Unix does save the complete state of a process and could back up the PC. The reason that it doesn't work is in the syscall API design, using registers to pass values etc. If all values were passed on the stack it would work. As to whether it is the right thing to be stuck in a read() call waiting for terminal input after a signal was received... I always thought that this story was entirely fictional, but now I wonder. The Unix guru referred to could be Ken Thompson (note how he is first referred to as "from Berkeley but working on Unix" and then as "the New Jersey guy"). Who can tell me more about this? Any of the old hands? Paul From pnr at planet.nl Tue Feb 14 19:06:38 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 14 Feb 2017 10:06:38 +0100 Subject: [TUHS] About the SPIDER network in V6 Message-ID: On page 3 of the Research Unix reader (http://www.cs.dartmouth.edu/~doug/reader.pdf). "Sandy (A. G.) Fraser devised the Spider local-area ring (v6) and the Datakit switch (v7) that have served in the lab for over a decade. Special services on Spider included a central network file store, nfs, and a communication package, ufs." I do not recall ever seeing any SPIDER related code in the public V6 source tree. Was it ever released outside Bell Labs? From a bit of Googling I understand that SPIDER was a ATDM ring network with a supervisor allocating virtual circuits. Apparently there was only ever one SPIDER loop with 11 hosts connected, although Fraser reportedly intended to create multiple connected loops as part of his research. The papers that Fraser wrote are hard to find: lots of citations, but no copies, not even behind pay walls. The base report seems to be: A. G. FRASER, " SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974. Is that tech report available online somewhere? Tanks! Paul From downing.nick at gmail.com Tue Feb 14 21:27:40 2017 From: downing.nick at gmail.com (Nick Downing) Date: Tue, 14 Feb 2017 22:27:40 +1100 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> Message-ID: Well I don't know about this actual conversation in history so I can't help with that. But I can describe how interrupted system calls work. Firstly it depends on what you mean by an interrupt. The guy from MIT might have meant, "what happens if the process is blocked in a system call and a task switch occurs". This isn't a problem in the design of unix, because a process continues to have a normal program counter (PC) and stack pointer (SP) whilst executing a system call. A task switch can only occur when executing inside the kernel, and what it does is to save the kernel PC and SP of the process going to sleep, and then restore the kernel PC and SP of the process waking up. So the system call that was being executed when the waking-up process went to sleep, is NOT restarted as a fresh system call. By contrast the MIT guy probably was working with a much smaller/more economical system that didn't maintain a kernel stack per process. I now have to digress a bit to discuss interrupts. There are two kinds of interrupts, one is a direct hardware interrupt that gets delivered to the kernel, such as a timer interrupt or an I/O event, e.g. for an RS232 TTY interface this could be receiver ready (character just came in) or transmitter ready (character just went out, can now transmit another one). The other is a simulated interrupt that gets delivered to a user process. This latter is what we call a "signal", some examples are SIGINT (Ctrl-C was pressed) or SIGALRM (process requested a timer interrupt and the requested period has elapsed). Note that signals are not real interrupts, they are a "fiction" created by the kernel that appears to the receiving process like an interrupt. This was chosen by Thompson and Ritchie because it's convenient and "makes sense" -- for exactly the same reasons that hardware designers created hardware interrupts, clever software designers created signals. One slight complication with hardware interrupts is they can happen in either kernel mode (current process is doing a system call) or user mode (current process is doing some computation in between system calls). The kernel mode case is the simplest -- it behaves as if the kernel had executed a subroutine call to the interrupt service routine (ISR). The ISR has to be careful to save and restore any registers it uses. It also cannot redirect execution flow anywhere else, it has to service the interrupting hardware device quickly and then return. On the other hand, if the hardware interrupt occurs in user mode, it behaves as if the user-mode program had executed a null system call -- which simply does nothing, does not alter any registers or memory, and returns. But once inside the kernel, it then behaves as if the kernel-mode program had executed a subroutine call to the ISR. Once this finishes, the kernel executes basically its normal system call return sequence (but without any status return), requiring checks (1) should process be pre-empted and (2) should signals be delivered. If process is going to be pre-empted (either at the conclusion of a system call, or else before the "fake" system call associated with a hardware interrupt returns) then the kernel does a normal in-kernel task switch, basically it goes to sleep and another process wakes up in kernel mode. Then when the pre-empted process eventually gets scheduled again, it resumes in kernel mode and continues with its system call return sequence. If signals are going to be delivered, this is where things get a bit interesting. Conceptually all we do is to take the user-mode PC we were going to return to, and put it on the user-mode stack (decrementing the user-mode SP by one word) and then load the user-mode PC with the address of the user-mode signal hander, and then continue the system call return sequence. So, to the user-mode program, it looks like the system call completed, and then the user program magically did a subroutine call to the signal handler. If the system call was a "fake" system call due to a hardware interrupt, then this appears asynchronous to the user program. One way of thinking about a signal, is that it's a "callback" from the operating system to tell you that something's happened. This is particularly useful in the context of long-running system calls, like for instance suppose I've used the alarm() system call to ask for a SIGALRM to be delivered to my process in 30 seconds, and then I've used the read() system call to get some input from the TTY. If the read() system call is still blocked after 30 seconds, the SIGALRM signal has to be delivered to me, and conceptually we would like the kernel to call my signal handler to tell me about the SIGALRM, and then return to the blocked read() system call, which conceptually should not return until there is some input available. But alas this conceptual model is too dangerous to implement, because of the risk to the kernel from badly behaved signal handlers. The kernel can't risk calling user code directly, in case that user code never returns. So, in early versions of unix what happened was that if SIGALRM or some other signal had to be delivered during a blocking operation, the blocking operation would terminate returning the error EINTR, and then in the normal system call return sequence the signal would be delivered, and after the signal handler executed, the user code that made the system call had to process the EINTR. Basically, every call to read() or similar, had to check for an EINTR return, and then restart the system call. Very annoying, and a source of bugs since there would be plenty of little-used read() sites in the program that didn't have the required checks. So, in my understanding at least, a new error code was reserved, I think by the BSD designers, called ERESTART, and the C library's system call routines like read() and write() were modified to always do the looping that restarts the system call, if the system call returns an error and the error is ERESTART. EINTR is thus (in my understanding) redundant, except for a few rare system calls where restarting isn't desirable or EINTR can be requested. With this innovation we can have callbacks from the operating system at any time, even though the operating system is executing a blocking operation, and if the signal handler returns normally (to the C library code just after the system call, i.e. to the ERESTART check), then from the user-mode foreground program's point of view it is completely transparent, the read() only returns when it has data. But if the signal handler instead chooses to, say, abort the user-mode foreground program by doing a longjmp() to an error recovery routine, and then restarting the user-mode foreground program from a known point such as its main loop or main menu, then this is also fine, the blocking system call appears to have been aborted so that the foreground program could do its error recovery. And the kernel just doesn't care, since once it's done its system call return sequence and diverted the user-mode execution appropriately, it washes its hands of it all. And now having explained all that, I can address your point about the interface complexity. To keep things simple, unix doesn't have the ability to actually undo or restart a system call. For instance, if I was reading the TTY and the kernel delivered some keystrokes into my buffer, it can't restore the previous contents of the buffer and move those keystrokes back into the TTY driver. Some other operating systems probably can do this. And, for instance, x86 processors can do something like this: If a pagefault occurs partway through the execution of an instruction, the x86 processor will actually restore all register values to their values prior to the instruction starting, so that the pagefault handler can resume the user program cleanly after a pagefault. This is kind of a good feature (the 68010 added this feature fixing a significant issue in the 68000 which prevented its widespread adoption in unix workstations), but it's also a potent source of bugs, for instance early 286 silicon didn't correctly restart some instructions after a segment-not-present or similar fault. It's clear to see why Thompson and Ritchie didn't adopt such a design. Instead what happens is, the blocking system calls are specified so that they can only return EINTR or ERESTART if no data has been transferred. If data has been transferred, they return a "short read" or "short write". To make my discussion complete I also have to mention something about signal trampolines. To understand these properly it's best to think about hardware interrupts (signals are just an emulation of a hardware interrupt). Hardware interrupts always disable further interrupts of the same kind while they execute. For instance suppose a TTY is receiving characters very fast, it would be unacceptable to have the ISR get interrupted by a fresh character arriving halfway through stashing the last character. So the hardware always provides a way to enter the ISR with interrupts of the same or lower priority as the one under service, disabled. The ISR then has to inform the hardware when these can be re-enabled. Moreover, this last step has to be done *atomically* with the interrupt return -- it can't be done BEFORE the interrupt return, because fast-arriving interrupts could each push a new return address on the stack until the stack overflows. Thus the hardware provides intructions like IRET (x86) which atomically re-enable interrupts and return. What unix provides is a system call that *behaves* like IRET, it is called sigreturn(). What this does conceptually, is to re-enable the signal that just got delivered, and then make the user-mode process do a return-from-subroutine. This neatly reverses the steps taken when delivering the signal, i.e. it pops the user-mode PC from the user-mode stack, increasing the user-mode SP by one word. To make this whole process more user-friendly, the C library provides something called the signal trampoline. When the kernel wants to deliver a signal, it first masks off further delivery of signals of the same kind. Then, instead of making the user-mode program issue a subroutine call to the signal handler, it makes the user-mode program call the signal trampoline. In turn the signal trampoline calls the user's signal handler, and when the user's signal handler returns (which is not compulsory, it is allowed to do a longjmp() to error recovery code instead), the signal trampoline does the sigreturn(). cheers, Nick On Tue, Feb 14, 2017 at 7:46 PM, Paul Ruizendaal wrote: > > There's an odd comment in V6, in tty.c, just above ttread(): > > /* > * Called from device's read routine after it has > * calculated the tty-structure given as argument. > * The pc is backed up for the duration of this call. > * In case of a caught interrupt, an RTI will re-execute. > */ > > That comment is strange, because it does not describe what the code does. The comment isn't there in V5 or V7. > > I wonder if there is a link to the famous Gabriel paper about "worse is better" (http://dreamsongs.com/RiseOfWorseIsBetter.html). In arguing its points, the paper includes this story: > > --- > Two famous people, one from MIT and another from Berkeley (but working on Unix) once met to discuss operating system issues. The person from MIT was knowledgeable about ITS (the MIT AI Lab operating system) and had been reading the Unix sources. He was interested in how Unix solved the PC loser-ing problem. The PC loser-ing problem occurs when a user program invokes a system routine to perform a lengthy operation that might have significant state, such as IO buffers. If an interrupt occurs during the operation, the state of the user program must be saved. Because the invocation of the system routine is usually a single instruction, the PC of the user program does not adequately capture the state of the process. The system routine must either back out or press forward. The right thing is to back out and restore the user program PC to the instruction that invoked the system routine so that resumption of the user program after the interrupt, for example, re-enters the system routine. It is called PC loser-ing because the PC is being coerced into loser mode, where loser is the affectionate name for user at MIT. > > The MIT guy did not see any code that handled this case and asked the New Jersey guy how the problem was handled. The New Jersey guy said that the Unix folks were aware of the problem, but the solution was for the system routine to always finish, but sometimes an error code would be returned that signaled that the system routine had failed to complete its action. A correct user program, then, had to check the error code to determine whether to simply try the system routine again. The MIT guy did not like this solution because it was not the right thing. > > The New Jersey guy said that the Unix solution was right because the design philosophy of Unix was simplicity and that the right thing was too complex. Besides, programmers could easily insert this extra test and loop. The MIT guy pointed out that the implementation was simple but the interface to the functionality was complex. The New Jersey guy said that the right tradeoff has been selected in Unix -- namely, implementation simplicity was more important than interface simplicity. > --- > > Actually, research Unix does save the complete state of a process and could back up the PC. The reason that it doesn't work is in the syscall API design, using registers to pass values etc. If all values were passed on the stack it would work. As to whether it is the right thing to be stuck in a read() call waiting for terminal input after a signal was received... > > I always thought that this story was entirely fictional, but now I wonder. The Unix guru referred to could be Ken Thompson (note how he is first referred to as "from Berkeley but working on Unix" and then as "the New Jersey guy"). > > Who can tell me more about this? Any of the old hands? > > Paul > From pnr at planet.nl Tue Feb 14 22:27:48 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 14 Feb 2017 13:27:48 +0100 Subject: [TUHS] Another odd comment in V6 In-Reply-To: References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> Message-ID: <0B8503D7-D696-4BB6-A2C7-75A95B603036@planet.nl> Hi Nick, Many thanks for that background! I think the quote from the Gabriel paper indeed refers to software interrupts, i.e. signals -- it would not make sense otherwise. The ITS system that the MIT guy referred to is 'large', it ran on PDP10 mainframes. I understand how executing a signal handler is piggy-backed on the return from kernel mode. However, when the signal handler is finished it could either continue with the next instruction or re-excute the system call trap instruction. See http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/sys/sys/trap.c (towards end) for details how this is actually done in 2.9BSD. I think you referred to that mechanism as well. However, my question remains: why is that mysterious comment there, above ttread() in V6, and is there a link with the Gabriel story? Paul On 14 Feb 2017, at 12:27 , Nick Downing wrote: > Well I don't know about this actual conversation in history so I can't > help with that. But I can describe how interrupted system calls work. > [..more..] From downing.nick at gmail.com Tue Feb 14 22:46:14 2017 From: downing.nick at gmail.com (Nick Downing) Date: Tue, 14 Feb 2017 23:46:14 +1100 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <0B8503D7-D696-4BB6-A2C7-75A95B603036@planet.nl> References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> <0B8503D7-D696-4BB6-A2C7-75A95B603036@planet.nl> Message-ID: Yes, you are right, I had not paid attention to that pc=opc stuff, in fact 2.9 has a comment saying it's backing the PC up but the other BSDs do not, so I hadn't noticed that bit. :) I was probably thinking of another unix that implements it in the C library not the kernel, however it makes no difference conceptually. Interestingly, 2.11BSD has ERESTART defined as an errno and does the pc=opc thing if ERESTART was to have been returned as the errno. Whereas the other BSDs have another variable eosys which has just a few possible values, where one of those values (NORMALRETURN or some such) means that errno should be checked as well. I like the 2.11BSD way. V7 does not have the pc=opc thing and there is no mention of restarting, so I suppose EINTR just aborts the interrupted system call. cheers, Nick On Tue, Feb 14, 2017 at 11:27 PM, Paul Ruizendaal wrote: > Hi Nick, > > Many thanks for that background! > > I think the quote from the Gabriel paper indeed refers to software > interrupts, i.e. signals -- it would not make sense otherwise. The > ITS system that the MIT guy referred to is 'large', it ran on PDP10 > mainframes. > > I understand how executing a signal handler is piggy-backed on the > return from kernel mode. However, when the signal handler is > finished it could either continue with the next instruction or > re-excute the system call trap instruction. See > http://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/sys/sys/trap.c > (towards end) for details how this is actually done in 2.9BSD. > I think you referred to that mechanism as well. > > However, my question remains: why is that mysterious comment there, > above ttread() in V6, and is there a link with the Gabriel story? > > Paul > > On 14 Feb 2017, at 12:27 , Nick Downing wrote: > >> Well I don't know about this actual conversation in history so I can't >> help with that. But I can describe how interrupted system calls work. >> [..more..] > From lars at nocrew.org Wed Feb 15 00:03:47 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Tue, 14 Feb 2017 15:03:47 +0100 Subject: [TUHS] Another odd comment in V6 In-Reply-To: (Nick Downing's message of "Tue, 14 Feb 2017 22:27:40 +1100") References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> Message-ID: <868tp8kgxo.fsf@molnjunk.nocrew.org> Nick Downing writes: > By contrast the MIT guy probably was working with a much smaller/more > economical system that didn't maintain a kernel stack per process. No. PCLSRing is a feature of MIT' ITS operating system, and it does have a separate stack for the kernel. Here is a copy of Alan Bawdens paper about PCLSRing: http://fare.tunes.org/tmp/emergent/pclsr.htm From jnc at mercury.lcs.mit.edu Wed Feb 15 00:14:24 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 14 Feb 2017 09:14:24 -0500 (EST) Subject: [TUHS] Another odd comment in V6 Message-ID: <20170214141424.A5BC518C0A2@mercury.lcs.mit.edu> > From: Paul Ruizendaal > There's an odd comment in V6, in tty.c, just above ttread(): > ... > That comment is strange, because it does not describe what the code > does. I can't actually find anyplace where the PC is backed up (except on a segmentation fault, when extending the stack)? So I suspect that the comment is a tombstone; it refers to what the code did at one point, but no longer does. > The comment isn't there in V5 or V7. Which is consistent with it documenting a temporary state of affairs... > I wonder if there is a link to the famous Gabriel paper I suspect so. Perhaps they tried backing up the PC (in the case where a system call is interrupted by a software interrupt in the user's process), and decided it was too much work to do it 'right' in all instances, and punted. The whole question of how to handle software interrupts while a process is waiting on some event, while in the kernel, is non-trivial, especially in systems which use the now-universal approach of i) writing in a higher-level stack oriented language, and ii) 'suspending' with a sub-routine call chain on the kernel stack. Unix (at least, in V6 - I'm not familiar with the others) just trashes the whole call stack (via the qsav thing), and uses the intflg mechanism to notify the user that a system call was aborted. But on systems with e.g. locks, it can get pretty complicated (try Googling Multics crawl-out). Many PhD theses have looked at these issues... > Actually, research Unix does save the complete state of a process and > could back up the PC. The reason that it doesn't work is in the syscall > API design, using registers to pass values etc. If all values were > passed on the stack it would work. Sorry, I don't follow this? The problem with 'backing up the PC' is that you 'sort of' have to restore the arguments to the state they were in at the time the system call was first made. This is actually easier if the arguments are in registers. I said 'sort of' because the hard issue is that there are system calls (like terminal I/O) where the system call is potentially already partially executed (e.g. a read asking for 10 characters from the user's console may have already gotten 5, and stored them in the user's buffer), so you can't just simply completely 'back out' the call (i.e. restore the arguments to what they were, and expect the system call to execute 'correctly' if retried - in the example, those 5 characters would be lost). Instead, you have to modify the arguments so that the re-tried call takes up where it left off - in the example above, tries to read 5 characters, starting 5 bytes into the buffer). The hard part is that the return value (of the number of characters actually read) has to count the 5 already read! Without the proper design of the system call interface, this can be hard - how does the system distinguish between the _first_ attempt at a system call (in which the 'already done' count is 0), and a _later_ attempt? If the user passes in the 'already done' count, it's pretty straightforward - otherwise, not so much! Alan Bawden wrote a good paper about PCLSR'ing which explores some of these issues. Noel From downing.nick at gmail.com Wed Feb 15 00:18:29 2017 From: downing.nick at gmail.com (Nick Downing) Date: Wed, 15 Feb 2017 01:18:29 +1100 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <868tp8kgxo.fsf@molnjunk.nocrew.org> References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> <868tp8kgxo.fsf@molnjunk.nocrew.org> Message-ID: Excellent paper, well that makes it completely clear what the MIT guy means by restarting a system call. It is interesting that in their approach they restart a read() or write() call or whatever they call it in their system, with the buffer advanced and the count reduced. This is a bit like what would happen in x86 if it gets interrupted in a REP MOVSB instruction, it returns into REP MOVSB with SI/DI advanced and CX reduced. However it would not work exactly right in unix due to the return value from read()/write() being wrong. Anyway, I like the unix way, it is nice and simple. I have never found it to be a problem when devices return a "short read" or "short write", although it is an interesting semantic that if you opened the file yourself and you're doing lseek on it, it cannot be a TTY, and short reads/writes do not occur. Having a hypothetical system with a very slow disk (or fast CPU) in which disk accesses are blocking, would break many programs. cheers, Nick On Wed, Feb 15, 2017 at 1:03 AM, Lars Brinkhoff wrote: > Nick Downing writes: >> By contrast the MIT guy probably was working with a much smaller/more >> economical system that didn't maintain a kernel stack per process. > > No. PCLSRing is a feature of MIT' ITS operating system, and it does > have a separate stack for the kernel. > > Here is a copy of Alan Bawdens paper about PCLSRing: > http://fare.tunes.org/tmp/emergent/pclsr.htm From pnr at planet.nl Wed Feb 15 00:35:46 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Tue, 14 Feb 2017 15:35:46 +0100 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <20170214141424.A5BC518C0A2@mercury.lcs.mit.edu> References: <20170214141424.A5BC518C0A2@mercury.lcs.mit.edu> Message-ID: <9D5768C7-995F-4C38-A316-E2B8F43E710F@planet.nl> On 14 Feb 2017, at 15:14 , Noel Chiappa wrote: >> From: Paul Ruizendaal > >> Actually, research Unix does save the complete state of a process and >> could back up the PC. The reason that it doesn't work is in the syscall >> API design, using registers to pass values etc. If all values were >> passed on the stack it would work. > > Sorry, I don't follow this? > > The problem with 'backing up the PC' is that you 'sort of' have to restore the > arguments to the state they were in at the time the system call was first > made. This is actually easier if the arguments are in registers. Yeah, you're right. I was thinking of the 2.9BSD code which only does the backup in certain cases and when stack parameter mode was used (the 0200 bit), but stating it like I did is indeed incomplete to say the least. Another difficulty in stock V6 would be code like this: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/chmod.s where the data at label 9: could be overwritten by a signal handler and re-executing the sys call would not work as intended. From jnc at mercury.lcs.mit.edu Wed Feb 15 01:40:04 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 14 Feb 2017 10:40:04 -0500 (EST) Subject: [TUHS] Another odd comment in V6 Message-ID: <20170214154004.6393A18C0A2@mercury.lcs.mit.edu> > From: Lars Brinkhoff > Nick Downing writes: >> By contrast the MIT guy probably was working with a much smaller/more >> economical system that didn't maintain a kernel stack per process. I'm not sure I'd call ITS 'smaller'... :-) > PCLSRing is a feature of MIT' ITS operating system, and it does have a > separate stack for the kernel. I wasn't sure if there was a separate kernel stack for each process; I checked the ITS source, and there is indeed a separate stack per process. There are also three other stacks in the kernel that are used from time to time (look for 'MOVE P,' for places where the SP is loaded). Oddly enough, it doesn't seem to ever _save_ the SP - there are no 'MOVEM P,' instructions that I could find! Noel From random832 at fastmail.com Wed Feb 15 01:48:13 2017 From: random832 at fastmail.com (Random832) Date: Tue, 14 Feb 2017 10:48:13 -0500 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <20170214141424.A5BC518C0A2@mercury.lcs.mit.edu> References: <20170214141424.A5BC518C0A2@mercury.lcs.mit.edu> Message-ID: <1487087293.1746007.880694176.29A6CC14@webmail.messagingengine.com> On Tue, Feb 14, 2017, at 09:14, Noel Chiappa wrote: > Without the proper design of the system call interface, this can be hard - how > does the system distinguish between the _first_ attempt at a system call (in > which the 'already done' count is 0), and a _later_ attempt? If the user passes > in the 'already done' count, it's pretty straightforward - otherwise, not so > much! You could return the address of the last character read, and let the user code do the math. I'm a bit confused though from a practical point of view where this comes up. If the terminal is in raw/cbreak mode, the user code must handle a "partial" read anyway, so returning five bytes is fine. If it's in canonical mode, the system call does not copy characters into the user buffer until they have pressed enter. Maybe there's some other case other than reading from a terminal that it makes sense for, but I couldn't think of any while writing this post. From random832 at fastmail.com Wed Feb 15 01:50:59 2017 From: random832 at fastmail.com (Random832) Date: Tue, 14 Feb 2017 10:50:59 -0500 Subject: [TUHS] Another odd comment in V6 In-Reply-To: References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl> <868tp8kgxo.fsf@molnjunk.nocrew.org> Message-ID: <1487087459.1747940.880726560.386E6275@webmail.messagingengine.com> On Tue, Feb 14, 2017, at 09:18, Nick Downing wrote: > Having a hypothetical system with a very slow disk (or fast > CPU) in which disk accesses are blocking, would break many programs. > cheers, Nick That's not very hypothetical, but it is probably the reason disk access (and even access to regular files on networked filesystems) isn't interruptible, and non-blocking I/O useless in such situations, on some modern systems. From crossd at gmail.com Wed Feb 15 02:06:20 2017 From: crossd at gmail.com (Dan Cross) Date: Tue, 14 Feb 2017 11:06:20 -0500 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <1487087293.1746007.880694176.29A6CC14@webmail.messagingengine.com> References: <20170214141424.A5BC518C0A2@mercury.lcs.mit.edu> <1487087293.1746007.880694176.29A6CC14@webmail.messagingengine.com> Message-ID: On Tue, Feb 14, 2017 at 10:48 AM, Random832 wrote: > On Tue, Feb 14, 2017, at 09:14, Noel Chiappa wrote: > > Without the proper design of the system call interface, this can be hard > - how > > does the system distinguish between the _first_ attempt at a system call > (in > > which the 'already done' count is 0), and a _later_ attempt? If the user > passes > > in the 'already done' count, it's pretty straightforward - otherwise, > not so > > much! > > You could return the address of the last character read, and let the > user code do the math. > > I'm a bit confused though from a practical point of view where this > comes up. If the terminal is in raw/cbreak mode, the user code must > handle a "partial" read anyway, so returning five bytes is fine. If it's > in canonical mode, the system call does not copy characters into the > user buffer until they have pressed enter. Maybe there's some other case > other than reading from a terminal that it makes sense for, but I > couldn't think of any while writing this post. > Reading is sort of a bad example; the mechanism shines much more brightly when one considers the write case. Consider typing a file out to a (slow - recall these systems were designed in the 70s when 300 BAUD terminals were considered fast and 1200 was downright zippy) terminal device. The user may interrupt and suspend the file-printing program in order to do something else for a time, and then want to resume output where it left off. The beauty of the ITS PCLSR mechanism is that it handles this case transparently: the system backs up the PC and adjusts the system call arguments so that when the program is resumed it automatically re-invokes the system call such that it continues printing where it left off, with no need for the application to care. An aside: The Gabriel papers elaborated on this, discussing the tradeoff between the Unix approach and ITS and suggesting that the Unix approach has better survivability characteristics. It's easier to get the Unix mechanism "right", whereas ITS's implementation took many pages of assembly language code (I recall him having a quip along the lines of, "and it probably isn't all right"). One of the interesting things about Gabriel's writing is that he acknowledges that the definition of "correct" varies and is subjective and takes into account a good deal of taste and other "soft" characteristics. The MIT folks who worked on ITS preferred their approach because they saw it as being more obviously "correct", while the Unix folks felt the same way, despite the obvious differences between the two. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnc at mercury.lcs.mit.edu Wed Feb 15 02:17:08 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 14 Feb 2017 11:17:08 -0500 (EST) Subject: [TUHS] Another odd comment in V6 Message-ID: <20170214161708.C298A18C0A2@mercury.lcs.mit.edu> > From: Random832 > You could return the address of the last character read, and let the > user code do the math. Yes, but that's still 'design the system call to work with interrupted and re-started system calls'. > If the terminal is in raw/cbreak mode, the user code must handle a > "partial" read anyway, so returning five bytes is fine. As in, if a software interrupt happens after 5 characters are read in, just terminate the read() call and have it return 5? Yeah, I suppose that would work. > If it's in canonical mode, the system call does not copy characters into > the user buffer until they have pressed enter. I didn't remember that; that TTY code makes my head hurt! I've had to read it (to add 8-bit input and output), but I can't remember all the complicated details unless I'm looking at it! > Maybe there's some other case other than reading from a terminal that it > makes sense for, but I couldn't think of any while writing this post. As the Bawden paper points out, probably a better example is _output_ to a slow device, such as a console. If the thing has already printed 5 characters, you can't ask for them back! :-) So one can neither i) roll the system call back to make it look like it hasn't started yet (as one could do, with input, by stuffing the characters back into the input buffer with kernel ungetc()), or ii) wait for it to complete (since that will delay delivery of the software interrupt). One can only interrupt the call (and show that it didn't complete, i.e. an error), or have re-startability (i.e. argument modification). Noel From pnr at planet.nl Wed Feb 15 20:16:01 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Wed, 15 Feb 2017 11:16:01 +0100 Subject: [TUHS] About the SPIDER network in V6 Message-ID: <4D228890-240E-419B-B8F8-4449AAA0C980@planet.nl> I have found a video by Sandy Fraser from 1994 which discusses the Spider network (but not the related Unix software). The first 30 min or so are about Spider and the ideas behind it, then it moves on to Datakit and ATM: https://www.youtube.com/watch?v=ojRtJ1U6Qzw Although the thinking behind them is very different, the "switch" on the Spider network seems to have been somewhat similar to an Arpanet IMP. Paul == On page 3 of the Research Unix reader (http://www.cs.dartmouth.edu/~doug/reader.pdf). "Sandy (A. G.) Fraser devised the Spider local-area ring (v6) and the Datakit switch (v7) that have served in the lab for over a decade. Special services on Spider included a central network file store, nfs, and a communication package, ufs." I do not recall ever seeing any SPIDER related code in the public V6 source tree. Was it ever released outside Bell Labs? From a bit of Googling I understand that SPIDER was a ATDM ring network with a supervisor allocating virtual circuits. Apparently there was only ever one SPIDER loop with 11 hosts connected, although Fraser reportedly intended to create multiple connected loops as part of his research. The papers that Fraser wrote are hard to find: lots of citations, but no copies, not even behind pay walls. The base report seems to be: A. G. FRASER, " SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974. Is that tech report available online somewhere? Tanks! Paul From cym224 at gmail.com Thu Feb 16 00:51:58 2017 From: cym224 at gmail.com (Nemo) Date: Wed, 15 Feb 2017 09:51:58 -0500 Subject: [TUHS] Mushi and Bagu Message-ID: Follow-up to Larry's "Mushi! Mushi!" story (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). I showed this to a Japanese acquaintance, who found it hilarious for a different reason. He told me that a s/w bug is "bagu" -- a semi-transliteration -- and "mushi" is "I ignore you". So corporate called, asked for status, and the technical guy said "I am going to ignore you!" and then hung up. N. From lm at mcvoy.com Thu Feb 16 01:01:39 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 15 Feb 2017 07:01:39 -0800 Subject: [TUHS] Mushi and Bagu In-Reply-To: References: Message-ID: <20170215150139.GC16647@mcvoy.com> On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote: > Follow-up to Larry's "Mushi! Mushi!" story > (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). > > I showed this to a Japanese acquaintance, who found it hilarious for a > different reason. He told me that a s/w bug is "bagu" -- a > semi-transliteration -- and "mushi" is "I ignore you". So corporate > called, asked for status, and the technical guy said "I am going to > ignore you!" and then hung up. Wow, that's even better than "Bug, bug!". Are you sure? Someone else said moshi was hi and mushi was bug. Does mushi have two meanings? From john at jfloren.net Thu Feb 16 01:04:52 2017 From: john at jfloren.net (John Floren) Date: Wed, 15 Feb 2017 08:04:52 -0700 Subject: [TUHS] Mushi and Bagu In-Reply-To: <20170215150139.GC16647@mcvoy.com> References: <20170215150139.GC16647@mcvoy.com> Message-ID: When I studied Japanese in high school, our teacher told us mushi is bug. Bagu is a literal transliteration that may be more common in actual use, but mushi certainly means bug. On Feb 15, 2017 08:01, "Larry McVoy" wrote: > On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote: > > Follow-up to Larry's "Mushi! Mushi!" story > > (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). > > > > I showed this to a Japanese acquaintance, who found it hilarious for a > > different reason. He told me that a s/w bug is "bagu" -- a > > semi-transliteration -- and "mushi" is "I ignore you". So corporate > > called, asked for status, and the technical guy said "I am going to > > ignore you!" and then hung up. > > Wow, that's even better than "Bug, bug!". Are you sure? Someone else > said moshi was hi and mushi was bug. Does mushi have two meanings? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Thu Feb 16 01:27:13 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 15 Feb 2017 10:27:13 -0500 (EST) Subject: [TUHS] Mushi and Bagu In-Reply-To: <20170215150139.GC16647@mcvoy.com> References: <20170215150139.GC16647@mcvoy.com> Message-ID: On Wed, 15 Feb 2017, Larry McVoy wrote: > On Wed, Feb 15, 2017 at 09:51:58AM -0500, Nemo wrote: >> Follow-up to Larry's "Mushi! Mushi!" story >> (http://minnie.tuhs.org/pipermail/tuhs/2017-February/008149.html). >> >> I showed this to a Japanese acquaintance, who found it hilarious for a >> different reason. He told me that a s/w bug is "bagu" -- a >> semi-transliteration -- and "mushi" is "I ignore you". So corporate >> called, asked for status, and the technical guy said "I am going to >> ignore you!" and then hung up. > > Wow, that's even better than "Bug, bug!". Are you sure? Someone else > said moshi was hi and mushi was bug. Does mushi have two meanings? > If you can believe this the Japanese version of "Pok��mon" occasionally puns on the dual meaning of "mushi" - ��ϟoҕ ("mushi wa mushi", more or less, "the bugs don't bug me"). -uso. From jnc at mercury.lcs.mit.edu Thu Feb 16 01:30:08 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 15 Feb 2017 10:30:08 -0500 (EST) Subject: [TUHS] Mushi and Bagu Message-ID: <20170215153008.5381F18C0BA@mercury.lcs.mit.edu> > From: Larry McVoy > Are you sure? Someone else said moshi was hi and mushi was bug. Does > mushi have two meanings? Yes: http://www.nihongodict.com/?s=mushi Actually, more than two! Japanese is chock-a-block with homonyms. Any given Japanese word will probably have more than one meaning. There's some story I don't quite recall about a recent Prime Minister who made a mistake of this sort - although now that I think about it, it was probably the _other_ kind of replication, which is that a given set of kanji (ideograms) usually has more than one pronunciation. (I won't go into why, see here: http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading for more.) So he was reading a speech, and gave the wrong reading for a word. There is apparently a book (or more) in Japanese, for the Japanese, that lists the common ones that cause confusion. A very complicated language! The written form is equally complicated; there are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there are several completely different written forms! Noel From downing.nick at gmail.com Thu Feb 16 02:13:39 2017 From: downing.nick at gmail.com (Nick Downing) Date: Thu, 16 Feb 2017 03:13:39 +1100 Subject: [TUHS] Mushi and Bagu In-Reply-To: <20170215153008.5381F18C0BA@mercury.lcs.mit.edu> References: <20170215153008.5381F18C0BA@mercury.lcs.mit.edu> Message-ID: Yes, I just looked it up too. http://jisho.org/search/むし States that mushi means "insect" and "the act of ignoring". (In Japanese some verbs are nouns and used with the word "suru" meaning "do"). http://jisho.org/search/ばぐ States that "bagu" means computer bug/error. That's also my recollection as they use loan words for most of these technical things. However, Japanese is NOT a complicated language. The spoken language is very simple. The grammar and sound system are basically like English but cut down and streamlined. It has a few unique features like "wa" but many of the particles like "o" and "ga" have direct translations. Where Japanese is harder to learn is the politeness levels of which there are basically 4: rude, normal, polite and ultra polite. In ultra polite there is a different vocabulary so that common actions such as seeing, going, eating etc have to use a different word, however most ultra polite language and basically all of the rude and polite language may be derived systematically from the normal. We do this in English but less rigorously. The other main thing is the writing system, well Japanese view it as a beautiful thing and highly cultured but it's not. It's actually the world's clunkiest writing system, in the 50s the Japanese government seriously tried to get rid of it and replace with Latin letters like many other sensible countries have done, and if they'd succeeded then learning Japanese would be no more difficult than say Tagalog (Filipino) or Bahasa (Indonesian/Malay). The reason they did not succeed is the many homonyms resulting from Japanese's very limited sound system (about 50 syllables compared with hundreds for English and thousands for Chinese or Vietnamese) which makes Japanese a bit confusing/slow to read when written phonetically. Note English also uses a similar system to disambiguate homonyms. cheers, Nick On Feb 16, 2017 2:30 AM, "Noel Chiappa" wrote: > > From: Larry McVoy > > > Are you sure? Someone else said moshi was hi and mushi was bug. Does > > mushi have two meanings? > > Yes: > > http://www.nihongodict.com/?s=mushi > > Actually, more than two! Japanese is chock-a-block with homonyms. Any > given Japanese word will probably have more than one meaning. > > There's some story I don't quite recall about a recent Prime Minister who > made a mistake of this sort - although now that I think about it, it was > probably the _other_ kind of replication, which is that a given set of > kanji > (ideograms) usually has more than one pronunciation. (I won't go into why, > see here: > > http://mercury.lcs.mit.edu/~jnc/prints/glossary.html#Reading > > for more.) So he was reading a speech, and gave the wrong reading for a > word. > There is apparently a book (or more) in Japanese, for the Japanese, that > lists > the common ones that cause confusion. > > A very complicated language! The written form is equally complicated; there > are two syllabaries ('hiragana' and 'katakana'), and for the kanji, there > are > several completely different written forms! > > Noel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Thu Feb 16 04:16:16 2017 From: cym224 at gmail.com (Nemo) Date: Wed, 15 Feb 2017 13:16:16 -0500 Subject: [TUHS] Mushi and Bagu In-Reply-To: References: <20170215153008.5381F18C0BA@mercury.lcs.mit.edu> Message-ID: On 15 February 2017 at 11:13, Nick Downing wrote: > Yes, I just looked it up too. I know no Japanese but I could not improve on Noel's and Nick's answers. My Japanese colleague was born in Japan and obtained his computer-engineering degrees from Japanese universities so I would defer to him. (He has lived here a few decades but married a Japanese woman and they send their kid to a special Japanese school for ex-patriats on the weekend.) N. From rudi.j.blom at gmail.com Thu Feb 16 17:28:14 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 16 Feb 2017 14:28:14 +0700 Subject: [TUHS] Mushi and Bagu Message-ID: Tonal languages are real fun. I'm living and working in Bangkok, Thailand and slightly tone deaf am still struggling. Which reminds me, regarding binary there are 10 types of people, those who understand and those who don't :-) Cheers, rudi From jsteve at superglobalmegacorp.com Thu Feb 16 19:36:06 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Thu, 16 Feb 2017 17:36:06 +0800 Subject: [TUHS] Mushi and Bagu In-Reply-To: References: Message-ID: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> Try Cantonese… 9 tones, or 10, or 12. Nobody agrees on how many which makes it all the more fun. The more I learn, the more I don’t know it just adds in more confusion. I never realized I was tondeaf until I moved to Hong Kong. Sent from Mail for Windows 10 From: Rudi Blom Sent: Friday, 17 February 2017 3:43 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Mushi and Bagu Tonal languages are real fun. I'm living and working in Bangkok, Thailand and slightly tone deaf am still struggling. Which reminds me, regarding binary there are 10 types of people, those who understand and those who don't :-) Cheers, rudi -------------- next part -------------- An HTML attachment was scrubbed... URL: From downing.nick at gmail.com Thu Feb 16 20:42:21 2017 From: downing.nick at gmail.com (Nick Downing) Date: Thu, 16 Feb 2017 21:42:21 +1100 Subject: [TUHS] Mushi and Bagu In-Reply-To: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> Message-ID: I don't think Westerners are actually tone deaf as such. It's basically that we didn't exercise our ability to tell those tones apart when we were acquiring language, so we more or less lost the opportunity to learn it when we could. Although it can be learnt later, something that happens as a very natural process during language aquisition, becomes a very artificial process involving MONTHS or YEARS in the lab listening to tapes and testing oneself and so on. Acquiring tones is somewhat similar to having perfect pitch in music. There are courses out there that claim to teach you perfect pitch. And, I believe it CAN be learnt, but it is an extraordinary amount of work and will probably slide backwards if not maintained. Anyway, I still find the phenomenon really strange and intriguing. My wife is Vietnamese and I was at her relatives' house just tonight. I spoke a little Vietnamese to her aunt and she didn't understand me at all (as usual). It's because what sounds to us identical, sounds to her like a completely different word -- so much so, that her brain doesn't even register any similarity. cheers, Nick PS OT sorry. On Thu, Feb 16, 2017 at 8:36 PM, wrote: > Try Cantonese… 9 tones, or 10, or 12. Nobody agrees on how many which makes > it all the more fun. The more I learn, the more I don’t know it just adds > in more confusion. > > > > I never realized I was tondeaf until I moved to Hong Kong. > > > > Sent from Mail for Windows 10 > > > > From: Rudi Blom > Sent: Friday, 17 February 2017 3:43 PM > To: tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Mushi and Bagu > > > > Tonal languages are real fun. I'm living and working in Bangkok, > > Thailand and slightly tone deaf am still struggling. > > > > Which reminds me, regarding binary there are 10 types of people, those > > who understand and those who don't :-) > > > > Cheers, > > rudi > > From rudi.j.blom at gmail.com Thu Feb 16 23:49:18 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Thu, 16 Feb 2017 20:49:18 +0700 Subject: [TUHS] Mushi and Bagu In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> Message-ID: The advantage of Thai is that it's character based so at least I can see the difference easily and try to replicate. Pronouncing correctly and hearing correctly is a different kettle of fish all together though. On 16/02/2017, Nick Downing wrote: > I don't think Westerners are actually tone deaf as such. It's > basically that we didn't exercise our ability to tell those tones > apart when we were acquiring language, so we more or less lost the > opportunity to learn it when we could. Although it can be learnt > later, something that happens as a very natural process during > language aquisition, becomes a very artificial process involving > MONTHS or YEARS in the lab listening to tapes and testing oneself and > so on. Acquiring tones is somewhat similar to having perfect pitch in > music. There are courses out there that claim to teach you perfect > pitch. And, I believe it CAN be learnt, but it is an extraordinary > amount of work and will probably slide backwards if not maintained. > Anyway, I still find the phenomenon really strange and intriguing. My > wife is Vietnamese and I was at her relatives' house just tonight. I > spoke a little Vietnamese to her aunt and she didn't understand me at > all (as usual). It's because what sounds to us identical, sounds to > her like a completely different word -- so much so, that her brain > doesn't even register any similarity. > cheers, Nick > PS OT sorry. > > On Thu, Feb 16, 2017 at 8:36 PM, wrote: >> Try Cantonese… 9 tones, or 10, or 12. Nobody agrees on how many which >> makes >> it all the more fun. The more I learn, the more I don’t know it just >> adds >> in more confusion. >> >> >> >> I never realized I was tondeaf until I moved to Hong Kong. >> >> >> >> Sent from Mail for Windows 10 >> >> >> >> From: Rudi Blom >> Sent: Friday, 17 February 2017 3:43 PM >> To: tuhs at minnie.tuhs.org >> Subject: Re: [TUHS] Mushi and Bagu >> >> >> >> Tonal languages are real fun. I'm living and working in Bangkok, >> >> Thailand and slightly tone deaf am still struggling. >> >> >> >> Which reminds me, regarding binary there are 10 types of people, those >> >> who understand and those who don't :-) >> >> >> >> Cheers, >> >> rudi >> >> > From jsteve at superglobalmegacorp.com Fri Feb 17 21:30:49 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Fri, 17 Feb 2017 19:30:49 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> Message-ID: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> While testing a crazy project I wanted to get working I came across this ancient link: http://altavista.superglobalmegacorp.com/usenet/b182/comp/os/mach/542.txt --------8<--------8<--------8<--------8< Newsgroups: comp.os.mach Subject: Mach for i386 - want to beta? Message-ID: <1364 at mtxinu.UUCP> Date: 2 Oct 90 17:12:19 GMT Reply-To: scherrer at mtxinu.COM (Deborah Scherrer) Organization: mt Xinu, Berkeley Mt Xinu is currently finishing up its release of 2.6 MSD for the i386. 2.6 MSD is a CMU-funded standard distribution of the Mach kernel, release-engineered with the following: 2.5 Mach kernel, with NFS & BSD-tahoe enhancements Transarc's AFS X11R4 most of the 4.3-tahoe BSD release Andrew Tool Kit Camelot transaction processing system Cornell's ISIS distributed programming environment most of the FSF utilities a few other nifty things --------8<--------8<--------8<--------8< Was any of this stuff ever saved? I know on the CSRG CD there is some buried source for Mach 2.5 although I haven’t seen anything on where to even start to compile it, how or even how to boot it... I know Mach is certainly not fast, nor all that ‘small’ but it’d be interesting to see a 4.3BSD on a PC! -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 18 00:22:11 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Feb 2017 09:22:11 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> Message-ID: Yes. In fact, the CMU's Mach/386 code base became the direct start for OSF/1 both the full (RI) and embedded uK (aka monolithic or mK) versions as well. The later would seed DEC Tru64 after being ported to the Alpha, but the 386 version of the mK would become Apple's Darwin. The RI (uK) version is what we used for the Intel Paragon. Anything called OSF/1 version 4 or later is based on the RI. Before that's probably mK, but you should check the readme to see which base. The joke, of course, was that microKernel, was not that micro (it was greater than 1-1.5M and used to run these on 4M 386 systems). It was cool and the research version (pure uK) is very slick and has a lot of interesting ideas. I think it's interesting to note that we did all of the core TNC development for the Paragon which was on i860 processor, on desktop 386 systems with ethernets to simulate the fabric in the supercomputer. OSF/1 uK technology worked very well, in fact; it worked so well AT&T's replacement for SVR4 was announced to be based on Chorus, which was a European rewrite using a different uKernel technology specifically to counter OSF/1. Anyway, if you do a little hunting around the archives, it is quite available. Note it will want to boot from either a floppy for a hard drive, as USB had yet to be created, so bootstrapping on more modern hardware might be take a little work. But it should work. A number of us that worked with it, are still findable and few lurk on this list. As a side note, during the OSF/UI wars, I made a plea with the late Roger Gourd (then VP of Eng at OSF) and some of the folks management team at OSF to make the OSF/1 generally available for the 386. At time, Linux was still in the .9 stages booting & installing from a 20-40 floppy disks, but still lacked networking and window system. 386BSD/FreeBSD was coming along but not quite reached its stride. The AT&T/BSDi case had just been completed so the UNIX IP question has been settled. I could not convince them it was of any value and to an extent it would have been competing with their members (HP, DEC et al). I've something thought that was a real opportunity lost. On Fri, Feb 17, 2017 at 6:30 AM, wrote: > While testing a crazy project I wanted to get working I came across this > ancient link: > > > > http://altavista.superglobalmegacorp.com/usenet/b182/comp/os/mach/542.txt > > > > --------8<--------8<--------8<--------8< > > > > Newsgroups: comp.os.mach > > Subject: Mach for i386 - want to beta? > > Message-ID: <1364 at mtxinu.UUCP> > > Date: 2 Oct 90 17:12:19 GMT > > Reply-To: scherrer at mtxinu.COM (Deborah Scherrer) > > Organization: mt Xinu, Berkeley > > Lines: 24 > > > > Mt Xinu is currently finishing up its release of 2.6 MSD for the i386. > > 2.6 MSD is a CMU-funded standard distribution of the Mach kernel, > > release-engineered with the following: > > 2.5 Mach kernel, with NFS & BSD-tahoe enhancements > > Transarc's AFS > > X11R4 > > most of the 4.3-tahoe BSD release > > Andrew Tool Kit > > Camelot transaction processing system > > Cornell's ISIS distributed programming environment > > most of the FSF utilities > > a few other nifty things > > > > --------8<--------8<--------8<--------8< > > > > Was any of this stuff ever saved? I know on the CSRG CD there is some > buried source for Mach 2.5 although I haven’t seen anything on where to > even start to compile it, how or even how to boot it... I know Mach is > certainly not fast, nor all that ‘small’ but it’d be interesting to see a > 4.3BSD on a PC! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Sat Feb 18 00:29:21 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Feb 2017 09:29:21 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> Message-ID: On Fri, Feb 17, 2017 at 6:30 AM, wrote: > ​i​ > t’d be interesting to see a 4.3BSD on a PC! ​It should have added - that's easy today. Just buy an Apple Mac or create an HackenTosh, then ignore the Apple UI, just run from the terminal. Darwin is Mach 2.5, with BSD under the covers. Although to be fair, over the years, that have more and more diverted from a lot of core UNIX in many things in the back, but frankly, I do find it more UNIX-like than not and 40+ years of "muscle memory" in my fingers mostly get the right results. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From atindra at mindspring.com Sat Feb 18 01:47:05 2017 From: atindra at mindspring.com (Atindra Chaturvedi) Date: Fri, 17 Feb 2017 10:47:05 -0500 (GMT-05:00) Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <27206820.3831.1487346425408@elwamui-huard.atl.sa.earthlink.net> An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Sat Feb 18 02:13:19 2017 From: chet.ramey at case.edu (Chet Ramey) Date: Fri, 17 Feb 2017 11:13:19 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> Message-ID: <82f226ca-45b9-26d2-1c67-5885c3f3c964@case.edu> On 2/17/17 9:22 AM, Clem Cole wrote: > the 386 version of the mK would become Apple's Darwin. Filtered through NeXT. -- ``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://cnswww.cns.cwru.edu/~chet/ From jnc at mercury.lcs.mit.edu Sat Feb 18 02:51:43 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 17 Feb 2017 11:51:43 -0500 (EST) Subject: [TUHS] Early Internet work Message-ID: <20170217165143.3B16B18C092@mercury.lcs.mit.edu> > OK, we're starting to get through all the clearances needed to release > the non-MIT Unix systems We have now completed (as best we can) the OK's for the 'BBN TCP/IP V6 Unix', and I finally bestirred myself to add in the documentation I found for it, and crank out a tarball, available here: http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/bbn.tar It includes all the documentation files I found for the Rand and BBN code (in the ./doc directory); included are the original NROFF source to the two Rand publications about ports, and several BBN reports. This is an early TCP/IP Unix system written at BBN. It was not the first TCP/IP Unix; that was one done at BBN in MACRO-11, based on a TCP done in MACRO-11 by Jim Mathis at SRI for the TIU (Terminal nterface Unit). This networking code is divided into three main groups. First there is code for the kernel, which includes IPC enhancements to Unix, including Rand ports, as well as further extensions to that done at BBN for the earlier TCP - the capac() and await() calls. It also includes a IMP interface driver (the code only interfaced to the ARPANET at this point in time). Next, TCP is implemented as a daemon which ran as a single process which handled all the connections. Finally, other programs implement applications; TELNET is the only one provided at this point in time. The original port code was written by Steven Zucker at Rand; the extensions done at BBN were by Jack Haverty. The TCP was mostly written by Mike Wingfield, apparently with some assistance by Jon Dreyer. Dan Franklin apparently wrote the TELNET. Next, I'll be working on the MIT-CSR machine. That's going to take quite a while - it's a whole system, with a lot of applications. It does include FTP, SMTP, etc, though, so it will be a good system for anyone who wants to run V6 with TCP on a /23. We'll have to write device drivers for whatever networking cards are out there, though. Noel From jnc at mercury.lcs.mit.edu Sat Feb 18 02:55:07 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 17 Feb 2017 11:55:07 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <20170217165507.A8BCE18C092@mercury.lcs.mit.edu> > From: Atindra Chaturvedi > including the Mt. Xinu Mach 386 distro. I still have it and will happily > send it to the archives Oh, that's fantastic. It's so important that everyone who has these chunk of computing history make sure they make it into repositories! > I have my books and the software for all the cool stuff as it came out > in those days - some day I will compile it and send it to where it can > be better used or archived as history. Please do! And everyone else, please emulate! (I'm already doing my bit! :-)p Noel From lm at mcvoy.com Sat Feb 18 03:06:15 2017 From: lm at mcvoy.com (Larry McVoy) Date: Fri, 17 Feb 2017 09:06:15 -0800 Subject: [TUHS] Early Internet work In-Reply-To: <20170217165143.3B16B18C092@mercury.lcs.mit.edu> References: <20170217165143.3B16B18C092@mercury.lcs.mit.edu> Message-ID: <20170217170615.GR20932@mcvoy.com> This is some fascinating reading. Read the stuff in ports/ipc. On Fri, Feb 17, 2017 at 11:51:43AM -0500, Noel Chiappa wrote: > > OK, we're starting to get through all the clearances needed to release > > the non-MIT Unix systems > > We have now completed (as best we can) the OK's for the 'BBN TCP/IP V6 Unix', > and I finally bestirred myself to add in the documentation I found for it, > and crank out a tarball, available here: > > http://ana-3.lcs.mit.edu/~jnc/tech/pdp11/tmp/bbn.tar > > It includes all the documentation files I found for the Rand and BBN code (in > the ./doc directory); included are the original NROFF source to the two Rand > publications about ports, and several BBN reports. > > This is an early TCP/IP Unix system written at BBN. It was not the first > TCP/IP Unix; that was one done at BBN in MACRO-11, based on a TCP done in > MACRO-11 by Jim Mathis at SRI for the TIU (Terminal nterface Unit). > > This networking code is divided into three main groups. First there is > code for the kernel, which includes IPC enhancements to Unix, including > Rand ports, as well as further extensions to that done at BBN for the > earlier TCP - the capac() and await() calls. It also includes a IMP > interface driver (the code only interfaced to the ARPANET at this point in > time). Next, TCP is implemented as a daemon which ran as a single process > which handled all the connections. Finally, other programs implement > applications; TELNET is the only one provided at this point in time. > > The original port code was written by Steven Zucker at Rand; the extensions > done at BBN were by Jack Haverty. The TCP was mostly written by Mike > Wingfield, apparently with some assistance by Jon Dreyer. Dan Franklin > apparently wrote the TELNET. > > > Next, I'll be working on the MIT-CSR machine. That's going to take quite a > while - it's a whole system, with a lot of applications. It does include FTP, > SMTP, etc, though, so it will be a good system for anyone who wants to run V6 > with TCP on a /23. We'll have to write device drivers for whatever networking > cards are out there, though. > > Noel -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From imp at bsdimp.com Sat Feb 18 03:23:16 2017 From: imp at bsdimp.com (Warner Losh) Date: Fri, 17 Feb 2017 10:23:16 -0700 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> Message-ID: On Fri, Feb 17, 2017 at 7:29 AM, Clem Cole wrote: > > On Fri, Feb 17, 2017 at 6:30 AM, wrote: >> >> i >> t’d be interesting to see a 4.3BSD on a PC! > > > It should have added - that's easy today. Just buy an Apple Mac or create > an HackenTosh, then ignore the Apple UI, just run from the terminal. Darwin > is Mach 2.5, with BSD under the covers. Although to be fair, over the > years, that have more and more diverted from a lot of core UNIX in many > things in the back, but frankly, I do find it more UNIX-like than not and > 40+ years of "muscle memory" in my fingers mostly get the right results. You could install FreeBSD 1 and have no UI to ignore. Most of BSD 4.3 compiles under it (though with some hacking iirc) and the difference in user experience between the 4.3 and 4.4 kernels isn't huge. Going the other way is harder (running 4.4 in 4.3) since the 4.4 userland uses a lot of kernel features new in 4.4. It was based on the net2 tape with missing bits filled in. Warner From clemc at ccc.com Sat Feb 18 06:04:28 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Feb 2017 15:04:28 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170217165507.A8BCE18C092@mercury.lcs.mit.edu> References: <20170217165507.A8BCE18C092@mercury.lcs.mit.edu> Message-ID: On Fri, Feb 17, 2017 at 11:55 AM, Noel Chiappa wrote: > > > Please do! And everyone else, please emulate! (I'm already doing my bit! > :-)p > ​Indeed - many, many thanks!!!! Clem​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Feb 18 10:05:31 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Feb 2017 10:05:31 +1000 Subject: [TUHS] Unix Archive: how to upload Message-ID: <20170218000531.GA17910@minnie.tuhs.org> Hi all, to quickly answer one recent question. If you want to upload something Unix-related for me to archive, you can anonymous ftp upload to ftp://minnie.tuhs.org/incoming/ Nobody can list the directory contents, so it's good for sensitive files. If you upload something called xyz, can you also add xyz_Readme which might describe e.g. what the thing is, where it came from, file format (e.g. floppy images), how to install it, any other useful information. If you think it can be added to the public Unix Archive at http://www.tuhs.org/Archive/, or if the file definitely can't be added and I should move it to the hidden archive, also say so. Also feel free not to disclose your identity. Cheers, Warren P.S Work has become busy this year. I might call for people to help out with the curation. Any volunteers? Discretion is a pre-requisite. From wkt at tuhs.org Sat Feb 18 10:12:44 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Feb 2017 10:12:44 +1000 Subject: [TUHS] Reorganising the Unix Archive? Message-ID: <20170218001244.GB17910@minnie.tuhs.org> Hi all, I think the current layout of the Unix Archive at http://www.tuhs.org/Archive/ is starting to show its limitations as we get more systems and artifacts that are not specifically PDP-11 and Vax. I'm after some suggestions on how to reorganise the archive. Obviously there are many ways to do this. Just off the top of my head, top level: - Applications: things which run at user level - Systems: things which have a kernel - Documentation - Tools: tools which can be used to deal with systems and files Under Applications, several directories which hold specific things. If useful, perhaps directories that collect similar things. Under Systems, a set of directories for specific organisations (e.g. Research, USL, BSD, Sun, DEC etc.). In each of these, directories for each system. Under Documentation, several directories which hold specific things. If useful, perhaps directories that collect similar things. Under Tools, subdirectories for Disk, Tape, Emulators etc., then subdirs for the specific tools. Does this sound OK? Any refinements or alternate suggestions? Cheers, Warren From wkt at tuhs.org Sat Feb 18 10:21:46 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Feb 2017 10:21:46 +1000 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <20170218001244.GB17910@minnie.tuhs.org> References: <20170218001244.GB17910@minnie.tuhs.org> Message-ID: <20170218002146.GB20586@minnie.tuhs.org> On Sat, Feb 18, 2017 at 10:12:44AM +1000, Warren Toomey wrote: > - Applications: things which run at user level > - Systems: things which have a kernel > - Documentation > - Tools: tools which can be used to deal with systems and files Clarification. Systems would be whole systems like 7th Edition, 4.3BSD etc. Applications would be things that were not distributed in a system, e.g. C-News. Documentation would be also material not part of a whole system, e.g. the AUUG newsletters. Cheers, Warren From clemc at ccc.com Sat Feb 18 10:40:16 2017 From: clemc at ccc.com (Clem Cole) Date: Fri, 17 Feb 2017 19:40:16 -0500 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <20170218001244.GB17910@minnie.tuhs.org> References: <20170218001244.GB17910@minnie.tuhs.org> Message-ID: On Fri, Feb 17, 2017 at 7:12 PM, Warren Toomey wrote: > Under Systems, a set of directories for specific organisations (e.g. > Research, > ​ ​ > USL, BSD, Sun, DEC etc.). In each of these, directories for each system. > ​Sounds good, although I might offer one slight twist. I think organizations should be the higher bit not systems, doc etc.... So you have DEC, AT&T, UCB, MIT, USENIX, UI, OSF, *etc..*.. Under AT&T you will have research and summit.​ Under UCB, you have CSRG, CAD, Ingress etc.. where you know things came from different teams. Same for MIT or the like. BTW: the anal fixation / some of the arguments we have had, I also feel that Year of Distribution probably needs to be in the name if possible (certainly in metadata or at least an explanatory README). For things like the USENIX tapes that's easier - because they were done by year. Anyway - its only under these directories that then have the split of doc, systems, *etc.*. If there is cross linking, you certainly can do a little if that makes sense. But I think that It will be easier keep each collection from where and when it came to help cement the origin & time and make it easier for people to find things. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Sat Feb 18 11:09:40 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Feb 2017 11:09:40 +1000 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: References: <20170218001244.GB17910@minnie.tuhs.org> Message-ID: <20170218010940.GA24036@minnie.tuhs.org> On Fri, Feb 17, 2017 at 07:40:16PM -0500, Clem Cole wrote: > Sounds good, although I might offer one slight twist. I think > organizations should be the higher bit not systems, doc etc.... I'll disagree, mainly because of what we have currently in terms of applications and documentation. At present, in these categories we have: - Circuit_Design Festoon Portable_CC Shoppa_Tapes Usenix_77 Early_C_Compilers Macro-11 README Software_Tools Algol68 Em_Editor OpenLook Ritter_Vi Spencer_Tapes - AUUGN Books Emails OralHistory PUPS Papers TUHS Unix_Review - various system setup docs Except for the last category, all the existing applications and documentation are not easily classifiable into . So I think it would be better to have a generic top-level Applications and Documentation directories. We can move the system setup docs into specific system areas. I don't mind having top-level directories, but I fear that in the long term there will be lots of them. So it's a question: do we clutter up the top level with a heap of directories, or do we have a heap of Systems/ directories. I'd prefer the latter. > I also feel that Year of Distribution probably needs to be in the > name if possible (certainly in metadata or at least an explanatory > README). For things like the USENIX tapes that's easier - because they > were done by year. My preference is to keep date details in metadata and not in directory names. There will be some things which are hard to date or whose date is in dispute, and there may be things which are aggregates of work done over several years. But I'll admit that there is not enough metadata and little consistency in the metadata (e.g. Readme files) that are currently in the Archive. Cheers & thanks for the feedback, Warren From doug at cs.dartmouth.edu Sat Feb 18 13:30:12 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 17 Feb 2017 22:30:12 -0500 Subject: [TUHS] Reorganising the Unix Archive? Message-ID: <201702180330.v1I3UCHj018425@coolidge.cs.Dartmouth.EDU> If things are filed by provenance, one useful kind of cross-linking would be a generic tree whose "leaves" link to all the versions of the "same" file. All the better if it could also indicate the degree of relatedness of the versions--perhaps an inferred evolutionary tree or a shaded grid, where the intensity of grid point x,y shows the relatedness of x and y. doug From wkt at tuhs.org Sat Feb 18 14:40:57 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 18 Feb 2017 14:40:57 +1000 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <201702180330.v1I3UCHj018425@coolidge.cs.Dartmouth.EDU> References: <201702180330.v1I3UCHj018425@coolidge.cs.Dartmouth.EDU> Message-ID: <16138E23-BFB8-47F8-B41B-2D2AE8DD8F46@tuhs.org> That's what the Unix Tree is for! http://minnie.tuhs.org/UnixTree Also, Diomidis' Github repository https://github.com/dspinellis/unix-history-repo Cheers, Warren On 18 February 2017 1:30:12 pm AEST, Doug McIlroy wrote: >If things are filed by provenance, one useful kind of >cross-linking would be a generic tree whose "leaves" >link to all the versions of the "same" file. All the >better if it could also indicate the degree of >relatedness of the versions--perhaps an inferred >evolutionary tree or a shaded grid, where the >intensity of grid point x,y shows the relatedness >of x and y. > >doug -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Sun Feb 19 15:48:28 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sun, 19 Feb 2017 13:48:28 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <0F0B9BFC06289346B88512B91E55670D2FF7@EXCHANGE> Wow that'd be incredible!!! I'd love to see how Mach 2.5/4.3BSD compared to the Mach 3.0/Lites 1.1 that is as close as I've been able to find... I know about the NeXT stuff, as I have NS 3.3 installed although running it on 'white' hardware gets harder and harder as PC's get newer and the IDE controllers just are too feature ful, and too new for NS to deal with, beyond it can only use 2GB disks properly. Obviously with no source or any way to get in to write drivers or update the FFS on NeXTSTEP it's basically stuck in those P1 era machines, or emulation. There is even previous a 68030/68040 cube based emulator for running all the 'native' versions. archive what you can, I can only contribute minro things I stubmle uppon, mostly by accident. > ---------- > From: Atindra Chaturvedi > Reply To: Atindra Chaturvedi > Sent: Friday, February 17, 2017 11:47 PM > To: jsteve at superglobalmegacorp.com; tuhs at minnie.tuhs.org > Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other > > Amazing - brings back memories. I was a Unix "enterprise IT user" not a > "kernel developer guru" back in the day working at a pharmaceutical > company and was responsible for moving the company off IBM 3090 and SNA to > Unix and TCP/IP. > > Used to buy the new Unix-like releases as they were available to stay > current - including the Mt. Xinu Mach 386 distro. I still have it and will > happily send it to the archives - if I can be guided a bit. > > Ran the Mt. Xinu for many years as my home machine - it is pre-SCSI for > booting ( needs ESDI disks ) but was very stable. So will need tweaking to > boot/install. > > Happy to have worked in the mid-70 - 80's era when there were huge changes > in computer hardware and software technology. I have my books and the > software for all the cool stuff as it came out in those days - some day I > will compile it and send it to where it can be better used or archived as > history. > > Atindra. > > > > -----Original Message----- > From: jsteve at superglobalmegacorp.com > Sent: Feb 17, 2017 6:30 AM > To: "tuhs at minnie.tuhs.org" > Subject: [TUHS] Mach for i386 / Mt Xinu or other > > > > While testing a crazy project I wanted to get working I came across > this ancient link: > > > > > http://altavista.superglobalmegacorp.com/usenet/b182/comp/os/mach/542.txt > > > > --------8<--------8<--------8<--------8< > > > > Newsgroups: comp.os.mach > > Subject: Mach for i386 - want to beta? > > Message-ID: <1364 at mtxinu.UUCP> > > Date: 2 Oct 90 17:12:19 GMT > > Reply-To: scherrer at mtxinu.COM (Deborah Scherrer) > > Organization: mt Xinu, Berkeley > > Lines: 24 > > > > Mt Xinu is currently finishing up its release of 2.6 MSD for the > i386. > > 2.6 MSD is a CMU-funded standard distribution of the Mach kernel, > > release-engineered with the following: > > 2.5 Mach kernel, with NFS & BSD-tahoe enhancements > > Transarc's AFS > > X11R4 > > most of the 4.3-tahoe BSD release > > Andrew Tool Kit > > Camelot transaction processing system > > Cornell's ISIS distributed programming environment > > most of the FSF utilities > > a few other nifty things > > > > --------8<--------8<--------8<--------8< > > > > Was any of this stuff ever saved? I know on the CSRG CD there is > some buried source for Mach 2.5 although I haven't seen anything on where > to even start to compile it, how or even how to boot it... I know Mach is > certainly not fast, nor all that 'small' but it'd be interesting to see a > 4.3BSD on a PC! > > From random832 at fastmail.com Sun Feb 19 03:17:26 2017 From: random832 at fastmail.com (Random832) Date: Sat, 18 Feb 2017 12:17:26 -0500 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <20170218001244.GB17910@minnie.tuhs.org> References: <20170218001244.GB17910@minnie.tuhs.org> Message-ID: <1487438246.694021.885279616.4CF2257D@webmail.messagingengine.com> On Fri, Feb 17, 2017, at 19:12, Warren Toomey wrote: > Under Tools, subdirectories for Disk, Tape, Emulators etc., then subdirs > for the specific tools. One thing that might be nice is a directory specifically for archive extraction tools for modern systems. I've probably reinvented ar11 half a dozen times. From random832 at fastmail.com Sun Feb 19 03:19:06 2017 From: random832 at fastmail.com (Random832) Date: Sat, 18 Feb 2017 12:19:06 -0500 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <16138E23-BFB8-47F8-B41B-2D2AE8DD8F46@tuhs.org> References: <201702180330.v1I3UCHj018425@coolidge.cs.Dartmouth.EDU> <16138E23-BFB8-47F8-B41B-2D2AE8DD8F46@tuhs.org> Message-ID: <1487438346.694147.885280512.2E304CC1@webmail.messagingengine.com> On Fri, Feb 17, 2017, at 23:40, Warren Toomey wrote: > That's what the Unix Tree is for! > http://minnie.tuhs.org/UnixTree One thing I noticed (I was going through versions of the "bcd" program and various other early-BSD utilities) is that the "similar files" dropdown doesn't seem to show up in some cases. From doug at cs.dartmouth.edu Sun Feb 19 04:49:50 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 18 Feb 2017 13:49:50 -0500 Subject: [TUHS] Reorganising the Unix Archive? Message-ID: <201702181849.v1IInoD2024605@coolidge.cs.Dartmouth.EDU> > That's what the Unix Tree is for! Yes, but it doesn't have cross links as far as I know. What I have in mind is effectively one more entry in the root. Call it "union" perhaps. In a leaf of that tree, say /union/usr/src/cmd/find, will ne a page that links to all the "find sources in the other systems. I don't know the range of topologies in the Unix Tree. For example, some systems may have /src while others have /usr/src. That could be hidden completely by simply not revealing the path names. Alternatively every level in the union tree could record its cousins in the various systems, as well as its children in the union system. Doug From cym224 at gmail.com Sun Feb 19 08:25:42 2017 From: cym224 at gmail.com (Nemo) Date: Sat, 18 Feb 2017 17:25:42 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> Message-ID: On 17 February 2017 at 09:29, Clem Cole wrote: [...] > It should have added - that's easy today. Just buy an Apple Mac or create > an HackenTosh, then ignore the Apple UI, just run from the terminal. Darwin > is Mach 2.5, with BSD under the covers. Although to be fair, over the > years, that have more and more diverted from a lot of core UNIX in many > things in the back, but frankly, I do find it more UNIX-like than not and > 40+ years of "muscle memory" in my fingers mostly get the right results. Hhhmmm... this was thrashed out last month, starting at http://minnie.tuhs.org/pipermail/tuhs/2017-January/007608.html #6-) > > Clem > From doug at cs.dartmouth.edu Sun Feb 19 10:12:16 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 18 Feb 2017 19:12:16 -0500 Subject: [TUHS] Reorganising the Unix Archive? Message-ID: <201702190012.v1J0CGml026966@coolidge.cs.Dartmouth.EDU> OMG. I don't know how many times I've consulted the Unix Tree and blissfully ignored the cross-links that come at the top of every file--I'm so intent on the content. Apologies for cluttering the mailing list about a solved topic. Doug From jsteve at superglobalmegacorp.com Sun Feb 19 16:20:15 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Sun, 19 Feb 2017 14:20:15 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> Message-ID: <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> True, but It’s not 4.3 BSD … I was hoping for something vintage of the era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the VAX…. And historical is far more interesting than something I can just go buy retail…. Speaking as someone who’s own a NeXT, and even bought OS X Server 1.0 on release. From: Nemo Sent: Monday, 20 February 2017 6:41 AM To: Clem Cole Cc: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other On 17 February 2017 at 09:29, Clem Cole wrote: [...] > It should have added - that's easy today. Just buy an Apple Mac or create > an HackenTosh, then ignore the Apple UI, just run from the terminal. Darwin > is Mach 2.5, with BSD under the covers. Although to be fair, over the > years, that have more and more diverted from a lot of core UNIX in many > things in the back, but frankly, I do find it more UNIX-like than not and > 40+ years of "muscle memory" in my fingers mostly get the right results. Hhhmmm... this was thrashed out last month, starting at http://minnie.tuhs.org/pipermail/tuhs/2017-January/007608.html #6-) > > Clem > -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Feb 19 17:01:04 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 19 Feb 2017 02:01:04 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: On Sun, 19 Feb 2017, jsteve at superglobalmegacorp.com wrote: > True, but It’s not 4.3 BSD … I was hoping for something vintage of the > era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the > VAX…. > > And historical is far more interesting than something I can just go buy > retail…. Speaking as someone who’s own a NeXT, and even bought OS X > Server 1.0 on release. Isn't Jolix essentially Reno, if a 4.3BSD is what you're after? -uso. From jsteve at superglobalmegacorp.com Sun Feb 19 23:46:47 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sun, 19 Feb 2017 21:46:47 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: It's a net/2 something much later. I'm interested in what would have been an encumbered pre net/2 release of 4.2 or 4.3 for the i386... I found out that CMU had BSD running on Mach, and I suspect there is straight ports as well. It's that evelotionary dead end of 386 UNIX from 1986-1991 that interests me as they clearly could have had the market but they obviously blew it. On February 19, 2017 3:01:04 PM GMT+08:00, Steve Nickolas wrote: >On Sun, 19 Feb 2017, jsteve at superglobalmegacorp.com wrote: > >> True, but It’s not 4.3 BSD … I was hoping for something vintage of >the >> era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the >> VAX…. >> >> And historical is far more interesting than something I can just go >buy >> retail…. Speaking as someone who’s own a NeXT, and even bought OS X >> Server 1.0 on release. > >Isn't Jolix essentially Reno, if a 4.3BSD is what you're after? > >-uso. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Feb 20 01:44:32 2017 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 19 Feb 2017 07:44:32 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: <20170219154432.GA19243@mcvoy.com> On Sun, Feb 19, 2017 at 09:46:47PM +0800, Jason Stevens wrote: > It's a net/2 something much later. I'm interested in what would have > been an encumbered pre net/2 release of 4.2 or 4.3 for the i386... > I found out that CMU had BSD running on Mach, and I suspect there is > straight ports as well. It's that evelotionary dead end of 386 UNIX > from 1986-1991 that interests me as they clearly could have had the > market but they obviously blew it. So before I start, let me state for the record I'm a died in the wool BSD guy. I grew up on BSD at University and then went to Sun and worked on SunOS 4.x which was a BSD derived OS (many people at the time called it "Bugfixed BSD" though it was more than that). In my opinion, 386 BSD and friends lost because they didn't have a Linus. They needed a strong leader that would provide direction to rally around. Jolitz, as much as I like him, was not that leader. Nor was Jordan or Theo or Chris. And BSDi, don't get me started. A friend of mine once said "They couldn't decide who was going to drive the big red fire truck, so instead they each got to sit on and drive their own personal toy fire truck". The mental image always fit for me. It's a big part of why I threw my support behind Linux. A lot of the BSD crowd considered me a "traitor" for doing so at the time. Shrug. Linus had the qualities of being a good programmer, a good architect, and a good manager. I've never seen all 3 in a person before or since. From clemc at ccc.com Mon Feb 20 07:19:56 2017 From: clemc at ccc.com (Clem Cole) Date: Sun, 19 Feb 2017 16:19:56 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: On Sun, Feb 19, 2017 at 1:20 AM, wrote: > True, but It’s not 4.3 BSD … I was hoping for something vintage of the > era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the VAX…. > ​Fair enough... the Mt Xinu version is pretty much the CMU version unadorned. Which mean that it is a 4.3BSD kernel, with the BSD based MMU code ripped out and replaced with the CMU code, and the Mach interfaces (ney RIG - Mach's and Accent's predecessor) messaging system spliced into it; then the whole mess was built back up using a 4.3BSD user space (and on top of the i386, an Intel developed boot system - which is a different story I'll not repeat at this time - but thankfully was common to all the UNIX systems of the day because Intel developed and make it available to community at large). The other option which I would suggest to look at is the OSF/1 mk for the i386 (monolithic) about version 3x which as I said forked off the Alpha line and a couple of other systems. The i386 version of OSF/1 supports the same chips (i386/i486/Pentium) at the CMU version, it also comes with more HW device support (disk, tape, network, display *et al*), than the CMU/Mt Xinu version -- including most importantly SCSI support by default, which is why is might be a little easier to work on today's HW and VMs. When I last used it, it lacked USB support; but that was being worked on around the time I started doing other things so even that might even be available today. FWIW: OSF/1 also started with 4.3BSD userspace, but it had a lot of work done to it to updating it - adding the Sys V commands that BSD lacked those days and adding Sys V options to many commands. * i.e.* its user space is a tad more "complete" / "wider" than pure 4.3BSD and again makes it a little easier to complete. Note that the user space commands from the mk would become the basis for Tru64, HP/UX and later versions of AIX. And also the OSF/1 version will have better Graphics, Motif and a much better GUI options all around that Mt Xinu, which alone may be it easier to work. As I also said elsewhere, the uK or Research Institute (RI) version is a tad more fun to play with. It's a real kernel architecture moving things like file systems *et al* in user space. But you can do do things like start up multiple system interfaces. LCC had their DOS/Win95 interface was actually developed running instead of as a VM like it did for the basic mk code, but in as "second server" but I do not think they ever sold it. The other thing the RI never did, was the uk still has the pager and all the networking code in the kernel, so the uk, is hardly 'micro' in size. There is a OSF Version 4 and maybe even version 5 (I've forgotten, if some one remembers - please correct me). The OSF RI folks were trying to rewrite it a bit in C++ as I recall, again this part of the UI vs OSF wars of the day and Chorus has rewritten there version from Pascal to C++, and IIRC the RI was trying to counter that. I don't remember if that version of the uk ever saw the light of day. Anyway, no matter which is the 3 code streams you pick, Mt Xinu, OSF/1 mk or uk one hardest problems for today will be that the compiler is of course extremely old by today's standards, and you are probably going to run it some walls in that area faster than you might think. That said, if you are willing to deal with the compiler as it comes, non of them should be very high, or hard to get clear, but some are likely to take some work. Have fun and good luck and let us know if you can get any of these running. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Mon Feb 20 08:39:57 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sun, 19 Feb 2017 14:39:57 -0800 Subject: [TUHS] Any BSDi interest? Message-ID: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> Hi, Forgot I'm sitting on a lot of BSDi sources/binaries. Is there any interest in this aside from me? ;) -- Cory Smelosky b4 at gewt.net From krewat at kilonet.net Mon Feb 20 10:09:14 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 19 Feb 2017 19:09:14 -0500 Subject: [TUHS] Any BSDi interest? In-Reply-To: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> Message-ID: <8df70e17-f615-871e-7a70-6118287a0ede@kilonet.net> If you don't archive it, you're a luser. :) On 2/19/2017 5:39 PM, Cory Smelosky wrote: > Hi, > > Forgot I'm sitting on a lot of BSDi sources/binaries. > > Is there any interest in this aside from me? ;) > From downing.nick at gmail.com Mon Feb 20 10:29:15 2017 From: downing.nick at gmail.com (Nick Downing) Date: Mon, 20 Feb 2017 11:29:15 +1100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: This is all very interesting, and I take it the source is available? I saw here: http://shiftleft.com/mirrors/ifctfvax.harhan.org/pub/UNIX/thirdparty/Ultrix-32/ The Ultrix sources are available, also SunOS, not sure if these are a "legally open sourced" copies, but in theory HP (Digital) and Oracle (Sun) and others would now be allowed to open-source ancient versions given that Caldera have opened up the code it was based on. So I wonder if OSF/1 is now in the same boat? I'm not as interested in comparing ancient VM or messaging architectures, I honestly feel like the microkernel concept, at least as expressed in Mach, has been pretty thoroughly debunked, exokernels or tiny hypervisors might be more the go these days. But when you said "compiler" and "walls" my ears pricked up. I'm partway through re-engineering the ancient Ritchie compiler to be able to do a few new tricks, such as automatically outputting ANSI compileable code. Unfortunately this would occur after the C preprocessor step, I don't have plans to back-annotate the original source code. But I have plans to make the entire system as painless as possible. I already have modified "cc" and "ld" to do some rather interesting stuff retaining Makefile compatibility. cheers, Nick On Mon, Feb 20, 2017 at 8:19 AM, Clem Cole wrote: > > > On Sun, Feb 19, 2017 at 1:20 AM, wrote: >> >> True, but It’s not 4.3 BSD … I was hoping for something vintage of the >> era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on the VAX…. > > Fair enough... the Mt Xinu version is pretty much the CMU version unadorned. > Which mean that it is a 4.3BSD kernel, with the BSD based MMU code ripped > out and replaced with the CMU code, and the Mach interfaces (ney RIG - > Mach's and Accent's predecessor) messaging system spliced into it; then the > whole mess was built back up using a 4.3BSD user space (and on top of the > i386, an Intel developed boot system - which is a different story I'll not > repeat at this time - but thankfully was common to all the UNIX systems of > the day because Intel developed and make it available to community at > large). > > The other option which I would suggest to look at is the OSF/1 mk for the > i386 (monolithic) about version 3x which as I said forked off the Alpha line > and a couple of other systems. The i386 version of OSF/1 supports the same > chips (i386/i486/Pentium) at the CMU version, it also comes with more HW > device support (disk, tape, network, display et al), than the CMU/Mt Xinu > version -- including most importantly SCSI support by default, which is why > is might be a little easier to work on today's HW and VMs. When I last > used it, it lacked USB support; but that was being worked on around the time > I started doing other things so even that might even be available today. > > FWIW: OSF/1 also started with 4.3BSD userspace, but it had a lot of work > done to it to updating it - adding the Sys V commands that BSD lacked those > days and adding Sys V options to many commands. i.e. its user space is a > tad more "complete" / "wider" than pure 4.3BSD and again makes it a little > easier to complete. > > Note that the user space commands from the mk would become the basis for > Tru64, HP/UX and later versions of AIX. And also the OSF/1 version will > have better Graphics, Motif and a much better GUI options all around that Mt > Xinu, which alone may be it easier to work. > > > As I also said elsewhere, the uK or Research Institute (RI) version is a tad > more fun to play with. It's a real kernel architecture moving things like > file systems et al in user space. But you can do do things like start up > multiple system interfaces. LCC had their DOS/Win95 interface was actually > developed running instead of as a VM like it did for the basic mk code, but > in as "second server" but I do not think they ever sold it. The other > thing the RI never did, was the uk still has the pager and all the > networking code in the kernel, so the uk, is hardly 'micro' in size. > > There is a OSF Version 4 and maybe even version 5 (I've forgotten, if some > one remembers - please correct me). The OSF RI folks were trying to rewrite > it a bit in C++ as I recall, again this part of the UI vs OSF wars of the > day and Chorus has rewritten there version from Pascal to C++, and IIRC the > RI was trying to counter that. I don't remember if that version of the uk > ever saw the light of day. > > > > > Anyway, no matter which is the 3 code streams you pick, Mt Xinu, OSF/1 mk or > uk one hardest problems for today will be that the compiler is of course > extremely old by today's standards, and you are probably going to run it > some walls in that area faster than you might think. That said, if you are > willing to deal with the compiler as it comes, non of them should be very > high, or hard to get clear, but some are likely to take some work. > > Have fun and good luck and let us know if you can get any of these running. > > Clem From b4 at gewt.net Mon Feb 20 11:29:54 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sun, 19 Feb 2017 17:29:54 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: <1487554194.778935.886229480.27F99937@webmail.messagingengine.com> On Sun, Feb 19, 2017, at 13:19, Clem Cole wrote: > > > On Sun, Feb 19, 2017 at 1:20 AM, > wrote: >> True, but It’s not 4.3 BSD … I was hoping for something vintage of >> the era, just as Solaris 11 is SYSV, but it’s nothing like SYSVr2 on >> the VAX…. > Fair enough... the Mt Xinu version is pretty much the CMU version > unadorned. Which mean that it is a 4.3BSD kernel, with the BSD based > MMU code ripped out and replaced with the CMU code, and the Mach > interfaces (ney RIG - Mach's and Accent's predecessor) messaging > system spliced into it; then the whole mess was built back up using a > 4.3BSD user space (and on top of the i386, an Intel developed boot > system - which is a different story I'll not repeat at this time - but > thankfully was common to all the UNIX systems of the day because Intel > developed and make it available to community at large). > > The other option which I would suggest to look at is the OSF/1 mk for > the i386 (monolithic) about version 3x which as I said forked off the > Alpha line and a couple of other systems. The i386 version of OSF/1 > supports the same chips (i386/i486/Pentium) at the CMU version, it > also comes with more HW device support (disk, tape, network, display > *et al*), than the CMU/Mt Xinu version -- including most importantly > SCSI support by default, which is why is might be a little easier to > work on today's HW and VMs. When I last used it, it lacked USB > support; but that was being worked on around the time I started doing > other things so even that might even be available today. > > FWIW: OSF/1 also started with 4.3BSD userspace, but it had a lot of > work done to it to updating it - adding the Sys V commands that BSD > lacked those days and adding Sys V options to many commands. * i.e.* > its user space is a tad more "complete" / "wider" than pure 4.3BSD and > again makes it a little easier to complete. > > Note that the user space commands from the mk would become the basis > for Tru64, HP/UX and later versions of AIX. And also the OSF/1 > version will have better Graphics, Motif and a much better GUI options > all around that Mt Xinu, which alone may be it easier to work. > > > As I also said elsewhere, the uK or Research Institute (RI) version is > a tad more fun to play with. It's a real kernel architecture moving > things like file systems *et al* in user space. But you can do do > things like start up multiple system interfaces. LCC had their > DOS/Win95 interface was actually developed running instead of as a VM > like it did for the basic mk code, but in as "second server" but I do > not think they ever sold it. The other thing the RI never did, was > the uk still has the pager and all the networking code in the kernel, > so the uk, is hardly 'micro' in size. > > There is a OSF Version 4 and maybe even version 5 (I've forgotten, if > some one remembers - please correct me). The OSF RI folks were trying > to rewrite it a bit in C++ as I recall, again this part of the UI vs > OSF wars of the day and Chorus has rewritten there version from Pascal > to C++, and IIRC the RI was trying to counter that. I don't remember > if that version of the uk ever saw the light of day. > > > > > Anyway, no matter which is the 3 code streams you pick, Mt Xinu, OSF/1 > mk or uk one hardest problems for today will be that the compiler is > of course extremely old by today's standards, and you are probably > going to run it some walls in that area faster than you might think. > That said, if you are willing to deal with the compiler as it comes, > non of them should be very high, or hard to get clear, but some are > likely to take some work. > > Have fun and good luck and let us know if you can get any of these > running. > > Clem Has any mtXinu stuff survived to be archives? -- Cory Smelosky b4 at gewt.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Mon Feb 20 11:31:43 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sun, 19 Feb 2017 17:31:43 -0800 Subject: [TUHS] Any BSDi interest? In-Reply-To: <8df70e17-f615-871e-7a70-6118287a0ede@kilonet.net> References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> <8df70e17-f615-871e-7a70-6118287a0ede@kilonet.net> Message-ID: <1487554303.779167.886230336.2F0B95A8@webmail.messagingengine.com> On Sun, Feb 19, 2017, at 16:09, Arthur Krewat wrote: > If you don't archive it, you're a luser. > > :) > > > > On 2/19/2017 5:39 PM, Cory Smelosky wrote: > > Hi, > > > > Forgot I'm sitting on a lot of BSDi sources/binaries. > > > > Is there any interest in this aside from me? ;) > > > My original archive https://gewt.net/bsdos got a little corrupted, so I need to re-upload some of the later ISOs and betas. the 1.x source and binaries are complete (and buildable!) -- Cory Smelosky b4 at gewt.net From wlc at jctaylor.com Mon Feb 20 11:48:32 2017 From: wlc at jctaylor.com (William Corcoran) Date: Sun, 19 Feb 2017 20:48:32 -0500 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <201702190012.v1J0CGml026966@coolidge.cs.Dartmouth.EDU> References: <201702190012.v1J0CGml026966@coolidge.cs.Dartmouth.EDU> Message-ID: <6961AB0F-422F-47E3-8204-C555B3F62E52@jctaylor.com> Hello Mr. Mcllroy, Well, along the lines of early UNIX preservation, I have a question. At some point SCCS began to take shape and take hold of the core of the early UNIX distributions. Google says SCCS has been around since 1972. Now, let's take my favorite UNIX releases Research 7, v7m and BSD 2.11. They are my favorite since I have access to the complete distributions and I have all working independently via simulators on dedicated hardware. Now, it's simply wonderful to view the sources. Even more wonderful, through simulation, to relink these distributions. And it's fun to read code and comments---most of it way over my head. But, is there somewhere a main distribution for Research 7, v7m 2.1, or BSD 2.11 that has all of the original SCCS deltas (leaf and non-leaf)? This would be extremely revealing. If we could view the SCCS comments (sccs prs) and the underlying code, it would be incredibly valuable. Please forgive me if this has been asked a million times. I just can't find it. Once SCCS was heavily used, was there a codebase that housed all of these distributions? I always wondered if there were some kind of SCCS or SCCS-like repository that maintained the final distribution and all of the deltas leading up to a minor or even major release. RELEASE, LEVEL, BRANCH and SEQUENCE: I do see "SCCSID" strings sprinkled throughout various distributions. So, this way the application could automatically report the RLBS to the end user. But, is there an early UNIX distribution that housed the complete SCCS repository---I want to dig deep, really deep. This way I could see the paths that were taken, the solutions that partially worked, or ended up causing other problems. Truly, Bill Corcoran > On Feb 18, 2017, at 7:12 PM, Doug McIlroy wrote: > > > OMG. I don't know how many times I've consulted the Unix > Tree and blissfully ignored the cross-links that come at > the top of every file--I'm so intent on the content. > > Apologies for cluttering the mailing list about a solved topic. > > Doug From clemc at ccc.com Mon Feb 20 11:58:59 2017 From: clemc at ccc.com (Clem Cole) Date: Sun, 19 Feb 2017 20:58:59 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing wrote: > This is all very interesting, and I take it the source is available? ​I have not looked in a while, they have been in the past.​ The RI version in particular was floating around the open parts of the Internet as recently as 10-15 years ago, if my memory serves me. I suspect, that the darker areas have other versions too. We played with/considered the RI version at one of my startups but eventually decided against as it was too big/heavy for what we needed at the time. Google is your friend, as is the Internet Way Back machines but I do expect if you poke around you'll find them. As for licenses, OSF/1 [from OSF itself] was based off the SVR3 AT&T license from an AT&T standpoint. If that is now clear, then it should be also, but I'm not a lawyer nor play one on TV etc... I'll leave that to other more knowledgable about what has been released and what has not. [As a side note, I do remember that all of Sun, IBM and HP had fully bought out AT&T licenses meaning they could do whatever they wanted with the IP, but DEC never took that step. However, when HP bought Compaq later and they started to shipping Tru64 et al under the HP licenses]. Anyway, Tru64 is based on OSF/1 but also has a lot of DEC proprietary things (like TruClusters and anything Alpha specific) that goes beyond the based OSF license, so you need the HP clearance before any of that can be made available [same is true for HP/UX of course]. To my knowledge, DEC/Compaq/HP never released the sources to Tru64 (or HP/UX) to the world they way Sun did for Solaris, which in the case of Tru64 is sort of shame - there is some every good stuff in there like the file systems, the lock managers, cluster scaling, messaging, etc - which would be nice to compare to today's solutions. Since HP did have a bought out AT&T license, that clearly could have done so, but I do not think anyone left there to make that decision - sigh. That said, VMS is still kept under lock and key, although HP has licensed it to "VMS, Inc" in the last year (who is now supplying support for same for Alpha, IA64 and announced a future INTEL*64 version amazingly). I bring this up, because we might be able to find out from those folks whom that are working with at HP and see if we can get one of the HP execs that is working with VMS to help to sign off on Tru64. I don't know. Which bring me to another though ....question for this fine group.... Sun had a bought out A&T&T SVR4 license. This was how they were able to make Solaris open source because they owned both the Sun parts and had the rights to release the part they had licenses from AT&T. Does any one know what became of the non-Sun version SVR4? Did the rest of it, ever get released? Since it sounds like we are digging up a few of the 386 flavors, I thinking that Warren needs to add an "x86" directory on the save level as the current VAX and PDP-11 versions. Then under that have "Distributions" - with an SRV4/i386 tape assuming we could find same. Same of course for SVR3 - which would make the some of the other versions less murky if it was released, since I'm fairly sure that the SVR3 license was the one that most commercial UNIX versions shipped under for the longest amount of time. If it was released, many of of the versions of UNIX from the other "dead branches" - say, early Masscomp, Apollo's first UNIX attempts, Pyramid's Universe stuff, etc would have a little clear path to being able to me made available. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Mon Feb 20 12:33:24 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 19 Feb 2017 21:33:24 -0500 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <6961AB0F-422F-47E3-8204-C555B3F62E52@jctaylor.com> References: <201702190012.v1J0CGml026966@coolidge.cs.Dartmouth.EDU> <6961AB0F-422F-47E3-8204-C555B3F62E52@jctaylor.com> Message-ID: <201702200233.v1K2XOgk010156@coolidge.cs.Dartmouth.EDU> > Once SCCS was heavily used, was there a codebase that housed all of these distributions? No. The Research Unix team was small, had no responsibility to support old versions, and eschewed paperwork. But we were conscientiouws about maintaining the manual and fixing bugs. Close personal contact kept things on track; SCCS was never used. Because of frequent exchanges of software, there may be hints of Research activity in PWB SCCS records. Doug From lm at mcvoy.com Mon Feb 20 12:52:48 2017 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 19 Feb 2017 18:52:48 -0800 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <201702200233.v1K2XOgk010156@coolidge.cs.Dartmouth.EDU> References: <201702190012.v1J0CGml026966@coolidge.cs.Dartmouth.EDU> <6961AB0F-422F-47E3-8204-C555B3F62E52@jctaylor.com> <201702200233.v1K2XOgk010156@coolidge.cs.Dartmouth.EDU> Message-ID: <20170220025248.GA20341@mcvoy.com> On Sun, Feb 19, 2017 at 09:33:24PM -0500, Doug McIlroy wrote: > > Once SCCS was heavily used, was there a codebase that housed all of these distributions? > > No. The Research Unix team was small, had no responsibility to > support old versions, and eschewed paperwork. But we were > conscientiouws about maintaining the manual and fixing bugs. > Close personal contact kept things on track; SCCS was never > used. Because of frequent exchanges of software, there > may be hints of Research activity in PWB SCCS records. That's the first practice I've heard about the Research Unix team that is disappointing. It would be oh so valuable to see the history in SCCS. From wes.parish at paradise.net.nz Mon Feb 20 13:59:27 2017 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Mon, 20 Feb 2017 16:59:27 +1300 (NZDT) Subject: [TUHS] Any BSDi interest? In-Reply-To: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> Message-ID: <1487563167.58aa699fbd46a@www.paradise.net.nz> It's a valuable part of BSD history. I'd be delighted to see it. Wesley Parish Quoting Cory Smelosky : > Hi, > > Forgot I'm sitting on a lot of BSDi sources/binaries. > > Is there any interest in this aside from me? ;) > > -- > Cory Smelosky > b4 at gewt.net > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn From jsteve at superglobalmegacorp.com Mon Feb 20 14:31:36 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 20 Feb 2017 12:31:36 +0800 Subject: [TUHS] Any BSDi interest? In-Reply-To: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> Message-ID: As always, I sure am! On February 20, 2017 6:39:57 AM GMT+08:00, Cory Smelosky wrote: >Hi, > >Forgot I'm sitting on a lot of BSDi sources/binaries. > >Is there any interest in this aside from me? ;) > >-- > Cory Smelosky > b4 at gewt.net -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Mon Feb 20 16:14:19 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 20 Feb 2017 14:14:19 +0800 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) Message-ID: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> I dont know if it's worth even trying to find and mirror pre 1993 ( IE when cheap CD-ROM mastering was possible) GNU software? Things like binutils, gas, and GCC can be tremendously useful, along with binaries for long "dead" platforms? I know that I've always been super thankful of the GNAT people for having some pre-compiled version of the ADA translator which would also include GCC. Sometimes having some kind of native toolset is a big positive, when you don't have anything, especially earlier versions that have issues cross or Canadian cross compiling. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Mon Feb 20 16:38:02 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Mon, 20 Feb 2017 13:38:02 +0700 Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: >Date: Sun, 19 Feb 2017 20:58:59 -0500 >From: Clem Cole >To: Nick Downing >Cc: Jason Stevens , > "tuhs at minnie.tuhs.org" >Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other >Message-ID: Content-Type: text/plain; charset="utf-8" > >On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing wrote: ... >Anyway, Tru64 is based on OSF/1 but also has a lot of DEC proprietary >things (like TruClusters and anything Alpha specific) that goes beyond the >based OSF license, so you need the HP clearance before any of that can be >made available [same is true for HP/UX of course]. To my knowledge, >DEC/Compaq/HP never released the sources to Tru64 (or HP/UX) to the world >they way Sun did for Solaris, which in the case of Tru64 is sort of shame. >there is some every good stuff in there like the file systems, the lock >managers, cluster scaling, messaging, etc - which would be nice to compare >to today's solutions. Since HP did have a bought out AT&T license, that >clearly could have done so, but I do not think anyone left there to make >that decision - sigh. As far as I know only the TRU64 Advanced File System (aka AdvFS) has been released to the OpenSource community, in 2008. Status now unknown (to me) See also . http://advfs.sourceforge.net . https://www.cyberciti.biz/tips/download-tru64-unix-advanced-filesystem-advfs-sourcecode.html Cheers, rudi From wkt at tuhs.org Mon Feb 20 16:50:13 2017 From: wkt at tuhs.org (Warren Toomey) Date: Mon, 20 Feb 2017 16:50:13 +1000 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> Message-ID: <20170220065013.GB19194@minnie.tuhs.org> On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: > I dont know if it's worth even trying to find and mirror pre 1993 ( IE > when cheap CD-ROM mastering was possible) GNU software? I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it may not be put into the Unix Archive. We do need a GNU historian and curator. Ditto for Linux. Cheers, Warren From downing.nick at gmail.com Mon Feb 20 17:00:33 2017 From: downing.nick at gmail.com (Nick Downing) Date: Mon, 20 Feb 2017 18:00:33 +1100 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <20170220065013.GB19194@minnie.tuhs.org> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> Message-ID: I would be happy to provide hosting for pretty much anything, although any curating activities would have to wait until I have time. I purchased a domain "retrosbc.com" which was supposed to be for a retro single-board computers business, not my current enthusiasm but it has "retro" in the name and is sufficiently opaque that it can host anything retro :) If anyone is keen to make use of this hosting to put curated materials online, then I will provide them an account, its a virtual server and I think anyone here would be capable of "sshing" to it. cheers, Nick On Mon, Feb 20, 2017 at 5:50 PM, Warren Toomey wrote: > On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: >> I dont know if it's worth even trying to find and mirror pre 1993 ( IE >> when cheap CD-ROM mastering was possible) GNU software? > > I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it > may not be put into the Unix Archive. > > We do need a GNU historian and curator. Ditto for Linux. > > Cheers, Warren From lars at nocrew.org Mon Feb 20 17:10:57 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 20 Feb 2017 08:10:57 +0100 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> (Jason Stevens's message of "Mon, 20 Feb 2017 14:14:19 +0800") References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> Message-ID: <86d1ed49ry.fsf@molnjunk.nocrew.org> Jason Stevens writes: > I dont know if it's worth even trying to find and mirror pre 1993 ( IE > when cheap CD-ROM mastering was possible) GNU software? > > Things like binutils, gas, and GCC can be tremendously useful, along > with binaries for long "dead" platforms? I have collected old version of GNU Emacs. 19.x is well covered. 18.x less so. Noah Friedman had 16.56, and I found two releases of Emacs 17 and one I believe to be version 13! Other historical Unix Emacsen: MicroEMACS 30 from Dave Conroy, Gosling Emacs, Warren Montgomery/BTL/ATT/unixpc Emacs, EMACS-11 by Fred Fish. Get these from https://github.com/larsbrinkhoff/emacs-history From jsteve at superglobalmegacorp.com Mon Feb 20 17:19:29 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 20 Feb 2017 15:19:29 +0800 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <86d1ed49ry.fsf@molnjunk.nocrew.org> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <86d1ed49ry.fsf@molnjunk.nocrew.org> Message-ID: <368ECC0A-A5F6-4B21-B226-26C3FEFA7D81@superglobalmegacorp.com> Cool, hopefully one has the cuckoo's root bug! On February 20, 2017 3:10:57 PM GMT+08:00, Lars Brinkhoff wrote: >Jason Stevens writes: >> I dont know if it's worth even trying to find and mirror pre 1993 ( >IE >> when cheap CD-ROM mastering was possible) GNU software? >> >> Things like binutils, gas, and GCC can be tremendously useful, along >> with binaries for long "dead" platforms? > >I have collected old version of GNU Emacs. 19.x is well covered. 18.x >less so. Noah Friedman had 16.56, and I found two releases of Emacs 17 >and one I believe to be version 13! > >Other historical Unix Emacsen: MicroEMACS 30 from Dave Conroy, Gosling >Emacs, Warren Montgomery/BTL/ATT/unixpc Emacs, EMACS-11 by Fred Fish. > >Get these from https://github.com/larsbrinkhoff/emacs-history -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfawcus+lists-tuhs at employees.org Mon Feb 20 08:59:14 2017 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Sun, 19 Feb 2017 22:59:14 +0000 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> Message-ID: <20170219225914.GA51800@cowbell.employees.org> On Sun, Feb 19, 2017 at 02:20:15p.m. +0800, jsteve at superglobalmegacorp.com wrote: > > And historical is far more interesting than something I can just go buy retail…. Speaking as someone who’s own a NeXT, and even bought OS X Server 1.0 on release. Didn't Apple release the kernel source code for that under V1 of their public licence? I seem to recall finding it once on a MIT server. DF From jsteve at superglobalmegacorp.com Mon Feb 20 17:23:05 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 20 Feb 2017 15:23:05 +0800 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <20170220065013.GB19194@minnie.tuhs.org> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> Message-ID: <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> I've been on again and off again collecting stuff... What I've found I've put on source forge since it's easier to upload binaries there. Same for Linux, while there is an ancient Linux site, all it's mirrors are vanishing On February 20, 2017 2:50:13 PM GMT+08:00, Warren Toomey wrote: >On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: >> I dont know if it's worth even trying to find and mirror pre 1993 >( IE >> when cheap CD-ROM mastering was possible) GNU software? > >I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it >may not be put into the Unix Archive. > >We do need a GNU historian and curator. Ditto for Linux. > >Cheers, Warren -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Feb 20 19:08:03 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Feb 2017 02:08:03 -0700 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> Message-ID: <201702200908.v1K983DP011135@freefriends.org> There's a fair amount of stuff on ftp.gnu.org itself. The FSF used to make tapes and CDs; perhaps they still have some laying around? I'm not sure who to ask there, though, although I could try to find someone. Arnold Jason Stevens wrote: > I've been on again and off again collecting stuff... What I've found I've put on source forge since it's easier to upload binaries there. Same for Linux, while there is an ancient Linux site, all it's mirrors are vanishing > > On February 20, 2017 2:50:13 PM GMT+08:00, Warren Toomey wrote: > >On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: > >> I dont know if it's worth even trying to find and mirror pre 1993 > >( IE > >> when cheap CD-ROM mastering was possible) GNU software? > > > >I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it > >may not be put into the Unix Archive. > > > >We do need a GNU historian and curator. Ditto for Linux. > > > >Cheers, Warren > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From jsteve at superglobalmegacorp.com Mon Feb 20 19:59:32 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Mon, 20 Feb 2017 17:59:32 +0800 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <201702200908.v1K983DP011135@freefriends.org> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> Message-ID: I recently found out that vim.org of all places had a copy of GCC 0.9, which was the first public version, to support the VAX & 68020 SUN platforms of the time. http://ftp.vim.org/languages/gcc/old-releases/gcc-1/ I built it on SIMH + 4.2BSD VAX along with the ‘gnu1988’ along with other gems like bison 1.00, flex 1.0 .. and it was a lot more unstable than I was expecting, the next oldest version is 1.21 which adds more platforms, and some much needed stability. I know it’s old, but it’s funny how pro SUN they were at the time. Sent from Mail for Windows 10 From: arnold at skeeve.com Sent: Tuesday, 21 February 2017 5:23 PM To: wkt at tuhs.org; jsteve at superglobalmegacorp.com Cc: tuhs at tuhs.org Subject: Re: [TUHS] Reorganising the Unix Archive? (GNU?) There's a fair amount of stuff on ftp.gnu.org itself. The FSF used to make tapes and CDs; perhaps they still have some laying around? I'm not sure who to ask there, though, although I could try to find someone. Arnold Jason Stevens wrote: > I've been on again and off again collecting stuff... What I've found I've put on source forge since it's easier to upload binaries there. Same for Linux, while there is an ancient Linux site, all it's mirrors are vanishing > > On February 20, 2017 2:50:13 PM GMT+08:00, Warren Toomey wrote: > >On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: > >> I dont know if it's worth even trying to find and mirror pre 1993 > >( IE > >> when cheap CD-ROM mastering was possible) GNU software? > > > >I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it > >may not be put into the Unix Archive. > > > >We do need a GNU historian and curator. Ditto for Linux. > > > >Cheers, Warren > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Mon Feb 20 21:12:58 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Feb 2017 04:12:58 -0700 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> Message-ID: <201702201112.v1KBCwVE017990@freefriends.org> Interesting. WRT sun and vax, those were the two most popular platforms at the time. So if you wanted to spread the Free Software gospel, it made sense to target those platforms first. Targetting 68020 also made a number of other vendors potentially available. Apollo comes to mind, I'm sure there were others. I remember bootstrapping GCC 1.0 on one of the vaxen I ran when I was a sysadmin at Emory University. I don't think I played with anything earlier but I don't remember. Arnold wrote: > I recently found out that vim.org of all places had a copy of GCC 0.9, which was the first public version, to support the VAX & 68020 SUN platforms of the time. > > http://ftp.vim.org/languages/gcc/old-releases/gcc-1/ > > I built it on SIMH + 4.2BSD VAX along with the ‘gnu1988’ along with other gems like bison 1.00, flex 1.0 .. and it was a lot more unstable than I was expecting, the next oldest version is 1.21 which adds more platforms, and some much needed stability. I know it’s old, but it’s funny how pro SUN they were at the time. > > Sent from Mail for Windows 10 > > From: arnold at skeeve.com > Sent: Tuesday, 21 February 2017 5:23 PM > To: wkt at tuhs.org; jsteve at superglobalmegacorp.com > Cc: tuhs at tuhs.org > Subject: Re: [TUHS] Reorganising the Unix Archive? (GNU?) > > There's a fair amount of stuff on ftp.gnu.org itself. The FSF > used to make tapes and CDs; perhaps they still have some laying around? > > I'm not sure who to ask there, though, although I could try to find > someone. > > Arnold > > Jason Stevens wrote: > > > I've been on again and off again collecting stuff... What I've found I've put on source forge since it's easier to upload binaries there. Same for Linux, while there is an ancient Linux site, all it's mirrors are vanishing > > > > On February 20, 2017 2:50:13 PM GMT+08:00, Warren Toomey wrote: > > >On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: > > >> I dont know if it's worth even trying to find and mirror pre 1993 > > >( IE > > >> when cheap CD-ROM mastering was possible) GNU software? > > > > > >I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it > > >may not be put into the Unix Archive. > > > > > >We do need a GNU historian and curator. Ditto for Linux. > > > > > >Cheers, Warren > > > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevity. > From dscherrer at solar.stanford.edu Tue Feb 21 02:46:55 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 20 Feb 2017 08:46:55 -0800 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <201702201112.v1KBCwVE017990@freefriends.org> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> <201702201112.v1KBCwVE017990@freefriends.org> Message-ID: <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> I would like to add the Software Tools to the Unix archive. As you may remember, Brian Kernighan and P. J. Plauger wrote a book about developing Unix-like code for non-Unix systems. We at the Lawrence Berkeley Lab took that idea and ran with it. We eventually produced a set of Unix utilities and a system interface that could be reproduced on virtually any operating system. This was freely distributed and eventually the package was put up on over 50 different computers/systems. There was a user group of about 2000. The movement earned one of the Usenix Flame Awards, way back when. We have the original tapes produced at Lawrence Berkeley Lab, plus a Pascal version, plus a version for CP/M. We would like to add these to the Unix archive, if you think it appropriate. Deborah On 2/20/17 3:12 AM, arnold at skeeve.com wrote: > Interesting. WRT sun and vax, those were the two most popular platforms > at the time. So if you wanted to spread the Free Software gospel, it > made sense to target those platforms first. > > Targetting 68020 also made a number of other vendors potentially available. > Apollo comes to mind, I'm sure there were others. > > I remember bootstrapping GCC 1.0 on one of the vaxen I ran when I > was a sysadmin at Emory University. I don't think I played with anything > earlier but I don't remember. > > Arnold > > > wrote: > >> I recently found out that vim.org of all places had a copy of GCC 0.9, which was the first public version, to support the VAX & 68020 SUN platforms of the time. >> >> http://ftp.vim.org/languages/gcc/old-releases/gcc-1/ >> >> I built it on SIMH + 4.2BSD VAX along with the ‘gnu1988’ along with other gems like bison 1.00, flex 1.0 .. and it was a lot more unstable than I was expecting, the next oldest version is 1.21 which adds more platforms, and some much needed stability. I know it’s old, but it’s funny how pro SUN they were at the time. >> >> Sent from Mail for Windows 10 >> >> From: arnold at skeeve.com >> Sent: Tuesday, 21 February 2017 5:23 PM >> To: wkt at tuhs.org; jsteve at superglobalmegacorp.com >> Cc: tuhs at tuhs.org >> Subject: Re: [TUHS] Reorganising the Unix Archive? (GNU?) >> >> There's a fair amount of stuff on ftp.gnu.org itself. The FSF >> used to make tapes and CDs; perhaps they still have some laying around? >> >> I'm not sure who to ask there, though, although I could try to find >> someone. >> >> Arnold >> >> Jason Stevens wrote: >> >>> I've been on again and off again collecting stuff... What I've found I've put on source forge since it's easier to upload binaries there. Same for Linux, while there is an ancient Linux site, all it's mirrors are vanishing >>> >>> On February 20, 2017 2:50:13 PM GMT+08:00, Warren Toomey wrote: >>>> On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: >>>>> I dont know if it's worth even trying to find and mirror pre 1993 >>>> ( IE >>>>> when cheap CD-ROM mastering was possible) GNU software? >>>> I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it >>>> may not be put into the Unix Archive. >>>> >>>> We do need a GNU historian and curator. Ditto for Linux. >>>> >>>> Cheers, Warren >>> -- >>> Sent from my Android device with K-9 Mail. Please excuse my brevity. From schily at schily.net Tue Feb 21 04:06:28 2017 From: schily at schily.net (Joerg Schilling) Date: Mon, 20 Feb 2017 19:06:28 +0100 Subject: [TUHS] Reorganising the Unix Archive? In-Reply-To: <6961AB0F-422F-47E3-8204-C555B3F62E52@jctaylor.com> References: <201702190012.v1J0CGml026966@coolidge.cs.Dartmouth.EDU> <6961AB0F-422F-47E3-8204-C555B3F62E52@jctaylor.com> Message-ID: <58ab3024.ssuRGwMAfWkSGtw/%schily@schily.net> William Corcoran wrote: > But, is there somewhere a main distribution for Research 7, v7m 2.1, or BSD 2.11 that has all of the original SCCS deltas (leaf and non-leaf)? > > This would be extremely revealing. If we could view the SCCS comments (sccs prs) and the underlying code, it would be incredibly valuable. > > Please forgive me if this has been asked a million times. I just can't find it. Once SCCS was heavily used, was there a codebase that housed all of these distributions? If you have access to the CSRG UNIX archives, you could fetch the latest SCCS sources from within the schily-tools: http://sourceforge.net/projects/schilytools/files/ compile it by just calling "make" and then: cd CSRG_Archive_4 sccs -R log > /tmp/file This gives you better readable results and it has the advantage that you get a listing that span the whole tree and combine daltas that happened within 24 hours and used the same delta message. Here is a small part as an example: Thu May 8 10:29:39 1980 bill * ./sys/kern/init_main.c 3.4 * ./sys/vax/uba/vp.c 3.2 * ./sys/vax/uba/va.c 3.2 * ./sys/kern/kern_proc.c 3.3 * ./sys/kern/kern_synch.c 3.7 * ./sys/kern/tty_subr.c 3.2 * ./sys/vax/vax/machdep.c 3.4 * ./sys/vax/mba/ht.c 3.2 * ./sys/vax/mba/hp.c 3.3 * ./sys/vax/vax/flp.c 3.2 * ./sys/kern/kern_clock.c 3.5 * ./sys/kern/kern_physio.c 3.4 * ./sys/kern/vfs_cluster.c 3.4 * ./sys/kern/vfs_bio.c 3.4 VOID=>void Thu May 8 10:15:38 1980 bill * ./sys/sys/conf.h 3.2 addition for netldis Thu May 8 10:14:51 1980 bill * ./sys/sys/tty.h 3.2 added BNETLDIS Thu May 8 10:13:56 1980 bill * ./sys/kern/tty.c 3.2 modified to support TIOCSETD reasonably The code at: CSRG_Archive_4 contains 108604 deltas in total. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From schily at schily.net Tue Feb 21 04:14:44 2017 From: schily at schily.net (Joerg Schilling) Date: Mon, 20 Feb 2017 19:14:44 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170219154432.GA19243@mcvoy.com> References: <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com> <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> Message-ID: <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> Larry McVoy wrote: > Linus had the qualities of being a good programmer, a good architect, > and a good manager. I've never seen all 3 in a person before or since. My memory is different. He claims that his intention is to keep kernel/userspace interfaces stable, but given the fact that this did never happen, I tend to believe that he lacks the understanding on what all is part of the kernel/userspace interface. He also send me a 10 line patch for cdrtools in 2004 and I did never get a worse patch (a patch that includes more new bugs) for my software. So I cannot confirm your view. He is a person with a strong ego and this may have helped to spread Linux. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From arnold at skeeve.com Tue Feb 21 04:27:04 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Feb 2017 11:27:04 -0700 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> <201702201112.v1KBCwVE017990@freefriends.org> <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> Message-ID: <201702201827.v1KIR4PR012916@freefriends.org> Hi Debborah. I don't know if we ever met but I certainly recognize your name from the Software Tools work. The original Ratfor and Pascal versions of the tools from the Kernighan and Plauger books are already in the archive, donated by yours truly many years ago. (They're from the tapes Addison Wesley would sell you at the time.) Nontheless, I think it would be WONDERFUL to have the enhanced tools you folks did in the archives. Please contribute them! Arnold P.S. I've asked before, but maybe there are more people around now... I was involved with the Georgia Tech subsystem for Pr1me computers which also built a very Unix like environment in an enhnaced Ratfor to run on top of Primos. Some of the doc is archived, and I have some paper copies, but I'd love to see that code unearthed... I've made a very few bits that were ported to C are available under http://github.com/arnoldrobbins, and the 'se' editor has been revived by Thomas Cort at se-editor.org, but that's all in C. If anyone has a tape, I might have a program that could extract it under *nix. Thanks! Deborah Scherrer wrote: > I would like to add the Software Tools to the Unix archive. As you may > remember, Brian Kernighan and P. J. Plauger wrote a book about > developing Unix-like code for non-Unix systems. We at the Lawrence > Berkeley Lab took that idea and ran with it. We eventually produced a > set of Unix utilities and a system interface that could be reproduced on > virtually any operating system. This was freely distributed and > eventually the package was put up on over 50 different > computers/systems. There was a user group of about 2000. The movement > earned one of the Usenix Flame Awards, way back when. > > We have the original tapes produced at Lawrence Berkeley Lab, plus a > Pascal version, plus a version for CP/M. We would like to add these to > the Unix archive, if you think it appropriate. > > Deborah From arnold at skeeve.com Tue Feb 21 04:56:05 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Mon, 20 Feb 2017 11:56:05 -0700 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <42e98887-0440-3903-65f8-cd35e772508c@solar.stanford.edu> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> <201702201112.v1KBCwVE017990@freefriends.org> <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> <201702201827.v1KIR4PR012916@freefriends.org> <42e98887-0440-3903-65f8-cd35e772508c@solar.stanford.edu> Message-ID: <201702201856.v1KIu5Xo014457@freefriends.org> I didn't realize the GT guys started with your stuff. I think it diverged and there were definitely things developed at GT but I won't claim to know who did what, since it was mature by the time I became involved with it. It was very tuned for the Pr1mes. In any case, please do contribute. Thanks! Arnold Deborah Scherrer wrote: > I was one of the 3 primary authors of the Software Tools system (along > with Dennis Hall and Joe Sventek), and I was the founder of the users > group. (Also served a long time on the Usenix Board, was even president > for a while.) Yes, the Georgia Tech stuff was from our system. And, we > expanded extensively beyond the tape that was available with the > Kernighan/Plauger book. > > I would be pleased to contribute our code to the archive. Thanks. > > Deborah > > On 2/20/17 10:27 AM, arnold at skeeve.com wrote: > > Hi Debborah. > > > > I don't know if we ever met but I certainly recognize your name > > from the Software Tools work. > > > > The original Ratfor and Pascal versions of the tools from the > > Kernighan and Plauger books are already in the archive, donated > > by yours truly many years ago. (They're from the tapes Addison Wesley > > would sell you at the time.) > > > > Nontheless, I think it would be WONDERFUL to have the enhanced > > tools you folks did in the archives. > > > > Please contribute them! > > > > Arnold > > > > P.S. I've asked before, but maybe there are more people around now... > > > > I was involved with the Georgia Tech subsystem for Pr1me computers which > > also built a very Unix like environment in an enhnaced Ratfor to run > > on top of Primos. Some of the doc is archived, and I have some paper > > copies, but I'd love to see that code unearthed... > > > > I've made a very few bits that were ported to C are available under > > http://github.com/arnoldrobbins, and the 'se' editor has been revived > > by Thomas Cort at se-editor.org, but that's all in C. > > > > If anyone has a tape, I might have a program that could extract > > it under *nix. > > > > Thanks! > > > > Deborah Scherrer wrote: > > > >> I would like to add the Software Tools to the Unix archive. As you may > >> remember, Brian Kernighan and P. J. Plauger wrote a book about > >> developing Unix-like code for non-Unix systems. We at the Lawrence > >> Berkeley Lab took that idea and ran with it. We eventually produced a > >> set of Unix utilities and a system interface that could be reproduced on > >> virtually any operating system. This was freely distributed and > >> eventually the package was put up on over 50 different > >> computers/systems. There was a user group of about 2000. The movement > >> earned one of the Usenix Flame Awards, way back when. > >> > >> We have the original tapes produced at Lawrence Berkeley Lab, plus a > >> Pascal version, plus a version for CP/M. We would like to add these to > >> the Unix archive, if you think it appropriate. > >> > >> Deborah > From brantleycoile at me.com Tue Feb 21 05:46:03 2017 From: brantleycoile at me.com (Brantley Coile) Date: Mon, 20 Feb 2017 14:46:03 -0500 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> <201702201112.v1KBCwVE017990@freefriends.org> <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> Message-ID: <90D77B62-0A21-4C0D-B4C5-9B21A6770805@me.com> I would love to see this? I first got a copy for the beginnings of the University of Georgia CS department for use on a CDC minicomputer that only had FORTRAN 3.8. (CDC said it was FORTRAN 4 but it wasn't quite.) Sent from my iPad > On Feb 20, 2017, at 11:46 AM, Deborah Scherrer wrote: > > I would like to add the Software Tools to the Unix archive. As you may remember, Brian Kernighan and P. J. Plauger wrote a book about developing Unix-like code for non-Unix systems. We at the Lawrence Berkeley Lab took that idea and ran with it. We eventually produced a set of Unix utilities and a system interface that could be reproduced on virtually any operating system. This was freely distributed and eventually the package was put up on over 50 different computers/systems. There was a user group of about 2000. The movement earned one of the Usenix Flame Awards, way back when. > > We have the original tapes produced at Lawrence Berkeley Lab, plus a Pascal version, plus a version for CP/M. We would like to add these to the Unix archive, if you think it appropriate. > > Deborah > >> On 2/20/17 3:12 AM, arnold at skeeve.com wrote: >> Interesting. WRT sun and vax, those were the two most popular platforms >> at the time. So if you wanted to spread the Free Software gospel, it >> made sense to target those platforms first. >> >> Targetting 68020 also made a number of other vendors potentially available. >> Apollo comes to mind, I'm sure there were others. >> >> I remember bootstrapping GCC 1.0 on one of the vaxen I ran when I >> was a sysadmin at Emory University. I don't think I played with anything >> earlier but I don't remember. >> >> Arnold >> >> >> wrote: >> >>> I recently found out that vim.org of all places had a copy of GCC 0.9, which was the first public version, to support the VAX & 68020 SUN platforms of the time. >>> >>> http://ftp.vim.org/languages/gcc/old-releases/gcc-1/ >>> >>> I built it on SIMH + 4.2BSD VAX along with the ‘gnu1988’ along with other gems like bison 1.00, flex 1.0 .. and it was a lot more unstable than I was expecting, the next oldest version is 1.21 which adds more platforms, and some much needed stability. I know it’s old, but it’s funny how pro SUN they were at the time. >>> >>> Sent from Mail for Windows 10 >>> >>> From: arnold at skeeve.com >>> Sent: Tuesday, 21 February 2017 5:23 PM >>> To: wkt at tuhs.org; jsteve at superglobalmegacorp.com >>> Cc: tuhs at tuhs.org >>> Subject: Re: [TUHS] Reorganising the Unix Archive? (GNU?) >>> >>> There's a fair amount of stuff on ftp.gnu.org itself. The FSF >>> used to make tapes and CDs; perhaps they still have some laying around? >>> >>> I'm not sure who to ask there, though, although I could try to find >>> someone. >>> >>> Arnold >>> >>> Jason Stevens wrote: >>> >>>> I've been on again and off again collecting stuff... What I've found I've put on source forge since it's easier to upload binaries there. Same for Linux, while there is an ancient Linux site, all it's mirrors are vanishing >>>> >>>>> On February 20, 2017 2:50:13 PM GMT+08:00, Warren Toomey wrote: >>>>>> On Mon, Feb 20, 2017 at 02:14:19PM +0800, Jason Stevens wrote: >>>>>> I dont know if it's worth even trying to find and mirror pre 1993 >>>>> ( IE >>>>>> when cheap CD-ROM mastering was possible) GNU software? >>>>> I'm happy to accept CD images of GNU stuff, but "GNU's not Unix" so it >>>>> may not be put into the Unix Archive. >>>>> >>>>> We do need a GNU historian and curator. Ditto for Linux. >>>>> >>>>> Cheers, Warren >>>> -- >>>> Sent from my Android device with K-9 Mail. Please excuse my brevity. > > From dscherrer at solar.stanford.edu Tue Feb 21 04:37:33 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 20 Feb 2017 10:37:33 -0800 Subject: [TUHS] Reorganising the Unix Archive? (GNU?) In-Reply-To: <201702201827.v1KIR4PR012916@freefriends.org> References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com> <20170220065013.GB19194@minnie.tuhs.org> <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com> <201702200908.v1K983DP011135@freefriends.org> <201702201112.v1KBCwVE017990@freefriends.org> <3fff4d4b-7977-aec1-b62d-fe2e23d79ecd@solar.stanford.edu> <201702201827.v1KIR4PR012916@freefriends.org> Message-ID: <42e98887-0440-3903-65f8-cd35e772508c@solar.stanford.edu> I was one of the 3 primary authors of the Software Tools system (along with Dennis Hall and Joe Sventek), and I was the founder of the users group. (Also served a long time on the Usenix Board, was even president for a while.) Yes, the Georgia Tech stuff was from our system. And, we expanded extensively beyond the tape that was available with the Kernighan/Plauger book. I would be pleased to contribute our code to the archive. Thanks. Deborah On 2/20/17 10:27 AM, arnold at skeeve.com wrote: > Hi Debborah. > > I don't know if we ever met but I certainly recognize your name > from the Software Tools work. > > The original Ratfor and Pascal versions of the tools from the > Kernighan and Plauger books are already in the archive, donated > by yours truly many years ago. (They're from the tapes Addison Wesley > would sell you at the time.) > > Nontheless, I think it would be WONDERFUL to have the enhanced > tools you folks did in the archives. > > Please contribute them! > > Arnold > > P.S. I've asked before, but maybe there are more people around now... > > I was involved with the Georgia Tech subsystem for Pr1me computers which > also built a very Unix like environment in an enhnaced Ratfor to run > on top of Primos. Some of the doc is archived, and I have some paper > copies, but I'd love to see that code unearthed... > > I've made a very few bits that were ported to C are available under > http://github.com/arnoldrobbins, and the 'se' editor has been revived > by Thomas Cort at se-editor.org, but that's all in C. > > If anyone has a tape, I might have a program that could extract > it under *nix. > > Thanks! > > Deborah Scherrer wrote: > >> I would like to add the Software Tools to the Unix archive. As you may >> remember, Brian Kernighan and P. J. Plauger wrote a book about >> developing Unix-like code for non-Unix systems. We at the Lawrence >> Berkeley Lab took that idea and ran with it. We eventually produced a >> set of Unix utilities and a system interface that could be reproduced on >> virtually any operating system. This was freely distributed and >> eventually the package was put up on over 50 different >> computers/systems. There was a user group of about 2000. The movement >> earned one of the Usenix Flame Awards, way back when. >> >> We have the original tapes produced at Lawrence Berkeley Lab, plus a >> Pascal version, plus a version for CP/M. We would like to add these to >> the Unix archive, if you think it appropriate. >> >> Deborah From lm at mcvoy.com Tue Feb 21 08:24:57 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Feb 2017 14:24:57 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> Message-ID: <20170220222457.GB3163@mcvoy.com> Oh brother. On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote: > Larry McVoy wrote: > > > Linus had the qualities of being a good programmer, a good architect, > > and a good manager. I've never seen all 3 in a person before or since. > > My memory is different. He claims that his intention is to keep > kernel/userspace interfaces stable, but given the fact that this did never > happen, I tend to believe that he lacks the understanding on what all is part > of the kernel/userspace interface. So you're taking on the guy who won the Unix wars, has stayed in charge for a couple of decades, created the OS that runs on 498 of 500 super computers, the OS that runs on more phones than apple's phones, tablets, and computers combined? I've worked with Linus, I know him pretty well. I stand by my description above and nothing you've said has changed (and isn't likely to). As for interfaces, huh. I've got two decades of supporting a commercial product that uses file system, networking, VM interfaces and I can't remember a time were we had to change something because Linux broke an API. From scj at yaccman.com Tue Feb 21 09:16:14 2017 From: scj at yaccman.com (Steve Johnson) Date: Mon, 20 Feb 2017 15:16:14 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170220222457.GB3163@mcvoy.com> Message-ID: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> I too have worked with Linus, and agree with the good programmer and good architect. I think he managed the project well for quite a while, but never quite recovered from the GNU incursions. As far as stability and portability is concerned, GNU is a disaster.  Even when a feature is the same across different architectures the option names and values are often different. In one company I worked for we had two releases nearly derailed because of Linux/GCC issues.  In one case, the way locales worked was different between different versions of Linux.  In another case, GCC simply silently removed an option that we depended on and we nearly shipped a product that would have bombed out if the user had already upgraded to the newest GCC. In terms of following the Unix philosophy, the widow managers on Linux are getting more bizarre by the year.  Hitting a key at random by mistake can cause windows to disappear, screens of unknown utility to appear, everything to disappear, etc.  Setting options to try to achieve some kind of consistency is totally different in each system.  Etc. etc.   There seems to be no larger organizing principle at work... ----- Original Message ----- From: "Larry McVoy" To:"Joerg Schilling" Cc: Sent:Mon, 20 Feb 2017 14:24:57 -0800 Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other Oh brother. On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote: > Larry McVoy wrote: > > > Linus had the qualities of being a good programmer, a good architect, > > and a good manager. I've never seen all 3 in a person before or since. > > My memory is different. He claims that his intention is to keep > kernel/userspace interfaces stable, but given the fact that this did never > happen, I tend to believe that he lacks the understanding on what all is part > of the kernel/userspace interface. So you're taking on the guy who won the Unix wars, has stayed in charge for a couple of decades, created the OS that runs on 498 of 500 super computers, the OS that runs on more phones than apple's phones, tablets, and computers combined? I've worked with Linus, I know him pretty well. I stand by my description above and nothing you've said has changed (and isn't likely to). As for interfaces, huh. I've got two decades of supporting a commercial product that uses file system, networking, VM interfaces and I can't remember a time were we had to change something because Linux broke an API. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Tue Feb 21 09:18:42 2017 From: lm at mcvoy.com (Larry McVoy) Date: Mon, 20 Feb 2017 15:18:42 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> References: <20170220222457.GB3163@mcvoy.com> <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> Message-ID: <20170220231842.GO20341@mcvoy.com> I don't see how it is far to lay the userland issues at the feet of Linus, he does the kernel. He's bitched about the same GCC issues as you are. And window managers? What does that have to do with Linus? On Mon, Feb 20, 2017 at 03:16:14PM -0800, Steve Johnson wrote: > I too have worked with Linus, and agree with the good programmer and > good architect. > I think he managed the project well for quite a while, but never quite > recovered from the > GNU incursions. > > As far as stability and portability is concerned, GNU is a disaster.?? > Even when a feature is > the same across different architectures the option names and values > are often different. > In one company I worked for we had two releases nearly derailed > because of Linux/GCC > issues.?? In one case, the way locales worked was different between > different versions of > Linux.?? In another case, GCC simply silently removed an option that > we depended on and we > nearly shipped a product that would have bombed out if the user had > already upgraded > to the newest GCC. > > In terms of following the Unix philosophy, the widow managers on Linux > are getting more > bizarre by the year.?? Hitting a key at random by mistake can cause > windows to disappear, > screens of unknown utility to appear, everything to disappear, etc.?? > Setting options to try to > achieve some kind of consistency is totally different in each > system.?? Etc. etc.???? There seems > to be no larger organizing principle at work... > > ----- Original Message ----- > From: "Larry McVoy" > To:"Joerg Schilling" > Cc: > Sent:Mon, 20 Feb 2017 14:24:57 -0800 > Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other > > Oh brother. > > On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote: > > Larry McVoy wrote: > > > > > Linus had the qualities of being a good programmer, a good > architect, > > > and a good manager. I've never seen all 3 in a person before or > since. > > > > My memory is different. He claims that his intention is to keep > > kernel/userspace interfaces stable, but given the fact that this > did never > > happen, I tend to believe that he lacks the understanding on what > all is part > > of the kernel/userspace interface. > > So you're taking on the guy who won the Unix wars, has stayed in > charge for > a couple of decades, created the OS that runs on 498 of 500 super > computers, > the OS that runs on more phones than apple's phones, tablets, and > computers > combined? > > I've worked with Linus, I know him pretty well. I stand by my > description > above and nothing you've said has changed (and isn't likely to). > > As for interfaces, huh. I've got two decades of supporting a > commercial > product that uses file system, networking, VM interfaces and I can't > remember a time were we had to change something because Linux broke > an API. > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From usotsuki at buric.co Tue Feb 21 09:20:30 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 20 Feb 2017 18:20:30 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> References: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> Message-ID: On Mon, 20 Feb 2017, Steve Johnson wrote: > As far as stability and portability is concerned, GNU is a disaster.  > Even when a feature is the same across different architectures the > option names and values are often different. In one company I worked for > we had two releases nearly derailed because of Linux/GCC issues.  In one > case, the way locales worked was different between different versions of > Linux.  In another case, GCC simply silently removed an option that we > depended on and we nearly shipped a product that would have bombed out > if the user had already upgraded to the newest GCC. I'm no fan of GNU either, and have long considered doing a GNU-less, SysV-flavored Linux distribution as a reaction to all things that annoy me about GNU. > In terms of following the Unix philosophy, the widow managers on Linux > are getting more bizarre by the year.  Hitting a key at random by > mistake can cause windows to disappear, screens of unknown utility to > appear, everything to disappear, etc.  Setting options to try to achieve > some kind of consistency is totally different in each system.  Etc. > etc.   There seems to be no larger organizing principle at work... Which is probably truer than you realize. -uso. From scj at yaccman.com Tue Feb 21 09:25:40 2017 From: scj at yaccman.com (Steve Johnson) Date: Mon, 20 Feb 2017 15:25:40 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170220231842.GO20341@mcvoy.com> Message-ID: <1a671b267d0147c6640e6ca003c193518141a4dc@webmail.yaccman.com> I was responding to the comment about the stability of Linux for product delivery. Having a car with a transmission that works perfectly is of little benefit if the engine and tires keep blowing up. Linus does take responsibility for the kernel, and that is good.  But nobody seems to take responsibility for the other stuff, and that causes a ton of problems. Steve ----- Original Message ----- From: "Larry McVoy" To:"Steve Johnson" Cc:"Larry McVoy" , "Joerg Schilling" , Sent:Mon, 20 Feb 2017 15:18:42 -0800 Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other I don't see how it is far to lay the userland issues at the feet of Linus, he does the kernel. He's bitched about the same GCC issues as you are. And window managers? What does that have to do with Linus? On Mon, Feb 20, 2017 at 03:16:14PM -0800, Steve Johnson wrote: > I too have worked with Linus, and agree with the good programmer and > good architect. > I think he managed the project well for quite a while, but never quite > recovered from the > GNU incursions. > > As far as stability and portability is concerned, GNU is a disaster.?? > Even when a feature is > the same across different architectures the option names and values > are often different. > In one company I worked for we had two releases nearly derailed > because of Linux/GCC > issues.?? In one case, the way locales worked was different between > different versions of > Linux.?? In another case, GCC simply silently removed an option that > we depended on and we > nearly shipped a product that would have bombed out if the user had > already upgraded > to the newest GCC. > > In terms of following the Unix philosophy, the widow managers on Linux > are getting more > bizarre by the year.?? Hitting a key at random by mistake can cause > windows to disappear, > screens of unknown utility to appear, everything to disappear, etc.?? > Setting options to try to > achieve some kind of consistency is totally different in each > system.?? Etc. etc.???? There seems > to be no larger organizing principle at work... > > ----- Original Message ----- > From: "Larry McVoy" > To:"Joerg Schilling" > Cc: > Sent:Mon, 20 Feb 2017 14:24:57 -0800 > Subject:Re: [TUHS] Mach for i386 / Mt Xinu or other > > Oh brother. > > On Mon, Feb 20, 2017 at 07:14:44PM +0100, Joerg Schilling wrote: > > Larry McVoy wrote: > > > > > Linus had the qualities of being a good programmer, a good > architect, > > > and a good manager. I've never seen all 3 in a person before or > since. > > > > My memory is different. He claims that his intention is to keep > > kernel/userspace interfaces stable, but given the fact that this > did never > > happen, I tend to believe that he lacks the understanding on what > all is part > > of the kernel/userspace interface. > > So you're taking on the guy who won the Unix wars, has stayed in > charge for > a couple of decades, created the OS that runs on 498 of 500 super > computers, > the OS that runs on more phones than apple's phones, tablets, and > computers > combined? > > I've worked with Linus, I know him pretty well. I stand by my > description > above and nothing you've said has changed (and isn't likely to). > > As for interfaces, huh. I've got two decades of supporting a > commercial > product that uses file system, networking, VM interfaces and I can't > remember a time were we had to change something because Linux broke > an API. > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From wes.parish at paradise.net.nz Tue Feb 21 10:12:46 2017 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Tue, 21 Feb 2017 13:12:46 +1300 (NZDT) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> Message-ID: <1487635966.58ab85fec0716@www.paradise.net.nz> I think we can lay a lot of the blame for that major annoyance on the two related facts: a: there is no universal windowing system everybody adheres to, just two major commercial ones with spin-offs for smartphones and the like; b: a lot of Linux developers are chasing MS Windows in hope of desktop market share and copy MS Windows features and misfeatures. A major irony is that MS Windows itself has chased Linux somewhat on the graphical user interface front - Linux was the platform of GUI redesign for OLPC and Android, Microsoft took the bait and tried it as a desktop in MS Win 8.0 and got slammed for it. Setting out standards for a herd of cats is not much of an option; the best one could do is publish RFCs giving a list of features that have been proven to work in practice and hope for the best. Wesley Parish Quoting Steve Nickolas : > On Mon, 20 Feb 2017, Steve Johnson wrote: > > > > In terms of following the Unix philosophy, the widow managers on Linux > > > are getting more bizarre by the year.  Hitting a key at random by > > mistake can cause windows to disappear, screens of unknown utility to > > > appear, everything to disappear, etc.  Setting options to try to > achieve > > some kind of consistency is totally different in each system.  Etc. > > etc.   There seems to be no larger organizing principle at work... > > Which is probably truer than you realize. > > -uso. > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn From usotsuki at buric.co Tue Feb 21 11:05:03 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Mon, 20 Feb 2017 20:05:03 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1487635966.58ab85fec0716@www.paradise.net.nz> References: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com> <1487635966.58ab85fec0716@www.paradise.net.nz> Message-ID: On Tue, 21 Feb 2017, Wesley Parish wrote: > I think we can lay a lot of the blame for that major annoyance on the > two related facts: > a: there is no universal windowing system everybody adheres to, just two > major commercial ones with spin-offs for smartphones and the like; > b: a lot of Linux developers are chasing MS Windows in hope of desktop > market share and copy MS Windows features and misfeatures. I don't disagree. But I think there is a universal system, although it has been left to crumble to dust over the years, and having been picked up it still needs a lot of work to be usable in the 21st century. That would be CDE - I'm not aware of any other X Window environment that made it into any versions of the Unix standard (iirc it's part of "Unix 93 Workstation"?) > A major irony is that MS Windows itself has chased Linux somewhat on the > graphical user interface front - Linux was the platform of GUI redesign > for OLPC and Android, Microsoft took the bait and tried it as a desktop > in MS Win 8.0 and got slammed for it. A tablet environment doesn't work very well on a desktop, although a desktop environment can work reasonably well on a tablet (been there done that; I have a Windows 10 tablet). > Setting out standards for a herd of cats is not much of an option; the > best one could do is publish RFCs giving a list of features that have > been proven to work in practice and hope for the best. > > Wesley Parish Herd of cats sums it up nicely. At least CUA makes a reasonable baseline, and most open-source GUI environments and programs seem to support that, as have Windows and OS/2 since almost the beginning. -uso. From doug at cs.dartmouth.edu Tue Feb 21 14:16:53 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Mon, 20 Feb 2017 23:16:53 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <201702210416.v1L4Grmk139053@tahoe.cs.Dartmouth.EDU> > Linus had the qualities of being a good programmer, a good architect, > and a good manager. I've never seen all 3 in a person before or since. No comment about Linus, but Vic Vyssotsky is my pick for the title. He created the first dataflow language (in 1960!). He invented bit-parallel flow analysis and put it into Fortran 2 years later. He was one of the technical triumvirs for Multics. Ran several big development groups at Bell Labs, and was 2 levels up from the Unix team in Research. I could go on and on. What he didn't do was publish; he got ahead on pure innate ability and brilliant insight--a profound influence on almost all] the original Unix crowd. Doug From schily at schily.net Tue Feb 21 20:30:34 2017 From: schily at schily.net (Joerg Schilling) Date: Tue, 21 Feb 2017 11:30:34 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170220222457.GB3163@mcvoy.com> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> Message-ID: <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> Larry McVoy wrote: > I've worked with Linus, I know him pretty well. I stand by my description > above and nothing you've said has changed (and isn't likely to). I know him as well, he send various personal attacks against me....when I tried to discuss Linux kernel bugs on LKML or made proposals on how problems could be fixed - e.g. the Linux kernel include files that are needed for various user space programs but these include files did not compile with user space programs. He told me that what I proposed was nonsense, but 5 years later, they implemented my proposal. As Linux personally and incorrectly claimed that I was talking about kernel internal interfaces even though I was definitely talking about kernel/userspace interfaces, I assume that he has a problem with understanding what an external interface is. > As for interfaces, huh. I've got two decades of supporting a commercial > product that uses file system, networking, VM interfaces and I can't > remember a time were we had to change something because Linux broke > an API. You may have had luck. You also may have used only those interfaces that are not Linux specific but rather UNIX interfaces that cannot be changed without protest from thousands of people. Let me assume that you are talking about BitKeeper SCCS, then it is obvious that you do not need to use Linux specific interfaces in your software. You may have started with Linux later than I did - I started in 1996. My software implements support for many Linux specific interfaces (*) and I have been a victim of incompatible interface changes many times. Fortunately, I have no longer been hit since 5 years. *) star e.g. implements support for Linux specific file meta data and cdrtools e.g need to implement pass through SCSI. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From jnc at mercury.lcs.mit.edu Tue Feb 21 22:02:18 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 21 Feb 2017 07:02:18 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> > From: Joerg Schilling > He is a person with a strong ego and this may have helped to spread > Linux. Well, I wasn't there, and I don't know much about the early Linux versus UNIX-derivative contest, but from personal experience in a similar contest (the TCP/IP versus ISO stack), I doubt such personal attributes had _that_ much weight in deciding the winner. The maximum might have been that it enabled him to keep the Linux kernel project unified and heading in one direction. Not inconsiderable, perhaps, if there's confusion on the other side.,, So there is a question here, though, and I'm curious to see what others who were closer to the action think. Why _did_ Linux succeed, and not a Unix derivative? (Is there any work which looks at this question? Some Linux history? If not, there should be.) It seems to me that they key battleground must have been the IMB PC-compatible world - Linux is where it is now because of its success there. So why did Linux succeed there? Was is that it was open-source, and the competitor(s) all had licensing issues? (I'm not saying they did, I just don't know.) Was it that Linux worked better on that platform? (Again, don't know, only asking.) Perhaps there was an early stage where it was the only good option for that platform, and that's how it got going? Was is that there were too many Unix-derived alternatives, so there was no clarity as to what the alternatives were? Some combination of all of the above (perhaps with different ones playing a key role at different points in time)? Noel From steffen at sdaoden.eu Tue Feb 21 22:24:25 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 21 Feb 2017 13:24:25 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: <20170221122425._PTIq%steffen@sdaoden.eu> jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: |So there is a question here, though, and I'm curious to see what others who |were closer to the action think. Why _did_ Linux succeed, and not a Unix |derivative? (Is there any work which looks at this question? Some Linux |history? If not, there should be.) Likely this can at least in parts be explained with human behaviour and social movement. It was new, it was fresh, the early postings of Linus Torvalds give a clear impression that he wants to get out and rise and get this thing done. His thing was completely baggage-free (means something, just listen [1]) and everybody was welcome to take part and make this something one can be prowd of. Or nearby that. And it has grown a very, very large codebase. Just yesterday: ?0[steffen at wales ]$ sysctl hw.ncpu sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory Then again i wildly guess and find this is to be a GNU problem. And: you don't have to write a good documentation, or any at all. I will _never_ forget once i came from SUSE, then RedHat and Halloween Linux to FreeBSD the first time, with all that grown infrastructure, also that in /usr/share/doc and /usr/share/misc, that was nothing but an enlightenment to me. Plan9 i didn't know at all until three or so years ago, there you also have nice documentation (and if you include doc.cat-v.org). You are a student, you have no girl friend, you don't have much money, saturday nights are long and boring, and there you can get something really great going, can be creative and get some self-fulfilment, and communicate with others all over the world which all pull together. That is pretty cool -- and the result really was, too, even before IBM and such spent billions of dollars to improve it even further. About, i don't know, 16 or so years later?, Linux is still free software, and it has not be torn in pieces due to all the interests: i think that really is a great achievement, and likely that the person Linus Torvalds is not innocent at it. [1] https://www.youtube.com/watch?v=45OhGdzcEFk --steffen From michael at kjorling.se Tue Feb 21 22:57:51 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Tue, 21 Feb 2017 12:57:51 +0000 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221122425._PTIq%steffen@sdaoden.eu> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221122425._PTIq%steffen@sdaoden.eu> Message-ID: <20170221125751.GI8034@yeono.kjorling.se> On 21 Feb 2017 13:24 +0100, from steffen at sdaoden.eu (Steffen Nurpmeso): > And it has grown a very, very large codebase. Just yesterday: > > ?0[steffen at wales ]$ sysctl hw.ncpu > sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory Not sure what you meant to show by that... > About, i don't know, 16 or so > years later?, Linux is still free software, and The Linux kernel was originally released in September 1991 (and was Torvald's way of learning about the 80386). 0.12 was the first GPL'd version, released in February 1992; and 1.0 was released in March 1994. So we are just about 23 years past Linux kernel 1.0. -- 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 random832 at fastmail.com Tue Feb 21 23:47:41 2017 From: random832 at fastmail.com (Random832) Date: Tue, 21 Feb 2017 08:47:41 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> Message-ID: <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> On Tue, Feb 21, 2017, at 05:30, Joerg Schilling wrote: > *) star e.g. implements support for Linux specific file meta data Which interfaces for accessing these have been broken by which versions of Linux? > and cdrtools e.g need to implement pass through SCSI. Requiring "pass through SCSI" for a CD burner violates the UNIX philosophy that everything is a file (which implies that reading and writing data be implemented, where possible, through the read and write system calls rather than through special interfaces specific to a device type). So does requiring SCSI bus numbers rather than device filenames. From clemc at ccc.com Wed Feb 22 01:02:22 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 10:02:22 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 21, 2017 at 7:02 AM, Noel Chiappa wrote: > So there is a question here, though, and I'm curious to see what others who > were closer to the action think. Why _did_ Linux succeed, and not a Unix > derivative? (Is there any work which looks at this question? Some Linux > history? If not, there should be.) > ​I​'ve thought and written a bit about this question a bit [ Would it be possible/advantageous to rewrite the Linux kernel in Rust when the language is stable? & Why did Unix succeed and not Multics ] ​ ​ and I'll not repeat all of here but ​as one of the people that did switch from 386BSD to linux at the time, the reason for me was purely because of the AT&T/BSDi case. You are right, I wanted a "free" (i.e. very inexpensive) UNIX for the 386 and the "big guns"​ were not going to give it. I thought we had it the 386 port BSD which I had helped in a small way to create. ​But I like, most hackers of the day, misunderstood incorrectly​ the case to be about *trade secret *and the all based around the 1956 consent decree, IBM vs AT&T; telephones and the computers. I was worried AT&T would win because it was going to hard to cleaim that that the BSD code was not a derivative work of the AT&T *copyright code base *(not understanding the *trade secret* and the *copyright* difference mattered). So...I switched to Linux *not because I thought it was "better"* - in fact, I b*tched (and still do) about many gratuitous differences, but as I knew that we needed something for "consumer" HW (which was bring driven by the WINTEL economics), and I was willing to use the "lessor" technology (Linux) because it was "good enough" and gave me what I needed (UNIX on a PC/386). I thought (incorrectly) somehow original Linux's European authorship was going to protect me and my fellow hackers ever though it was not as good as my beloved BSD system. Simple put - using Christiansen's theories: Linux "won" because: - it was "good enough", - had a lot of people behind it that valued that was there and invested in making it "better", and - the economics of the platform (PC/386 - WINTEL etc) was on the fastest grow curve [and its Christiansen's economic disruption was displacing the Mini & Workstation]. BTW: at the time, I argued with the Roger Gourd and the OSF folks, that if they released (sold) the OSF/1 RI uK which had not AT&T technology in it (again thinking Copyright not Trade Secret); I was suggesting $100/copy there was a market for it. I just could not get them interested. Sun has done the RoadRunner and had their 386 port of Solaris; but again. All the "UNIX" folks were still interested in pushing out "iron" so were blind to the WINTEL economic disruption. Woulda, Coulda, Shoulda .... sigh Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Wed Feb 22 01:15:47 2017 From: chet.ramey at case.edu (Chet Ramey) Date: Tue, 21 Feb 2017 10:15:47 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: On 2/21/17 7:02 AM, Noel Chiappa wrote: > So there is a question here, though, and I'm curious to see what others who > were closer to the action think. Why _did_ Linux succeed, and not a Unix > derivative? (Is there any work which looks at this question? Some Linux > history? If not, there should be.) > > It seems to me that they key battleground must have been the IMB PC-compatible > world - Linux is where it is now because of its success there. So why did > Linux succeed there? > > Was is that it was open-source, and the competitor(s) all had licensing > issues? (I'm not saying they did, I just don't know.) Was it that Linux worked > better on that platform? (Again, don't know, only asking.) Perhaps there was > an early stage where it was the only good option for that platform, and that's > how it got going? Was is that there were too many Unix-derived alternatives, > so there was no clarity as to what the alternatives were? I was there at the time (bash was the first thing Linus ported to Linux) and I have to say it was the combination of the availability, since the BSDs were still encumbered, the accessibility, since its hardware demands were very modest, and the FSF's enthusiastic porting of all the GNU apps to it. It was the perfect student/starting system for the time. You can talk about lost opportunities, but it was the right system at the time, and I say this as a BSD guy from way back. Chet -- ``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://cnswww.cns.cwru.edu/~chet/ From schily at schily.net Wed Feb 22 01:18:18 2017 From: schily at schily.net (Joerg Schilling) Date: Tue, 21 Feb 2017 16:18:18 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> Message-ID: <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> Random832 wrote: > On Tue, Feb 21, 2017, at 05:30, Joerg Schilling wrote: > > *) star e.g. implements support for Linux specific file meta data > > Which interfaces for accessing these have been broken by which versions > of Linux? The filesystem specific kernel include files are broken on many linux distributions. > > and cdrtools e.g need to implement pass through SCSI. > > Requiring "pass through SCSI" for a CD burner violates the UNIX > philosophy that everything is a file (which implies that reading and > writing data be implemented, where possible, through the read and write > system calls rather than through special interfaces specific to a device > type). You are incorrectly informed: Writing CDs is a highly complex task. No known kernel is able to do that internally. So the only useful method is to use SCSI pass through. > So does requiring SCSI bus numbers rather than device filenames. SCSI bus numbers are part of the SCSI CAM Standard for SCSI addressing, you are badly informed a second time. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From dds at aueb.gr Wed Feb 22 01:54:13 2017 From: dds at aueb.gr (Diomidis Spinellis) Date: Tue, 21 Feb 2017 17:54:13 +0200 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> Message-ID: <094c861a-e7ef-3e79-9d70-ada7e579d127@aueb.gr> On 21/02/2017 17:18, Joerg Schilling wrote: >> Requiring "pass through SCSI" for a CD burner violates the UNIX >> philosophy that everything is a file (which implies that reading and >> writing data be implemented, where possible, through the read and write >> system calls rather than through special interfaces specific to a device >> type). > > You are incorrectly informed: > > Writing CDs is a highly complex task. No known kernel is able to do that > internally. > > So the only useful method is to use SCSI pass through. This is an interesting point. However, controlling the C/A/T phototypesetter 20 years before writable CD-ROM appeared, was also a very complex task, yet it was accomplished through a simple device file. Controlling a voice modem is also complex, time-critical, and requires bidirectional communication. Again, voice modems were controlled through a character device file. One can envisage a CD-ROM device driver abstracting the commands required for writing CD-ROMs into a text-based interface made available though a character device. These precedents demonstrate that the SCSI pass through was an unneeded architecture-violating shortcut. Arguably, the same can also be claimed for the networking system calls. Diomidis From jnc at mercury.lcs.mit.edu Wed Feb 22 02:25:30 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 21 Feb 2017 11:25:30 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <20170221162530.79EAB18C116@mercury.lcs.mit.edu> > From: Diomidis Spinelli > Arguably, the same can also be claimed for the networking system calls. Well, it depends on exactly what you mean by "networking system calls". If you mean networking a la BSD, perhaps. However, I can state (from personal experience :-) that the I/O architecture circa V6/V7 was not very suitable for TCP/IP internetworking (with its emphasis on an un-reliable network, and smart endpoints). The reason is that such networking doesn't really fit well into the 'start one I/O operation and then block the process until it completes' model. Yes, if you have an application running on top of a reliable stream, you might be able to coerce that into the 'uni-directional, blocking' I/O model (if the reliable stream implementation is in, or routed through, the kernel), but lots of other thing don't work so well. (Think, e.g. an interface with asynchronous, un-predictable, RPC calls in both directions.) Noel From random832 at fastmail.com Wed Feb 22 02:32:22 2017 From: random832 at fastmail.com (Random832) Date: Tue, 21 Feb 2017 11:32:22 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> Message-ID: <1487694742.1619299.888147784.303CBC43@webmail.messagingengine.com> On Tue, Feb 21, 2017, at 10:18, Joerg Schilling wrote: > > So does requiring SCSI bus numbers rather than device filenames. > > SCSI bus numbers are part of the SCSI CAM Standard for SCSI addressing, > you > are badly informed a second time. Why does that make them more useful for end users than device filenames, especially for non-SCSI devices? USB or ATA bus numbers - or USB device identifiers - might be more useful than SCSI bus numbers, for end users who have USB or ATA devices. ATA bus numbers had a deterministic mapping to /dev/hd* device filenames, once upon a time. Why does that mean the correct solution is "require the user to type in the bus number on a program's command line" rather than "configure a particular bus number to have a particular filename"? From b4 at gewt.net Wed Feb 22 02:38:49 2017 From: b4 at gewt.net (Cory Smelosky) Date: Tue, 21 Feb 2017 08:38:49 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <094c861a-e7ef-3e79-9d70-ada7e579d127@aueb.gr> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> <094c861a-e7ef-3e79-9d70-ada7e579d127@aueb.gr> Message-ID: <58AC6D19.9010100@gewt.net> Diomidis Spinellis wrote: > On 21/02/2017 17:18, Joerg Schilling wrote: >>> Requiring "pass through SCSI" for a CD burner violates the UNIX >>> philosophy that everything is a file (which implies that reading and >>> writing data be implemented, where possible, through the read and write >>> system calls rather than through special interfaces specific to a device >>> type). >> >> You are incorrectly informed: >> >> Writing CDs is a highly complex task. No known kernel is able to do that >> internally. >> >> So the only useful method is to use SCSI pass through. > > This is an interesting point. However, controlling the C/A/T > phototypesetter 20 years before writable CD-ROM appeared, was also a > very complex task, yet it was accomplished through a simple device file. > Controlling a voice modem is also complex, time-critical, and requires > bidirectional communication. Again, voice modems were controlled through > a character device file. How would you handle the different writing methods? Separate device files or an ioctl on a generic device node? (not arguing - genuinely curious about your theory) > > One can envisage a CD-ROM device driver abstracting the commands > required for writing CD-ROMs into a text-based interface made available > though a character device. These precedents demonstrate that the SCSI > pass through was an unneeded architecture-violating shortcut. > > Arguably, the same can also be claimed for the networking system calls. > > Diomidis > From lm at mcvoy.com Wed Feb 22 02:47:28 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 08:47:28 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: <20170221164728.GZ20341@mcvoy.com> On Tue, Feb 21, 2017 at 07:02:18AM -0500, Noel Chiappa wrote: > So there is a question here, though, and I'm curious to see what others who > were closer to the action think. Why _did_ Linux succeed, and not a Unix > derivative? (Is there any work which looks at this question? Some Linux > history? If not, there should be.) http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html is worth a read, I was very much in the middle of all this at the time. I think Linux succeeded because: - it was free and GPLed. BSD license is nice but it has the problem that people can take it closed source and not give back changes. - no lawsuit - Linus (as mentioned, much stronger leader than any in the Unix world) - no religion. I can't make this point hard enough. At Sun, we couldn't change any API, any utility, it was compat to the point that it was not useful. Look at SVr4/Solaris /proc and then look at Linux /proc. The Linux one is way, way, way, way more useful, you can dig shit out with shell scripts. The rest of the Unix world was blindly posix compat even when posix compat made no sense. Linux was glorious in that Linus wanted compat but was willing to break it for good reasons. - good enough - fun, all the cool kids were there. Here is perhaps something that will resonate with this crowd. When I was teaching OS at Stanford, for file systems I made people go through the thought process on when you write what (think the sync writes so the FS isn't busted when you crash). For years, the BSD guys insisted that Linux was doing it wrong because they didn't do the sync writes, they did ordered writes (but the BSD guys didn't understand the write ordering so they thought it was busted, as did I). But Linux wasn't busted, they had carefully gone through the process of figuring out when stuff had to be first so that you could survive a crash. The BSD guys refused to believe that it was possible, they were stuck on writes had to be synchronous in order to get a file system that wasn't corrupted on a crash. I eventually started convincing them that Linux had it right by saying just untar some big tarball and unplug the power in the middle of that on a system with UFS and a system with ext2. Tell me what happens when you power it up. Answer? The UFS based system dropped you into a fsck nightmare of unattached inodes, the ext2 based systems lost some data but the file system was fine. Obviously, the Linux approach won, it's better. Way better, higher performance and a much better user experience. But the traditional Unix guys had to be dragged kicking and screaming, over a decade, into that world. It's stuff like that that made Unix stagnate while Linux forged ahead. From schily at schily.net Wed Feb 22 02:48:03 2017 From: schily at schily.net (Joerg Schilling) Date: Tue, 21 Feb 2017 17:48:03 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <094c861a-e7ef-3e79-9d70-ada7e579d127@aueb.gr> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> <094c861a-e7ef-3e79-9d70-ada7e579d127@aueb.gr> Message-ID: <58ac6f43.Seb4wAXiRwCTvCR3%schily@schily.net> Diomidis Spinellis wrote: > > Writing CDs is a highly complex task. No known kernel is able to do that > > internally. > > > > So the only useful method is to use SCSI pass through. > > This is an interesting point. However, controlling the C/A/T > phototypesetter 20 years before writable CD-ROM appeared, was also a > very complex task, yet it was accomplished through a simple device file. Well, it used a serial or parallel connection on top of a standard driver. I cannot speak for a real C/A/T device, but I know the Berthold phototypesetters that use a serial line with a nearly identical interface and C/A/T probably was a clone of a Berthold phototypesetter. In the C/A/T case, troff has the knowledge about how to talk to the phototypesetter and uses a "pass through" UNIX driver to transfer the data. For the CD writers, please keep in mind that during the time when everybody used them, there was a constant development on the SCSI command interface for the devices and many of the drives had massive firmware bugs. cdrecord does always include support for all recent drives and implements workarounds for the firmware bugs. Do not expect that people in the UNIX kernel area would ever react in time and do not expect that potential abstraction layers from the CD drives would be compatible amongst different UNIX versions. Have a look at a similar problem from 1969: There was only one IMP and a set of IMP<->computer adaptors for every possible "computer" system. The IMP<->computer adaptor is similar to the lowest layer of my libscg. Above that layer in libscg, everything is portable and unified. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From schily at schily.net Wed Feb 22 02:55:04 2017 From: schily at schily.net (Joerg Schilling) Date: Tue, 21 Feb 2017 17:55:04 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1487694742.1619299.888147784.303CBC43@webmail.messagingengine.com> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> <1487694742.1619299.888147784.303CBC43@webmail.messagingengine.com> Message-ID: <58ac70e8.0rhyveE4L0rLZuge%schily@schily.net> Random832 wrote: > Why does that make them more useful for end users than device filenames, > especially for non-SCSI devices? USB or ATA bus numbers - or USB device > identifiers - might be more useful than SCSI bus numbers, for end users > who have USB or ATA devices. ATA bus numbers had a deterministic mapping > to /dev/hd* device filenames, once upon a time. You know that Linux implements several different competing methods to access these drive types? You know that some of them do not (or not correctly) support DMA? You know that DVD drives will not work for writing if you do not have DMA? > Why does that mean the correct solution is "require the user to type in > the bus number on a program's command line" rather than "configure a > particular bus number to have a particular filename"? Why do people always repeat the same questions that have been answered many times in the past already? 1) CAM is a standard, why not use it? full stop 2) **Most** Operating systems do not support /dev/* based access to SCSI. This includes a POSIX certified system like Mac OS X. 3) **Most** Operating systems do not even support a file descriptor based interface to SCSI commands. This includes a POSIX certified system like Mac OS X. 4) CAM is the only interface method that can be mapped to all existing operating system specific implementations. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From crossd at gmail.com Wed Feb 22 03:10:07 2017 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Feb 2017 12:10:07 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ac70e8.0rhyveE4L0rLZuge%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> <1487694742.1619299.888147784.303CBC43@webmail.messagingengine.com> <58ac70e8.0rhyveE4L0rLZuge%schily@schily.net> Message-ID: On Feb 21, 2017 11:55 AM, "Joerg Schilling" wrote: Random832 wrote: > Why does that make them more useful for end users than device filenames, > especially for non-SCSI devices? USB or ATA bus numbers - or USB device > identifiers - might be more useful than SCSI bus numbers, for end users > who have USB or ATA devices. ATA bus numbers had a deterministic mapping > to /dev/hd* device filenames, once upon a time. You know that Linux implements several different competing methods to access these drive types? You know that some of them do not (or not correctly) support DMA? You know that DVD drives will not work for writing if you do not have DMA? All of which *could* be supported in a kernel driver. > Why does that mean the correct solution is "require the user to type in > the bus number on a program's command line" rather than "configure a > particular bus number to have a particular filename"? Why do people always repeat the same questions that have been answered many times in the past already? I don't think it was a question. It was a philosophical statement. 1) CAM is a standard, why not use it? full stop 2) **Most** Operating systems do not support /dev/* based access to SCSI. This includes a POSIX certified system like Mac OS X. 3) **Most** Operating systems do not even support a file descriptor based interface to SCSI commands. This includes a POSIX certified system like Mac OS X. 4) CAM is the only interface method that can be mapped to all existing operating system specific implementations. In other words, you worked around perceived problems in what most on this list would consider the traditional file based UNIX method by implementing in terms of a different standard. That's fine, of course, but is independent of the philosophical point that it is not in keeping with the traditional method. It's perhaps noteworthy that writing to a CD or DVD on Plan 9 is done with cat (and networking is implemented in terms of opening, reading and writing named files). So it's certainly *possible* to use a filesystem method to write physical media, even if impractical on the array of real-world systems you want to support. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 22 04:58:40 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 13:58:40 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221164728.GZ20341@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> Message-ID: comments below, before I start, I will say - "hear, hear" - I agree with Larry on this way more than I disagree. On Tue, Feb 21, 2017 at 11:47 AM, Larry McVoy wrote: > > http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html > > is worth a read, ​Indeed - I agreed then and still do.​ I was trying to do the same thing at OSF. But we were working the same ideas. > I was very much in the middle of all this at the time. > Indeed, I can verify that ;-)​ > > I think Linux succeeded because: > > - it was free ​I agree...​ > and GPLed. BSD license is nice but it has the problem > that people can take it closed source and not give back changes. > ​This is where we disagree and probably always have on this point, but that's topic for a beer sometime which I definitely want to have! ​ > > - no lawsuit > ​100% agree, to be that was the most important point after the acquisition cost. ​ > > - Linus (as mentioned, much stronger leader than any in the Unix world) > ​Mumble - maybe. Like you, I've know the players. Linus' ego is​ not better or worse than any of the rest of them, although I admit some of the UNIX players got really nasty. Sadly, the old "he who has the gold, rules" game held true [a dragon's curse maybe]. The best I ever saw were folks that never really wanted it. Dennis and Vic (as Doug said), were quiet leaders. Linus was better at the beginning, but he really did not listen well either. There was a lot of reinventing going on, with little true advantage other than said person was able to say they did it. For instance, I personally don't think ext[234] are much better that BFFS/UFS[12], certainly compared to MegaSafe (aka AdvFS) or XFS. But Ted got to write his own, which was cool for a young guy at the time. To me, it would have made a lot more sense because BSD was freely licensed to just grab the BFFS to replace Minux FS and run with it. But Linus was not that type of leader, I also think he is a very smart guy, but was blind to a lot of the things on outside of his world. He admits he did not know about 386BSD when he started. That said, Linus got along with enough folks at it worked. If, Linus has had say, Theo's or some of other personalities of the day, maybe he would have ticked off more people early on and you might be right. So personally >>helped<< here but I don't think it was as important as being at the right place, when the law suit came about a lot of scared hackers like me looking for an alternative for the 386. > > - no religion. I can't make this point hard enough. ​I'ld change that a little. It started with less religion, it now is as contentions, if not worse than the UNIX Wars of the day. The difference is when is started it did not have the economic impact of the "big UNIX/big Iron" so it was irgnored. That's Christiansen disruption -- a worse technology is ignored by the big guys.​ > ​ ​ > At Sun, we couldn't > change any API, any utility, it was compat to the point that it was > not > useful. ​I get it and I will grant this to a point.​ > ​ ​ > Look at SVr4/Solaris /proc and then look at Linux /proc. The > Linux one is way, way, way, way more useful, you can dig shit out > with > shell scripts. The rest of the Unix world was blindly posix compat > even when posix compat made no sense. Linux was glorious in that > Linus wanted compat but was willing to break it for good reasons. > ​Yep, a clean sheet can help when you are lucky enough to be able to ignore the past. But Linux got started and it's toe hold because it did not ignore the past. It was the POSIX nature that allowed us to consider it. What you are saying is that UNIX dogma, got in the way. Again, we let traditional "Harvard Business School -H-BS" thinking set up sustaining thinking, and could not see it was killing the golden goose.​ > > - good enough > ​Amen brother... I really think this is the key point. It was good enough, and worked on a the WINTEL economic disruption. Yup is was not "as good" but it was good enough, and with *BSD being tainted by the USL/BSDi legal actions, folks like you, me and folks on this list not only said " we can fix that", that did it and filled in what was missing. ​ > > - fun, all the cool kids were there. ​All amend that to say, many of the cool kids ran over there because the pool was not being "peed in" by all the other messes we just discussed. Anyway - as I said, I agree way more than I disagree. Well said Larry!! Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 22 05:21:24 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 11:21:24 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> Message-ID: <20170221192124.GO20341@mcvoy.com> On Tue, Feb 21, 2017 at 01:58:40PM -0500, Clem Cole wrote: > For instance, I personally don't think ext[234] are much better that > BFFS/UFS[12], certainly compared to MegaSafe (aka AdvFS) or XFS. So I was also at SGI, I know the whole XFS (and XLV) team, and I know the code pretty well, I plugged it into NFS so that NFS could use all that bandwidth: http://www.mcvoy.com/lm/bitmover/lm/talks/bds.pdf In terms of crash worthyness, ext2 was better. I think the ext2 people took the approach that they wanted to be as robust as dos but with performance. And they made it, it's some very nice work. > got to write his own, which was cool for a young guy at the time. To me, > it would have made a lot more sense because BSD was freely licensed to just > grab the BFFS to replace Minux FS and run with it. Nope. And I sort of made my name working on FFS with srk, I'm a fan of what FFS/UFS could do but ext2 went way way further. And did so pretty quickly, far more quickly than any of the Unix shops would have done, they were more cautious. The linux kids were like the young guys you got straight out of school and told them to do the impossible. Once in a while, they did. > That said, Linus got along with enough folks at it worked. Sort of. i think a far bigger deal was that he commanded respect, there were lots of stories floating around like when people sent him patches he knew the code well enough that an context diff was enough context that he'd see a bug in the patch, edit the patch, and apply it. I've seen him do that, he's a programmer's programmer. Unlike a lot of leaders who lead but when they have to get their hands dirty they are sort of wussy. From norman at oclsc.org Wed Feb 22 05:23:48 2017 From: norman at oclsc.org (Norman Wilson) Date: Tue, 21 Feb 2017 14:23:48 -0500 Subject: [TUHS] Another odd comment in V6 Message-ID: <1487705031.29325.for-standards-violators@oclsc.org> Noel: Instead, you have to modify the arguments so that the re-tried call takes up where it left off - in the example above, tries to read 5 characters, starting 5 bytes into the buffer). The hard part is that the return value (of the number of characters actually read) has to count the 5 already read! Without the proper design of the system call interface, this can be hard - how does the system distinguish between the _first_ attempt at a system call (in which the 'already done' count is 0), and a _later_ attempt? If the user passes in the 'already done' count, it's pretty straightforward - otherwise, not so much! ==== Sometime in the latter days of the Research system (somewhere between when the 9/e and 10/e manuals were published), I had an inspiration about that, and changed things as follows: When a system call like read is interrupted by a signal: -- If no characters have been copied into the user's buffer yet, return -1 and set errno to EINTR (as would always have been done in Heritage UNIX). -- If some data has already been copied out, return the number of characters copied. So no data would be lost. Programs that wanted to keep reading into the same buffer (presumably until a certain terminator character is encountered or the buffer is full or EOF) would have to loop, but a program that didn't loop in that case was broken anyway: it probably wouldn't work right were its input coming from a pipe or a network connection. I don't remember any programs breaking when I made that change, but since it's approaching 30 years since I did it, I don't know whether I can trust my memory. Others on this list may have clearer memories. All this was a reaction to the messy (both in semantics and in implementation) compromise that had come from BSD, to have separate `restart the system call' and `interrupt the system call' states. I could see why they did it, but was never satisfied with the result. If only I'd had my inspiration some years earlier, when there was a chance of it getting out into the real world and influencing POSIX and so on. Oh, well. Norman Wilson Toronto ON From schily at schily.net Wed Feb 22 05:44:43 2017 From: schily at schily.net (Joerg Schilling) Date: Tue, 21 Feb 2017 20:44:43 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> <1487694742.1619299.888147784.303CBC43@webmail.messagingengine.com> <58ac70e8.0rhyveE4L0rLZuge%schily@schily.net> Message-ID: <58ac98ab.afYqPbvivuKUTFMJ%schily@schily.net> Dan Cross wrote: > In other words, you worked around perceived problems in what most on this No, I designed an interface that works on top of all known operating systems. The term "perceived" does not apply. > It's perhaps noteworthy that writing to a CD or DVD on Plan 9 is done with > cat (and networking is implemented in terms of opening, reading and writing > named files). So it's certainly *possible* to use a filesystem method to > write physical media, even if impractical on the array of real-world > systems you want to support. So you believe you can create a dual layer video DVD with a layer break that matches the meta data in the IFO file with that driver concept? So you believe you can write an audio CD with CD-Text that matches the indices on an existing CD with that driver concept? So you believe you can read an audio CD in a way that allows you make a definite statement on whether all bits have been read correctly or whether there have been interpolated parts inside? People who only have a hammer tend to believe that all problems are nails. This is what you get on Plan 9... Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From clemc at ccc.com Wed Feb 22 06:17:18 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 15:17:18 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221192124.GO20341@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> Message-ID: On Tue, Feb 21, 2017 at 2:21 PM, Larry McVoy wrote: > In terms of crash worthyness, ext2 was better. I think the ext2 people > took the approach that they wanted to be as robust as dos but with > performance. And they made it, it's some very nice work. > ​Fair enough - It never seems from the outside a much different and when I was working with it, it was just enough different that all of the tools (like BSD backup/restore) broke.​ Having personally worked on fsck v6/v7 at CMU and Kirk reimplementing it with BSD, I had a fairly strong sense of "keep the tools" working. I actually hated SysV's FSDB, but could use it. Kirk and Sam reimplemented dump/restore but kept the "script" level interface pretty much as is. So, here come linux and the only part of file kits that still works is part of the user space stuff (ls, tar, cp). But beyond that it is all different. Ted/Steve eventually did do a fsck-like thing for ext2 fairly quickly, but nothing else - so that was part of my comment about "gratuitous changes." Why because by 1991 when linux comes into my house, I have a set of other UNIX systems at home running and here it is I have to have different tools for this new linux box. grumble... > > Nope. And I sort of made my name working on FFS with srk, I'm a fan of > what FFS/UFS could do but ext2 went way way further. > ​Fair enough...​ > And did so pretty > quickly, far more quickly than any of the Unix shops would have done, > they were more cautious. > ​Agreed, although I always thought megasafe (advfs) was pretty cool and have had fairly good experiences with XFS after SGI let it out to other folks (still run it on my linux based NAS box truth known) . As I said, my main complaint against ext2 was when I first encountered it none of the BSD FS tools worked and that ticked me off. ​ > > The linux kids were like the young guys you got straight out of school > and told them to do the impossible. Once in a while, they did. > ​Ok, I'll accept that. ​ Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug at cs.dartmouth.edu Wed Feb 22 06:25:43 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 21 Feb 2017 15:25:43 -0500 Subject: [TUHS] Re; Mach for i486 / Mt Xinu or other Message-ID: <201702212025.v1LKPhRp021592@coolidge.cs.Dartmouth.EDU> > 2) **Most** Operating systems do not support /dev/* based access to SCSI. > This includes a POSIX certified system like Mac OS X. > > 3) **Most** Operating systems do not even support a file descriptor based > interface to SCSI commands. > This includes a POSIX certified system like Mac OS X. Had Ken thought that way, Unix's universal byte-addressable file format would never have happened; this mailing list would not exist; and we all might still be fluent in dialects of JCL. dd was sufficient glue to bridge the gap between Unix and **Most** Operating Systems. Meanwhile everyday use of Unix was freed from the majority's folly. Doug From usotsuki at buric.co Wed Feb 22 06:28:13 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 21 Feb 2017 15:28:13 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221192124.GO20341@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> Message-ID: On Tue, 21 Feb 2017, Larry McVoy wrote: > In terms of crash worthyness, ext2 was better. I think the ext2 people > took the approach that they wanted to be as robust as dos but with > performance. And they made it, it's some very nice work. Wouldn't "as robust as DOS" be a *bad* thing? -uso. From lm at mcvoy.com Wed Feb 22 06:32:56 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 12:32:56 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> Message-ID: <20170221203256.GF3250@mcvoy.com> On Tue, Feb 21, 2017 at 03:28:13PM -0500, Steve Nickolas wrote: > On Tue, 21 Feb 2017, Larry McVoy wrote: > > >In terms of crash worthyness, ext2 was better. I think the ext2 people > >took the approach that they wanted to be as robust as dos but with > >performance. And they made it, it's some very nice work. > > Wouldn't "as robust as DOS" be a *bad* thing? The DOS file system, while stupid, was very robust in the face of crashes (sort of had to be, he says slyly). From crossd at gmail.com Wed Feb 22 07:17:29 2017 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Feb 2017 16:17:29 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ac98ab.afYqPbvivuKUTFMJ%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <1487684861.1580775.887937752.698B8B60@webmail.messagingengine.com> <58ac5a3a.geKODIzKbcVWDsIS%schily@schily.net> <1487694742.1619299.888147784.303CBC43@webmail.messagingengine.com> <58ac70e8.0rhyveE4L0rLZuge%schily@schily.net> <58ac98ab.afYqPbvivuKUTFMJ%schily@schily.net> Message-ID: On Tue, Feb 21, 2017 at 2:44 PM, Joerg Schilling wrote: > [snip] People who only have a hammer tend to believe that all problems are nails. > > This is what you get on Plan 9... I think you entirely missed the point of this discussion. I've noticed this follows something of a pattern. *shrug* - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 22 07:37:54 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 13:37:54 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> Message-ID: <20170221213754.GA6103@mcvoy.com> On Tue, Feb 21, 2017 at 11:30:34AM +0100, Joerg Schilling wrote: > Larry McVoy wrote: > > > I've worked with Linus, I know him pretty well. I stand by my description > > above and nothing you've said has changed (and isn't likely to). > > I know him as well, he send various personal attacks against me. Linus attacks anyone who he thinks is misguided. He's been wrong but he's usually right. > As Linux personally and incorrectly claimed that I was talking about kernel > internal interfaces even though I was definitely talking about > kernel/userspace interfaces, I assume that he has a problem with understanding > what an external interface is. Yeah, uh huh. If it makes you feel better to say stuff like that, go for it. You do realize it doesn't reflect well on you, right? The guy is a pretty darn good kernel engineer, I think he knows what a kernel/userspace interface is. It's a big part of the job description. > You may have started with Linux later than I did - I started in 1996. Was running Linux well before that, I ran it when you booted off of floppies and there was no networking. I don't know when I started but this was in 1993: http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html and I'm sure I'd been running it for quite a while by that time. From jnc at mercury.lcs.mit.edu Wed Feb 22 07:49:13 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 21 Feb 2017 16:49:13 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <20170221214913.1843B18C117@mercury.lcs.mit.edu> > From: Larry McVoy > The DOS file system, while stupid, was very robust in the face of > crashes I'm not sure it's so much the file system (in the sense of the on-disk format), as how the system _used_ it (although I suppose one could consider that part of the FS too). The duplicated FAT, and the way file sectors are linked using it, is I suppose a little more robust than other designs (e.g. the way early Unixes did it, with indirect blocks and free lists), but I think a lot of it must have been that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on early Unix FS's, etc). That probably appoximated the write-ordering of more designed-robust FS's. Noel From wes.parish at paradise.net.nz Wed Feb 22 08:58:08 2017 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Wed, 22 Feb 2017 11:58:08 +1300 (NZDT) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221203256.GF3250@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> Message-ID: <1487717888.58acc60090241@www.paradise.net.nz> Now that brings up another reason why I think Linux won. Most of the early Linux developers were educated partly in the MS/PC/DR DOS world. They wanted a Unix, but they had bought IBM PC clones with MS DOS and were familiar with the DOS way of doing things. Linux's disk partitioning is very familiar to anyone who's familiar with the DOS way of disk partitioning. BSD's disk partitioning is a culture shock. (I know. I'd gotten used to the DOS way of doing things after learning about disk partitioning with my 486 and IBM OS/2 - the hard way. I tried Linux and the terminology was the same and due to a neat trick with the DOS filesystem I could experiment with it on an unchanged DOS system. I then tried FreeBSD and I didn't understand the terminology. So I stuck with what I'd learnt.) FWLIW :) Wesley Parish Quoting Larry McVoy : > On Tue, Feb 21, 2017 at 03:28:13PM -0500, Steve Nickolas wrote: > > On Tue, 21 Feb 2017, Larry McVoy wrote: > > > > >In terms of crash worthyness, ext2 was better. I think the ext2 > people > > >took the approach that they wanted to be as robust as dos but with > > >performance. And they made it, it's some very nice work. > > > > Wouldn't "as robust as DOS" be a *bad* thing? > > The DOS file system, while stupid, was very robust in the face of > crashes > (sort of had to be, he says slyly). > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn From downing.nick at gmail.com Wed Feb 22 09:10:05 2017 From: downing.nick at gmail.com (Nick Downing) Date: Wed, 22 Feb 2017 10:10:05 +1100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221214913.1843B18C117@mercury.lcs.mit.edu> References: <20170221214913.1843B18C117@mercury.lcs.mit.edu> Message-ID: I'm just going to jump in about the philosophical "everything is a file" Unix concept. I reckon this works very well for things that are "file like" in nature. The genius of Thompson and Ritchie was to realize that a file is a sequence of characters, and so is a TTY (or at least one direction of a TTY). And of course it is REALLY REALLY HANDY, to have things like an ad-hoc scripting ability (redirect a file to a program that's expecting a TTY) and all the other combinations that are possible. At the same time, files have an additional capability which is seeking. So did they implement some crazy ad-hoc scheme where you have to write an escape sequence to the file in order to effect a seek? No they did not. They added a seek(), or later lseek() system call, which sensibly returns an error code if the thing receiving the command is not capable of doing a seek. That is, they made it object-oriented. As well, terminals have additional capabilities, like setting the baudrate, changing the interrupt character, etc. And, in the same vein, they added an ioctl() system call, which sensibly returns an error code (ENOTTY) if the thing receiving the command is not a TTY. Same thing for pipes, except now another object-oriented feature comes into the mix: Constructors. Once created, a pipe does not have any interesting extra capabilities, indeed it acts like a base class of files and terminals since it does not support lseek() OR ioctl(), however the interesting thing is that pipes (ignoring named pipes) are not created with open(), they have their own constructor function pipe(). The BSD sockets interface is nice because it exactly follows the same philosophy: Sockets are like terminals except that instead of ioctl() they have slightly different capabilities (setting buffer size, checking for out-of-band data, etc), and they also have some interesting new characteristics like being bidirectional. But the most interesting thing with sockets is the elaborate set of constructors/factories for them. Now, along comes Plan 9 and what do they do? Completely reverse all this and force everyone to go through open() in the filesystem, which is NOT object-oriented, can you imagine C++ without constructors? And, in my understanding at least (it's a while since I looked at this), you do things like opening sockets by echoing strings to various places in the filesystem. This is nice if you're shell scripting. To explain why I think this is a bad thing I'm going to digress slightly. Let's consider the AT command set for modems. Well it's nice because it's human readable, and it was also a decent engineering solution to a problem where a programmable device was connected through a dumb terminal interface. Likewise, the ANSI command set for terminals, pretty much the same thing -- a good idea at the time. But what I most emphatically DO NOT agree with, is when a modem is built into the system, and still emulates an AT command set. Or when a terminal is built into the system (xterm, say), and still emulates an ANSI command set. It IS nice in some respects: (1) compatibility, and (2) shell scripting / expect type stuff. But as an engineering solution it's really bad. It's wasteful since any other program, such as say a dialer, is encoding the commands into AT commands, and then they are immediately getting decoded and executed. Same thing with xterm and the ANSI command sequences. It's nice to be able to put escape sequences in your prompt to change the colour of your prompt, but something like the curses library should NOT have to encode everything into ANSI when it's then decoded immediately. So, in my humble opinion the best way to handle such issues is, to provide a programmatic API where you tell the device what you want it to do, and then if it's something like an xterm or an internal modem, it immediately does what you ask it to do, whereas if it's something like an actual ANSI terminal or an external modem, the driver takes care of encoding your commands into ANSI or AT commands and then untangling the results, and reports to you in a machine-readable way (rather than a human-readable way) whether it succeeded etc. So, my philosophy is quite opposite to the Plan 9 philosophy, and that's why I don't use Plan 9. I don't believe in trying to put square pegs in round holes basically. What I would like to see is basically every device to implement the common functionality like read() and write() but ONLY IF THAT IS SENSIBLE, and to expose a programmatic interface through ioctl() or similar. Note that I have actually come to believe that overloading everything onto ioctl() is a bit undesirable since ioctl() was originally intended only for terminals. It would be better if each thing that a user process can hold a "fd" to, could define its own syscalls, but ioctl() is okay as an encapsulation for such syscalls. I also don't really agree with things like the /proc filesystem. For its intended and original purpose, it's fine -- it was supposed to be a collection of files named for the pids of running processes in the system, so that debuggers and such like, could read/write the process's address space. Personally I think it should have its own constructor, like say: fd = openaddressspace(pid, O_RDWR); which would be equivalent to something like: sprintf(buf, "/proc/%d", pid); fd = open(buf, O_RDWR); since there's no good reason to put it in the filesystem in my opinion. Having said that, there's no real harm in putting it in the filesystem, especially as it's hardly ever used. What I DO NOT agree with, is all the pseudo-files, where you do something like: echo 1 >/proc/sys/some/silly/function from the shell to turn stuff on or off. So now having explained my basic philosophy I will touch on the SCSI driver and burning CDs/DVDs/BDs. We can look at it two ways, either we can build a high level interface into the system so that writing software doesn't need to know how the drive is connected. This is a bit like my proposal for xterms vs. ANSI terminals and internal vs external modems. Then if it HAPPENS to be a SCSI drive then the driver should communicate with the drive in SCSI language, etc. BUT: This is a huge amount of work, because the SCSI specification is very complicated. Moreover, it's highly unlikely that any device will be built in the foreseeable future that burns CDs/DVDs/BDs and does not understand SCSI. (It might be iSCSI, it might be SCSI encapsulated into IDE or SATA, or whatever, but it still understands SCSI). In my opinion then, there is no need for a high level driver. It's like the situation with ANSI terminals or external models BEFORE things like xterms or internal modems were ever invented. So why would you need an extra level of abstraction? Just provide access to the TTY. cheers, Nick On Wed, Feb 22, 2017 at 8:49 AM, Noel Chiappa wrote: > > From: Larry McVoy > > > The DOS file system, while stupid, was very robust in the face of > > crashes > > I'm not sure it's so much the file system (in the sense of the on-disk > format), as how the system _used_ it (although I suppose one could consider > that part of the FS too). > > The duplicated FAT, and the way file sectors are linked using it, is I suppose > a little more robust than other designs (e.g. the way early Unixes did it, > with indirect blocks and free lists), but I think a lot of it must have been > that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on > early Unix FS's, etc). That probably appoximated the write-ordering of more > designed-robust FS's. > > Noel From krewat at kilonet.net Wed Feb 22 09:14:14 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 21 Feb 2017 18:14:14 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221214913.1843B18C117@mercury.lcs.mit.edu> References: <20170221214913.1843B18C117@mercury.lcs.mit.edu> Message-ID: Not to mention, DOS was pretty much single-threaded. It wasn't very often that you had multiple threads writing files in different locations. And when they did, a write was atomic. Update the block(s), update the FAT. There was no preemption. Only when Windows (and it's other multi-tasking brethren) came along was it possible that two threads would be writing to different files. Even then, I'm willing to bet that the entire "write block, update FAT" was atomic for the DOS-based Windows. Of course, I'm only talking about the FAT file system as it grew out of the first floppy-disk based PC's, and not NTFS nor the NT-based Windows versions to come later. However, it was possible to actually be in the middle of writing a block (or sector) and cut the power and it wouldn't finish writing sector. Leading to data or FAT corruption. If I remember correctly, when that happened, it was best to manually pick through both FAT copies and see which one was correct :) The worst was overwriting an existing block, because the FAT wasn't updated, and if the data wasn't completely written when the power cut, well, say good bye to the disk sector it was on. On 2/21/2017 4:49 PM, Noel Chiappa wrote: > The duplicated FAT, and the way file sectors are linked using it, is I suppose > a little more robust than other designs (e.g. the way early Unixes did it, > with indirect blocks and free lists), but I think a lot of it must have been > that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on > early Unix FS's, etc). That probably appoximated the write-ordering of more > designed-robust FS's. > From schily at schily.net Wed Feb 22 09:44:22 2017 From: schily at schily.net (Joerg Schilling) Date: Wed, 22 Feb 2017 00:44:22 +0100 Subject: [TUHS] Re; Mach for i486 / Mt Xinu or other In-Reply-To: <201702212025.v1LKPhRp021592@coolidge.cs.Dartmouth.EDU> References: <201702212025.v1LKPhRp021592@coolidge.cs.Dartmouth.EDU> Message-ID: <58acd0d6.lIWt8IAsU2xSUluK%schily@schily.net> Doug McIlroy wrote: > Had Ken thought that way, Unix's universal byte-addressable file format > would never have happened; this mailing list would not exist; and we > all might still be fluent in dialects of JCL. dd was sufficient glue > to bridge the gap between Unix and **Most** Operating Systems. > Meanwhile everyday use of Unix was freed from the majority's folly. Ken was lucky as he did not need to honor constraints from other operating systems. Hard disks are also much simpler to use than optical media with complex meta data. BTW: do you know why UNIX did create something that is completely non-extensible like cpio or hard to extend like tar? We had to wait until 1997 for Sun to propose a nice extensible archive format that has become the base for the POSIX.1-2001 TAR extension headers. Do you know why UNIX had a "ps" command that could be used to create random junk output in 1982 because there was no interface to get reliable process information? At the same time, UNOS written at Charles River Data Systems by former AT&T engineers could do this right already. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From wkt at tuhs.org Wed Feb 22 10:16:58 2017 From: wkt at tuhs.org (Warren Toomey) Date: Wed, 22 Feb 2017 10:16:58 +1000 Subject: [TUHS] OK, the archive has been reorganised Message-ID: <20170222001658.GA25054@minnie.tuhs.org> All, after getting your feedback, I've reorganised the Unix Archive at http://www.tuhs.org/Archive/ I'm sure there will be some rough edges, let me know if there is anything glaringly obvious. I'd certainly like a few helpers to take over responsibility for specific sections, e.g. UCB, DEC. Cheers all, Warren P.S It will take a while for the mirrors to pick this up. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From akosela at andykosela.com Wed Feb 22 10:52:26 2017 From: akosela at andykosela.com (Andy Kosela) Date: Tue, 21 Feb 2017 18:52:26 -0600 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221164728.GZ20341@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> Message-ID: On Tuesday, February 21, 2017, Larry McVoy wrote: > On Tue, Feb 21, 2017 at 07:02:18AM -0500, Noel Chiappa wrote: > > So there is a question here, though, and I'm curious to see what others > who > > were closer to the action think. Why _did_ Linux succeed, and not a Unix > > derivative? (Is there any work which looks at this question? Some Linux > > history? If not, there should be.) > > http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html > > is worth a read, I was very much in the middle of all this at the time. > > I think Linux succeeded because: > > - it was free and GPLed. BSD license is nice but it has the problem > that people can take it closed source and not give back changes. > > - no lawsuit > > - Linus (as mentioned, much stronger leader than any in the Unix world) > > - no religion. I can't make this point hard enough. At Sun, we > couldn't > change any API, any utility, it was compat to the point that it was > not > useful. Look at SVr4/Solaris /proc and then look at Linux /proc. > The > Linux one is way, way, way, way more useful, you can dig shit out > with > shell scripts. The rest of the Unix world was blindly posix compat > even when posix compat made no sense. Linux was glorious in that > Linus wanted compat but was willing to break it for good reasons. > > - good enough > > - fun, all the cool kids were there. > > Here is perhaps something that will resonate with this crowd. When I was > teaching OS at Stanford, for file systems I made people go through the > thought process on when you write what (think the sync writes so the FS > isn't busted when you crash). > > For years, the BSD guys insisted that Linux was doing it wrong because > they didn't do the sync writes, they did ordered writes (but the BSD > guys didn't understand the write ordering so they thought it was busted, > as did I). > > But Linux wasn't busted, they had carefully gone through the process > of figuring out when stuff had to be first so that you could survive > a crash. > > The BSD guys refused to believe that it was possible, they were stuck > on writes had to be synchronous in order to get a file system that > wasn't corrupted on a crash. > > I eventually started convincing them that Linux had it right by saying > just untar some big tarball and unplug the power in the middle of that > on a system with UFS and a system with ext2. Tell me what happens when > you power it up. Answer? The UFS based system dropped you into a fsck > nightmare of unattached inodes, the ext2 based systems lost some data > but the file system was fine. > > Obviously, the Linux approach won, it's better. Way better, higher > performance and a much better user experience. But the traditional > Unix guys had to be dragged kicking and screaming, over a decade, > into that world. It's stuff like that that made Unix stagnate while > Linux forged ahead. > Interesting points. I think Linux really succeded because big IT players like IBM, HP, Oracle etc. started to promote and financially support it around 99. Before that time Linux and FreeBSD went head-to-head and one can argue that actually FreeBSD was more technically advanced at that time. When IBM poured millions of dollars in developing Linux it showed. After year 2000 the growth of Linux was phenomenal -- it started to show up everywhere, from embedded world to supercomputers. Hardware support from big vendors also helped make it the official Open Source Unix. To this day you will not get a support contract for FreeBSD from HP or Dell, and they make up the majority of what you see in modern data centers. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Feb 22 11:04:16 2017 From: rminnich at gmail.com (ron minnich) Date: Wed, 22 Feb 2017 01:04:16 +0000 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> Message-ID: I got to thinking about the file system sync vs. order argument as a result of this interesting discussion. Back in NJ in 1998 I had a 144-node PC cluster. It started with 80 FreeBSD nodes, and a few months later we add 64 Linux nodes. It was DARPA funded and we were looking at issues around clustering. What we discovered, when we added the Linux cluster, was that building power was really terrible. We had not realized it with the freebsd cluster because it tended to cleanly recover from unplanned nasty power cycles. But the Linux cluster tended to always have a small number of nodes that did not get through fsck. yeah, it's not that good a data point maybe, but we found it interesting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Wed Feb 22 11:19:19 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 20:19:19 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1487717888.58acc60090241@www.paradise.net.nz> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: ​below... this one made me a laugh a little because it skipped a few steps that knew (and was a part).​ Once again it was ignorance and little luck that brought us what we got, not invention nor knowledge. On Tue, Feb 21, 2017 at 5:58 PM, Wesley Parish wrote: > Now that brings up another reason why I think Linux won. Most of the early > Linux developers were > ​ ​ > educated partly in the MS/PC/DR DOS world. They wanted a Unix, but they > had bought IBM PC clones > ​ ​ > with MS DOS and were familiar with the DOS way of doing things. > ​Sort of.... but be careful of a little history here.​ > > Linux's disk partitioning is very familiar to anyone who's familiar with > the DOS way of disk partitioning. > ​Yes, because Linux was not not really enough of UNIX hacker to know that UNIX partition scheme for PC's was open source and all the code to do it was available to him. He wrote his own.​ I remember when I first encountered the Linux craziness and thinking something on the order of: "Why, why are they putting things in DOS partitions ... the BIOS ROMS are a mess and are already broken... we fixed this already for UNIX on the 386!!!!" In truth, most end users running real UNIX on a PC/386 were not trying to dual boot DOS and UNIX, so other than being able to boot the system into UNIX, they just wanted partitions to map an entire drive and properly load the read OS (UNIX). So the UNIX scheme, of reserving the disk from the boot rom, and getting those damned DOS roms out the way ASAP was a fine solution. And in the beginning of PC/UNIX that is all that was wanted and what was there. > BSD's disk partitioning is a culture shock. > The PC Disk partitioning scheme was developed by Intel and the code released to the UNIX community. It was the same code base for all 3 System V ports (which were all done by Interactive Systems under contract for each of Intel, IBM, and AT&T - one of the best bit of salesmanship Phil Shevrin ever pulled off IMO -- they did one port and sold it three times). It was also used by the AIX/386 folks and eventually usd by Sun. Part of the original deal was a project CMU had done with both Intel and IBM for during that time frame, and between Intel and IBM they got the CMU code made available (as part of the Andrew project IIRC). CMU would of course use this bot/partition code for the Mach port, Jolitz for the BSD port, as well as all the AT&T base versions. In fact, it was because of CMU, that UNIX partition type (type 63) was defined as Intel got Microsoft to add it to the master database. The history was something like this as I understand it.... Microsoft starts to develop Xenix for the 286/68K/Z8000 and maybe one other processor I've forgotten. One of the original Xenix ports it to the PC/AT which is 286 based, which it is doing jointly with Intel as well as IBM. CMU was working with IBM in Andrew and some how got into that mix and is using PC/AT as part of the Andrew project. CMU guys want C tools, so they write an fdisk/boot system for their stuff. That migrates back to Intel which migrates to back to Xenix and Microsoft. They also made it to UCB as a version of them is what Jolitz uses for 386BSD. The question I always wonder was why Andy Tannenbaum did not use those tools with Minix, but I'm guessing he was trying to do everything virgin and clean. Because Linus started with the Minix fdisk, the rest is history. Had Linus looked (or asked) the code was very available and he might have used it too. The point is that until Minux and Linux, it was actually kinda cool. All of the UNIX on a PC/386 platform used the made boot and disk scheme and hard started with the same C source for boot and fdisk. > I then tried FreeBSD and I didn't understand the terminology. So I stuck > with > what I'd learnt.) > That said, as disks kept getting bigger and bigger and the "big iron" folks had better boot roms, folks like Sun, Masscomp, DEC et al, had much better support for disk geometry. The original UNIX on PC partition scheme had some rough edges, particularly WRT linear addressed drives (such stated with SCSI, but the PC morphed there also), so BSD took the current scheme and re-did. Hence, one group PC/UNIX (BSD) folks started to trying to make the PC boxes do the same things that the Workstations and Mini's could. So the FreeBSD guys start to extend (sounds like folks from Redmond eh...).... Anyway, that's were the new terms like "slice" came from, and I ​admit by the 3rd or 4th rewrite what was in PC/BSD and what was originally in PC/UNIX differed. Of course, Microsoft/Intel also had to deal with the bigger and bigger disks and the same issues withe BIOS that IBM had given us from very small disks a long time ago but they were not trying emulate "big unix." So they did something that worked well for them. Linux was able to ride the MS/Intel solutions. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Wed Feb 22 11:22:40 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Wed, 22 Feb 2017 08:22:40 +0700 Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: Probably my (misplaced?) sense of humour, but I can't help it. After reading all comment I feel I have to mention I had a look at freeDOS :-) Cheers, rudi From krewat at kilonet.net Wed Feb 22 11:35:42 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Tue, 21 Feb 2017 20:35:42 -0500 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: Anyone interested in this source code? I did a quick Google search and couldn't find anything relevant. If it's out there somewhere, let me know, I'd like to take a look at it. It's Network File System Sun Microsystems Release 2.0 Where I got it from, that will remain nameless, used it to compile against BSD 4.3 on VAX, and possibly even 4.2 Is it not releasable? I also seem to have version 3.2, but I need to verify that. For example: /* @(#)showmount.c 1.3 87/08/13 3.2/4.3NFSSRC */ thanks! -- Arthur Krewat krewat at kilonet.net From jason-tuhs at shalott.net Wed Feb 22 11:33:06 2017 From: jason-tuhs at shalott.net (jason-tuhs at shalott.net) Date: Tue, 21 Feb 2017 17:33:06 -0800 (PST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> Message-ID: > I got to thinking about the file system sync vs. order argument as a > result of this interesting discussion. > [...] > What we discovered, when we added the Linux cluster, was that building > power was really terrible. We had not realized it with the freebsd > cluster because it tended to cleanly recover from unplanned nasty power > cycles. But the Linux cluster tended to always have a small number of > nodes that did not get through fsck. Soft updates was available in 1998. Were you running that? Surprised it hasn't come up already in this discussion; I've been waiting for someone to mention it. http://www.mckusick.com/softdep/ There was some licensing issue with it in the early days: it was freely available and free to use, but McKusick wanted a chance to try to sell it to a commercial unix vendor as well. But he ended up BSD-licensing it a couple years later. The original README from the FreeBSD source tree: https://svnweb.freebsd.org/base/release/3.0.0/contrib/sys/softupdates/README?revision=42952&view=co Anyway, it solved the on-disk consistency problem and boosted performance as well. I enabled it on all my systems. -Jason From clemc at ccc.com Wed Feb 22 11:46:13 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 20:46:13 -0500 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: On Tue, Feb 21, 2017 at 8:35 PM, Arthur Krewat wrote: > Anyone interested in this source code? I did a quick Google search and > couldn't find anything relevant. If it's out there somewhere, let me know, > I'd like to take a look at it. > > It's Network File System Sun Microsystems Release 2.0 > Since, the core of Solaris was made FOSS, I would hope there is(are) persons at Oracle/Sun that can officially stamp the technology has only historical value. Anyone know whom that should be so it can make it from the dark side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Wed Feb 22 11:50:45 2017 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Feb 2017 20:50:45 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 21, 2017 at 10:02 AM, Clem Cole wrote: > > On Tue, Feb 21, 2017 at 7:02 AM, Noel Chiappa > wrote: > >> So there is a question here, though, and I'm curious to see what others >> who >> were closer to the action think. Why _did_ Linux succeed, and not a Unix >> derivative? (Is there any work which looks at this question? Some Linux >> history? If not, there should be.) >> > > ​I​'ve thought and written a bit about this question a bit [ > Would it be possible/advantageous to rewrite the Linux kernel in Rust when > the language is stable? > > & > Why did Unix succeed and not Multics > ] ​ > ​ > and I'll not repeat all of here but > ​as one of the people that did switch from 386BSD to linux at the time, > the reason for me was purely because of the AT&T/BSDi case. You are > right, I wanted a "free" (i.e. very inexpensive) UNIX for the 386 and the > "big guns"​ were not going to give it. I thought we had it the 386 port > BSD which I had helped in a small way to create. > > ​But I like, most hackers of the day, misunderstood incorrectly​ the case > to be about *trade secret *and the all based around the 1956 consent > decree, IBM vs AT&T; telephones and the computers. I was worried AT&T > would win because it was going to hard to cleaim that that the BSD code was > not a derivative work of the AT&T *copyright code base *(not > understanding the *trade secret* and the *copyright* difference > mattered). > > So...I switched to Linux *not because I thought it was "better"* - in > fact, I b*tched (and still do) about many gratuitous differences, but as I > knew that we needed something for "consumer" HW (which was bring driven by > the WINTEL economics), and I was willing to use the "lessor" technology > (Linux) because it was "good enough" and gave me what I needed (UNIX on a > PC/386). I thought (incorrectly) somehow original Linux's European > authorship was going to protect me and my fellow hackers ever though it was > not as good as my beloved BSD system. > > Simple put - using Christiansen's theories: Linux "won" because: > > - it was "good enough", > - had a lot of people behind it that valued that was there and > invested in making it "better", and > - the economics of the platform (PC/386 - WINTEL etc) was on the > fastest grow curve [and its Christiansen's economic disruption was > displacing the Mini & Workstation]. > > > BTW: at the time, I argued with the Roger Gourd and the OSF folks, that if > they released (sold) the OSF/1 RI uK which had not AT&T technology in it > (again thinking Copyright not Trade Secret); I was suggesting $100/copy > there was a market for it. I just could not get them interested. > > Sun has done the RoadRunner and had their 386 port of Solaris; but again. > All the "UNIX" folks were still interested in pushing out "iron" so were > blind to the WINTEL economic disruption. > > Woulda, Coulda, Shoulda .... sigh > If I may, I think there was an additional thing at play: Linux was essentially Unix. Linux "won" because people wanted low-cost or free (as in gratis) Unix with source that could run on modest commodity hardware, and Unix wasn't available at a price point that was reasonable for most individuals (certainly not with source). The people working on successor systems weren't trying to reinvent Unix: they were working on new systems that weren't Unix, but that's not what people wanted: Unix was good enough and people were familiar and comfortable with it and that's what they wanted. So Linux comes along and it's basically a "simplest possible solution" Unix, freely available, runs on a PC, comes with source, and wasn't mired in a lawsuit brought by a major US company. It was the right thing in the right place at the right time. I think there's a network effect that blinds a lot of folks to this reality. Most of the folks on this list had access to Unix source and, with no disrespect intended, it's easy to lose sight of what a big deal that was. But unless you were in a position to already have access to it, it was remarkably difficult to come by. Linux filled a gap that a lot of people were looking to have filled. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Wed Feb 22 12:07:43 2017 From: b4 at gewt.net (Cory Smelosky) Date: Tue, 21 Feb 2017 18:07:43 -0800 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: <1487729263.2313858.888725168.40D323E9@webmail.messagingengine.com> On Tue, Feb 21, 2017, at 17:35, Arthur Krewat wrote: > Anyone interested in this source code? I did a quick Google search and > couldn't find anything relevant. If it's out there somewhere, let me > know, I'd like to take a look at it. > > It's Network File System Sun Microsystems Release 2.0 > > Where I got it from, that will remain nameless, used it to compile > against BSD 4.3 on VAX, and possibly even 4.2 > > Is it not releasable? > > I also seem to have version 3.2, but I need to verify that. For example: > /* @(#)showmount.c 1.3 87/08/13 3.2/4.3NFSSRC */ > > thanks! > > -- > Arthur Krewat > krewat at kilonet.net Is this pre- or post- 4.3-UWisc? -- Cory Smelosky b4 at gewt.net From usotsuki at buric.co Wed Feb 22 12:25:12 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Tue, 21 Feb 2017 21:25:12 -0500 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: On Tue, 21 Feb 2017, Dan Cross wrote: > If I may, I think there was an additional thing at play: Linux was > essentially Unix. > > Linux "won" because people wanted low-cost or free (as in gratis) Unix with > source that could run on modest commodity hardware, and Unix wasn't > available at a price point that was reasonable for most individuals > (certainly not with source). The people working on successor systems > weren't trying to reinvent Unix: they were working on new systems that > weren't Unix, but that's not what people wanted: Unix was good enough and > people were familiar and comfortable with it and that's what they wanted. > So Linux comes along and it's basically a "simplest possible solution" > Unix, freely available, runs on a PC, comes with source, and wasn't mired > in a lawsuit brought by a major US company. It was the right thing in the > right place at the right time. > > I think there's a network effect that blinds a lot of folks to this > reality. Most of the folks on this list had access to Unix source and, with > no disrespect intended, it's easy to lose sight of what a big deal that > was. But unless you were in a position to already have access to it, it was > remarkably difficult to come by. Linux filled a gap that a lot of people > were looking to have filled. > > - Dan C. > I started screwing around with Linux in the late 90s, and it would be many years before any sort of real Unix (of the AT&T variety), in any form, was readily available to me - that being Solaris when Sun started offering it for free download. -uso. From b4 at gewt.net Wed Feb 22 13:08:33 2017 From: b4 at gewt.net (Cory Smelosky) Date: Tue, 21 Feb 2017 19:08:33 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: Message-ID: <1487732913.2324220.888765688.57D2BFC0@webmail.messagingengine.com> On Tue, Feb 21, 2017, at 17:22, Rudi Blom wrote: > Probably my (misplaced?) sense of humour, but I can't help it. > > After reading all comment I feel I have to mention I had a look at > freeDOS :-) > > Cheers, > rudi Do I need to pull out TOPS-10 filesystem code now, too? ;) -- Cory Smelosky b4 at gewt.net From clemc at ccc.com Wed Feb 22 13:11:14 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 22:11:14 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 21, 2017 at 8:50 PM, Dan Cross wrote: > If I may, I think there was an additional thing at play: Linux was > essentially Unix. > ​But that is of course my point. Linux is (was) UNIX, AND ... "UNIX" as a free UNIX *was *available at the time.​ > > Linux "won" because people wanted low-cost or free (as in gratis) Unix > with source that could run on modest commodity hardware, and Unix wasn't > available at a price point that was reasonable for most individuals > (certainly not with source). > ​Indeed - that was 386BSD.​ At first anyone with a source license (which was just about anyone at University - so that means students like Linus BTW), and most commercial places had access to the BSD license. The ftp site for download 'Jolix' as some one called it earlier today was pretty much the worst kept secret on the Internet. All you had to do is ask, and you could find it and once NET/2 was released, and then FreeBSD, NetBSD et al came to be it was all over. They key was in the case of 386BSD, you want to ask for it (and officially needed a license to ask), but long before Linux shows up there were >>freely<< available PC/UNIX systems. And you point, which is 100% in agreement with my own is that under the rules of Christiansen disruption, a PC/386 based UNIX that was "cheap enough" was going to win. The question Noel asked was why did *this flavor *of UNIX win over the others since there were other choices. That is what I tried to answer. As Larry and I both pointed out, if the BSDi/AT&T suit had not occurred the "hackers" which Larry described very well in his document, were going to find something. 386BSD was that place. Then it got clouded in legal nonsense and lot of us fled. Larry suggest there were other reasons. He and many others think the GPL/2 vs the BSD license was important. I really don't think so. But that's less of an argument. The key is that the BSD version was cloud in legal issues (and as Larry pointed out some strong personalities). ​... > So Linux comes along and it's basically a "simplest possible solution" > Unix, freely available, runs on a PC, comes with source, and wasn't mired > in a lawsuit brought by a major US company. It was the right thing in the > right place at the right time. > ​Exactly ... ​ Linux arrive at the right time, free of the *perceived* legal issues. The sad truth is that if AT&T had won, technically Linux would have had to be removed from the market in the US and NATO countries. I'll not try to speculate what would have happened then other than to say the not only was cow out of the barn, th ​e​ barn had caught fire so there was not place to put it back. > > I think there's a network effect that blinds a lot of folks to this > reality. Most of the folks on this list had access to Unix source and, with > no disrespect intended, it's easy to lose sight of what a big deal that > was. But unless you were in a position to already have access to it, it was > remarkably difficult to come by. > ​Actually, I always found that a strange statement. I hear you and no disrespect intended, but I fear that people that make that claim just did not know where to look. It was ignorance (not stupidity mind you) - just lack of knowledge that is was available. I'm going to ask Dan, were you not at an university at time? Most schools in the US and Europe had BSD licenses. If you working, I can understand it somewhat. Many people's first UNIX experience was on a Sun Workstation so those folks did not have UNIX source licenses. But if you were at a either a University or commercial enterprise with a AT&T and BSD license, All it took was making sure you university had one and sending and email to the UCB folks (which many of us on this list were some of the folks that might have read it).​ They reply (I if I got searching through old email I might even have a copy of some where) basically was the url of the blind ftp address to pull the iso off the ucb ftp site. It was incredibly easy to get but you did have to have ftp access (and know the magic path - which if you asked was easy to get). Even with the first ISO, at one point, I seem to remember the bazillion *BSD floppies showed up on the one of the netnews channels and clogging up the dial-up links for a few days. The point was if you were at all in the community, it was pretty easy to find the BSD code. Which brings me to my point... many developers abandoned it - and most of them certainly know how to get it. They why I think the incorrect belief that legal entanglement (miss guided as it turned out) where not there with Linux. By the time the legal case was settled, the developed had "completed enough" of what was missing in Linux from *BSD that many folks never went back. And the newbie never knew any better. > Linux filled a gap that a lot of people were looking to have filled. > ​Agreed..​ but that gap would not have been there if the AT&T legal case had not clouded it all. Imagine that if the case had no occurred, the hackers were already working with *BSD. So then the question comes which Larry raises, was the UNIX personalities and/or the licensing what would have caused Linux to rise. I don't think so, because BSD had too much of a lead - already had networking, windowing, and in fact had a "better" installer on a PC/386. The first stuff "distro" that was at all reasonably easy t install was a PC was slackware and that was partly because they pulled a bunch of stuff from the stuff Jordan had created. But they problem was that FreeBSD et al was starting under a legal cloud, I know I was worried. I ran it on two of my systems, but was working on Linux on another to hedge my bet. I was not sure BSDi/UCB would win, so I started helping make Linux work better too. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 22 13:17:58 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 19:17:58 -0800 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: <20170222031758.GG9439@mcvoy.com> So Sun did a public release of the RPC / XDR code and I think all the user space utilities. It used to be on sunsite. Is there an archive of that somewhere? I may have an archive on CD somewhere (maybe). On Tue, Feb 21, 2017 at 08:35:42PM -0500, Arthur Krewat wrote: > Anyone interested in this source code? I did a quick Google search and > couldn't find anything relevant. If it's out there somewhere, let me know, > I'd like to take a look at it. > > It's Network File System Sun Microsystems Release 2.0 > > Where I got it from, that will remain nameless, used it to compile against > BSD 4.3 on VAX, and possibly even 4.2 > > Is it not releasable? > > I also seem to have version 3.2, but I need to verify that. For example: /* > @(#)showmount.c 1.3 87/08/13 3.2/4.3NFSSRC */ > > thanks! > > -- > Arthur Krewat > krewat at kilonet.net -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From lm at mcvoy.com Wed Feb 22 13:18:36 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 19:18:36 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> Message-ID: <20170222031836.GH9439@mcvoy.com> That was pretty early, Ron. I betcha if you tried it now (or 10 years ago) things would be different. On Wed, Feb 22, 2017 at 01:04:16AM +0000, ron minnich wrote: > I got to thinking about the file system sync vs. order argument as a result > of this interesting discussion. > > Back in NJ in 1998 I had a 144-node PC cluster. It started with 80 FreeBSD > nodes, and a few months later we add 64 Linux nodes. It was DARPA funded > and we were looking at issues around clustering. > > What we discovered, when we added the Linux cluster, was that building > power was really terrible. We had not realized it with the freebsd cluster > because it tended to cleanly recover from unplanned nasty power cycles. But > the Linux cluster tended to always have a small number of nodes that did > not get through fsck. > > yeah, it's not that good a data point maybe, but we found it interesting. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Wed Feb 22 13:38:43 2017 From: clemc at ccc.com (Clem Cole) Date: Tue, 21 Feb 2017 22:38:43 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] Message-ID: On Tue, Feb 21, 2017 at 9:25 PM, Steve Nickolas wrote: > I started screwing around with Linux in the late 90s, and it would be many > years before any sort of real Unix (of the AT&T variety), in any form, was > readily available to me - that being Solaris when Sun started offering it > for free download. See my comment to Dan. I fear you may not have known where to look, or whom to ask.​ As I asked Dan, were you not at an university at time? Or where you running a Sun or the like -- i.e. working with real UNIX but working for someone with binary license, not sources from AT&T (and UCB)? I really am curious because I have heard this comment before and never really understood it because the sources really were pretty much available to anyone that asked. Most professionals and almost any/all university students had did have source access if they ask for it. That is part of why AT&T lost the case. The trade secret was out, by definition. The required by the 1956 consent decree to make the trade secrets available. A couple of my European university folks have answer that the schools kept the sources really locked down. I believe you, I never saw that at places like Cambridge, Oxford, Edinburg, Darmstad or other places I visited in those days in Europe. Same was true of CMU, MIT, UCB et al where I had been in the USA, so I my experience was different. The key that by definition, UNIX was available and there were already versions from AT&T or not "in the wild." You just need to know where to look and whom to ask. The truth is that the UCB/BSDi version of UNIX - was based on the AT&T trade secret, as was Linux, Minix, Coherent and all of the other "clones" -- aka look-a-likes and man of those sources were pretty available too (just as Minix was to Linus and 386BSD was to him also but he did not know to where/whom to ask). So a few years later when the judge said, these N files might be tain'ted by AT&T IP, but can't claim anything more. The game was over. The problem was when the case started, techies (like me, and I'm guessing Larry, Ron and other ex BSD hackers that "switched") went to Linux and started to making it better because we thought we going to lose BSD. That fact is if we had lost BSD, legally would have lost Linux too; but we did not know that until after the dust settled. But by that time, many hackers had said, its good enough and made it work for everyone. As you and Dan have pointed out, many non-hackers did know that UNIX really was available so they went with *Linux because they thought that had no other choice, *when if fact, you actually did and that to me was the sad part of the AT&T case. A whole generation never knew and by the time they did have a choice but a few religion began and new wars could be fought. Anyway - that's my thinking/answer to Noel's original question. Of why Linux over the over the PC/UNIX strains... I think we all agree that one of the PC/UNIX was going to be the winner, the question really is why did Linux and not a BSD flavor? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rminnich at gmail.com Wed Feb 22 13:45:54 2017 From: rminnich at gmail.com (ron minnich) Date: Wed, 22 Feb 2017 03:45:54 +0000 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170222031836.GH9439@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170222031836.GH9439@mcvoy.com> Message-ID: On Tue, Feb 21, 2017 at 7:18 PM Larry McVoy wrote: > That was pretty early, Ron. I betcha if you tried it now (or 10 years > ago) things would be different. > > > I think that is true. But from my point of view "linux winning" was not necessarily "linux was better at the time." I think it was a lot of factors. When I got to Los Alamos in 1999, it was still a tossup between the BSDs and Linux as to "which is better." Nevertheless, for lots of reasons, in 1998 (the same year I found Linux to be less reliable over time) Los Alamos had cast its lot with Linux, for all kinds of reasons. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Wed Feb 22 13:51:16 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Wed, 22 Feb 2017 10:51:16 +0700 Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: >On Tue, 21 Feb 2017 19:08:33 -0800 Cory Smelosky wrote: > >>On Tue, Feb 21, 2017, at 17:22, Rudi Blom wrote: >> Probably my (misplaced?) sense of humour, but I can't help it. >> >> After reading all comment I feel I have to mention I had a look at >> freeDOS :-). >> >> Cheers, >> rudi > >Do I need to pull out TOPS-10 filesystem code now, too? ;) In 1967 I was 12 and probably had barely discovered ScienceFiction novel and computers. Just quickly downloaded a TOPS-10 OS Commands Manual (from 1988) but no mention of the Level-D filesystem From lm at mcvoy.com Wed Feb 22 14:06:29 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 20:06:29 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170222031836.GH9439@mcvoy.com> Message-ID: <20170222040629.GN9439@mcvoy.com> On Wed, Feb 22, 2017 at 03:45:54AM +0000, ron minnich wrote: > On Tue, Feb 21, 2017 at 7:18 PM Larry McVoy wrote: > > > That was pretty early, Ron. I betcha if you tried it now (or 10 years > > ago) things would be different. > > I think that is true. But from my point of view "linux winning" was not > necessarily "linux was better at the time." I think it was a lot of factors. > > When I got to Los Alamos in 1999, it was still a tossup between the BSDs > and Linux as to "which is better." Nevertheless, for lots of reasons, in > 1998 (the same year I found Linux to be less reliable over time) Los Alamos > had cast its lot with Linux, for all kinds of reasons. I lived through all this and payed close attention to all of the people involved (Theo has/had my Sun 4/470, we argued about VM systems in my flat in SF, Jolitz worked for me, I hung with Chris Demetriou back in the 386BSD days, I was all over that stuff and wanted it to succeed). The open source BSD stuff was a train wreck from the very beginning. Nobody could get along with Jolitz, so NetBSD started, then Theo wanted to be in charge of something so OpenBSD was born. I can't remember how FreeBSD got spun out, but what I do remember is that there were power struggles from day 1. Everyone thought they were better than the other guy, when in fact, what was pretty good was the BSD source base and most of these people, initially, had very little skin in the game in the form of code, they were all leveraging the BSD source base. I actually think Jolitiz had more code in there in the beginning than anyone else. No matter who did what, they couldn't / wouldn't / didn't rally around a single leader and a single project. So it was "divide and fail" where Linux was a big tent, anyone who could write decent code was welcome, but you had to get it past Linus. Which was fine, people figured out he had a clue and put up with the fact that they had to get past his filter (many of us, myself included, valued that filter very, very much). By 1998/1999, all of these BSD struggles for power were blindingly obvious to anyone who was remotely paying attention. I think they were obvious 4-5 years before that. And it wasn't obvious just to people like me, management types track this stuff far more than most people believe. They have to back the right horse or it costs them. Linux was simply a safer bet. The community was larger and growing very fast. I was program committee chair at Linux Expo in 1999 (sort of their Usenix at the time). It was way more fun than Usenix. I think a lot of the "better" stuff came from the fact that Linux got networking long after BSD had pretty sweet networking. The BSD guys still think their networking is better than Linux (pro tip, it is not, go read networking research papers, they all use Linux as the platform and it's not because there is so much to fix, it's because Linux networking is better). BSD hasn't been better than Linux in any way that I know of for about 15 years. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From crossd at gmail.com Wed Feb 22 14:07:20 2017 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Feb 2017 23:07:20 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: On Tue, Feb 21, 2017 at 10:11 PM, Clem Cole wrote: > [snip: I think we're mostly in agreement here, Clem] > >> I think there's a network effect that blinds a lot of folks to this >> reality. Most of the folks on this list had access to Unix source and, with >> no disrespect intended, it's easy to lose sight of what a big deal that >> was. But unless you were in a position to already have access to it, it was >> remarkably difficult to come by. >> > ​Actually, I always found that a strange statement. I hear you and no > disrespect intended, but I fear that people that make that claim just > did not know where to look. It was ignorance (not stupidity mind you) - > just lack of knowledge that is was available. > > I'm going to ask Dan, were you not at an university at time? Most schools > in the US and Europe had BSD licenses. If you working, I can understand it > somewhat. Many people's first UNIX experience was on a Sun Workstation so > those folks did not have UNIX source licenses. But if you were at a > either a University or commercial enterprise with a AT&T and BSD license, > All it took was making sure you university had one and sending and email > to the UCB folks (which many of us on this list were some of the folks that > might have read it).​ They reply (I if I got searching through old email I > might even have a copy of some where) basically was the url of the blind > ftp address to pull the iso off the ucb ftp site. It was incredibly easy > to get but you did have to have ftp access (and know the magic path - which > if you asked was easy to get). Even with the first ISO, at one point, I > seem to remember the bazillion *BSD floppies showed up on the one of the > netnews channels and clogging up the dial-up links for a few days. > So I was in high school, but I was affiliated with a major university (one that, yes, did have a Unix source license) because I held a part-time sysadmin job. For the curious, it was Penn State University; not a huge CS powerhouse like, say, MIT or CMU, but it held it's own as a large research university (they have, for instance, hands-down the best Acoustics department in the world. Also, while it may seem quaint, they hands-down have the best agriculture department in the world: kind of important for that whole food thing. :-)). I didn't go there as a student, but lived in the town during high school and cut my teeth on their computers. I can say from first-hand experience that it was NOT easy to get access to Unix source code there. The cadre of university system administrators that formed something of a cabal did not hand it out lightly, and it took significant time to gain the sort of trust that would result in you getting access to it. I strongly suspect that if a random CS student had written to UCB asking for access to the BSD source code, and that had gotten back to the aforementioned cabal, it would not have gone well for the student. Lots of intrusive questions would have been asked; angry letters written and placed into files. Uncomfortable meetings with academic advisors and the university computer security officer would have taken place. Questions of academic malfeasance or expulsion may have come up, etc. Was any of that justified? No, not really. I suspect much of it came from an outsized sense of trying to protect the university from potential litigation should a poorly-secured student machine on the dorm network be compromised with AT&T proprietary material/trade secrets on it, etc. As became clear a few years ago, perhaps that energy should have been spent looking into the school's football program, but of course the local sysadmins had nothing to do with that. Anyway, for what it's worth, as a student/low-level staff in the early- to mid- 90s? No, you weren't going to get access to Unix code using the site license -- even from Berkeley -- unless you were on a first-name basis with a number of folks in the local computing community. And that wasn't going to happen for the majority of students for logistical reasons if nothing else. The point was if you were at all in the community, it was pretty easy to > find the BSD code. > Please see above. It may have been easy, but that didn't mean there wouldn't be consequences due to misunderstandings or what have you. Which brings me to my point... many developers abandoned it - and most of > them certainly know how to get it. They why I think the incorrect belief > that legal entanglement (miss guided as it turned out) where not there with > Linux. > > By the time the legal case was settled, the developed had "completed > enough" of what was missing in Linux from *BSD that many folks never went > back. And the newbie never knew any better. > The point I was trying to make was that the newbie didn't know any better but didn't want anything else, even if s/he did know any better. Plan 9 was available after 2000 gratis, but by then no one wanted it (more's the pity, IMHO). If I think about the systems that were interesting in the research sphere in the late 80s early 90s, they were V, Chorus, Minix and Xinu for education, Mach, NeXTSTEP, etc: again, no one really wanted them. They wanted Unix a la SunOS 4/System V instead. As you noted, BSD's future looked dubious, so they got Linux instead: it was the next closest thing that didn't look like it might result in a trench-coated G-man breaking down your door. Linux filled a gap that a lot of people were looking to have filled. >> > ​Agreed..​ but that gap would not have been there if the AT&T legal case > had not clouded it all. Imagine that if the case had no occurred, the > hackers were already working with *BSD. > > So then the question comes which Larry raises, was the UNIX personalities > and/or the licensing what would have caused Linux to rise. > > I don't think so, because BSD had too much of a lead - already had > networking, windowing, and in fact had a "better" installer on a PC/386. > The first stuff "distro" that was at all reasonably easy t install was a PC > was slackware and that was partly because they pulled a bunch of stuff from > the stuff Jordan had created. > > But they problem was that FreeBSD et al was starting under a legal cloud, > I know I was worried. I ran it on two of my systems, but was working on > Linux on another to hedge my bet. I was not sure BSDi/UCB would win, so I > started helping make Linux work better too. > I think you are absolutely right. It's kind of sad, in a way. Oh well. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Wed Feb 22 14:11:37 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 20:11:37 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170222040629.GN9439@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170222031836.GH9439@mcvoy.com> <20170222040629.GN9439@mcvoy.com> Message-ID: <20170222041137.GO9439@mcvoy.com> On Tue, Feb 21, 2017 at 08:06:29PM -0800, Larry McVoy wrote: > The open source BSD stuff was a train wreck from the very beginning. > Nobody could get along with Jolitz, so NetBSD started, then Theo wanted > to be in charge of something so OpenBSD was born. I can't remember how > FreeBSD got spun out, but what I do remember is that there were power > struggles from day 1. Oh, and I forgot, then there was the BSDi group. While we all loved those guys, they left a sour taste. There was some bad blood between them and Jolitz (he unfairly got the short end of that stick). And as Clem says, we all wanted a free or really really cheap Unix and these guys wanted $995 for a release. I think a lot of us felt like they sort of betrayed the ethos of Unix, we wanted free like it was when you got a tape from dmr (no, I never got one, just got to hear the stories and they sounded great). The whole BSD thing in the early 90's was a train wreck. In my opinion. From lm at mcvoy.com Wed Feb 22 14:17:34 2017 From: lm at mcvoy.com (Larry McVoy) Date: Tue, 21 Feb 2017 20:17:34 -0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: <20170222041734.GP9439@mcvoy.com> On Tue, Feb 21, 2017 at 11:07:20PM -0500, Dan Cross wrote: > I can say from first-hand experience that it was NOT easy to get access to > Unix source code there. The cadre of university system administrators that > formed something of a cabal did not hand it out lightly, and it took > significant time to gain the sort of trust that would result in you getting > access to it. I strongly suspect that if a random CS student had written to > UCB asking for access to the BSD source code, and that had gotten back to > the aforementioned cabal, it would not have gone well for the student. Lots > of intrusive questions would have been asked; angry letters written and > placed into files. Uncomfortable meetings with academic advisors and the > university computer security officer would have taken place. Questions of > academic malfeasance or expulsion may have come up, etc. My experience at UWisc-Madison, during the time they were working on 4.3-Uwisc, matches Dan's pretty well. Yup, source was there. Access was restricted, you had to get a login on slovax, and you had to be "somebody" to get that login. I don't remember how I got access, I just knew I wanted it. So I probably just begged and eventually one of the admins took pity on me? Dunno. I don't think it was like what Clem says for most people. Clem went to CMU if I remember correctly, that puts him in a pretty elite class right there. I can easily imagine that the CMU CS department let all their students have access to the source if they wanted it. I don't think that was anywhere near as common as Clem thinks it was. My guess is that Clem interacted with a bunch of people who were his peers (aka pretty elite people) and all those guys had source access. Us unwashed masses had to work a lot harder to get it. Once 386BSD came out, yeah, source was easy. Not before. Even when I was at Sun the historic source was there, v7, 32v, etc., but you had to get past Shannon to get at it. From crossd at gmail.com Wed Feb 22 14:28:42 2017 From: crossd at gmail.com (Dan Cross) Date: Tue, 21 Feb 2017 23:28:42 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: On Tue, Feb 21, 2017 at 10:38 PM, Clem Cole wrote: > > On Tue, Feb 21, 2017 at 9:25 PM, Steve Nickolas wrote: > >> I started screwing around with Linux in the late 90s, and it would be >> many years before any sort of real Unix (of the AT&T variety), in any form, >> was readily available to me - that being Solaris when Sun started offering >> it for free download. > > > See my comment to Dan. I fear you may not have known where to look, or > whom to ask.​ As I asked Dan, were you not at an university at time? Or > where you running a Sun or the like -- i.e. working with real UNIX but > working for someone with binary license, not sources from AT&T (and UCB)? > Clem, I think this is a great way to put it, and that you're fundamentally right, but bear in mind the following, below: I really am curious because I have heard this comment before and never > really understood it because the sources really were pretty much available > to anyone that asked. Most professionals and almost any/all > university students had did have source access if they ask for it. That is > part of why AT&T lost the case. The trade secret was out, by definition. > The required by the 1956 consent decree to make the trade secrets > available. A couple of my European university folks have answer that the > schools kept the sources really locked down. I believe you, I never saw > that at places like Cambridge, Oxford, Edinburg, Darmstad or other places I > visited in those days in Europe. Same was true of CMU, MIT, UCB et al > where I had been in the USA, so I my experience was different. > The universities you are mentioning here are top-tier for CS. But please do bear in mind that if you were not at one of those institutions (for whatever reason), asking for that code might well have gotten you the hairy eyeball from folks you didn't want giving you a furry look. If you were in an institution better known for Mech E than CS, even if you had access, the folks who you would ask to get it wouldn't necessarily know to give it to you. By the time I was a student, I didn't much care as I was more interested in pure math than computers, but hey. The key that by definition, UNIX was available and there were already > versions from AT&T or not "in the wild." You just need to know where to > look and whom to ask. The truth is that the UCB/BSDi version of UNIX - was > based on the AT&T trade secret, as was Linux, Minix, Coherent and all of > the other "clones" -- aka look-a-likes and man of those sources were > pretty available too (just as Minix was to Linus and 386BSD was to him also > but he did not know to where/whom to ask). > > So a few years later when the judge said, these N files might be tain'ted > by AT&T IP, but can't claim anything more. The game was over. The > problem was when the case started, techies (like me, and I'm guessing > Larry, Ron and other ex BSD hackers that "switched") went to Linux and > started to making it better because we thought we going to lose BSD. > > That fact is if we had lost BSD, legally would have lost Linux too; but we > did not know that until after the dust settled. But by that time, many > hackers had said, its good enough and made it work for everyone. > > As you and Dan have pointed out, many non-hackers did know that UNIX > really was available so they went with *Linux because they thought that > had no other choice, *when if fact, you actually did and that to me was > the sad part of the AT&T case. > > A whole generation never knew and by the time they did have a choice but a > few religion began and new wars could be fought. > > Anyway - that's my thinking/answer to Noel's original question. > > Of why Linux over the over the PC/UNIX strains... I think we all agree > that one of the PC/UNIX was going to be the winner, the question really is > why did Linux and not a BSD flavor? > Small anecdote: I got access to NetBSD fairly quickly (but it still had this feeling of not *really* being Unix, for some odd reason). I suppose I must have installed 0.8. I switched to FreeBSD once I realized one could install via FTP instead of a myriad of floppies. I ran Linux on one machine but some folks I regarded gave me guff about it and I switched to the publicly available BSD stuff shortly thereafter. As someone once said, BSD is what you get when Unix folks port to the PC; Linux is what you get when PC folks build a Unix. Most local folks were running Suns or RS/6000s and the PC-based stuff was regarded as something of a toy. A couple of years later, someone pointed out the Wintel economics and it was hard to refute. - Dan C. (PS: A self-deprecating anecdote. When I started gaining access to the local Unix culture, access to USENET came along with that and, of course, discovery of the local flame newsgroup. Not knowing anything, I posted something; I was immediately flambeed and told to post my SAT score. a) I hadn't yet taken the SAT, and b) I had no idea how to respond to a posting and quote what I was responding to, so I just "played it cool" by responding with single-word posts saying likes what, "Whatever." or "Loser." This apparently gained me something of a reputation as a savvy participant as it drove some of the regulars batty, but really, it was entirely due to my own ignorance of how [not] to use an NNTP client. The SAT thing was apparently a matter of local lore and had to do with a particularly verbose community participant who was sufficiently impressed with his SAT score that he kept posting about it, eventually prompting a flood of tongue-in-cheek replies about standardized test scores....) -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Wed Feb 22 15:56:39 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Wed, 22 Feb 2017 00:56:39 -0500 (EST) Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: On Tue, 21 Feb 2017, Clem Cole wrote: > On Tue, Feb 21, 2017 at 9:25 PM, Steve Nickolas wrote: > >> I started screwing around with Linux in the late 90s, and it would be many >> years before any sort of real Unix (of the AT&T variety), in any form, was >> readily available to me - that being Solaris when Sun started offering it >> for free download. > > > See my comment to Dan. I fear you may not have known where to look, or whom > to ask.​ As I asked Dan, were you not at an university at time? Or where > you running a Sun or the like -- i.e. working with real UNIX but working > for someone with binary license, not sources from AT&T (and UCB)? No, and no. I was in high school, actually, and I only attended college - a local 2-year school - for one semester before dropping out because I couldn't handle it. -uso. From arnold at skeeve.com Wed Feb 22 18:43:59 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 22 Feb 2017 01:43:59 -0700 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: <20170222031758.GG9439@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> <20170222031758.GG9439@mcvoy.com> Message-ID: <201702220843.v1M8hx2t017602@freefriends.org> Larry McVoy wrote: > So Sun did a public release of the RPC / XDR code and I think all the > user space utilities. It used to be on sunsite. Is there an archive > of that somewhere? I may have an archive on CD somewhere (maybe). It was posted in a USENET source group. My archive of UUNET's ftp site with all the sources group archivess from ~ 2004 is also in the archives, so it should be findable. Thanks, Arnold From jsteve at superglobalmegacorp.com Wed Feb 22 18:57:26 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Wed, 22 Feb 2017 16:57:26 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170221213754.GA6103@mcvoy.com> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <20170221213754.GA6103@mcvoy.com> Message-ID: <4652e32b-d39d-480f-8adf-6f84934bfb79@SG2APC01FT046.eop-APC01.prod.protection.outlook.com> Wow that captures so much there. I think the big thing at the time was the tools, and even the precious kernel source code. I got into Linux around 0.12-0.95. To me it was so amazing to get the kernel source code, and actually compile it myself. Prior that that, I’d only been a user on VAX Ultrix, and helped out some mom & pop resellers that got in over their heads with Xenix. BSD Unix was something that ran on massively expensive hardware, and was guarded like a state secret, so I never bothered to look it up as I didn’t get the exciting computerlab job, and by the time I had one we ran AIX, and were 100% against doing anything else, especially talks of using GCC/F2c instead of IBM’s XLC/Fortran. We also had another lab with AT&T 3B2’s that one college kid had apparently ‘stolen’ source code to the kernel had relinked the kernels with his ‘improved’ modules .. and which is what they always blamed for stability issues (certainly not having 30 users on a machine that could barely keep up with 5). There was such a high bar to get a UNIX system to mess around with, and it was such a castle vs peasant thing that it really reminded me of the whole microcomputer revolution. Had I known that 386BSD was a thing I would have been interested. But it was digging around on a BBS where I found SLS Linux diskette images that I could install on a 386sx that was just as useful as Xenix. But with GCC I could actually port over my own stupid stuff. The SDK didn’t cost more than a car and it was amazing. Even better you not only could download the kernel, but were encouraged to do so, as the generic kernel sucked. So reading comments up to here, it seems that being baggage free in terms of not working with ‘existing good’ code gave them a chance to challenge every known idea of what things should be, and then like extfs trying things, failing, and improving like ext2fs, ext3fs and ext4fs … My personal catastrophic issues with Linux has always been the ‘hookers and blackjack’ approach, where someone doesn’t like LIBC then they’ll just replace it, over and over and over. Then you get binary commercial products (Oracle) which are a nightmare to deal with, and now you end up with containers as a way to deal with the horrible impossibility of deploying binaries to Linux. I’m still hopeful someone will just “borrow” what NeXT did with packages, and fat binaries. I guess the other takeaway is that with Linus only focusing on a kernel is that everyone could make their own, while forking or making your own BSD as a user was (and Im sure is still) looked highly down on. Just as we went through the whole NetBSD ouster of Theo and OpenBSD thing, and of course Matt’s Dragonfly. I used to think it was more so right place at the right time, but really that blank slate seems to have been a big thing too, just as there has been some ancient bugs in BSD like the 33 year yacc bug (http://undeadly.org/cgi?action=article&sid=20080708155228) and a 25 year BSD bug (http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug). Linux would have never existed without the 386 Minix branch, which of course relied on there being a UNIX to copy and ‘improve’ with it’s microkernel in the first place, but now we seem to be really in that post UNIX world. By modern standards SYSVr4 is embedded sized. Although last time I asked Attachmate about it they didn’t know what a UNIX was. I suspect it’s about the same with Microfocus. From: Larry McVoy Sent: Thursday, 23 February 2017 5:53 AM To: Joerg Schilling Cc: lm at mcvoy.com; tuhs at minnie.tuhs.org; jsteve at superglobalmegacorp.com Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other On Tue, Feb 21, 2017 at 11:30:34AM +0100, Joerg Schilling wrote: > Larry McVoy wrote: > > > I've worked with Linus, I know him pretty well. I stand by my description > > above and nothing you've said has changed (and isn't likely to). > > I know him as well, he send various personal attacks against me. Linus attacks anyone who he thinks is misguided. He's been wrong but he's usually right. > As Linux personally and incorrectly claimed that I was talking about kernel > internal interfaces even though I was definitely talking about > kernel/userspace interfaces, I assume that he has a problem with understanding > what an external interface is. Yeah, uh huh. If it makes you feel better to say stuff like that, go for it. You do realize it doesn't reflect well on you, right? The guy is a pretty darn good kernel engineer, I think he knows what a kernel/userspace interface is. It's a big part of the job description. > You may have started with Linux later than I did - I started in 1996. Was running Linux well before that, I ran it when you booted off of floppies and there was no networking. I don't know when I started but this was in 1993: http://www.mcvoy.com/lm/bitmover/lm/papers/srcos.html and I'm sure I'd been running it for quite a while by that time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Wed Feb 22 19:00:46 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Wed, 22 Feb 2017 17:00:46 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <1487717888.58acc60090241@www.paradise.net.nz> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: <83fe218c-c0f4-4c28-bdcd-5ac6368b5edc@SG2APC01FT010.eop-APC01.prod.protection.outlook.com> Yeah slices? A: b: c: d: e:? But C: is the whole drive??? I had some really old BSD book that talks about needing 4 people to install a harddisk as they were so heavy, and talking about it’s massive ‘500MB’ capacity (Eagle drive on a VAX?) but it certainly didn’t fit in the DOS / OS/2 / Windows NT world. And OS/2 was so much like MS-DOS needing to reboot and so clunky, while Windows NT let you partition at will, and even concatenating disks, or setting up software raid with absolute ease it made you wonder why it always was so difficult on anything else. Sent from Mail for Windows 10 From: Wesley Parish Sent: Thursday, 23 February 2017 7:14 AM To: Larry McVoy Cc: TUHS main list; Noel Chiappa Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other Now that brings up another reason why I think Linux won. Most of the early Linux developers were educated partly in the MS/PC/DR DOS world. They wanted a Unix, but they had bought IBM PC clones with MS DOS and were familiar with the DOS way of doing things. Linux's disk partitioning is very familiar to anyone who's familiar with the DOS way of disk partitioning. BSD's disk partitioning is a culture shock. (I know. I'd gotten used to the DOS way of doing things after learning about disk partitioning with my 486 and IBM OS/2 - the hard way. I tried Linux and the terminology was the same and due to a neat trick with the DOS filesystem I could experiment with it on an unchanged DOS system. I then tried FreeBSD and I didn't understand the terminology. So I stuck with what I'd learnt.) FWLIW :) Wesley Parish Quoting Larry McVoy : > On Tue, Feb 21, 2017 at 03:28:13PM -0500, Steve Nickolas wrote: > > On Tue, 21 Feb 2017, Larry McVoy wrote: > > > > >In terms of crash worthyness, ext2 was better. I think the ext2 > people > > >took the approach that they wanted to be as robust as dos but with > > >performance. And they made it, it's some very nice work. > > > > Wouldn't "as robust as DOS" be a *bad* thing? > > The DOS file system, while stupid, was very robust in the face of > crashes > (sort of had to be, he says slyly). > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Wed Feb 22 19:56:13 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Wed, 22 Feb 2017 09:56:13 +0000 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <4652e32b-d39d-480f-8adf-6f84934bfb79@SG2APC01FT046.eop-APC01.prod.protection.outlook.com> References: <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <20170221213754.GA6103@mcvoy.com> <4652e32b-d39d-480f-8adf-6f84934bfb79@SG2APC01FT046.eop-APC01.prod.protection.outlook.com> Message-ID: <20170222095613.GB14469@yeono.kjorling.se> On 22 Feb 2017 16:57 +0800, from jsteve at superglobalmegacorp.com: > My personal catastrophic issues with Linux has always been > the ‘hookers and blackjack’ approach, where someone doesn’t like > LIBC then they’ll just replace it, over and over and over. Then you > get binary commercial products (Oracle) which are a nightmare to > deal with, and now you end up with containers as a way to deal with > the horrible impossibility of deploying binaries to Linux. I’m still > hopeful someone will just “borrow” what NeXT did with packages, and > fat binaries. Something like _snaps_, which Ubuntu is apparently pushing in their most recent releases? What is a snap? https://snapcraft.io/docs/snaps/intro Can a vanilla Ubuntu 16.04 LTS Server run without snapd? https://askubuntu.com/q/878431/11751 -- 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 jsteve at superglobalmegacorp.com Wed Feb 22 20:16:52 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Wed, 22 Feb 2017 18:16:52 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> Message-ID: I always hear that universities had access, but it wasn’t undergrads in 1000 level classes that arrived. Asking for that kind of thing was either greeted with laughs, or should shrugging. Access to anything like that was for either graduate students or people ‘in the click’ and people just arriving were neither. Just like the partitioning code that was apparently common, none of this stuff was available to anyone that simply didn’t know as there was no central clearing house of information. And I gather the fear of AT&T meant it wasn’t anything anyone was willing to share. Not everyone got 20th generation photocopies of the Lions book, nor did they get access to anything other than what teachers were willing to let kids have access to. Prior to Net/2 people were trying to hack milnet to find BSD source code. And even when Net/2 was a thing I can tell you that in south Florida among hackers I knew that were my age, none of us had heard of it, or knew anything about it. When people saw us kids swapping floppies, and lugging around our 386’s to do Linux install parties nobody ever once mentioned anything about having BSD source or anything. It was a very much gated community, and new students were certainly not welcome. In those regards it really is no surprise that Linux used nothing from places with ‘source licenses’ as nothing in that was available to actually look at. Another thing that killed Net/2 was that second networking package for Linux, surprisingly called NET2 shared an incredibly similar name, and even in it’s readme: NOTE: In this document, ``NET-2'' does not refer to the Berkeley Software Distribution NET-2 release of BSD UNIX. Yes, the names are conflicting. In this FAQ, ``NET-2'' refers only to the new generation of TCP/IP code in the Linux kernel. And I’m sure the lawyers were happy that way as us 1000 level kids didn’t care and would happily steal said source, and try to use it. Even today I’m finding out about this CMU Mach+4.3BSD that was available in 1990, and I suspect there are other i386 based BSD’s that could have filled some kind of gap but either chose not to, or were at best public secrets. Just as I’m sure if the non Portuguese world had heard of Tropix (http://www.tropix.nce.ufrj.br/) it too may have had a following. Had AT&T won, there was no stopping Linux though. It didn’t use anything from AT&T, and back then it was still based on a.out, and some people were looking at using COFF... After AT&T’s defeat did the whole ELF thing come, and then there was the lawsuits on API’s and headers. If anything I’m more so surprised that the USSR with their stolen BSD didn’t push some kind of Soviet UNIX (DEMOS) into the west, to ride that whole ‘free’ software thing. Or they were just too politically blind, and figured that westerns would be highly suspicious of Russians pushing stolen American tech. Sent from Mail for Windows 10 From: Clem Cole Sent: Thursday, 23 February 2017 11:27 AM To: Dan Cross Cc: TUHS main list; Noel Chiappa Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other On Tue, Feb 21, 2017 at 8:50 PM, Dan Cross wrote: If I may, I think there was an additional thing at play: Linux was essentially Unix. ​But that is of course my point.   Linux is (was) UNIX, AND ...  "UNIX" as a free UNIX was available at the time.​   Linux "won" because people wanted low-cost or free (as in gratis) Unix with source that could run on modest commodity hardware, and Unix wasn't available at a price point that was reasonable for most individuals (certainly not with source). ​Indeed - that was 386BSD.​   At first anyone with a source license (which was just about anyone at University - so that means students like Linus BTW), and most commercial places had access to the BSD license.  The ftp site for download 'Jolix' as some one called it earlier today was pretty much the worst kept secret on the Internet.   All you had to do is ask, and you could find it and once NET/2 was released, and then FreeBSD, NetBSD et al came to be it was all over. They key was in the case of 386BSD, you want to ask for it (and officially needed a license to ask), but long before Linux shows up there were >>freely<< available PC/UNIX systems. And you point, which is 100% in agreement with my own is that under the rules of Christiansen disruption, a PC/386 based UNIX that was "cheap enough" was going to win. The question Noel asked was why did this flavor of UNIX win over the others since there were other choices.   That is what I tried to answer.   As Larry and I both pointed out, if the BSDi/AT&T suit had not occurred the "hackers" which Larry described very well in his document, were going to find something.   386BSD was that place.   Then it got clouded in legal nonsense and lot of us fled. Larry suggest there were other reasons.  He and many others think the GPL/2 vs the BSD license was important.  I really don't think so.  But that's less of an argument.   The key is that the BSD version was cloud in legal issues (and as Larry pointed out some strong personalities).   ​...   So Linux comes along and it's basically a "simplest possible solution" Unix, freely available, runs on a PC, comes with source, and wasn't mired in a lawsuit brought by a major US company. It was the right thing in the right place at the right time. ​Exactly ... ​ Linux arrive at the right time, free of the perceived legal issues.  The sad truth is that if AT&T had won, technically Linux would have had to be removed from the market in the US and NATO countries.   I'll not try to speculate what would have happened then other than to say the not only was cow out of the barn, th ​e​ barn had caught fire so there was not place to put it back.   I think there's a network effect that blinds a lot of folks to this reality. Most of the folks on this list had access to Unix source and, with no disrespect intended, it's easy to lose sight of what a big deal that was. But unless you were in a position to already have access to it, it was remarkably difficult to come by. ​Actually, I always found that a strange statement.  I hear you and no disrespect intended, but  I fear that people that make that claim just did not know where to look.  It was ignorance (not stupidity mind you) - just lack of knowledge that is was available. I'm going to ask Dan, were you not at an university at time?  Most schools in the US and Europe had BSD licenses.  If you working, I can understand it somewhat.   Many people's first UNIX experience was on a Sun Workstation so those folks did not have UNIX source licenses.   But if you were at a either a University or commercial enterprise with a AT&T and BSD license,  All it took was making sure you university had one and sending and email to the UCB folks (which many of us on this list were some of the folks that might have read it).​ They reply (I if I got searching through old email I might even have a copy of some where) basically was the url of the blind ftp address to pull the iso off the ucb ftp site.  It was incredibly easy to get but you did have to have ftp access (and know the magic path - which if you asked was easy to get).   Even with the first ISO, at one point, I seem to remember the bazillion *BSD floppies showed up on the one of the netnews channels and clogging up the dial-up links for a few days. The point was if you were at all in the community, it was pretty easy to find the BSD code.   Which brings me to my point... many developers abandoned it - and most of them certainly know how to get it.  They why I think the incorrect belief that legal entanglement (miss guided as it turned out) where not there with Linux. By the time the legal case was settled, the developed had "completed enough" of what was missing in Linux from *BSD that many folks never went back.   And the newbie never knew any better.     Linux filled a gap that a lot of people were looking to have filled. ​Agreed..​ but that gap would not have been there if the AT&T legal case had not clouded it all.   Imagine that if the case had no occurred, the hackers were already working with *BSD. So then the question comes which Larry raises, was the UNIX personalities and/or the licensing what would have caused Linux to rise. I don't think so, because BSD had too much of a lead - already had networking, windowing, and in fact had a "better" installer on a PC/386.   The first stuff "distro" that was at all reasonably easy t install was a PC was slackware and that was partly because they pulled a bunch of stuff from the stuff Jordan had created. But they problem was that FreeBSD et al was starting under a legal cloud, I know I was worried.  I ran it on two of my systems, but was working on Linux on another to hedge my bet.  I was not sure BSDi/UCB would win, so I started helping make Linux work better too. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Wed Feb 22 19:59:49 2017 From: dot at dotat.at (Tony Finch) Date: Wed, 22 Feb 2017 09:59:49 +0000 Subject: [TUHS] Another odd comment in V6 In-Reply-To: <1487705031.29325.for-standards-violators@oclsc.org> References: <1487705031.29325.for-standards-violators@oclsc.org> Message-ID: Norman Wilson wrote: > > Sometime in the latter days of the Research system (somewhere > between when the 9/e and 10/e manuals were published), I had > an inspiration about that, and changed things as follows: > > When a system call like read is interrupted by a signal: > -- If no characters have been copied into the user's > buffer yet, return -1 and set errno to EINTR (as would > always have been done in Heritage UNIX). > -- If some data has already been copied out, return the > number of characters copied. Weird, I thought what you describe was the traditional behaviour, e.g. https://www.freebsd.org/cgi/man.cgi?query=read&sektion=2&manpath=4.3BSD+NET%2F2 https://www.freebsd.org/cgi/man.cgi?query=read&sektion=2&manpath=SunOS+4.1.3 both say you only get EINTR if nothing was read. (This detail seems to go back to the 4.1c manual.) Was this a BSDism? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Thames, Dover, Wight, Portland, Plymouth: West or southwest 6 to gale 8. Moderate or rough. Occasional drizzle. Moderate occasionally poor. From jsteve at superglobalmegacorp.com Wed Feb 22 20:26:35 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Wed, 22 Feb 2017 18:26:35 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170222095613.GB14469@yeono.kjorling.se> References: <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <20170221213754.GA6103@mcvoy.com> <4652e32b-d39d-480f-8adf-6f84934bfb79@SG2APC01FT046.eop-APC01.prod.protection.outlook.com> <20170222095613.GB14469@yeono.kjorling.se> Message-ID: <2ee94444-c967-4d84-8a73-9b3224c2eced@SG2APC01FT112.eop-APC01.prod.protection.outlook.com> Packages go one further by including a single multi architecture binary. Of course the only thing more fun than compiling something is to say compile it four times. “-arch i386 -arch sparc -arch hppa -arch m68k” but now you had a binary that could run on all the NeXT platforms, instead of having 4 separate files.... Although I think today it’s largely x86_64 & ARM. But I’m sure there is some holdouts with MIPS/PowerPC/S390/Sparc/Sparc64 etc. Sent from Mail for Windows 10 From: Michael Kjörling Sent: Thursday, 23 February 2017 6:12 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other On 22 Feb 2017 16:57 +0800, from jsteve at superglobalmegacorp.com: > My personal catastrophic issues with Linux has always been > the ‘hookers and blackjack’ approach, where someone doesn’t like > LIBC then they’ll just replace it, over and over and over. Then you > get binary commercial products (Oracle) which are a nightmare to > deal with, and now you end up with containers as a way to deal with > the horrible impossibility of deploying binaries to Linux. I’m still > hopeful someone will just “borrow” what NeXT did with packages, and > fat binaries. Something like _snaps_, which Ubuntu is apparently pushing in their most recent releases? What is a snap? https://snapcraft.io/docs/snaps/intro Can a vanilla Ubuntu 16.04 LTS Server run without snapd? https://askubuntu.com/q/878431/11751 -- 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From schily at schily.net Wed Feb 22 20:29:13 2017 From: schily at schily.net (Joerg Schilling) Date: Wed, 22 Feb 2017 11:29:13 +0100 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <4652e32b-d39d-480f-8adf-6f84934bfb79@SG2APC01FT046.eop-APC01.prod.protection.outlook.com> References: <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com> <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com> <20170219154432.GA19243@mcvoy.com> <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net> <20170220222457.GB3163@mcvoy.com> <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net> <20170221213754.GA6103@mcvoy.com> <4652e32b-d39d-480f-8adf-6f84934bfb79@SG2APC01FT046.eop-APC01.prod.protection.outlook.com> Message-ID: <58ad67f9.Yh2DTEr/h30tO+1Q%schily@schily.net> wrote: > I used to think it was more so right place at the right time, but really that blank slate seems to have been a big thing too, just as there has been some ancient bugs in BSD like the 33 year yacc bug (http://undeadly.org/cgi?action=article&sid=20080708155228) and a 25 year BSD bug (http://www.osnews.com/story/19731/The-25-Year-Old-UNIX-Bug). Well, this is nothing special. Last year, I fixed several aprox. 35 year old bugs in the Bourne Shell while doing automated testing after POSIX support was ready. One was related to the rewrite that was needed to work around the design bug in the MC68000 but the other three were interesting: - Fixed a bug introduced in 1981 with SYSTEM III that caused continue large-number to break and not to continue the outer loop. - Fixed a bug - present since 1977 - that caused an interactive shell that calls "for i in 1 2 3 ; do echo $i; break 0; done" stop working. - Fixed a bug introduced in 1981 with SYSTEM III that caused cat 0<<-EOF not to strip leading TABs. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From krewat at kilonet.net Wed Feb 22 23:25:10 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 22 Feb 2017 08:25:10 -0500 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: <1487729263.2313858.888725168.40D323E9@webmail.messagingengine.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> <1487729263.2313858.888725168.40D323E9@webmail.messagingengine.com> Message-ID: <158188a2-4023-f40a-a0be-f774a79f79ec@kilonet.net> In the release.ms included on the tape: "This section lists the steps required to install this distribution on a Vax running 4.2" And from bin/passwd.c, for example: static char sccsid[] = "@(#)passwd.c 1.1 85/05/30 SMI"; /* from UCB 4.4 82/07/10 */ Yet, from the 4.3 Uwisc passwd.c on tuhs.org: static char sccsid[] = "@(#)passwd.c 4.24 (Berkeley) 5/28/86"; On 2/21/2017 9:07 PM, Cory Smelosky wrote: > > On Tue, Feb 21, 2017, at 17:35, Arthur Krewat wrote: >> Anyone interested in this source code? I did a quick Google search and >> couldn't find anything relevant. If it's out there somewhere, let me >> know, I'd like to take a look at it. >> >> It's Network File System Sun Microsystems Release 2.0 >> >> Where I got it from, that will remain nameless, used it to compile >> against BSD 4.3 on VAX, and possibly even 4.2 >> >> Is it not releasable? >> >> I also seem to have version 3.2, but I need to verify that. For example: >> /* @(#)showmount.c 1.3 87/08/13 3.2/4.3NFSSRC */ >> >> thanks! >> >> -- >> Arthur Krewat >> krewat at kilonet.net > Is this pre- or post- 4.3-UWisc? > From krewat at kilonet.net Wed Feb 22 23:33:42 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 22 Feb 2017 08:33:42 -0500 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: <1029512c-b1c6-9cf8-f66d-8852164dc610@kilonet.net> So what's the consensus at this point? Open source? Already released? I can't vouch that this wasn't some under-the-table exchange. It was for an "educational" institution but did not necessarily wind up there. Hence why I want to compare with similar releases if it exists. The sources all have copyright dates ranging from 1983 to 1985 for Sun-generated bits that looks like this: static char sccsid[] = "@(#)domainname.c 1.1 85/05/30 Copyr 1984 Sun Micro"; And sccsid's like this for sources taken from BSD and altered to fit: df.c:static char sccsid[] = "@(#)df.c 1.1 85/05/30 SMI"; /* from UCB 4.18 84/02/02 */ Sorry for fracturing this thread already. On 2/21/2017 8:46 PM, Clem Cole wrote: > > On Tue, Feb 21, 2017 at 8:35 PM, Arthur Krewat > wrote: > > Anyone interested in this source code? I did a quick Google search > and couldn't find anything relevant. If it's out there somewhere, > let me know, I'd like to take a look at it. > > It's Network File System Sun Microsystems Release 2.0 > > Since, the core of Solaris was made FOSS, I would hope there is(are) > persons at Oracle/Sun that can officially stamp the technology has > only historical value. > > Anyone know whom that should be so it can make it from the dark side. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Thu Feb 23 01:36:08 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 10:36:08 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: Dan & Larry thank you -- this helps me understand and I'm going reply you both in line hopefully without screwing up either of your messages as I try... On Tue, Feb 21, 2017 at 11:28 PM, Dan Cross wrote: > > The universities you are mentioning here are top-tier for CS. But please > do bear in mind that if you were not at one of those institutions (for > whatever reason), asking for that code might well have gotten you the hairy > eyeball from folks you didn't want giving you a furry look. > ​Unfortunately, I can see that. Sad, but probably a reality.​ Again, "he who has the gold, rules." Funny thing about gatekeepers. Larry's closing comment about Bill Shannon walling off the Research kernels was the same thing, and IT folks often seem to be like that too. My wife likes referred this behavior just this AM at breakfast, she calls "can't" a "magic button word" for me. I hate it when providers say things like that. Pisses me off and something go off to prove otherwise. ;-) > > ​....Small anecdote: I got access to NetBSD fairly quickly (but it still > had this feeling of not *really* being Unix, for some odd reason). I > suppose I must have installed 0.8. I switched to FreeBSD once I realized > one could install via FTP instead of a myriad of floppies. I ran Linux on > one machine but some folks I regarded gave me guff about it and I switched > to the publicly available BSD stuff shortly thereafter. > ​FYI: I ran them both in the early days. @ the time, *BSD was more "finger ROM" compliant(still is). I preferred Slackware for Linux​ because it was more BSD-like, and seemed a little less hackneyed but as you say the floppy distro just sucked. > > As someone once said, BSD is what you get when Unix folks port to the PC; > Linux is what you get when PC folks build a Unix. > I love it, never heard that and in fact that helps with Noel's original question, I think. It all comes back to the Christiansen disruption theory. > ​... > A self-deprecating anecdote. > ​I had to laugh a little when I read all that. I'm going to reply to something Larry said in a minute and this all related. Yeah, Larry's right, places like CMU, MIT, UCB are elite schools and yes, I have too solid board scores *etc*. As I like to say I have "the usual degrees from the usual institutions" - *i.e*. I have my union card. But I'm nothing special. You're from Penn State or UWisc (aka "UC Madison" - a lot of my class from UCB is the core of the faculty there). Hey, I believe Seymour Cray did his undergrad at St. Olaf's, a school better know for music - i.e. a small liberal arts school in Northfield, MN. I've never really cared where you went to school, what your score were, what your degrees are etc. I'm a hacker, and proud of being that. The schools, as you and Larry correctly point out, gave me opportunity and access. So I have network from them. But its what you do with it that matters to me. Two stories about me. First, I have always said, the greatest gift I was ever given was *not* getting a scholarship to MIT. I would have gone there and likely been "The nerd down the hall" - either that or flunked out. Who knows, as I later got to know folks that went there, it would not have been a good match for me as an undergrad. CMU (as screwed up as it was at time) was a better match for my personality. The fact is, I did not know know enough about the MIT culture when I was in HS (I was a faculty brat - *i.e.* scholarship student -- from a Philadelphia prep school - my Sr year in college 7 of the 7 Ivy League Squash Captains are my classmates from said prep school). That HS pushed me to MIT because I wanted to an engineer and that's all they knew. I did not even know about CMU until it was suggested by a family friend who was professor in the B School there. But in the end, it was about $. CMU offered me a scholarship, MIT did not and tricky Dick wanted to put a gun in hand. It was an easy choice. What was lucky for me was it a reasonably good culture match... mostly because of the close friends I made there ... out side of the EE, Math and CS Depts (two weekend ago I was a party with some of them that has occurred for 40 years on the same weekend since). Point is, I got lucky... Second, the proudest moment for me was watching my children pick colleges. Unlike me, I swore they would know about the culture of the schools and make darned sure that where they went matched their personalities and not rely on luck (and I'm very pleased to say that worked well with my daughter and seems to be working with my son). So to me, what the school you one too says about you is the network you have, who are your friends and the culture you learned. It tells me a little about how I can expect you to have been versed as a starting point, but I'm really much more interest want you do, have done. It's sad, that Penn State and UWisc had walled areas like both described. Sadly I saw the same thing at UCB, certainly of the undergrads. I have nothing but respect for the young folks that did an undergrad at UCB, because it was definitely different as a grad student. To me that's about respect for the individual and helping them grown up to be their best - creating opportunity. But I fear you are right. If things like UNIX access were walled off at places like that, then as you both point out, people we search for it where they could find it, *what is sad is that BSD UNIX was available at the time Linux was available. *The problem was that too few knew it, although many did (more in a minute). On Tue, Feb 21, 2017 at 11:17 PM, Larry McVoy wrote: > ... Yup, source was there. Access was restricted, you had to get a login > on slovax, and you had to be > "somebody" to get that login. I don't remember how I got access, I just > knew I wanted it. So I probably just begged and eventually one of the > admins took pity on me? Dunno. > Fair enough... that's me... I don't take no for answer either ;-). > > I can easily imagine that the CMU CS department let all > their students have access to the source if they wanted it. Sort of... when you took the OS course, since we used V6, everyone signed a "sub-license" from the CMU lawyers saying you were bound by the same rules as CMU, subject to being drawn and qtr'ed or otherwise severely admonished. > I don't think that was anywhere near as common as Clem thinks it was. I have to accept that, as strange as it seems to me. But I can see it happening. > My guess is that Clem interacted with a bunch of people who were his peers > (aka > pretty elite people) and all those guys had source access. Maybe... I accept that view, but I don't think it was intended that way by the >>developers<<. Security by obscurity more than intent I actually think. But people that >>owned<< the computers, did tend to put up the walls. I saw that. The problem was that the cost of those systems was very high, so making the available to "anyone" was a hard thing to "justify." Only pretty "enlighten" folk knew it was in their self interest to do so. Places like CMU, MIT and Stanford where the computing was pretty available to anyone who asked, were probably fewer than place like what two have described... sigh. > Us unwashed masses had to work a lot harder to get it. > Fair enough - on the other side, you could not tell the difference and I'll grant that. But I don't think it was intended. In fact, just the opposite was intended I think. If you look at the core of things like the GNU project for the 386BSD / Jolitix it was all about trying get a code available to anyone. The "hacker philosophy" really was of science and computing for all. > Once 386BSD came out, yeah, source was easy. Not before. > Maybe... As I said, the ftp address to download the original Jolitz 386 stuff (before the BSDi) split, was a poorly kept secret. I think I can date this sketch because as I remember it, it happened very near the time I was about to leave for my honeymoon. So that would have made it sometime in 2nd qtr of 1990. But around that time, I was consulting for NCR and during that gig, I was helping Bill with the disk driver for what would be BSD for the PC/386 (Bill references in the DDJ article BTW). Because of my working NCR, I had access to the documentation for the WD disk controller used in the PC/AT. Jollitz had tried to write the driver by reverse engineering the AT BIOS ROMS. But since I had access to the actual docs, I was able to tell what board was supposed to be doing, so I was able fix the driver to work correctly. I also think I added the original SCSI support of the WD7000 which they had just released and NCR was using (which is pre CAM BTW). Anyway, I remember trying to upload a new copy of the driver to the UCB ftp server and having issues, and i wanted to get it done before I left and was not available for a month. IIRC, Bostic told me that earlier that week the reason I was having issues, was the path for the ISO download for "hidden" 386 bits had been posted on Netnoise or the like and hehe ftp server was getting slammed. The point is that the* if you knew* where to look, the BSD UNIX was out there and people that were listening were finding it. And that was before Linus released Linux (or BSDi was forked or the court case etc...). But as I said, after the case, those of that wanted a PC/UNIX switched to Linux because we were worried we were going to lose the BSD base and Linux was good enough to get us going. That was my point. I think your counter point is that while I believe folks like yourselves or Linus could have gotten BSD UNIX if you had tried to find it it was available and folks like Keith and Bill were trying to get it out the door, but have suggest that you don't think so. You think the walls were too high, the access was only for the "chosen few" and a difference was the Linux really was available to what Larry referred to as the great unwashed. To that I say, fair enough. You could be right, I do hope you are not. I don't think that was the intention/theory - but in practice, it seems different. As I said -- thanks. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 02:11:14 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2017 08:11:14 -0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: <20170222161114.GT9439@mcvoy.com> On Wed, Feb 22, 2017 at 10:36:08AM -0500, Clem Cole wrote: > I think your counter point is that while I believe folks like yourselves or > Linus could have gotten BSD UNIX if you had tried to find it it was > available and folks like Keith and Bill were trying to get it out the door, > but have suggest that you don't think so. You think the walls were too > high, the access was only for the "chosen few" and a difference was the > Linux really was available to what Larry referred to as the great unwashed. The way it felt to me at the time was yes, you could, maybe, get access but it was proprietary source code. If you put it up for FTP you were going to get sued or something. It was not freely available. You keep saying that 386BSD was up for FTP as a poorly kept secret. Why was it secret? Because it wasn't legal to get it. A lot of us were pretty sick of that legal bullshit. Linux didn't have that problem. > To that I say, fair enough. You could be right, I do hope you are not. I > don't think that was the intention/theory - but in practice, it seems > different. I think most hackers wanted it to be free, though even there it was sort of hit and miss. The BSDi guys thought they saw a market opportunity so they weren't so excited about free. From clemc at ccc.com Thu Feb 23 03:00:59 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 12:00:59 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222161114.GT9439@mcvoy.com> References: <20170222161114.GT9439@mcvoy.com> Message-ID: On Wed, Feb 22, 2017 at 11:11 AM, Larry McVoy wrote: > It was not freely available. > ​Mumble....​ > > You keep saying that 386BSD was up for FTP as a poorly kept secret. > Why was it secret? Because it wasn't legal to get it. > ​Fair enough.. but that was the point where the CRSG folks were beginning to push back a little. Bostic has already suggested it had been rewritten to the "CSRG Management" and folks were beginning the rethink the whole issue at UCB. Remember BSDi does not yet exist. ​ Before BSDi can come to be, the idea of BSD for being "freely" available (for any processor) has to be broached. > > A lot of us were pretty sick of that legal bullshit. > ​Actually - that was exactly the point. A lot of folks did not think that the AT&T copyright mattered any more. I think most of us at the time we sick of it. The code base had been rewritten. But of course, none of us were lawyers. It was pretty clear an awful lot of the code was not "direct derivative works"​ of the Research base at this point. /usr/ucb was >> /usr/bin. The boot system had pretty much been completely redone. Tools like Sam's config subsystem did not exist in the AT&T code base. Plus, by now BSD has already switch compilers, so the whole PCC thread is gone. Even the rest of user level tools had slowly been rewritten. Keith had been replacing anything in /usr/bin or /bin with code from a difference provenance. That's part of why he rewrite ex/vi - so they it could not claimed to have been based on ed anymore. But you are right .. no one was really sure what was going to happen. So the BSD/386 iso's were hidden, so at least officially they could say the only people that we supposed to have access were the BSD licensees. But as I say it was a well known "secret." Take someone like myself at time. Officially, I'm a contractor. I had been working at Masscomp and Stellar before this. I had been a student at UCB and worked with the CSRG folks. At this point, I had branched out on my own. I'm whoring myself to anyone that will pay me to hack on UNIX. At the time I had a gig with NCR. I don't personally own AT&T licenses. The folks I work for do. NCR is working on what would become SVR4 BTW. I'm clearly "mentally contaminated" with the AT&T IP. But I know the BSD code base pretty well also. Since, I had been a BSD hacker and he was a friend of mine from the old days, I hear that Bill Jolitz is having issues with the AT/Disk controller. I offer to help him cause I have access to the WD1003 controller doc and think I know what is going on. Bill sends me the url for the system so I can down load it mess with it. I use my Wyse 386:16 at home in MA to load it (and it fails). So, I start hacking, redo the driver and send it back to Bill. Bill likes my new driver and switches it.... etc... now I have the sources ... too "unofficially." BTW: the truth is my customer (NCR) is a licensee and I have access to the AT&T code South Carolina when I am there. I'm very, very careful to never mix code bases. But if the Judge ever asked, I justify that NCR is license from UCB who is licensed from AT&T and I'm licenses from NCR. But I will also look the judge in the eye and insist never, never did the UCB code run on anything owned by or paid for by NCR. Could I have been sued, I don't know. I'm not a lawyer, but as I have had copyright law explained to me, I should have been ok. Trade Secret on the other hand, clearly, I had seen AT&T's IP so I was contaminated. But I had been was contaminated at CMU, 15-20 years earlier with the same AT&T IP. > Linux didn't > ​ ​ > have that problem. > ​And BSD did not either in practice, although as I said, once the suit was filed, you are right. A lot us, myself in included got scared. So we switched... because we thought (incorrectly)​ that Linux was free of the legal burden (it wasn't) - we were all contaminated, Linus, Tannenbaum, you, me, the Russias :-). As I said, the cow as out of the barn and barn had burn downed long ago, so trying to keep the IP off the market, had little realistic chance, IMO. It did not matter if it was called UNIX, Minux, Linux, Idris, Coherent or Larry and Clem's cool new OS. They all had the problem. > > I think most hackers wanted it to be free, though even there it was > ​ ​ > sort of hit and miss. > ​I agree. Or really closer to free than $1K. I was willing to pay $50-100. ​ > The BSDi guys thought they saw a market > ​ ​ > opportunity so they weren't so excited about free. > ​Yup, and I understood that too. I had done 2 startup's by then, so I already had a feel for the cost of care and feeding of hackers like you and me.​ IIRC, BSDi's "nut" those days was about $2-3M per year, so at $1K a copy they need a few thousand copies per year to may salaries and expenses. What they really needed was a larger firm, say some one like ILM or one of the National Labs that was using the technology for a critical thing and would pay many K per year for support. But they had not been figure out yet. They were getting there ... but then the law suite came. Having had this conversation with him at one point, I actually think, Kolstad had already gotten to "service model" - but the law suite killed the goose. They never recovered. So Linux with RH and Cygnus behind them filled the vacuum. So in summary -- I think the two parts of Christiansen disruption theory we all agree is that it was - the PC/386 based UNIX that was the key driver and - the acquisition cost for the end user had to get low enough to make it spread. Those other stuff we will never completely know. I suspect it depending on how to you look at it, personal experience. I acknowledge a number of your points and can see how you might come to such conclusions. That said, I do stick by own belief of the root cause, but not coming to complete agreement is ok with me. I definitely learned a bit from you and Dan's view and I thank you both. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From chet.ramey at case.edu Thu Feb 23 03:06:20 2017 From: chet.ramey at case.edu (Chet Ramey) Date: Wed, 22 Feb 2017 12:06:20 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222161114.GT9439@mcvoy.com> Message-ID: <8c534c33-349d-3c3c-ebaf-eccf49928784@case.edu> On 2/22/17 12:00 PM, Clem Cole wrote: > But you are right .. no one was really sure what was going to happen. So > the BSD/386 iso's were hidden, so at least officially they could say the > only people that we supposed to have access were the BSD licensees. But > as I say it was a well known "secret." This has very much the aura of a private club. If you were in the club, the secret was well known, but most of the people who went to Linux and supported its growth were not. -- ``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://cnswww.cns.cwru.edu/~chet/ From krewat at kilonet.net Thu Feb 23 03:41:01 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Wed, 22 Feb 2017 12:41:01 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222161114.GT9439@mcvoy.com> References: <20170222161114.GT9439@mcvoy.com> Message-ID: <049e7686-4c9f-6128-156f-3976175ac1ce@kilonet.net> The line of succession for me, starting with my hobby/business UNIX installs on Intel was: Beginning 1991-1992, Consensys SVR4 - Used up until around 1995. UUCP and USENET. Ran a BBS off of this and was a USENET node "kilowatt" during that time. I'm in NIXPUB. Buying this version of UNIX was for a joint business venture I went into with a friend, and we needed a decent UNIX platform to work with without a huge hardware cost. Very happy with it, but it did have some bugs. Wound up getting a few UNIXware drivers with fixes that took care of many of the issues mostly to do with the Adaptec 1541 SCSI card. I toyed with Linux around this time, but there was a local BBS guy who was such a fanboy that I was turned off by it - and there was NO advantage to it over SVR4 at that time. All I saw was a bunch of stuff glued together that was not "real" UNIX. It also offered almost no possibility of developing for SunOS or the up and coming Solaris 2.x During the above time, I also ran a Sparc-IPC with SunOS 4.1.2(3?) on it so it wasn't for lack of having a decent hardware platform to work with. I did a lot of SunOS development on it, and wrote stuff that I could compile it on both SVR4 and SunOS Around 1994-1995, started getting into FreeBSD - which I loved. Ran that from 1995 or so right up until around 1999 as my main firewall/router on one machine, and file server on another. Device support was better than Consensys, and I could fix any bugs I found myself if I had to - but never really had to. And, it was much like SunOS 4, if you squinted and tilted your head slightly. Also around that timeframe, I think I toyed with Solaris 2.4 or 2.5 on x86, but I know I that I went fully into Solaris x86 around the late-1998/early-1999 with Solaris 2.7 I'm not entirely sure when it was but at various times I checked out Linux on test machines. I had instances where I thought "oh boy! this is cool" but then, my installed base of computers and development environments meant having to go whole-hog into Linux for at least one of my machines and I had too much invested in them in terms of time. At one point, I decided I needed to find an alternative to my main workstation (running on Solaris 7 or maybe even 8 by this time) and turned back to Linux for it's plethora of device drivers and third-party applications - mostly audio/video players, Adobe Flash, Acrobat Reader, that sort of thing. This was the time of the turning-point for me for Linux, and it was turning AWAY from it for a long time. Still haven't recovered from it. I found that while running a decent-sized machine at the time - maybe it was 64 megs of RAM, maybe it was even more, I really don't remember. I'd have to go back and look at my old archived hardware to find out. Suffice it to say, I had a machine that made a GREAT Windows NT 4.0 machine. Did everything I wanted, plenty of applications ran on it, etc. So, I started to look at Linux again, because I detested Windows at the time. Installed it, early kernel 2.6 version, it ran great, did everything. Netscape, Flash, Acrobat Reader, some word processing (don't remember what), etc. Problem was, after running a while, it got really REALLY slow and kept banging the disk for long periods of time. Took about 5 seconds to realize what it was. It had swapped out most of the application pages to disk. Click on a link in Netscape, chunka-chunka-chunka. Go to a shell and try to do an ls, chunka-chunka-chunka. Found some references for kernel 2.4 that you could limit the amount of disk cache. So went to try that, 2.6 didn't have that anymore. So I went online, forget where, maybe it was a mailing list, maybe it was a USENET group, I really don't remember. I remember asking why the HELL did they remove that when it so obviously caused the system to get slower than dog-shit in a snow storm. First, it was "you need more RAM" - yeah, I never like the "go buy more hardware answer" neither for myself nor my customers. Strike one. Continue the discussion, and got some answer like "We know better than you do about how to deal with virtual memory, go away". This, after having worked with SunOS, Solaris, HP/UX, IBM AIX, SCO, SGI, and everything else under the sun that did NOT DO THIS. The discussion continued like that a little bit, and I turned around, installed Windows NT on the machine, and never looked back until the past 5-6 years where I've been forced to deal with Linux. Of course, now, there are tunables to alter the "pressure points" and timing of how the kernel decides that it needs a page for disk cache more than the application does. By default Oracle Linux will still swap the Oracle database itself out to disk when it thinks it needs more disk cache. That blows. Answer is to open the Oracle on Linux best practices PDF and set all the tunables to different values, and VOILA - now it only swaps out once in a while. Of course one of those is "swappiness" which for years seemed to do absolutely nothing. So now, it's OK - when a company I consult for eventually brings up "We can run this on Linux, right? We need to cut costs" - My answer is "yes" even though I don't want to. But when you consider a SPARC or IBM AIX box compared to an Intel Linux box, it's really a no-brainer. My only caveat when they do this is: If you had X amount of RAM in your existing system, and you're not making any substantial changes, double it for the Linux box. This tends to relieve the pressure to swap out, but it still doesn't completely remove it. And then, of course, I send them a document with all the tunables I've gathered. Anyway, long winded, rambling story, but I think you all might get the idea why for ME it wasn't the answer. After that period of time, I upgraded some of my hardware to newer dual-core AMD, and started running Solaris 10 and used ZFS for the first time in my "production" environment. What a blast ZFS has been. Linux doesn't come out-of-the-box with ZFS support? Oh well... see ya! :) I now have over 56TB of multiple raidz2 arrays spread over 46 disks or so all tied to a Solaris 11.3 machine and run multiple Solaris guests in VMware. Still not going Linux except when I need to test/develop stuff for customers and that's always on a VMware guest. zfs_arc_max for-the-win. And now, for Solaris 11.3|, |user_reserve_hint_pct - even better. Yes, I grew up to be a "real UNIX" snob. Now, at 51 years old, I'm confident I made the right choice. I know enough about Linux to make sure my customers are well taken care of. But for my personal use, if I have to, I'll go back to FreeBSD and ZFS before I run Linux. Hopefully Oracle does the "right thing" with Solaris when it's time. | ||| -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 04:24:40 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2017 10:24:40 -0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222161114.GT9439@mcvoy.com> Message-ID: <20170222182440.GE9439@mcvoy.com> On Wed, Feb 22, 2017 at 12:00:59PM -0500, Clem Cole wrote: > > A lot of us were pretty sick of that legal bullshit. > > > ???Actually - that was exactly the point. A lot of folks did not think that > the AT&T copyright mattered any more. I think most of us at the time we > sick of it. The code base had been rewritten. Sorry to keep yapping on this, but I think we're trying to get at accurate history, right? So what is written there was not how I felt at all. I personally felt like AT&T had a case, I thought it was copyright not trade secret. I went through the code, I had access to the AT&T code and the free code. I was a UFS/FFS hacker at the time so that's what I read. I found routines that were bit for bit identical in both in less than 5 minutes. The one I remember was bmap(), I found a couple of others that I don't remember (just remember there were more) and I gave up in disgust. I was pretty disappointed that CSRG considered this not AT&T source, it was. That left me with a strong feeling that AT&T was going to win. I was wrong but it didn't matter, BSD was sort of dead to me. I can't tell you how painful that was for me, I was very much a BSD guy, SunOS was BSD plus the stuff you would want fixed, fixed. Linux wasn't BSD but it wasn't going to get taken away from me like SunOS was taken away and now BSD looked like it was going to be taken away. It just looked like a bad investment to work on BSD so I worked on Linux. From clemc at ccc.com Thu Feb 23 05:35:00 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 14:35:00 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222182440.GE9439@mcvoy.com> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> Message-ID: On Wed, Feb 22, 2017 at 1:24 PM, Larry McVoy wrote: > I think we're trying to get at accurate > ​ ​ > history, right? > ​Agreed... apologies to all if this is a strange thread, but frankly its refreshing to try to tease this out in my own mind and I respect so many of you here. Thank you for listening to my rambling and my dealing with my dyslexic typing. ​ > > So what is written there was not how I felt at all. I personally felt > like AT&T had a case, I thought it was copyright not trade secret. > ​So did I at the time!! So did most people I knew. That was exactly the problem.​ > ​... > I found routines > ​ ​ > that were bit for bit identical in both in less than 5 minutes. The one > I remember was bmap(), I found a couple of others that I don't remember > (just remember there were more) and I gave up in disgust. I was pretty > disappointed that CSRG considered this not AT&T source, it was. > ​Agreed... the argument... I'm not saying it was correct... was that the code for bmap and like was the obvious code and any reasonable programmer would have written it that way.​ Again .. not a lawyer ... but as the law has been explained to me... *obviousness* is one place in copyright law where code *can be duplicate*. So the question, come if there are when does it go over the line and become *infringement*. Don't ask me.... I'm not defending or saying one way was right or wrong. In fact, like you, I was *really* worried, I too thought the case was about copyright and I thought, like the Apple/Franklin Computer Case (which I personally knew a little about but thats a different story), believed that AT&T would win (which pissed me off - even though I had a number of friends at AT&T - i remember grousing at some of them - they would not defend their employees for their actions - I'm not sure they were happy either). But like you, I started to help the Linux folks too. That said, I will also say I thought morally.... *Bostic and team was right.* By that point the core of what I consider "UNIX" really had been rewritten and it ws not the same thing I had run on the PDP-11 at CMU years before. I too, wanted a "freely available PC/UNIX" (with sources). Even if I was as, Chet suggested, a card carrying member of the "BSD Club." So, maybe I was splitting hairs. Could be. I wanted BSD, I had helped make it happen. Like Larry, it was a system I cared deeply about. I did not yet have children, at that point, probably felt similar to the way I feel today about them. I have put lot emotional energy into BSD's success. All of my early career. I had started companies around it etc... I watch Microsoft unfairly crap on the UNIX community etc... Can't say I wasn't too happy with Sun in those days too, as I felt Scotty was almost a slimy as Billy G. I had a pretty low opinion of the "boys in the coats and ties" and this court case was just another example of "TPC" (see the movie "The Presidents Analyst" for the reference) doing it again. But it was the AT&T lawyers that made the case about trade secret not copyright. They want to win everything and they lost it all. That called karma: "Squeeze too tight, while you keep the bird, it will die." > > That left me with a strong feeling that AT&T was going to win. > ​ditto..​ > I was > ​ ​ > wrong but it didn't matter, BSD was sort of dead to me. > ​Ah, that was the difference... I was still rooting for phoenix to rise from the ashes.​ I was hoping there was a still one more chance.​ > I can't tell > ​ ​ > you how painful that was for me, I was very much a BSD guy, SunOS was > BSD plus the stuff you would want fixed, fixed. > ​I think I have an idea. I was very nearly the in same spot.​ > Linux wasn't BSD but it wasn't going to get taken away from me like > SunOS was taken away and now BSD looked like it was going to be taken > away. It just looked like a bad investment to work on BSD so I worked > on Linux. > ​Ah... and I was hedging my bet. but trying to help both. I admit, I wanted BSD to win. Which is why I also tried to get OSF to make an alternative. OSF/1 vs. Linux at the point (again as a pure technology play) was the same as BSD vs Linux. Linux had a long way to go. I just wanted a PC/UNIX (basically with the BSD extension and managed like a BSD system) that I run on the PC/386 that was no more than the cost of DOS/Win or the like. If that could be found and better yet, source were available (and here Chet is probably right - because I had always been part of the club, I guess I was less worried, as I suspect my employers would always have sources and thus I would too). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnold at skeeve.com Thu Feb 23 06:18:30 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Wed, 22 Feb 2017 13:18:30 -0700 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> Message-ID: <201702222018.v1MKIUKO030787@freefriends.org> I'll add my two cents. My experience was that source was hard to get to. My undergrad school had IS/1 - v6 on a PDP-11 - and source was definitely not available to us seniors. One person who actually worked for the computer center did have access. This was 1980-1981. In grad school at Georgia Tech, there was no access to students to the vax, and even after I went to work there I had to sign something first before seeing source. Later I was a sysadmin at Emory U and so I had source but it wasn't widely open. We ran Mt. Xinu 4.3 + BSD on vaxen, so there source was necessary. By the mid-80s, even if you had AT&T and BSD licenses, it didn't help, as there were lots of vendors NOT giving out source (Sun, Pyramid, DEC, Gould, DG, you name it). This was pretty much OK; things worked fairly well and you didn't need to fix drivers and recompile the kernel and so on on those machines. Vaxen were aging, BSD didn't support 8500s, and so if you wanted BSD you pretty much had to go to one of the vendors offering it. Sun was probably the most popular. At a startup company we ran ESIX, SVR3 (and later SVR4) based on 386s for our product alongside a few Sun boxen. It was a good Unix, but again no source, but no real need for it either. This was ~ 1990-1991. W.R.T. personal machines, I shelled out $$ to buy an AT&T 3B1 (68010 based, System V kernel, SVR2 user land + vi) which I used happily for many years. Later I bought a Sun IPC. (More $$.) Also used happily for quite a while. I only got into Intel land for myself when I moved to Israel, buying a laptop and running Linux on it. I had played some with Linux on Sparc and was fairly impressed with it. This was circa 1997. Linux generally "just works" out of the box on PC hardware, and with Debian/Ubuntu, software updates are a breeze. I spend almost no time having to be a sysadmin for myself, which is wonderful. I mostly watched the whole AT&T/BSD lawsuit stuff from the side. At one USENIX I remember talking to Keith Bostic about it, and understanding that it was trade secret, but I asked him "Given the book by Maurice Bach on how UNIX works, how can they still think it's trade secret?" He just sorta nodded and said "yep" or something equivalent. But yes, the sense while it was going on was definitely that BSD was risky and problematic. And that the whole lawsuit thing was really, REALLY stupid. Sigh. Arnold From madcrow.maxwell at gmail.com Thu Feb 23 07:00:51 2017 From: madcrow.maxwell at gmail.com (Michael Kerpan) Date: Wed, 22 Feb 2017 16:00:51 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: Personal anecdote time. I'm probably a bit younger than most of the folks here and my first exposure to computers came when my father bought a shiny new Northgate 486 in 1990. He'd been talking about getting a computer for a few years and had been researching getting some sort of Unix, but even it was all too expensive even for someone who could buy a 486 in 1990. By the time I got interested in Unix-y systems (partly by reading a copy of _Life With Unix_ that my dad had bought back before we go our first computer), Linux was the cheapest game in town: free on CDs from the back of books in the public library. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 07:34:05 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2017 13:34:05 -0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> Message-ID: <20170222213405.GJ9439@mcvoy.com> On Wed, Feb 22, 2017 at 02:35:00PM -0500, Clem Cole wrote: > > I found routines > > that were bit for bit identical in both in less than 5 minutes. The one > > I remember was bmap(), I found a couple of others that I don't remember > > (just remember there were more) and I gave up in disgust. I was pretty > > disappointed that CSRG considered this not AT&T source, it was. > > > ???Agreed... the argument... I'm not saying it was correct... was that the > code for bmap and like was the obvious code and any reasonable programmer > would have written it that way.??? So suppose you owned a software company and someone had a source license, rewrote some of the code and claimed the rest was obvious so it didn't need to be rewritten. Now your code is out there for free. Affecting your revenue stream. How well is that "any reasonable programmer would have written it that way" going to play with with you? You are an experienced guy, you know that any reasonable programmer would have written the very same initial version of your code but that's not what you shipped. You shipped debugged, tuned code. It was debugged and tuned through years of experience with users, that takes time. I find it really really hard to swallow that any reasonable programmer would come up with the same code in a vacuum. I'll remind you I'm deep into the source management world and I've repeatedly seen my own engineers want to rewrite code and what do they want to write? What was checked in as version 1.1. All the warts are from real world experience and they want to get rid of them (until they look at the history and understand why the warts are there). I'd argue that what you'd get from any reasonable programmer is the naive initial version that works in theory but fails in practice. In my mind, the BSD guys cheated. If it were my code, if I owned that and they tried to make that argument, yeah, I'd sue them as well. AT&T messed up the suit but I don't think they were wrong. IP counts for something, it's expensive to fix all those bugs, it's cheap to do the initial naive implementation. Morally, in my mind, BSD was tainted. Whether it was proven so in a court of law doesn't change my opinion. It was AT&T's code to release, yes, I wanted them to do so as well, but it's their code. Just because we think it should free doesn't make it morally right to make it be free. Doing so is theft in my book. And for the record, I've seen the same behaviour in Linux. There was wholesale copying of BSD licensed drivers and other code into the kernel, some mumbles about it being dual licensed, but eventually it became GPL only. That's theft as well in my opinion. Perhaps my ethics are a bit too rigid, but they are my ethics and aren't likely to change. From clemc at ccc.com Thu Feb 23 08:11:54 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 17:11:54 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <201702222018.v1MKIUKO030787@freefriends.org> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <201702222018.v1MKIUKO030787@freefriends.org> Message-ID: On Wed, Feb 22, 2017 at 3:18 PM, wrote: > I mostly watched the whole AT&T/BSD lawsuit stuff from the side. At > one USENIX I remember talking to Keith Bostic about it, and understanding > that it was trade secret, but I asked him "Given the book by Maurice > Bach on how UNIX works, how can they still think it's trade secret?" > He just sorta nodded and said "yep" or something equivalent. > ​Not a lawyer... but for patents, I am under the impression that the date is defined as "first public discloser." So I think the official date would be the UNIX talk given in *"paper presented at the Fourth ACM Symposium on Operating Systems Principles, IBM Thomas J. Watson Research Center, Yorktown Heights, New York, October 15-17, 1973." [* https://www.bell-labs.com/usr/dmr/www/cacm.html] I believe that said paper predates all of the books. Fact is before Bach, UNIX shows up in a number of OS texts, so the point is that the IP is being taught by Universities and studies by students. Which is of course what the judge points out when the case was decided. And clearly, the legal battle was stupid. But pride is an amazing thing and corporate pride seems the worst in my experience. all quite sad. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From arno.griffioen at ieee.org Thu Feb 23 08:03:21 2017 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Wed, 22 Feb 2017 23:03:21 +0100 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org> IMHO one thing that Linux offered many people/coders/developers, especially in the early years, was the chance to actually make a contribution and a difference to the development and growth of the system. Especially in the early Linux years you could track down bugs or make improvements, send the patches to Linus and they'd actually end up in the code in a few days to weeks. How cool was that!?!? On BSD (at least my experience with NetBSD) it was *hard* to get fixes incorporated and with new releases only once a year or so it seemed very 'stale' and boring. I think this Linux style open-ness of development, the willingness to accept fixes and patches and perhaps horribly break things along the way, resonated with a lot of coders and enthousiasts making it popular very rapidly in those circles. Heck.. I did some minor low-level and early stuff on the Linux/M68k kernel port for the Amiga's and even though Linus himself was not interested in a 'non-i386' port or version of Linux he was also not against it and open to the idea and did accept fixes for bugs in the mainline kernel that were exposed by the port (eg. byteorder issues, hardcoded i386 bits, etc.) and basically sanitized a lot of code. It also forced some of the early splits in some drivers in platform independent and dependent pieces because of the vastly different styles of I/O and interrupt handing between the i386 and the M68k family, but Linus also saw the merit in such increased abstraction and portability and accepted such changes even though they did 'nothing' for the i386. All in all at the time (early/mid 90's) I feel that the whole 'community' (a much-abused word these days..) around Linux was much more conductive and supportive than any of the other *IX-with-source-available options for those that wanted to help/improve/fix stuff in the OS/kernel so it drew in more people. And when the (snow)ball started rolling with the free CD's on magazines and such then all hell broke loose as far as the popularity goes. Not saying it's "the best" at all as it can be a horrible mess, but the earlier mention of 'good enough' (or perhaps being the 'VHS' of *IX'es) is probably a good description. Bye, Arno. From clemc at ccc.com Thu Feb 23 08:18:02 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 17:18:02 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: On Wed, Feb 22, 2017 at 4:00 PM, Michael Kerpan wrote: > ​... > Linux was the cheapest game in town: free on CDs from the back of books > in the public library. > ​Yup... and the point is ended up in the legal troubles, I believe what you would have seen in​ library would have been based on some flavor of BSD because the BSD unix was much farther along/more mature/stable than Linux at the time. As Larry said -- people just wanted some "free" (I said "cheap enough"). -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 08:51:57 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2017 14:51:57 -0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org> References: <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org> Message-ID: <20170222225157.GL9439@mcvoy.com> +1 to all of this, I agree. And I was working on SunOS at the time, then later IRIX, and both were walled gardens. I loved working with customers who had source licenses but those were few and far between. Linux was like everyone had the source, because, well, they did. On Wed, Feb 22, 2017 at 11:03:21PM +0100, Arno Griffioen wrote: > IMHO one thing that Linux offered many people/coders/developers, especially > in the early years, was the chance to actually make a contribution and a > difference to the development and growth of the system. > > Especially in the early Linux years you could track down bugs or > make improvements, send the patches to Linus and they'd actually end > up in the code in a few days to weeks. How cool was that!?!? > > On BSD (at least my experience with NetBSD) it was *hard* to get > fixes incorporated and with new releases only once a year or so > it seemed very 'stale' and boring. > > I think this Linux style open-ness of development, the willingness to > accept fixes and patches and perhaps horribly break things along the way, > resonated with a lot of coders and enthousiasts making it popular very > rapidly in those circles. > > Heck.. I did some minor low-level and early stuff on the Linux/M68k > kernel port for the Amiga's and even though Linus himself was not interested > in a 'non-i386' port or version of Linux he was also not against it and open to > the idea and did accept fixes for bugs in the mainline kernel that were > exposed by the port (eg. byteorder issues, hardcoded i386 bits, etc.) > and basically sanitized a lot of code. > > It also forced some of the early splits in some drivers in platform > independent and dependent pieces because of the vastly different styles > of I/O and interrupt handing between the i386 and the M68k family, > but Linus also saw the merit in such increased abstraction and > portability and accepted such changes even though they did 'nothing' > for the i386. > > All in all at the time (early/mid 90's) I feel that the whole 'community' > (a much-abused word these days..) around Linux was much more conductive > and supportive than any of the other *IX-with-source-available options > for those that wanted to help/improve/fix stuff in the OS/kernel so it > drew in more people. > > And when the (snow)ball started rolling with the free CD's on magazines > and such then all hell broke loose as far as the popularity goes. > > Not saying it's "the best" at all as it can be a horrible mess, but > the earlier mention of 'good enough' (or perhaps being the 'VHS' of > *IX'es) is probably a good description. > > Bye, Arno. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm From clemc at ccc.com Thu Feb 23 08:56:38 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 17:56:38 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222213405.GJ9439@mcvoy.com> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <20170222213405.GJ9439@mcvoy.com> Message-ID: On Wed, Feb 22, 2017 at 4:34 PM, Larry McVoy wrote: > > How well is that "any reasonable programmer > would have written it that way" going to play with with you? > ​That is the key point of course. I suspect it depends on a lot of things. I could see myself being pretty upset. > > I find it really really hard to swallow that any reasonable programmer > would come up with the same code in a vacuum. > ​And that is why there are courts. I'm not going to say you are right or wrong. Low level routines like bit map, locks etc, I suspect are going to look pretty similar. For whatever it is worth we talk about this in a committee I'm on at Intel. The lawyers want to know how they can detect that some one is infringing on a patent. I'm usually the guy saying -- "wait a minute -- that's how we designed the instruction - that how its supposed to be used, so that's reasonable."​ I'm not lawyer.... and I don't even try to play one. But my experience is that at least in the low level stuff, the lower stuff, it does get pretty common. That said, if you have a trick or two up, say using an instruction sequence in an unusual manner - as you say -- experience -- that's where the differences start to show. BTW: you pick on BFFS (aka UFS). I was under the impression that pretty much that was an entire rewrite. The vax code brought over from 4.1 was code Berkeley had written during the joy's speed up work (even things like bmap). I did not think that came from 32/V. The key is the changes were done a little a time. Some in BSD, some more in BSD 2.0, more in 3.0 .... by the time of 4.2 the feeling was most of the kernel was different from what Ken and Dennis had originally written. > I'd argue that what you'd get from any reasonable programmer is the > naive initial version that works in theory but fails in practice. > ​Fair enough... and you might be able to make a reasonable living as a expert witness ;-) ​ > > In my mind, the BSD guys cheated. ​I understand and I see your point, although here is where we disagree.​ I lived it differently, since I was part of it. I think it was like the wolf that became the dog. A very slow process. But at some point, there was a change and the wolf stopped being a wolf and started being a new thing, a dog. Morally, in my mind, BSD was tainted. Whether it was proven so in a > court of law doesn't change my opinion. ​That's fair and I think you know, I very much respect your opinion and thinking. I don't expect to change it any more than I can expect you will change mine own, but I'm trying to understand it. > It was AT&T's code to release > ​ ​ > .... > Doing so is theft in my book. > ​Fair enough. To you its still a wolf and I can see that and if I did see it as a wold, I suspect I might agree. But I think having lived so much working being done outside of AT&T that was not getting credit and that "DNA" was being "stollen" by AT&T in my mind, it worked both ways. ​ > > And for the record, I've seen the same behaviour in Linux. > ​yep...​as bad or worse. Names of have changed to protect the guilty ;-) Many of the things the esr, rms et al have pontificated about frankly is not different. I see the same behaviors, just a change in who has the gold now. > Perhaps my ethics are a bit too rigid, but they are my ethics and > aren't likely to change. > Amen, they work for you, and I as I said, I can (and do) respect that.​ Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Thu Feb 23 09:13:20 2017 From: lm at mcvoy.com (Larry McVoy) Date: Wed, 22 Feb 2017 15:13:20 -0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <20170222213405.GJ9439@mcvoy.com> Message-ID: <20170222231320.GM9439@mcvoy.com> On Wed, Feb 22, 2017 at 05:56:38PM -0500, Clem Cole wrote: > BTW: you pick on BFFS (aka UFS). I was under the impression that pretty > much that was an entire rewrite. Nope, that's my wheelhouse, I spent a lot of time in there. I rewrote bmap() for the extent based file system work: http://www.mcvoy.com/lm/bitmover/lm/papers/SunOS.ufs_clustering.pdf so I know that code very well. The bmap() from research is the bmap() in BSD. It's bit for bit, including comments, identical. There were others but I sort of lost interest at that point, it was stolen code in my opinion. > code Berkeley had written during the joy's speed up work (even things like > bmap). I did not think that came from 32/V. The key is the changes were > done a little a time. Some in BSD, some more in BSD 2.0, more in 3.0 .... > by the time of 4.2 the feeling was most of the kernel was different from > what Ken and Dennis had originally written. A lot of it was different. But enough of it was the same that it was stolen code in my opinion. And I don't say that lightly, I admire and respect the BSD guys from CSRG pretty deeply. > > I'd argue that what you'd get from any reasonable programmer is the > > naive initial version that works in theory but fails in practice. > > > ???Fair enough... and you might be able to make a reasonable living as a > expert witness ;-) I took early retirement, I spend a lot of my time on tractors these days: http://www.mcvoy.com/lm/tractor-tree.jpg If someone offers me a pile of money to be an expert witness, I suppose. But quite frankly, that sounds like being an adult. Not a lot of fun in my opinion. > > In my mind, the BSD guys cheated. > > ???I understand and I see your point, although here is where we disagree.??? I > lived it differently, since I was part of it. I think it was like the wolf > that became the dog. A very slow process. But at some point, there was a > change and the wolf stopped being a wolf and started being a new thing, a > dog. I'd so love to agree with you. But the code diffs I did do not support that view, there was more than enough unchanged to call it cheating. I think that if I spent 20 minutes with you diffing code you would agree. > ???Fair enough. To you its still a wolf and I can see that and if I did see > it as a wolf, I suspect I might agree. But I think having lived so much > working being done outside of AT&T that was not getting credit and that > "DNA" was being "stollen" by AT&T in my mind, it worked both ways. So there we can agree. In no way do I hold AT&T blameless, if you want me to rail on them I can do that. Kind of an easy target, they really didn't understand what they had or what to do with it. It was better when it was Bell Labs and Bell Labs had a charter (didn't it have to do with being a monoply) that said they released their patents for free (or something like that, right?). When the suits came in it all got screwed up. And for the record, BSD moved the state of the art forward, I know that. I'd much rather be stuck on 4.3 BSD than SVr3 (and even SVr4). They redid a lot and added sockets and at least imagined mmap(). A BSD kernel was a nicer place to be than a AT&T kernel. So I mean no disrespect to their work. I just don't think they rewrote as much as they claimed they did, it was not a total rewrite, there was more than enough still there that AT&T could have prevailed with a copyright case. --lm From dave at horsfall.org Thu Feb 23 09:21:03 2017 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 23 Feb 2017 10:21:03 +1100 (EST) Subject: [TUHS] Any BSDi interest? In-Reply-To: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> Message-ID: On Sun, 19 Feb 2017, Cory Smelosky wrote: > Is there any interest in this aside from me? ;) As a loyal BSD/OS fan (until WinDriver took them over and shut them down, which is why I went to FreeBSD), I'm certainly interested... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From clemc at ccc.com Thu Feb 23 09:29:50 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 18:29:50 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org> References: <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org> Message-ID: Arno - thanks for more on this, as I think you scratched a difference between your experience and my own. ​By the time Linux shows up in the early 1990s, people like me had been developing UNIX for a long time and the novelty of hacking on the system, making changes, bug fixes was gone. I just wanted to use it on a PC/386. BSD for the 386 worked and so Linux was a step backwards and I was only going there because I felt I needed too. I remember when I first got Slackware running, after the trying Linus's 0.9 mumble release.... and it actually sort of ran ... saying "maybe this will work" but then I start running it issues such as I could not back up it like my other systems, network hosed up, few scripts "just worked", etc.. Yet, one of my coworkers who was about 2/3 years out of school at that point, thought Linux was so cool because of all things Arno suggested. He could submit bug reports and he changes go in. When I was b*tching about something breaking, he would say - "Clem you know how to fix it And I would reply "yup I do. But I don't want to." This was a the system I wanted to use ( at home ).​ I get paid to hack at work. I wanted a DOS/Windows alternative for home that I could rely on. I was not looking for a yet another system to do development (I had that). Which shows that difference... I was part of Chet's club, so I was hacking on UNIX already, and I did not need/want another system at home to hack just to keep my day to day working at home (or my wife being able to print things etc). The point was that I did not mind fixing the occasional thing I ran into with BSD - but those problem were few and usually had to do with new device bring up. But once something was was running, I could just use it. But the Linux systems I could not do that - they were very fragile, so it was not "fun" -- it was work. That was probably different for many of you. Linux was fun and cool, just like UNIX had been for me 10-15 years earlier in the mid 1970s. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From pnr at planet.nl Thu Feb 23 09:51:11 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Thu, 23 Feb 2017 00:51:11 +0100 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222182440.GE9439@mcvoy.com> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> Message-ID: <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> On 22 Feb 2017, at 19:24 , Larry McVoy wrote: > So what is written there was not how I felt at all. I personally felt > like AT&T had a case, I thought it was copyright not trade secret. I'm not a lawyer, but wasn't part of the background that prior to 1988 in US law one could not claim both copyright and trade secret protection, and that for something to be copyrighted it had to expressly claim to be copyrighted material, and be registered as such? I have a vague recollection that the AT&T legal department instructed the Unix team to remove copyright notices from the Unix source (and this seems supported by code, see for instance: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/ken/sys1.c and http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c) because the legal folks thought that trade secret was a stronger protection for software? I also seem to recall that the AT&T code base included original material from CSRG where the copyright notice had been removed by USL. All in all, the USL lawyers probably felt that they would lose the case if fought on the grounds of copyright violations alone. I wish something like Groklaw had existed during the USL-UCB case: the legal twists and turns would have been documented a lot better. There is some material though, see: http://www.groklaw.net/staticpages/index.php?page=legal-docs#bsdi The amicus brief by the Regents, and the settlement make for interesting reading. If the position taken by the Regents is correct, all of Unix up to and including 32V is in the public domain now. Warren: the links from Groklaw to TUHS are broken, perhaps because of the recent reorganization of the archive. From clemc at ccc.com Thu Feb 23 09:51:24 2017 From: clemc at ccc.com (Clem Cole) Date: Wed, 22 Feb 2017 18:51:24 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <20170222231320.GM9439@mcvoy.com> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <20170222213405.GJ9439@mcvoy.com> <20170222231320.GM9439@mcvoy.com> Message-ID: On Wed, Feb 22, 2017 at 6:13 PM, Larry McVoy wrote: > I just don't think they rewrote as much as they claimed > ​ ​ > they did, > ​​Maybe... > it was not a total rewrite, there was more than enough still > there that AT&T could have prevailed with a copyright case. > ​I agreed today and I certainly thought so at the time it all went down ( I was scared UNIX for the PC was going to disappear). But we all never know what would have happened if AT&T had only taken on copyright. Greed took over and AT&T tried to get everything. Their exec's make a choice and they did keep the goose, but they killed it too. Which brings us back to the original question Noel asked: W*hy Linux and not another UNIX flavor?* While I learned a great deal in the thread and I think I personally have a better understanding of why different people acted in different ways, the the answer is to me in unchanged and stays a simple two parts: 1. I think most if not all of us agree it was the WINTEL economics that made the PC/386 the HW platform "win", and 2. I truly believe that it was the the AT&T/BSDi legal entanglement that was the key item in Linux end up in the lead All of the other contributed things people talked about were good reasons for some specific choice by different folk, but the common driver behind it all / the real root of it was the court case. It did not matter which side you were on and who you thought was right/wrong, held the moral ground etc... if that case had not been there, I really don't think Linux would have gotten the momentum and had the ability to last. Others may not think so, but too me, that is sad, it was opportunity lost. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Thu Feb 23 10:10:46 2017 From: b4 at gewt.net (Cory Smelosky) Date: Wed, 22 Feb 2017 16:10:46 -0800 Subject: [TUHS] Any BSDi interest? In-Reply-To: References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com> Message-ID: <119FBD5F-1295-4C8D-8BC5-B11ECB54370F@gewt.net> So you want 1.1 and the 5 betas, right? :D Sent from my iPhone > On Feb 22, 2017, at 15:21, Dave Horsfall wrote: > >> On Sun, 19 Feb 2017, Cory Smelosky wrote: >> >> Is there any interest in this aside from me? ;) > > As a loyal BSD/OS fan (until WinDriver took them over and shut them down, > which is why I went to FreeBSD), I'm certainly interested... > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From gregg.drwho8 at gmail.com Thu Feb 23 14:53:37 2017 From: gregg.drwho8 at gmail.com (Gregg Levine) Date: Wed, 22 Feb 2017 23:53:37 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org> Message-ID: Hello! And as it happens, I downloaded a two disk job and found it ran on my first P100 system. I eventually tried others and much the same style as some you. I've been running Slackware since they packaged the 2.2.xx series. I still do. However I've got a Sun SPARC box here, who's happily running Solaris 10. ----- Gregg C Levine gregg.drwho8 at gmail.com "This signature fought the Time Wars, time and again." On Wed, Feb 22, 2017 at 6:29 PM, Clem Cole wrote: > Arno - thanks for more on this, as I think you scratched a difference > between your experience and my own. > > By the time Linux shows up in the early 1990s, people like me had been > developing UNIX for a long time and the novelty of hacking on the system, > making changes, bug fixes was gone. I just wanted to use it on a PC/386. > > BSD for the 386 worked and so Linux was a step backwards and I was only > going there because I felt I needed too. I remember when I first got > Slackware running, after the trying Linus's 0.9 mumble release.... and it > actually sort of ran ... saying "maybe this will work" but then I start > running it issues such as I could not back up it like my other systems, > network hosed up, few scripts "just worked", etc.. > > Yet, one of my coworkers who was about 2/3 years out of school at that > point, thought Linux was so cool because of all things Arno suggested. He > could submit bug reports and he changes go in. When I was b*tching about > something breaking, he would say - "Clem you know how to fix it And I > would reply "yup I do. But I don't want to." This was a the system I > wanted to use ( at home ). I get paid to hack at work. I wanted a > DOS/Windows alternative for home that I could rely on. I was not looking > for a yet another system to do development (I had that). > > Which shows that difference... I was part of Chet's club, so I was hacking > on UNIX already, and I did not need/want another system at home to hack just > to keep my day to day working at home (or my wife being able to print things > etc). The point was that I did not mind fixing the occasional thing I ran > into with BSD - but those problem were few and usually had to do with new > device bring up. But once something was was running, I could just use it. > But the Linux systems I could not do that - they were very fragile, so it > was not "fun" -- it was work. > > That was probably different for many of you. Linux was fun and cool, just > like UNIX had been for me 10-15 years earlier in the mid 1970s. > > Clem > From cym224 at gmail.com Fri Feb 24 01:31:04 2017 From: cym224 at gmail.com (Nemo) Date: Thu, 23 Feb 2017 10:31:04 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: <20170222041734.GP9439@mcvoy.com> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: On 21 February 2017 at 23:17, Larry McVoy wrote (in part): > On Tue, Feb 21, 2017 at 11:07:20PM -0500, Dan Cross wrote (in part): >> I can say from first-hand experience that it was NOT easy to get access to >> Unix source code there. > > My experience at UWisc-Madison, during the time they were working on > 4.3-Uwisc, matches Dan's pretty well. > > I don't think it was like what Clem says for most people. Clem went > to CMU if I remember correctly, that puts him in a pretty elite class > right there. I can easily imagine that the CMU CS department let all > their students have access to the source if they wanted it. I don't > think that was anywhere near as common as Clem thinks it was. Agreement here. I was a grad student at Toronto but in math, not CS. Outside CS were the hoi-poli. (But there was a lively MINIX community, especially in biomed.) N. From clemc at ccc.com Fri Feb 24 02:00:47 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Feb 2017 11:00:47 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: On Thu, Feb 23, 2017 at 10:31 AM, Nemo wrote: > I was a grad student at Toronto but in math, not C ​I hear you and accept that was your experience, but I do find that it is interesting, that one of the most infamous and notorious UNIX hackers of all time is Henry Spenser of the UT Zoology Dept - not Math, not CS or EE. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cym224 at gmail.com Fri Feb 24 02:50:51 2017 From: cym224 at gmail.com (Nemo) Date: Thu, 23 Feb 2017 11:50:51 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: On 23 February 2017 at 11:00, Clem Cole wrote: > > On Thu, Feb 23, 2017 at 10:31 AM, Nemo wrote: >> >> I was a grad student at Toronto but in math, not C > > > I hear you and accept that was your experience, but I do find that it is > interesting, that one of the most infamous and notorious UNIX hackers of > all time is Henry Spenser of the UT Zoology Dept - not Math, not CS or EE. Sure -- this is real irony (and a missed opportunity). I walked past Zoo almost daily ignorant of Henry's existence. (Had I known, I would have gladly stopped in to talk.) The point is that though we had Sun kit in the math dep't, we were not part of the UNIX "in crowd". N. From clemc at ccc.com Fri Feb 24 05:15:15 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Feb 2017 14:15:15 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> Message-ID: On Wed, Feb 22, 2017 at 6:51 PM, Paul Ruizendaal wrote: > I'm not a lawyer, but wasn't part of the background that prior to 1988 > in US law one could not claim both copyright and trade secret protection, > and that for something to be copyrighted it had to expressly claim to > be copyrighted material, and be registered as such? > ​Take this with what its worth (it came for free and I'm not a lawyer ....) Your comment got me thinking, why would try to change and can you. So I asked on our patent counsel this am to explain the difference. For context in the USA we have Patent, Trade Secret, Copyright Registration and Copyright Protection. Her reply to me was: Copyright *protection* is automatic – as soon as the code is written it is considered protected. Copyright *registration* is just a formality necessary to instigate litigation. There is no time limit for registration. Trade Secret is not compatible with copyright and patents (in a patent you have to disclose how to make and use the invention while a trade secret must be kept secret). You can get a patent while having the automatic copyright protection – remember that they protect two different things. A patent protects the “functionality” while a copyright protects what is written, word for word. So, you can get patent protection for what a software program does while having copyright protection for what is written. A patent is a stronger form of protection. ​ > because the legal folks thought that trade secret was a stronger > protection for software? > ​At the time, you could not get SW patents, and it is not clear you could have patented UNIX as a whole anyway.​ But that begs the secrecy issue. We know it had been disclosed as early as SOSP4. My engineering training and what we teach folks I work with is, secret is secret. Do not publish and no release, even under confidential NDA. My company, like government folks who I have worked with, have different classification for different documents. But "secret" means that. Which means we would not be allowed to give a talk about the technology, nor would be we able to call it "secret" if we had given a talk about it. > I also seem to recall that the AT&T code base included original material > from CSRG where the copyright notice had been removed by USL. > ​Yep - it's hard to live in a glass house.​ > > All in all, the USL lawyers probably felt that they would lose the case if > fought on the grounds of copyright violations alone. > ​Which I fear, we will never know.​ But to me, if they thought copyright was not strong enough, how could anyone think it was a "secret" when by the definition of the 1956 consent decree they had to tell people? > > I wish something like Groklaw had existed during the USL-UCB case: the > legal twists and turns would have been documented a lot better. > ​Indeed.... ​ > There is > ​ ​ > some material though, see: > http://www.groklaw.net/staticpages/index.php?page=legal-docs#bsdi > The amicus brief by the Regents, and the settlement make for interesting > ​ ​ > reading. > ​Right, I recommend all read it.​ > If the position taken by the Regents is correct, all of Unix > ​ ​ > up to and including 32V is in the public domain now. > ​That's been said before and I think between this precedent of this case, the code for the old UNIX versions, given the ancient system licenses, the formal publication of Lions book et al, I personally feel good about the legality of the code being available today. But everyone should ask their own lawyer and make their own decision definitively if they believe it or not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From random832 at fastmail.com Fri Feb 24 06:31:04 2017 From: random832 at fastmail.com (Random832) Date: Thu, 23 Feb 2017 15:31:04 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> Message-ID: <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com> On Thu, Feb 23, 2017, at 14:15, Clem Cole wrote: > On Wed, Feb 22, 2017 at 6:51 PM, Paul Ruizendaal wrote: > > > I'm not a lawyer, but wasn't part of the background that prior to 1988 > > in US law one could not claim both copyright and trade secret protection, > > and that for something to be copyrighted it had to expressly claim to > > be copyrighted material, and be registered as such? > > > ​Take this with what its worth (it came for free and I'm not a lawyer > ....) > Your comment got me thinking, why would try to change and can you. So I > asked on our patent counsel this am to explain the difference. For > context in the USA we have Patent, Trade Secret, Copyright Registration and > Copyright Protection. Her reply to me was: > > Copyright *protection* is automatic – as soon as the code is written it > is > considered protected. Copyright *registration* is just a formality > necessary to instigate litigation. There is no time limit for > registration. That's true today, but to my understanding wasn't true in 1988. (Well, registration wasn't a requirement to be copyrighted - that requirement went away retroactively in 1978, and only applied to unpublished works then.) The change seems to have been March 1, 1989 from what I can find. I think AT&T *tried* to construct a basis to claim that UNIX source code was "unpublished", even when distributed to source licensees (or e.g. shell scripts which were by necessity distributed to all licensees), possibly in service of this trade secret theory. Remember, the infamous comment on the otherwise empty SVR2 /bin/true had two lines of copyright notice and three lines of assertion that it was unpublished. And if that attempt involved removing all copyright notices from V6, V7, and 32V (and presumably not registering any copyright on any "unpublished" works pre-1978) then that might have killed any copyright-based case. By the time the actual lawsuit happened, they were fully committed to the trade secret theory. > Dennis Ritchie wrote: > > > > "Paul" wrote in message >> > > .... > >> ISTR there was a copyright notice in a Sys V /bin/true; explaining > >> why we thought this was funny might be a violation of that copyright! > > > > The local lawyers here also flip-flopped over the copyright issue. > > I can't recall whether it was because of law changes or reinterpretation > > or whether they just changed their minds. The issue partly had to do > > with the question of whether a copyright claim amounted to publication, > > while their primary protection theory had to do with trade secret > > protection, and its possible conflict with publication. > > > > At any rate, here is the whole contents of /bin/true in SVr2: > > > > # Copyright (c) 1984 AT&T > > # All Rights Reserved > > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T > > # The copyright notice above does not evidence any > > # actual or intended publication of such source code. > > > > #ident "@(#)true:true.sh 1.4" From dave at horsfall.org Fri Feb 24 08:02:35 2017 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 24 Feb 2017 09:02:35 +1100 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: On Thu, 23 Feb 2017, Clem Cole wrote: > I hear you and accept that was your experience, but I do find that it is > interesting, that one of the most  infamous and notorious UNIX hackers > of all time is Henry Spenser of the UT Zoology Dept - not Math, not CS > or EE. Spencer, not Spenser; I actually met him when he visited Australia, and he's about the most unassuming guy you will ever meet. His email address was something like *vax!utzoo!henry. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From schily at schily.net Fri Feb 24 08:48:08 2017 From: schily at schily.net (Joerg Schilling) Date: Thu, 23 Feb 2017 23:48:08 +0100 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com> Message-ID: <58af66a8.RixQ2R2YtVU32E8p%schily@schily.net> Random832 wrote: > On Thu, Feb 23, 2017, at 14:15, Clem Cole wrote: > > Copyright *protection* is automatic ??? as soon as the code is written it > > is > > considered protected. Copyright *registration* is just a formality > > necessary to instigate litigation. There is no time limit for > > registration. > > That's true today, but to my understanding wasn't true in 1988. (Well, > registration wasn't a requirement to be copyrighted - that requirement > went away retroactively in 1978, and only applied to unpublished works > then.) The change seems to have been March 1, 1989 from what I can find. >From what I have in mind, there have been changes from around 1992 from the Berne convention. Before, US code (even when it was copyrighted) was not protected in Europe. I know that in former times, code was only copyrighted in the USA in case a sample had been given to a governmental site. I thought this changed together with the Berne convention.... Given that the AT&T code that was used by BSD does not have a copyright notice, it seems to be obvious that it was not copyrighted as AT&T did not give a sample to the government. So the question was whether there was a copyright problem with the fact that BSD included the code. The fact that AT&T did give away their code did exhaust the right to prevent distribution. BSD on the other side did bundle the right to distribute with the condition that the license notice must not be removed and that distributors need to announce that they include software developed at BSD. AT&T removed this notice and did not announce the porevenance. This is why BSD finally won... Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From wes.parish at paradise.net.nz Fri Feb 24 09:06:12 2017 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Fri, 24 Feb 2017 12:06:12 +1300 (NZDT) Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com> Message-ID: <1487891172.58af6ae4822e8@www.paradise.net.nz> And given the Unix-based CS study and research going on world-wide at the time, AT&T versus the Regents of the University of California at Berkeley is an example of why you must maintain a careful separation of the arts of sticking your foot in your mouth and shooting yourself in the foot. Medical authorities warn against it, and who am I to dispute them? :) FWVLIW Wesley Parish Quoting Random832 : > On Thu, Feb 23, 2017, at 14:15, Clem Cole wrote: > > On Wed, Feb 22, 2017 at 6:51 PM, Paul Ruizendaal > wrote: > > > > > I'm not a lawyer, but wasn't part of the background that prior to > 1988 > > > in US law one could not claim both copyright and trade secret > protection, > > > and that for something to be copyrighted it had to expressly claim > to > > > be copyrighted material, and be registered as such? > > > > > ​Take this with what its worth (it came for free and I'm not a > lawyer > > ....) > Your comment got me thinking, why would try to change and can > you. So I > > asked on our patent counsel this am to explain the difference. For > > context in the USA we have Patent, Trade Secret, Copyright > Registration and > > Copyright Protection. Her reply to me was: > > > > Copyright *protection* is automatic – as soon as the code is written > it > > is > > considered protected. Copyright *registration* is just a formality > > necessary to instigate litigation. There is no time limit for > > registration. > > That's true today, but to my understanding wasn't true in 1988. (Well, > registration wasn't a requirement to be copyrighted - that requirement > went away retroactively in 1978, and only applied to unpublished works > then.) The change seems to have been March 1, 1989 from what I can > find. > > I think AT&T *tried* to construct a basis to claim that UNIX source > code > was "unpublished", even when distributed to source licensees (or e.g. > shell scripts which were by necessity distributed to all licensees), > possibly in service of this trade secret theory. Remember, the infamous > comment on the otherwise empty SVR2 /bin/true had two lines of > copyright > notice and three lines of assertion that it was unpublished. > > And if that attempt involved removing all copyright notices from V6, > V7, > and 32V (and presumably not registering any copyright on any > "unpublished" works pre-1978) then that might have killed any > copyright-based case. By the time the actual lawsuit happened, they > were > fully committed to the trade secret theory. > > > > Dennis Ritchie wrote: > > > > > > "Paul" wrote in message >> > > > .... > > >> ISTR there was a copyright notice in a Sys V /bin/true; explaining > > >> why we thought this was funny might be a violation of that > copyright! > > > > > > The local lawyers here also flip-flopped over the copyright issue. > > > I can't recall whether it was because of law changes or > reinterpretation > > > or whether they just changed their minds. The issue partly had to > do > > > with the question of whether a copyright claim amounted to > publication, > > > while their primary protection theory had to do with trade secret > > > protection, and its possible conflict with publication. > > > > > > At any rate, here is the whole contents of /bin/true in SVr2: > > > > > > # Copyright (c) 1984 AT&T > > > # All Rights Reserved > > > > > > # THIS IS UNPUBLISHED PROPRIETARY SOURCE CODE OF AT&T > > > # The copyright notice above does not evidence any > > > # actual or intended publication of such source code. > > > > > > #ident "@(#)true:true.sh 1.4" > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn From krewat at kilonet.net Fri Feb 24 09:48:55 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Thu, 23 Feb 2017 18:48:55 -0500 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: <1029512c-b1c6-9cf8-f66d-8852164dc610@kilonet.net> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> <1029512c-b1c6-9cf8-f66d-8852164dc610@kilonet.net> Message-ID: <55eca846-4c97-8bca-ec81-f5499d796ea7@kilonet.net> I've never received an answer to this, and I wonder if it was because it was sent another route and got choked as SPAM after the mailing list (I received it from the mailing list). On 2/22/2017 8:33 AM, Arthur Krewat wrote: > So what's the consensus at this point? Open source? Already released? > > I can't vouch that this wasn't some under-the-table exchange. It was > for an "educational" institution but did not necessarily wind up > there. Hence why I want to compare with similar releases if it exists. > > The sources all have copyright dates ranging from 1983 to 1985 for > Sun-generated bits that looks like this: > > static char sccsid[] = "@(#)domainname.c 1.1 85/05/30 Copyr 1984 Sun > Micro"; > > And sccsid's like this for sources taken from BSD and altered to fit: > > df.c:static char sccsid[] = "@(#)df.c 1.1 85/05/30 SMI"; /* from > UCB 4.18 84/02/02 */ > > Sorry for fracturing this thread already. > > > On 2/21/2017 8:46 PM, Clem Cole wrote: >> >> On Tue, Feb 21, 2017 at 8:35 PM, Arthur Krewat > > wrote: >> >> Anyone interested in this source code? I did a quick Google >> search and couldn't find anything relevant. If it's out there >> somewhere, let me know, I'd like to take a look at it. >> >> It's Network File System Sun Microsystems Release 2.0 >> >> Since, the core of Solaris was made FOSS, I would hope there is(are) >> persons at Oracle/Sun that can officially stamp the technology has >> only historical value. >> >> Anyone know whom that should be so it can make it from the dark side. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Feb 24 11:01:57 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 24 Feb 2017 09:01:57 +0800 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: And thanks to Henry we have those Usenet tapes! It's amazing that a decade of Usenet is about 7GB. On February 24, 2017 12:00:47 AM GMT+08:00, Clem Cole wrote: > > >On Thu, Feb 23, 2017 at 10:31 AM, Nemo < cym224 at gmail.com > > wrote: > > >I was a grad student at Toronto but in math, not C > > >​I hear you and accept that was your experience, but I do find that it >is interesting, that one of the most infamous and notorious UNIX >hackers of all time is Henry Spenser of the UT Zoology Dept - not Math, >not CS or EE. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clemc at ccc.com Fri Feb 24 11:30:22 2017 From: clemc at ccc.com (Clem Cole) Date: Thu, 23 Feb 2017 20:30:22 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: On Thu, Feb 23, 2017 at 5:02 PM, Dave Horsfall wrote: > Spencer, not Spenser; > ​sorry and yes that is correct - dyslexia-r-me -- I'll often not notice the error. until you point it out. > I actually met him when he visited Australia, and > he's about the most unassuming guy you will ever meet. > ​Indeed - ​I've know him for years. He's an old USENIX type (like me). Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Feb 24 12:07:13 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Fri, 24 Feb 2017 10:07:13 +0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: <58af66a8.RixQ2R2YtVU32E8p%schily@schily.net> References: <20170222161114.GT9439@mcvoy.com> <20170222182440.GE9439@mcvoy.com> <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl> <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com> <58af66a8.RixQ2R2YtVU32E8p%schily@schily.net> Message-ID: Isn't the lack of notices and wide distribution which also lead VM/370 and friends being in the public domain? It's odd now that history is fluid they are now considered open source? On February 24, 2017 6:48:08 AM GMT+08:00, Joerg Schilling wrote: >Random832 wrote: > >> On Thu, Feb 23, 2017, at 14:15, Clem Cole wrote: >> > Copyright *protection* is automatic ??? as soon as the code is >written it >> > is >> > considered protected. Copyright *registration* is just a formality >> > necessary to instigate litigation. There is no time limit for >> > registration. >> >> That's true today, but to my understanding wasn't true in 1988. >(Well, >> registration wasn't a requirement to be copyrighted - that >requirement >> went away retroactively in 1978, and only applied to unpublished >works >> then.) The change seems to have been March 1, 1989 from what I can >find. > >From what I have in mind, there have been changes from around 1992 from >the >Berne convention. Before, US code (even when it was copyrighted) was >not >protected in Europe. > >I know that in former times, code was only copyrighted in the USA in >case a >sample had been given to a governmental site. I thought this changed >together >with the Berne convention.... > >Given that the AT&T code that was used by BSD does not have a copyright >notice, >it seems to be obvious that it was not copyrighted as AT&T did not give >a >sample to the government. > >So the question was whether there was a copyright problem with the fact >that >BSD included the code. The fact that AT&T did give away their code did >exhaust >the right to prevent distribution. > >BSD on the other side did bundle the right to distribute with the >condition >that the license notice must not be removed and that distributors need >to >announce that they include software developed at BSD. > >AT&T removed this notice and did not announce the porevenance. > >This is why BSD finally won... > >Jörg > >-- >EMail:joerg at schily.net (home) Jörg Schilling D-13353 >Berlin >joerg.schilling at fokus.fraunhofer.de (work) Blog: >http://schily.blogspot.com/ >URL: http://cdrecord.org/private/ >http://sourceforge.net/projects/schilytools/files/ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Feb 24 13:33:54 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Fri, 24 Feb 2017 11:33:54 +0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! Message-ID: <7ef5abf3-8e66-4755-b7ee-c8ddf13f3bf6@SG2APC01FT029.eop-APC01.prod.protection.outlook.com> It’s embarrassing to mention this, but I thought I’d share. I’ve always wondered what on earth a TAHOE was, as they disappeared just about as quickly as they came out. As we all know that they were instrumental from separating out the VAX code from 4.3BSD in the official CSRG source. I was looking through old usenet stuff when I typed in something wrong, and came across people looking for GCC for the Tahoe running BSD. (http://altavista.superglobalmegacorp.com/usenet/b128/comp/sys/tahoe/79.txt) In article <2287 at trantor.harris-atd.com>, bbadger at x102c (Badger BA 64810) writes: `We have a Harris HCX-9 computer, also known as a Tahoe, and we'd like to `get gcc and g++ up and running. I haven't seen anything refering to `the HCX or any Tahoe machines in the gcc distribution. Anyone have it? `Working on it? Pointers to who might? Know if Berkely cc/ld/asm is PD? Turns out they were using Harris mini’s called the HCX-9. That’s when I went back to the source and saw this: # # GENERIC POWER 6/32 (HCX9) # machine tahoe cpu "TAHOE" ident GENERIC So if anyone else is wondering what was a Tahoe, did it exist, was there actual sales, is their pictures of it, etc, the answer is yes, it was a real machine, yes it was sold, and there are even print ads in Computer world. I thought it was interesting though. Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Fri Feb 24 13:38:13 2017 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 24 Feb 2017 13:38:13 +1000 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <7ef5abf3-8e66-4755-b7ee-c8ddf13f3bf6@SG2APC01FT029.eop-APC01.prod.protection.outlook.com> References: <7ef5abf3-8e66-4755-b7ee-c8ddf13f3bf6@SG2APC01FT029.eop-APC01.prod.protection.outlook.com> Message-ID: <20170224033813.GA11542@minnie.tuhs.org> On Fri, Feb 24, 2017 at 11:33:54AM +0800, jsteve at superglobalmegacorp.com wrote: > I’ve always wondered what on earth a TAHOE was, as they disappeared > just about as quickly as they came out. As we all know that they were > instrumental from separating out the VAX code from 4.3BSD in the > official CSRG source. I was looking through old usenet stuff when I > typed in something wrong, and came across people looking for GCC for > the Tahoe running BSD. > ([1]http://altavista.superglobalmegacorp.com/usenet/b128/comp/sys/tahoe > /79.txt) I've exploded the Unix-related parts of the Usenet archive from UTZoo, so you can look here for more Tahoe postings: http://www.tuhs.org/Usenet/comp.sys.tahoe/ Cheers, Warren P.S Also http://www.tuhs.org/Usenet -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jsteve at superglobalmegacorp.com Fri Feb 24 13:51:07 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Fri, 24 Feb 2017 11:51:07 +0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <20170224033813.GA11542@minnie.tuhs.org> References: <20170224033813.GA11542@minnie.tuhs.org> Message-ID: I went one further, and loaded the old AltaVista desktop search tool, extracted all the usenet, added .txt extensions to make Windows happy, and converted them to something IIS can deal with, then setup Apache to de-mangle the pages, and a stunnel connection from Apache to the AltaVista desktop search as it only listens on 127.0.0.1:9988 .. So the upshot is that you can search the usenet archive via AltaVista http://altavista.superglobalmegacorp.com I know there is a million ‘modern’ ways to do this, but I had though this was cooler. From: Warren Toomey Sent: Saturday, 25 February 2017 11:53 AM To: jsteve at superglobalmegacorp.com Cc: tuhs at minnie.tuhs.org Subject: Re: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! On Fri, Feb 24, 2017 at 11:33:54AM +0800, jsteve at superglobalmegacorp.com wrote: > I’ve always wondered what on earth a TAHOE was, as they disappeared > just about as quickly as they came out. As we all know that they were > instrumental from separating out the VAX code from 4.3BSD in the > official CSRG source. I was looking through old usenet stuff when I > typed in something wrong, and came across people looking for GCC for > the Tahoe running BSD. > ([1]http://altavista.superglobalmegacorp.com/usenet/b128/comp/sys/tahoe > /79.txt) I've exploded the Unix-related parts of the Usenet archive from UTZoo, so you can look here for more Tahoe postings: http://www.tuhs.org/Usenet/comp.sys.tahoe/ Cheers, Warren P.S Also http://www.tuhs.org/Usenet -------------- next part -------------- An HTML attachment was scrubbed... URL: From crossd at gmail.com Fri Feb 24 13:53:48 2017 From: crossd at gmail.com (Dan Cross) Date: Thu, 23 Feb 2017 22:53:48 -0500 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: [Apologies in advance for this enormous wall of text] On Wed, Feb 22, 2017 at 10:36 AM, Clem Cole wrote: > Dan & Larry thank you -- this helps me understand and I'm going reply you > both in line hopefully without screwing up either of your messages as I > try... > > On Tue, Feb 21, 2017 at 11:28 PM, Dan Cross wrote: > >> >> The universities you are mentioning here are top-tier for CS. But please >> do bear in mind that if you were not at one of those institutions (for >> whatever reason), asking for that code might well have gotten you the hairy >> eyeball from folks you didn't want giving you a furry look. >> > ​Unfortunately, I can see that. Sad, but probably a reality.​ Again, > "he who has the gold, rules." Funny thing about gatekeepers. Larry's > closing comment about Bill Shannon walling off the Research kernels was the > same thing, and IT folks often seem to be like that too. My wife likes > referred this behavior just this AM at breakfast, she calls "can't" a > "magic button word" for me. I hate it when providers say things like > that. Pisses me off and something go off to prove otherwise. ;-) > Well, for what it's worth, I think that all parties were acting in good faith. Sure, there was a little bit of a "ooo and ahh" factor to have root access or access to source code on what were, at the time, expensive machines, and that lead to something of a "cabal" forming that felt like they needed to protect such things. Still, I think the bulk of the hesitation had its roots in three things: 1) Protecting university resources. Hardware often came from research grants, and the bulk of the school's research wasn't in CS. The MechE or EE departments, for example, didn't really want Unix hackers using machines that had been obtained through a grant to study beam stresses or molecular properties of semiconductor materials. Could you imagine some poor grad student 16 hours into an 18 hour simulation run when his/her professor's workstation rebooted because some joker thought he had a better terminal driver or something goofy like that that just absolutely had to go into the kernel right then? (I mention that example specifically because Ken Arnold has a great vignette on his web site about hacking the TTY driver at UCB.) Similarly, access to wide area networks was mainly to support research, not give budding CS weenies FTP access. I mean, I kind of get this: being irresponsible with a grant could get you in trouble with the funding agency; similarly, starving out bandwidth for your researchers so that they had trouble communicating with their collaborators at other institutions or with their sponsors would give the administration headaches as they got an earful from a large community of angry professors and grad students. And at the time, for geographical reasons, getting more bandwidth to State College would have been painful. Example: I found a discarded VAX 750 in a room in the physics department one day; someone had put 4.3BSD on it. I fired it up and a physicist nearly had a heart attack, "You mean that thing is running?! OMG; shut it off before someone sees you!" I'm pretty sure they were thinking that this was not exactly in line with the department's core academic mission. 2) Protecting the university from litigation. Let's be frank: students (and, uh, young townies who hang around too) could be careless and don't always exercise the best judgement (*cough* not that I would be talking about myself or anything *cough*). I could imagine that sys admins who were not lawyers might be paranoid that they could endanger their jobs and their ability to support themselves and their families by opening the university to some legal danger by giving someone access to something they shouldn't have access to (e.g., Unix source code). If I thought my job was at stack, I'd be hesitant too. 3) Protecting themselves from being overburdened supporting someone in waaaay over his/her head. I managed to wrangle a tape of the SPARC port of 4.4BSD (encumbered) out of someone and get it installed on a SPARCstation; I was a high school senior. I had to promise to a) not give it to anyone else, and b) leave the person who gave me the tape the hell alone when it didn't work (though it did). In other words, he'd give me an 8mm exabyte tape if I never mentioned it to him ever again, but only because I knew him. I thought that was a fair deal. There also just wasn't that much of a Unix hacker culture there. There were a few folks who were exceptionally good, but they'd graduate or otherwise migrate away. And by the time I came on the scene, we were in that odd phase where the most advanced systems were commercial and vendor supplied. I remember suggesting that we put BSD on a bunch of the Suns in one of the labs, and getting shot down because it wouldn't be supported by Sun. I found that odd since only a decade before the same group of people didn't seem to bat an eye at getting a tape of 4.2 or 4.3 from Berkeley and putting that on a VAX that cost something like 10-20 times what a SPARCstation cost and running the whole department off of that. For myself, early on, I may have encountered resistance more because I wasn't actually a student (though I was nominally "staff" in the sense of being a university employee, albeit minimum wage...hey, for a high schooler, it sure beat what my buddies who were washing dishes or flipping burgers were doing to earn gas money). I ended up going elsewhere for college and majoring in math instead of CS, but by then it was clear that Linux had won and it wasn't an issue anymore anyway. I was running Plan 9 at the time, though. [snip] >> > As someone once said, BSD is what you get when Unix folks port to the PC; >> Linux is what you get when PC folks build a Unix. >> > I love it, never heard that and in fact that helps with Noel's original > question, I think. It all comes back to the Christiansen disruption > theory. > I think the disruption was also cultural and not just technical. One of the most maddening things to me about the Linux community is that they don't seem to listen to other folks or critically examine prior art. I know that's a massive generalization and it's obviously not true in all cases, but I think it's fair to a first order approximation that they often "go with their gut." I think at least part of that is because, when Linux was getting started, the existing Unix community was somewhat haughty and aloof and sort of looked down on it as a toy that would never go anywhere. As a result, I sort of feel like they've got something of a chip on their shoulder about other ways of doing things; the prevailing attitude seems to be one of, "well, it's right because that's how we do it." Epoll is a great example of this; it has all sorts of strange structural problems that didn't exist in BSD's kqueue, but adopting kqueue was unpopular. Perhaps that stems from being told too many times that what they wanted to do was alternately impossible and stupid. They've proven the "other side" (for whatever that means) wrong enough times that when they're told there could be another way it's immediately dismissed. And while skepticism in general is probably good (the 'S' in 'CS' is for 'Science', after all, and a healthy dose of skepticism is important to look at something scientifically...), I feel that the pendulum has swung so far it's now just incredulity that someone would dare contradict the way Linux does something. ​... >> A self-deprecating anecdote. >> > ​I had to laugh a little when I read all that. I'm going to reply to > something Larry said in a minute and this all related. Yeah, Larry's > right, places like CMU, MIT, UCB are elite schools and yes, I have too > solid board scores *etc*. As I like to say I have "the usual degrees > from the usual institutions" - *i.e*. I have my union card. But I'm > nothing special. You're from Penn State or UWisc (aka "UC Madison" - a > lot of my class from UCB is the core of the faculty there). Hey, I > believe Seymour Cray did his undergrad at St. Olaf's, a school better know > for music - i.e. a small liberal arts school in Northfield, MN. > > I've never really cared where you went to school, what your score were, > what your degrees are etc. I'm a hacker, and proud of being that. The > schools, as you and Larry correctly point out, gave me opportunity and > access. So I have network from them. But its what you do with it that > matters to me. > > Two stories about me. First, I have always said, the greatest gift I was > ever given was *not* getting a scholarship to MIT. I would have gone > there and likely been "The nerd down the hall" - either that or flunked > out. Who knows, as I later got to know folks that went there, it would not > have been a good match for me as an undergrad. CMU (as screwed up as it > was at time) was a better match for my personality. > > The fact is, I did not know know enough about the MIT culture when I was > in HS (I was a faculty brat - *i.e.* scholarship student -- from a > Philadelphia prep school - my Sr year in college 7 of the 7 Ivy League > Squash Captains are my classmates from said prep school). That HS pushed > me to MIT because I wanted to an engineer and that's all they knew. I did > not even know about CMU until it was suggested by a family friend who was > professor in the B School there. But in the end, it was about $. CMU > offered me a scholarship, MIT did not and tricky Dick wanted to put a gun > in hand. It was an easy choice. What was lucky for me was it a > reasonably good culture match... mostly because of the close friends I > made there ... out side of the EE, Math and CS Depts (two weekend ago I > was a party with some of them that has occurred for 40 years on the same > weekend since). Point is, I got lucky... > > Second, the proudest moment for me was watching my children pick > colleges. Unlike me, I swore they would know about the culture of the > schools and make darned sure that where they went matched their > personalities and not rely on luck (and I'm very pleased to say that worked > well with my daughter and seems to be working with my son). So to me, what > the school you one too says about you is the network you have, who are your > friends and the culture you learned. It tells me a little about how I can > expect you to have been versed as a starting point, but I'm really much > more interest want you do, have done. > Great stories. I understand where you are coming from. The culture thing is critical; that's why I decided not to go to Penn State; having lived in the town I knew it wasn't a great fit for me. Also, to be frank, I wasn't really ready to go immediately after HS. A couple of startups, a stint in the Marines and experiencing M.O.Rabin teach cryptography at Columbia (he was on sabbatical from Harvard) eventually got me walking in the right direction though. :-) It's sad, that Penn State and UWisc had walled areas like both described. Sadly > I saw the same thing at UCB, certainly of the undergrads. I have nothing > but respect for the young folks that did an undergrad at UCB, because it > was definitely different as a grad student. > To be fair, I think a lot of it was that those schools have a different focus. The educational focus is on grad students and the academic focus is primarily on research. I don't think that's bad, but the educational mission towards undergrads is just different: the state schools do an excellent job of taking in-state kids from farms and formerly-factory towns and giving them a solid education. A colleague in my office now dropped out of a math PhD program $n$ years in ABD and made a fascinating remark to me once; he asserted that the way to REALLY learn math was over coffee with a professor or with fellow grad students, not sitting in a classroom or studying texts or the literature. I remembered that from my own perspective, some of the most eye opening experiences accompanied by the largest number of "Aha!" moments *I* had were sitting in the common room chatting with my advisor about various math topics, or taking something simple I'd done to a professor and asking for commentary. But certainly not sitting in the lecture hall in Mathematics building furiously transcribing what the learned professor had written on the board into my notebook. Well, when you've got a huge undergrad population logistically that's just not feasible for everyone. To me that's about respect for the individual and helping them grown up > to be their best - creating opportunity. But I fear you are right. If > things like UNIX access were walled off at places like that, then as you > both point out, people we search for it where they could find it, *what > is sad is that BSD UNIX was available at the time Linux was available. *The > problem was that too few knew it, although many did (more in a minute). > Yup. It really feels like a lost opportunity. [snip] > I think your counter point is that while I believe folks like yourselves > or Linus could have gotten BSD UNIX if you had tried to find it it was > available and folks like Keith and Bill were trying to get it out the door, > but have suggest that you don't think so. You think the walls were too > high, the access was only for the "chosen few" and a difference was the > Linux really was available to what Larry referred to as the great unwashed. > The unwashed masses comment is apropos. A few places I've read papers advocating that one should look at Unix the way one would go about literary criticism; in this sense, Linux feels more like a populist reaction to Unix than a linear continuation of the same school of thought. Indeed, comparisons to the arts abound in our community. Indeed, Stu Feldman wrote a neat metaphorical paper comparing the history of Unix to the history of western architecture ( https://books.google.com/books?id=5xyk_PXaloAC&lpg=PA8&ots=cZQ3TYbp71&dq=stuart%20feldman%20architectural%20history&pg=PA8#v=onepage&q&f=false ). - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkt at tuhs.org Fri Feb 24 14:21:36 2017 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 24 Feb 2017 14:21:36 +1000 Subject: [TUHS] A Couple of Early Networking Unix System Message-ID: <20170224042136.GA18159@minnie.tuhs.org> All, thanks to the hard effort of Noel Chiappa and Paul Ruizendaal, we now have a couple of early Unix systems with networking modifications. They can be found in: http://www.tuhs.org/Archive/Distributions/Early_Networking/ I'll get them added to the Unix Tree soon. Cheers, Warren -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From fair-tuhs at netbsd.org Fri Feb 24 14:23:09 2017 From: fair-tuhs at netbsd.org (Erik E. Fair) Date: Thu, 23 Feb 2017 20:23:09 -0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <7ef5abf3-8e66-4755-b7ee-c8ddf13f3bf6@SG2APC01FT029.eop-APC01.prod.protection.outlook.com> Message-ID: <28418.1487910189@cesium.clock.org> Aside from being the name of the very large lake I live near, the "Tahoe" was a system from Computer Consoles, Inc. (CCI): https://en.wikipedia.org/wiki/Computer_Consoles_Inc. Erik From b4 at gewt.net Fri Feb 24 14:27:10 2017 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 23 Feb 2017 20:27:10 -0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <28418.1487910189@cesium.clock.org> References: <28418.1487910189@cesium.clock.org> Message-ID: <1487910430.2910579.891270784.53290BC0@webmail.messagingengine.com> On Thu, Feb 23, 2017, at 20:23, Erik E. Fair wrote: > Aside from being the name of the very large lake I live near, the > "Tahoe" was a system from Computer Consoles, Inc. (CCI): > > https://en.wikipedia.org/wiki/Computer_Consoles_Inc. > > Erik Have you ever seen a picture of one, though? ;) I found a picture of the Harris system once...tried to track down who owns the IP, too. It got really confusing when it split between Nortel and someone else... -- Cory Smelosky b4 at gewt.net From jsteve at superglobalmegacorp.com Fri Feb 24 14:33:41 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Fri, 24 Feb 2017 12:33:41 +0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <28418.1487910189@cesium.clock.org> References: <7ef5abf3-8e66-4755-b7ee-c8ddf13f3bf6@SG2APC01FT029.eop-APC01.prod.protection.outlook.com> <28418.1487910189@cesium.clock.org> Message-ID: <39084dea-1f9c-4c95-95b2-4c2abd56db88@SG2APC01FT056.eop-APC01.prod.protection.outlook.com> It was mostly a processor set. It was resold by Harris, Unisys and CCI. The Harris HCX-9 is the interesting one though. Sent from Mail for Windows 10 From: Erik E. Fair Sent: Saturday, 25 February 2017 12:38 PM To: jsteve at superglobalmegacorp.com Cc: tuhs at minnie.tuhs.org Subject: Re: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! Aside from being the name of the very large lake I live near, the "Tahoe" was a system from Computer Consoles, Inc. (CCI): https://en.wikipedia.org/wiki/Computer_Consoles_Inc. Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Fri Feb 24 14:35:19 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Fri, 24 Feb 2017 12:35:19 +0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <1487910430.2910579.891270784.53290BC0@webmail.messagingengine.com> References: <28418.1487910189@cesium.clock.org> <1487910430.2910579.891270784.53290BC0@webmail.messagingengine.com> Message-ID: As a matter of fact, I’ve found 2 images…. https://virtuallyfun.superglobalmegacorp.com/wordpress/wp-content/uploads/2017/02/Harris-HCX-9-print-ad.jpg https://virtuallyfun.superglobalmegacorp.com/wordpress/wp-content/uploads/2017/02/Oracle-worker.png Something tells me this was neither light, nor was it quite. Sent from Mail for Windows 10 From: Cory Smelosky Sent: Saturday, 25 February 2017 12:42 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! On Thu, Feb 23, 2017, at 20:23, Erik E. Fair wrote: > Aside from being the name of the very large lake I live near, the > "Tahoe" was a system from Computer Consoles, Inc. (CCI): > > https://en.wikipedia.org/wiki/Computer_Consoles_Inc. > > Erik Have you ever seen a picture of one, though? ;) I found a picture of the Harris system once...tried to track down who owns the IP, too. It got really confusing when it split between Nortel and someone else... -- Cory Smelosky b4 at gewt.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Fri Feb 24 14:35:30 2017 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 23 Feb 2017 20:35:30 -0800 Subject: [TUHS] A Couple of Early Networking Unix System In-Reply-To: <20170224042136.GA18159@minnie.tuhs.org> References: <20170224042136.GA18159@minnie.tuhs.org> Message-ID: <1487910930.2912602.891274064.7F77CC93@webmail.messagingengine.com> On Thu, Feb 23, 2017, at 20:21, Warren Toomey wrote: > All, thanks to the hard effort of Noel Chiappa and Paul Ruizendaal, > we now have a couple of early Unix systems with networking modifications. > They can be found in: > > http://www.tuhs.org/Archive/Distributions/Early_Networking/ > > I'll get them added to the Unix Tree soon. > > Cheers, Warren > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) Hmmm. Now SIMH's PDP-11 emu needs to talk to the IMP simulation ;) -- Cory Smelosky b4 at gewt.net From b4 at gewt.net Fri Feb 24 14:36:35 2017 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 23 Feb 2017 20:36:35 -0800 Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: References: <28418.1487910189@cesium.clock.org> <1487910430.2910579.891270784.53290BC0@webmail.messagingengine.com> Message-ID: <1487910995.2913217.891274672.3DB06712@webmail.messagingengine.com> On Thu, Feb 23, 2017, at 20:35, jsteve at superglobalmegacorp.com wrote: > As a matter of fact, I’ve found 2 images…. > > https://virtuallyfun.superglobalmegacorp.com/wordpress/wp-content/uploads/2017/02/Harris-HCX-9-print-ad.jpg > > https://virtuallyfun.superglobalmegacorp.com/wordpress/wp-content/uploads/2017/02/Oracle-worker.png > > Something tells me this was neither light, nor was it quite. > > Sent from Mail[1] for Windows 10 > > *From: *Cory Smelosky[2] *Sent: *Saturday, 25 February 2017 12:42 PM > *To: *tuhs at minnie.tuhs.org *Subject: *Re: [TUHS] 4.3BSD TAHOE aka what > is a TAHOE?! > > > > On Thu, Feb 23, 2017, at 20:23, Erik E. Fair wrote: > > Aside from being the name of the very large lake I live near, the > > "Tahoe" was a system from Computer Consoles, Inc. (CCI): > > > > https://en.wikipedia.org/wiki/Computer_Consoles_Inc. > > > > Erik > > Have you ever seen a picture of one, though? ;) > > I found a picture of the Harris system once...tried to track down who > owns the IP, too. > > It got really confusing when it split between Nortel and > someone else... > -- > Cory Smelosky > b4 at gewt.net > Has anyone tried contacting Harris for more info? :D -- Cory Smelosky b4 at gewt.net Links: 1. https://go.microsoft.com/fwlink/?LinkId=550986 2. mailto:b4 at gewt.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnl at johnlabovitz.com Fri Feb 24 15:31:56 2017 From: johnl at johnlabovitz.com (John Labovitz) Date: Thu, 23 Feb 2017 21:31:56 -0800 Subject: [TUHS] Why Linux not another PC/UNIX [was Mach for i386 ...] In-Reply-To: References: Message-ID: > On Feb 21, 2017, at 9:56 PM, Steve Nickolas wrote: > > On Tue, 21 Feb 2017, Clem Cole wrote: > >> See my comment to Dan. I fear you may not have known where to look, or whom >> to ask.​ As I asked Dan, were you not at an university at time? Or where >> you running a Sun or the like -- i.e. working with real UNIX but working >> for someone with binary license, not sources from AT&T (and UCB)? > > No, and no. I was in high school, actually, and I only attended college - a local 2-year school - for one semester before dropping out because I couldn't handle it. Apologies for the late response, but just wanted to chime in to say that I, too, was in a position similar to Steve’s. As a teenager around 1982, I’d been fortunate enough to sneak my way onto the ARPAnet (via a DOD TAC dialup in DC), and had wrangled accounts on MIT-CCC (a V6 machine) and Brookhaven National Lab (V7 on an 11/44). I believe both machines had source (CCC definitely did), and I enjoyed perusing the code. Instead of going to college, I moved west to the Bay Area, and no longer had local dialup access to the ARPAnet (not to mention Unix source code), so moved over to UUCP. I ported the UUCP/NNTP code to Mac OS (classic, not OS X) using the Lightspeed C compiler, splurged on a Telebit Trailblazer, and somehow convinced some very kind person at MIPS to call my modem in Sonoma County once an hour. For a time, I think I had the only Mac-based UUCP node — sly.graton.ca.us. I still regret not releasing my port. At some point there in the late eighties, I had the bright idea to start a small Unix ISP, and bought (with too many $$$) what I recall was an ESIX system, on a big 386 tower. I remember SVR4 (?) feeling pretty corporate and sterile, and there definitely was no source. I can’t remember why I couldn’t/didn’t buy a BSDi system — maybe too expensive? Spent too much time writing code, not enough time actually getting the ISP up, but the experience was educational. A few years hence, I worked for O’Reilly & Associates (also in Sonoma County) on Global Network Navigator, the first commercial web publication. We had a few Sun workstations, but mostly these clunky monochrome X terminals. So the idea of Linux — a downloadable, hackable, personal, fun, almost punk-rock Unix, easily installable on a fairly generic 386 machine (once I downloaded the fifty-odd diskette images) was pretty damned appealing. And because my previous experience had been mostly V6 and V7 (with only a smattering of BSD), the supposed difference between Linux and “real Unix" felt quite minimal to me. —John From wkt at tuhs.org Fri Feb 24 16:37:44 2017 From: wkt at tuhs.org (Warren Toomey) Date: Fri, 24 Feb 2017 16:37:44 +1000 Subject: [TUHS] Put a copy of the TUHS mail archive into the Unix Archive? Message-ID: <20170224063744.GB2239@minnie.tuhs.org> Is it worth putting a copy of this mailing list into the Unix Archive? I don't want to dump the mbox in, as it has all our e-mail addresses: spam etc. I could symlink in the monthly text archives, e.g. http://minnie.tuhs.org/pipermail/tuhs/2016-December.txt.gz What do you think? Perhaps in Documentation/TUHS_Mail? Warren -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From lars at nocrew.org Fri Feb 24 17:27:36 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Fri, 24 Feb 2017 08:27:36 +0100 Subject: [TUHS] A Couple of Early Networking Unix System In-Reply-To: <1487910930.2912602.891274064.7F77CC93@webmail.messagingengine.com> (Cory Smelosky's message of "Thu, 23 Feb 2017 20:35:30 -0800") References: <20170224042136.GA18159@minnie.tuhs.org> <1487910930.2912602.891274064.7F77CC93@webmail.messagingengine.com> Message-ID: <86a89cujyv.fsf@molnjunk.nocrew.org> Cory Smelosky writes: > Hmmm. Now SIMH's PDP-11 emu needs to talk to the IMP simulation ;) Yes, please do add some kind of IMP to SIMH! (Off topic, don't read this: I want it for the PDP-10 running ITS, as any kind of networking option is sourly missing.) From b4 at gewt.net Fri Feb 24 17:28:49 2017 From: b4 at gewt.net (Cory Smelosky) Date: Thu, 23 Feb 2017 23:28:49 -0800 Subject: [TUHS] A Couple of Early Networking Unix System In-Reply-To: <86a89cujyv.fsf@molnjunk.nocrew.org> References: <20170224042136.GA18159@minnie.tuhs.org> <1487910930.2912602.891274064.7F77CC93@webmail.messagingengine.com> <86a89cujyv.fsf@molnjunk.nocrew.org> Message-ID: <3F8D3432-3F07-4C86-AB37-C40B4F5C13C1@gewt.net> I want it for: 1). VAX 2). pdp11 3). pdp10 4). Incomplete sigma simulator ;) Sent from my iPhone > On Feb 23, 2017, at 23:27, Lars Brinkhoff wrote: > > Cory Smelosky writes: >> Hmmm. Now SIMH's PDP-11 emu needs to talk to the IMP simulation ;) > > Yes, please do add some kind of IMP to SIMH! (Off topic, don't read > this: I want it for the PDP-10 running ITS, as any kind of networking > option is sourly missing.) From arnold at skeeve.com Fri Feb 24 17:47:43 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Fri, 24 Feb 2017 00:47:43 -0700 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: <55eca846-4c97-8bca-ec81-f5499d796ea7@kilonet.net> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> <1029512c-b1c6-9cf8-f66d-8852164dc610@kilonet.net> <55eca846-4c97-8bca-ec81-f5499d796ea7@kilonet.net> Message-ID: <201702240747.v1O7lhVM012173@freefriends.org> It got to the list. I think you didn't get an answer because noone here knows what to tell you. I suggest working off-list with Warren to get him the code and help him try to figure out if he can publish it. Arnold Arthur Krewat wrote: > I've never received an answer to this, and I wonder if it was because it > was sent another route and got choked as SPAM after the mailing list (I > received it from the mailing list). > > On 2/22/2017 8:33 AM, Arthur Krewat wrote: > > So what's the consensus at this point? Open source? Already released? > > > > I can't vouch that this wasn't some under-the-table exchange. It was > > for an "educational" institution but did not necessarily wind up > > there. Hence why I want to compare with similar releases if it exists. > > > > The sources all have copyright dates ranging from 1983 to 1985 for > > Sun-generated bits that looks like this: > > > > static char sccsid[] = "@(#)domainname.c 1.1 85/05/30 Copyr 1984 Sun > > Micro"; > > > > And sccsid's like this for sources taken from BSD and altered to fit: > > > > df.c:static char sccsid[] = "@(#)df.c 1.1 85/05/30 SMI"; /* from > > UCB 4.18 84/02/02 */ > > > > Sorry for fracturing this thread already. > > > > > > On 2/21/2017 8:46 PM, Clem Cole wrote: > >> > >> On Tue, Feb 21, 2017 at 8:35 PM, Arthur Krewat >> > wrote: > >> > >> Anyone interested in this source code? I did a quick Google > >> search and couldn't find anything relevant. If it's out there > >> somewhere, let me know, I'd like to take a look at it. > >> > >> It's Network File System Sun Microsystems Release 2.0 > >> > >> Since, the core of Solaris was made FOSS, I would hope there is(are) > >> persons at Oracle/Sun that can officially stamp the technology has > >> only historical value. > >> > >> Anyone know whom that should be so it can make it from the dark side. > >> > >> > > > From jnc at mercury.lcs.mit.edu Fri Feb 24 23:23:08 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 24 Feb 2017 08:23:08 -0500 (EST) Subject: [TUHS] A Couple of Early Networking Unix System Message-ID: <20170224132308.91D8518C0CA@mercury.lcs.mit.edu> > From: Lars Brinkhoff > Yes, please do add some kind of IMP to SIMH! BTDT: http://walden-family.com/impcode/imp-code.pdf Noel From spedraja at gmail.com Fri Feb 24 23:32:21 2017 From: spedraja at gmail.com (SPC) Date: Fri, 24 Feb 2017 14:32:21 +0100 Subject: [TUHS] A Couple of Early Networking Unix System In-Reply-To: <20170224132308.91D8518C0CA@mercury.lcs.mit.edu> References: <20170224132308.91D8518C0CA@mercury.lcs.mit.edu> Message-ID: Oh, yes... the "Walden" simulation (speaking informally). I'd like to put my hands on these stuff, yo can be sure. But seriously: these efforts from Noel and Paul (Congratulations) deserves to be reflected in an IMP hardware simulator under SIMH (at least), both the interfaces and the IMP itself. And at least I do not care if it goes slower than hell. Gracias | Regards - Saludos | Greetings | Freundliche Grüße | Salutations -- Sergio Pedraja -- twitter: @sergio_pedraja | skype: Sergio Pedraja -- http://www.linkedin.com/in/sergiopedraja ----- No crea todo lo que ve, ni crea que está viéndolo todo ----- "El estado de una Copia de Seguridad es desconocido hasta que intentas restaurarla" (- nixCraft) 2017-02-24 14:23 GMT+01:00 Noel Chiappa : > > From: Lars Brinkhoff > > > Yes, please do add some kind of IMP to SIMH! > > BTDT: > > http://walden-family.com/impcode/imp-code.pdf > > Noel From david at kdbarto.org Sat Feb 25 02:30:56 2017 From: david at kdbarto.org (David) Date: Fri, 24 Feb 2017 08:30:56 -0800 Subject: [TUHS] Access to Unix Message-ID: <3F95348D-9D95-4BE6-AC7C-757D30784E39@kdbarto.org> (somewhat long story) After reading all the stories about how Unix source was protected and hard to access to I’ve got to say that my experience was a little different. I was at UCSD from 76-80 when UCSD got a VAX and I think it was running 32V at the time. Well being a CS student didn’t get you access to that machine, it was for the grad students and others doing all the real work. I became friends with the admin of the system (sdcsvax) and he mentioned one day that the thing he wanted more than anything else was more disks. He had a bunch of the removable disk packs and wanted a couple more to swap out to do things like change the OS quickly etc. My dad worked for CDC at the time, and he was making removable media of the same type that the VAX was using. My luck. I asked him about getting a disk pack, or two. He said that these things cost thousands and he couldn’t just pick them up and bring them home. Then one day a couple of them ‘fell off a truck’ and my Dad just happened to be there to pick them up and bring them home. You know, so the kids could see what he did for a job. I took them into the lab and gave them to the admin who looked the disks, then at me, and asked what I wanted in exchange. I asked for a seat at the VAX, with full access. Since then I’ve had a ucsd email account, and been a dyed in the wool Unix guy. David From sauer at technologists.com Sat Feb 25 05:20:27 2017 From: sauer at technologists.com (Charles H Sauer) Date: Fri, 24 Feb 2017 13:20:27 -0600 Subject: [TUHS] Linux vs. other X86 options Message-ID: <7F8B7B9FC8074CFFBD9CBB1E7347327B@studyvista> Since the X86 discussions seem to have focused on BSD & Linux, I thought I should offer another perspective. TLDR: I worked on System V based UNIX on PCs from 1982 to 1993. IMO, excessive royalties & the difficulty of providing support for diverse hardware doomed (USL) UNIX on x86. It didn't help that SCO was entrenched in the PC market and slow to adopt new UNIX versions. Longer Summary: >From 1975-82 at IBM Research and UT-Austin C.S. dept, I tried to get access to UNIX but couldn't. At IBM Austin from '82 to '89, I worked on AIX and was involved with IBM's BSD for RT/PC. Starting in '89, I was the executive responsible for Dell UNIX (https://notes.technologists.com/notes/2008/01/10/a-brief-history-of-dell-unix/) for most of its existence. The royalties Dell paid for SVR4 plus addons were hard to bear. Those royalties were at least an order of magnitude greater than what we paid to Microsoft. We couldn't support all of the devices Dell supplied to customers, certainly couldn't afford to support hardware only supplied by other PC vendors. SCO had dominant marketplace success with Xenix and SVRx products, seemingly primarily using PCs with multiport serial cards to enable traditional timesharing applications. Many at Dell preferred that we emphasize SCO over Dell SVR4. When I joined my first Internet startup in 1996 and had to decide what OS to use for hosting, I was pretty cognizant of all the options. I had no hands on Linux experience but thought Linux the likely choice. A Linux advocate friend recommended I choose between Debian and Red Hat. I chose Red Hat and have mostly used Red Hat & Fedora for my *IX needs since then. Today, Linux device support is comprehensive, but still not as complete as with Windows. I installed Fedora 24 on some 9 and 15 year old machines last week. The graphics hardware is nothing fancy, a low end NVIDIA card in the older one, just what Intel supplied on their OEM circuit boards in the newer one. Windows (XP/7/10) on those machines gets 1080p without downloading extra drivers. (Without extra effort??) Fedora 24 won't do more than 1024x768 on one and 1280x1024 with the other. Charlie From dave at horsfall.org Sat Feb 25 06:54:20 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Feb 2017 07:54:20 +1100 (EST) Subject: [TUHS] Mach for i386 / Mt Xinu or other In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170222041734.GP9439@mcvoy.com> Message-ID: On Thu, 23 Feb 2017, Clem Cole wrote: > > I actually met [Henry Spencer] when he visited Australia, and he's > > about the most unassuming guy you will ever meet. > > ​Indeed - ​I've know him for years.  He's an old USENIX type (like me). Yep; his USENET fame did not go to his head. And if my failing memory serves me correctly, he wrote C-News in conjunction with Geoff Collier, as B-News was starting to show its age and limitations. All of which of course got blown away when NNTP arrived... There was an infamous USENET forgery of him, complete with his style and diction, and Henry actually congratulated the forger! Sigh; those were the days... Now everything is based upon instant gratification by the kiddie brigade (overnight batch jobs on ye olde 360/50, anyone?). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From wkt at tuhs.org Sat Feb 25 06:57:31 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 25 Feb 2017 06:57:31 +1000 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> Message-ID: <20170224205731.GA14701@minnie.tuhs.org> On Tue, Feb 21, 2017 at 08:35:42PM -0500, Arthur Krewat wrote: > Anyone interested in this source code? I did a quick Google search and > couldn't find anything relevant. If it's out there somewhere, let me know, > I'd like to take a look at it. > It's Network File System Sun Microsystems Release 2.0 I eyeballed it against the 4.3BSD from UWisc that is in the archive already. It looks like the UWisc code is either a later version or a modified version of this NFSv2 code. Therefore, I think it's safe to put the original NFSv2 code into the archive. It's at http://www.tuhs.org/Archive/Distributions/Sun/ I'll add it and the early networking code to the Unix Tree soon. Thanks Arthur! Warren -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From dave at horsfall.org Sat Feb 25 07:30:06 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Feb 2017 08:30:06 +1100 (EST) Subject: [TUHS] 4.3BSD TAHOE aka what is a TAHOE?! In-Reply-To: <28418.1487910189@cesium.clock.org> References: <28418.1487910189@cesium.clock.org> Message-ID: On Thu, 23 Feb 2017, Erik E. Fair wrote: > Aside from being the name of the very large lake I live near, the > "Tahoe" was a system from Computer Consoles, Inc. (CCI): > > https://en.wikipedia.org/wiki/Computer_Consoles_Inc. Ahh... I remember the CCI Power series very well. IIRC, there was the 5/32 (a pissy little box, until the 5/32X came along, which actually did the Right Thing (tm) when it implemented instruction restart correctly upon a SEGV) and the 6/32 (we had the 8MHz board, whereas most users had the 5MHz board; "we got cycles to burn!"). Those were the days, when geeks did their best but were over-ruled by the marketoids; oh, the stories I could tell about my STC days (known by the geeks as "Strangled Tangled and Confused), but I'm unsure about the Statute of Limitations... - Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From dave at horsfall.org Sat Feb 25 07:45:29 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 25 Feb 2017 08:45:29 +1100 (EST) Subject: [TUHS] Put a copy of the TUHS mail archive into the Unix Archive? In-Reply-To: <20170224063744.GB2239@minnie.tuhs.org> References: <20170224063744.GB2239@minnie.tuhs.org> Message-ID: On Fri, 24 Feb 2017, Warren Toomey wrote: [...] > Is it worth putting a copy of this mailing list into the Unix Archive? I > don't want to dump the mbox in, as it has all our e-mail addresses: spam > etc. I could symlink in the monthly text archives, e.g. It definitely ought to be archived, if you can obscure the email addresses whilst making them humanoid-readable. Damned spammers... Could the task (of de-spamming the archive) be farmed out to some volunteers? I will raise my hand, of course. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From pnr at planet.nl Sat Feb 25 07:57:03 2017 From: pnr at planet.nl (Paul Ruizendaal) Date: Fri, 24 Feb 2017 22:57:03 +0100 Subject: [TUHS] Put a copy of the TUHS mail archive into the Unix Archive? In-Reply-To: References: <20170224063744.GB2239@minnie.tuhs.org> Message-ID: <36B20D7B-8A85-4927-9C5A-F8308ED1BC33@planet.nl> Eh... I think the horse has already bolted: http://minnie.tuhs.org/pipermail/tuhs/2017-February/008526.html It would seem to be relatively easy to harvest the addresses of all posters already. Pa On 24 Feb 2017, at 22:45 , Dave Horsfall wrote: > On Fri, 24 Feb 2017, Warren Toomey wrote: > > [...] > >> Is it worth putting a copy of this mailing list into the Unix Archive? I >> don't want to dump the mbox in, as it has all our e-mail addresses: spam >> etc. I could symlink in the monthly text archives, e.g. > > It definitely ought to be archived, if you can obscure the email addresses > whilst making them humanoid-readable. Damned spammers... > > Could the task (of de-spamming the archive) be farmed out to some > volunteers? I will raise my hand, of course. > > -- > Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From wkt at tuhs.org Sat Feb 25 08:09:59 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 25 Feb 2017 08:09:59 +1000 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: <20170224205731.GA14701@minnie.tuhs.org> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> <20170224205731.GA14701@minnie.tuhs.org> Message-ID: <20170224220959.GA25938@minnie.tuhs.org> On Sat, Feb 25, 2017 at 06:57:31AM +1000, Warren Toomey wrote: > I think it's safe to put the original NFSv2 code into the archive. > It's at http://www.tuhs.org/Archive/Distributions/Sun/ > I'll add it and the early networking code to the Unix Tree soon. I've added NFSv2, the BBN and the SRC-NOSC networking code to the Unix Tree: http://minnie.tuhs.org/cgi-bin/utree.pl Cheers, Warren -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From wkt at tuhs.org Sat Feb 25 08:11:50 2017 From: wkt at tuhs.org (Warren Toomey) Date: Sat, 25 Feb 2017 08:11:50 +1000 Subject: [TUHS] Put a copy of the TUHS mail archive into the Unix Archive? In-Reply-To: References: <20170224063744.GB2239@minnie.tuhs.org> Message-ID: <20170224221150.GB25938@minnie.tuhs.org> On Fri, 24 Feb 2017, Warren Toomey wrote: > > Is it worth putting a copy of this mailing list into the Unix Archive? On Sat, Feb 25, 2017 at 08:45:29AM +1100, Dave Horsfall wrote: > It definitely ought to be archived, if you can obscure the email addresses > whilst making them humanoid-readable. Damned spammers... I've symlinked the mailman text archives in to the archive here: http://www.tuhs.org/Archive/Documentation/TUHS/Mail_list/ Mailman does obfuscate the e-mail addresses somewhat. Cheers, Warren -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jsteve at superglobalmegacorp.com Sat Feb 25 12:10:48 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sat, 25 Feb 2017 10:10:48 +0800 Subject: [TUHS] Put a copy of the TUHS mail archive into the Unix Archive? In-Reply-To: <20170224063744.GB2239@minnie.tuhs.org> References: <20170224063744.GB2239@minnie.tuhs.org> Message-ID: I think like the UTZOO archives, it would be incredibly invaluable On February 24, 2017 2:37:44 PM GMT+08:00, Warren Toomey wrote: >Is it worth putting a copy of this mailing list into the Unix Archive? >I don't want to dump the mbox in, as it has all our e-mail addresses: >spam etc. I could symlink in the monthly text archives, e.g. > >http://minnie.tuhs.org/pipermail/tuhs/2016-December.txt.gz > >What do you think? Perhaps in Documentation/TUHS_Mail? > > Warren -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Sat Feb 25 13:52:19 2017 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 24 Feb 2017 19:52:19 -0800 Subject: [TUHS] BSDi Imaging Message-ID: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> All, I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, sources, and betas. Unable to dump any floppies, however. -- Cory Smelosky b4 at gewt.net From b4 at gewt.net Sat Feb 25 13:53:45 2017 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 24 Feb 2017 19:53:45 -0800 Subject: [TUHS] BSDi Imaging In-Reply-To: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> Message-ID: <1487994825.4144951.892332064.2F6F7039@webmail.messagingengine.com> On Fri, Feb 24, 2017, at 19:52, Cory Smelosky wrote: > All, > > I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, > sources, and betas. > > Unable to dump any floppies, however. I never found my USB floppy drive, unfortunately. Nothing else with a floppy drive is currently happy. > > -- > Cory Smelosky > b4 at gewt.net -- Cory Smelosky b4 at gewt.net From random832 at fastmail.com Sat Feb 25 14:35:46 2017 From: random832 at fastmail.com (Random832) Date: Fri, 24 Feb 2017 23:35:46 -0500 Subject: [TUHS] Put a copy of the TUHS mail archive into the Unix Archive? In-Reply-To: References: <20170224063744.GB2239@minnie.tuhs.org> Message-ID: <1487997346.1004594.892347632.4EE1DD4F@webmail.messagingengine.com> On Fri, Feb 24, 2017, at 16:45, Dave Horsfall wrote: > On Fri, 24 Feb 2017, Warren Toomey wrote: > > [...] > > > Is it worth putting a copy of this mailing list into the Unix Archive? I > > don't want to dump the mbox in, as it has all our e-mail addresses: spam > > etc. I could symlink in the monthly text archives, e.g. > > It definitely ought to be archived, if you can obscure the email > addresses > whilst making them humanoid-readable. Damned spammers... > > Could the task (of de-spamming the archive) be farmed out to some > volunteers? I will raise my hand, of course. The archive files already have the email addresses minimally obfuscated (with "at"), and are already available in the right hand column at http://minnie.tuhs.org/pipermail/tuhs/ (which is probably a softer target for spam bots than the archive itself) - it seems unlikely that putting them in as-is would increase the amount of spam people get. From b4 at gewt.net Sat Feb 25 17:34:57 2017 From: b4 at gewt.net (Cory Smelosky) Date: Fri, 24 Feb 2017 23:34:57 -0800 Subject: [TUHS] BSDi Imaging In-Reply-To: <1487994825.4144951.892332064.2F6F7039@webmail.messagingengine.com> References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> <1487994825.4144951.892332064.2F6F7039@webmail.messagingengine.com> Message-ID: <1488008097.4185274.892412096.212D39A0@webmail.messagingengine.com> On Fri, Feb 24, 2017, at 19:53, Cory Smelosky wrote: > > > On Fri, Feb 24, 2017, at 19:52, Cory Smelosky wrote: > > All, > > > > I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, > > sources, and betas. > > > > Unable to dump any floppies, however. > > I never found my USB floppy drive, unfortunately. Nothing else with a > floppy drive is currently happy. > > > > > -- > > Cory Smelosky > > b4 at gewt.net > > > -- > Cory Smelosky > b4 at gewt.net Snagged it all - it's 19G. Now I can get the documentation to the CHM. -- Cory Smelosky b4 at gewt.net From doug at cs.dartmouth.edu Sat Feb 25 22:41:27 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 25 Feb 2017 07:41:27 -0500 Subject: [TUHS] Access to Unix Message-ID: <201702251241.v1PCfRZl024156@coolidge.cs.Dartmouth.EDU> > Then one day a couple of them ‘fell off a truck’ and my Dad just happened to be there to pick them up and bring them home. Wonderful story. It reminded me of the charming book, "five Finger Discount" by Helene Stapinski, whose father brought home truckfall steaks. Thanks for sharing the tale. Doug From arno.griffioen at ieee.org Sun Feb 26 00:17:38 2017 From: arno.griffioen at ieee.org (Arno Griffioen) Date: Sat, 25 Feb 2017 15:17:38 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? Message-ID: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> Hi! Some of the stories on here reminded me of the fact that there's also likely a whole boat-load of UNIX ports/variants in the past that were never released to customers or outside certain companies. Not talking about UNIX versions that have become obsolete or which have vanished by now like IRIX or the original Apple A/UX (now *that* was an interesting oddball though..) and such, but the ones that either died or failed or got cancelled during the product development process or were never intended to be released to the outside ar all. Personally I came across one during some UNIX consultancy work at Commodore during the time that they were working on bringing out an SVR4 release for the Amiga (which they actually sold for some time) Side-note.. Interestingly enough according to my contacts at that time inside CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the M68k codebase which explained some of the oddities and lack of M68k ABI compliance of the Amiga SVR4 release.. However.. It turned out that they had been running an SVRIII port on much older Amiga 2000's with 68020 cards for some of their internal corporate networking and email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it was never released to the public or external customers. It was a fairly 'plain jane' SVRIII port with little specific 'Amiga' hardware bits supported but otherwise quite complete and pretty stable. Worked quite well in the 4MB DRAM available on these cards. The later SVR4 didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) 16MB. It was known 'outside' that something like this existed as the boot ROM's on the 68020 card had an 'AMIX' option but outside CBM few people really knew much about it. It may have been used at the University of Lowell as they developed a TI34010 based card that may already have had some support in this release. Still.. This does make me wonder.. Does anyone else know of these kinds of special 'snowflake' UNIX versions that never got out at various companies/insitutes? (and can talk about it without violating a whole stack of NDA's ;) ) No special reason.. Just idle curiosity :) Likely all these are gone forever anyway as prototypes and small run production devices and related software tends to get destroyed when companies go bust or get aquired. Bye, Arno. From lm at mcvoy.com Sun Feb 26 00:32:55 2017 From: lm at mcvoy.com (Larry McVoy) Date: Sat, 25 Feb 2017 06:32:55 -0800 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> Message-ID: <20170225143255.GH21761@mcvoy.com> On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote: > Worked quite well in the 4MB DRAM available on these cards. The later SVR4 > didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) > 16MB. Back in the days of 4MB SPARC machines (and 68K machines) we joked that EMACS stood for Eight Megs And Constantly Swapping. David Rosenthal, a Sun DE, was known for running emacs on the bitmapped console in terminal mode so as to not let X11 or NeWS eat up ram. From jsteve at superglobalmegacorp.com Sun Feb 26 00:44:45 2017 From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com) Date: Sat, 25 Feb 2017 22:44:45 +0800 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during theyears? In-Reply-To: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> Message-ID: <37bb0648-3c13-4b00-897d-2e6afe3219c2@HK2APC01FT004.eop-APC01.prod.protection.outlook.com> I’ve read from early Microsoft employee’s that you had to learn to use vi to get vacation time, as they ran Xenix on all their backend stuff. Although their first Xenix ads did mention it was available on the PDP-11, and other than one old post where someone mentioned that anytime there was a serious bug it was always in the Xenix portion. It’s kind of funny that despite at one time being the highest installation by site count, Xenix has all but disappeared. Not that OpenSERVER was either open or much of a good server. And the only people I ever saw all that excited about UnixWare was telecom companies. Sent from Mail for Windows 10 From: Arno Griffioen Sent: Saturday, 25 February 2017 10:18 PM To: tuhs at minnie.tuhs.org Subject: [TUHS] Un-released/internal/special UNIX versions/ports during theyears? Hi! Some of the stories on here reminded me of the fact that there's also likely a whole boat-load of UNIX ports/variants in the past that were never released to customers or outside certain companies. Not talking about UNIX versions that have become obsolete or which have vanished by now like IRIX or the original Apple A/UX (now *that* was an interesting oddball though..) and such, but the ones that either died or failed or got cancelled during the product development process or were never intended to be released to the outside ar all. Personally I came across one during some UNIX consultancy work at Commodore during the time that they were working on bringing out an SVR4 release for the Amiga (which they actually sold for some time) Side-note.. Interestingly enough according to my contacts at that time inside CBM it was based on the much cheaper to license 3B2 SVR4 codebase and not the M68k codebase which explained some of the oddities and lack of M68k ABI compliance of the Amiga SVR4 release.. However.. It turned out that they had been running an SVRIII port on much older Amiga 2000's with 68020 cards for some of their internal corporate networking and email, UUCP, etc. and was called 'AMIX' internally. But as far as I know it was never released to the public or external customers. It was a fairly 'plain jane' SVRIII port with little specific 'Amiga' hardware bits supported but otherwise quite complete and pretty stable. Worked quite well in the 4MB DRAM available on these cards. The later SVR4 didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) 16MB. It was known 'outside' that something like this existed as the boot ROM's on the 68020 card had an 'AMIX' option but outside CBM few people really knew much about it. It may have been used at the University of Lowell as they developed a TI34010 based card that may already have had some support in this release. Still.. This does make me wonder.. Does anyone else know of these kinds of special 'snowflake' UNIX versions that never got out at various companies/insitutes? (and can talk about it without violating a whole stack of NDA's ;) ) No special reason.. Just idle curiosity :) Likely all these are gone forever anyway as prototypes and small run production devices and related software tends to get destroyed when companies go bust or get aquired. Bye, Arno. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Sun Feb 26 02:35:24 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Sat, 25 Feb 2017 11:35:24 -0500 (EST) Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170225143255.GH21761@mcvoy.com> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: On Sat, 25 Feb 2017, Larry McVoy wrote: > On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote: >> Worked quite well in the 4MB DRAM available on these cards. The later SVR4 >> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) >> 16MB. > > Back in the days of 4MB SPARC machines (and 68K machines) we joked > that EMACS stood for Eight Megs And Constantly Swapping. David > Rosenthal, a Sun DE, was known for running emacs on the bitmapped > console in terminal mode so as to not let X11 or NeWS eat up ram. > >From that nickname I came up with "Enough Memory A Concept Strange", as 8 MB was no longer a lot of memory. Disclosure - never was an EMACS person, or a vi person, pico was and nano is more my cup of tea. That said, I can fumble my way around vi if I absolutely must. -uso. From clemc at ccc.com Sun Feb 26 03:31:00 2017 From: clemc at ccc.com (Clem Cole) Date: Sat, 25 Feb 2017 12:31:00 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170225143255.GH21761@mcvoy.com> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy wrote: > Back in the days of 4MB SPARC machines (and 68K machines) we joked > ​ ​ > that EMACS stood for Eight Megs And Constantly Swapping. > ​To me the good news is was if you could laugh at yourself I think it was pretty sign. There were a bunch of them... two more I can remember: LISP -- Lots of Insipidly Silly Parens Multics - Many Unbelievably Large Tables In Core Simultaneously ​ There was a Fortran one I've forgotten that started with "Friendly Only" .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.unix.pro at gmail.com Sun Feb 26 03:34:54 2017 From: charles.unix.pro at gmail.com (Charles Anthony) Date: Sat, 25 Feb 2017 09:34:54 -0800 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: On Sat, Feb 25, 2017 at 9:31 AM, Clem Cole wrote: > > On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy wrote: > >> Back in the days of 4MB SPARC machines (and 68K machines) we joked >> ​ ​ >> that EMACS stood for Eight Megs And Constantly Swapping. >> > > ​To me the good news is was if you could laugh at yourself I think it was > pretty sign. There were a bunch of them... two more I can remember: > > LISP -- Lots of Insipidly Silly Parens > Multics - Many Unbelievably Large Tables In Core Simultaneously ​ > > PCMCIA - 'People Can't Memorize Computer Industry Acronyms" -- Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: From brantleycoile at me.com Sun Feb 26 03:36:24 2017 From: brantleycoile at me.com (Brantley Coile) Date: Sat, 25 Feb 2017 12:36:24 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: <21DF548F-658F-4327-9221-10559F19DC3C@me.com> Compiles Only Because Of Luck. Completely Obsolete, Badly Outdated Language Even Feldman Likes it (The other FORTRAN.) > On Feb 25, 2017, at 12:31 PM, Clem Cole wrote: > > > On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy wrote: > Back in the days of 4MB SPARC machines (and 68K machines) we joked​ ​that EMACS stood for Eight Megs And Constantly Swapping. > > ​To me the good news is was if you could laugh at yourself I think it was pretty sign. There were a bunch of them... two more I can remember: > > LISP -- Lots of Insipidly Silly Parens > Multics - Many Unbelievably Large Tables In Core Simultaneously ​ > > There was a Fortran one I've forgotten that started with "Friendly Only" .. > > > > From cym224 at gmail.com Sun Feb 26 03:40:12 2017 From: cym224 at gmail.com (Nemo) Date: Sat, 25 Feb 2017 12:40:12 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170225143255.GH21761@mcvoy.com> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: On 25 February 2017 at 09:32, Larry McVoy wrote: > On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote: >> Worked quite well in the 4MB DRAM available on these cards. The later SVR4 >> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) >> 16MB. > > Back in the days of 4MB SPARC machines (and 68K machines) we joked > that EMACS stood for Eight Megs And Constantly Swapping. Ah, EMACS jokes (though this be off-topic)! I remember one cartoon, which I cannot place, of someone at a terminal and a platter flying through the room having broken free from the drive pack, the caption reading "EMACS tends to hit the disc a little too often." N. From brantleycoile at me.com Sun Feb 26 03:43:18 2017 From: brantleycoile at me.com (Brantley Coile) Date: Sat, 25 Feb 2017 12:43:18 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: <3F3F4A7C-C3A7-4B77-9F75-49E42011B44D@me.com> I remember in 1991 noticing suspiciously high load activity on a workstation of an engineer on vacation. Turns out he had just left EMACS running. > On Feb 25, 2017, at 12:40 PM, Nemo wrote: > > On 25 February 2017 at 09:32, Larry McVoy wrote: >> On Sat, Feb 25, 2017 at 03:17:38PM +0100, Arno Griffioen wrote: >>> Worked quite well in the 4MB DRAM available on these cards. The later SVR4 >>> didn't fare so well.. Paged itself to death unless you had 8 or even (gasp!) >>> 16MB. >> >> Back in the days of 4MB SPARC machines (and 68K machines) we joked >> that EMACS stood for Eight Megs And Constantly Swapping. > > Ah, EMACS jokes (though this be off-topic)! I remember one cartoon, > which I cannot place, of someone at a terminal and a platter flying > through the room having broken free from the drive pack, the caption > reading "EMACS tends to hit the disc a little too often." > > N. From schily at schily.net Sun Feb 26 04:11:57 2017 From: schily at schily.net (Joerg Schilling) Date: Sat, 25 Feb 2017 19:11:57 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: <58b1c8ed.cS2tH2WxK2fCGUgD%schily@schily.net> Steve Nickolas wrote: > On Sat, 25 Feb 2017, Larry McVoy wrote: > > Back in the days of 4MB SPARC machines (and 68K machines) we joked > > that EMACS stood for Eight Megs And Constantly Swapping. David > > Rosenthal, a Sun DE, was known for running emacs on the bitmapped > > console in terminal mode so as to not let X11 or NeWS eat up ram. > > > > From that nickname I came up with "Enough Memory A Concept Strange", as 8 > MB was no longer a lot of memory. On my Sun-2/50 at home and my 3-50 at work, I edited in console mode when I was working on drivers - just because launching Sunview did take too much time and I needed to reboot frequently. Note that I could not load the driver when I was e.g. working on the kbd driver. I stopped with this kind of usage once the console on sparc systems came up and has been too slow. OK there was a hack to copy the FORTH boot code into RAM to make it faster, but it still has been slower than the Sun2 or Sun3 machines. Memory was definitely not a problem on Sparc systems as the Sparc systems I used never had less than 16MB of RAM (usually 64MB). I started with what I call a "SparcStation-1-" at home, an engineering sample delivered aprox. 9 months before the official Sparcstation-1 launch that used a TI Floatingpoint processor with a gate array adaptor on a piggy back rather than the official Weitek chip. > Disclosure - never was an EMACS person, or a vi person, pico was and nano > is more my cup of tea. That said, I can fumble my way around vi if I > absolutely must. I do not know EMACS well enough to use it and I know vi for emergency only. I usually use my VED (see schilytools). Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From brantleycoile at me.com Sun Feb 26 04:16:48 2017 From: brantleycoile at me.com (Brantley Coile) Date: Sat, 25 Feb 2017 13:16:48 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <58b1c8ed.cS2tH2WxK2fCGUgD%schily@schily.net> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> <58b1c8ed.cS2tH2WxK2fCGUgD%schily@schily.net> Message-ID: <241A44C8-7A39-4D03-8B7E-25F7E2D06D8C@me.com> For the record, I use sam, ed, and acme, in that order. > On Feb 25, 2017, at 1:11 PM, Joerg Schilling wrote: > > Steve Nickolas wrote: > >> On Sat, 25 Feb 2017, Larry McVoy wrote: >>> Back in the days of 4MB SPARC machines (and 68K machines) we joked >>> that EMACS stood for Eight Megs And Constantly Swapping. David >>> Rosenthal, a Sun DE, was known for running emacs on the bitmapped >>> console in terminal mode so as to not let X11 or NeWS eat up ram. >>> >> >> From that nickname I came up with "Enough Memory A Concept Strange", as 8 >> MB was no longer a lot of memory. > > On my Sun-2/50 at home and my 3-50 at work, I edited in console mode when I was > working on drivers - just because launching Sunview did take too much time and > I needed to reboot frequently. Note that I could not load the driver when I was > e.g. working on the kbd driver. > > I stopped with this kind of usage once the console on sparc systems came up and > has been too slow. OK there was a hack to copy the FORTH boot code into RAM to > make it faster, but it still has been slower than the Sun2 or Sun3 machines. > > Memory was definitely not a problem on Sparc systems as the Sparc systems I > used never had less than 16MB of RAM (usually 64MB). I started with what I call > a "SparcStation-1-" at home, an engineering sample delivered aprox. 9 months > before the official Sparcstation-1 launch that used a TI Floatingpoint > processor with a gate array adaptor on a piggy back rather than the official > Weitek chip. > >> Disclosure - never was an EMACS person, or a vi person, pico was and nano >> is more my cup of tea. That said, I can fumble my way around vi if I >> absolutely must. > > I do not know EMACS well enough to use it and I know vi for emergency only. I > usually use my VED (see schilytools). > > Jörg > > -- > EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin > joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ > URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From tfb at tfeb.org Sun Feb 26 04:28:58 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Sat, 25 Feb 2017 18:28:58 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: <773222BF-B109-4EC0-8E55-F022AE7B69DA@tfeb.org> On 25 Feb 2017, at 17:31, Clem Cole wrote: > > LISP -- Lots of Insipidly Silly Parens Lots of Irritating Single Parens (Although why anyone who has looked at the tail of some bit of C-derived language with its apparently endless sequence of close braces, carefully arranged one-per line to maximise the wasted screen real-estate would say this is beyond me. One of Python's few good features is that it is impossible to do this when writing Python -- although somewhere, no doubt, there are coding style guidelines which say that Python definitions must be separated from the following definition by 1 + number-of-nesting-levels blank lines.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aek at bitsavers.org Sun Feb 26 05:02:20 2017 From: aek at bitsavers.org (Al Kossow) Date: Sat, 25 Feb 2017 11:02:20 -0800 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> Message-ID: On 2/25/17 6:17 AM, Arno Griffioen wrote: > the original Apple A/UX (now *that* was an > interesting oddball though..) The original release was based on Unisoft UniPlus+, with some boot resiliency added. From aek at bitsavers.org Sun Feb 26 04:57:08 2017 From: aek at bitsavers.org (Al Kossow) Date: Sat, 25 Feb 2017 10:57:08 -0800 Subject: [TUHS] BSDi Imaging In-Reply-To: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> Message-ID: <3d863863-b788-b372-cc2d-3ab116b8244e@bitsavers.org> MtXinu w NFS is still on the most wanted list. Unforunately, they used really bad magtape for distribuition which remains sticky no matter what I try to do to make it readable. On 2/24/17 7:52 PM, Cory Smelosky wrote: > All, > > I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, > sources, and betas. > > Unable to dump any floppies, however. > From b4 at gewt.net Sun Feb 26 05:25:40 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 25 Feb 2017 11:25:40 -0800 Subject: [TUHS] BSDi Imaging In-Reply-To: <3d863863-b788-b372-cc2d-3ab116b8244e@bitsavers.org> References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> <3d863863-b788-b372-cc2d-3ab116b8244e@bitsavers.org> Message-ID: Argh! MtXinu is something I really want. Sent from my iPhone > On Feb 25, 2017, at 10:57, Al Kossow wrote: > > MtXinu w NFS is still on the most wanted list. > Unforunately, they used really bad magtape for distribuition which remains sticky > no matter what I try to do to make it readable. > >> On 2/24/17 7:52 PM, Cory Smelosky wrote: >> All, >> >> I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, >> sources, and betas. >> >> Unable to dump any floppies, however. >> > From dscherrer at solar.stanford.edu Sun Feb 26 06:47:22 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Sat, 25 Feb 2017 12:47:22 -0800 Subject: [TUHS] BSDi Imaging In-Reply-To: References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> <3d863863-b788-b372-cc2d-3ab116b8244e@bitsavers.org> Message-ID: <6876c5f6-b7a0-26bf-ac76-31d18636c1f0@solar.stanford.edu> I worked there for 10 years (eventually becoming President). I'll try to dig up a tape. Deborah On 2/25/17 11:25 AM, Cory Smelosky wrote: > Argh! > > MtXinu is something I really want. > > Sent from my iPhone > >> On Feb 25, 2017, at 10:57, Al Kossow wrote: >> >> MtXinu w NFS is still on the most wanted list. >> Unforunately, they used really bad magtape for distribuition which remains sticky >> no matter what I try to do to make it readable. >> >>> On 2/24/17 7:52 PM, Cory Smelosky wrote: >>> All, >>> >>> I'm dumping as much BSD/OS stuff as I can tonight. This includes: SPARC, >>> sources, and betas. >>> >>> Unable to dump any floppies, however. >>> From ron at ronnatalie.com Sun Feb 26 07:21:56 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sat, 25 Feb 2017 16:21:56 -0500 Subject: [TUHS] BSDi Imaging In-Reply-To: <1487994825.4144951.892332064.2F6F7039@webmail.messagingengine.com> References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com> <1487994825.4144951.892332064.2F6F7039@webmail.messagingengine.com> Message-ID: <002701d28fad$318ddaa0$94a98fe0$@ronnatalie.com> I've got a USB floppy drive that is kind of worthless for the purpose I bought it for. If someone wants it for historical research purposes, I'd be glad to send it along. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Cory Smelosky Sent: Friday, February 24, 2017 10:54 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] BSDi Imaging On Fri, Feb 24, 2017, at 19:52, Cory Smelosky wrote: > All, > > I'm dumping as much BSD/OS stuff as I can tonight. This includes: > SPARC, sources, and betas. > > Unable to dump any floppies, however. I never found my USB floppy drive, unfortunately. Nothing else with a floppy drive is currently happy. > > -- > Cory Smelosky > b4 at gewt.net -- Cory Smelosky b4 at gewt.net From dave at horsfall.org Sun Feb 26 09:23:01 2017 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 26 Feb 2017 10:23:01 +1100 (EST) Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170225143255.GH21761@mcvoy.com> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> Message-ID: On Sat, 25 Feb 2017, Larry McVoy wrote: > Back in the days of 4MB SPARC machines (and 68K machines) we joked that > EMACS stood for Eight Megs And Constantly Swapping. David Rosenthal, a > Sun DE, was known for running emacs on the bitmapped console in terminal > mode so as to not let X11 or NeWS eat up ram. Another acronym is Esc Meta Alt Ctl Shift... -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From b4 at gewt.net Sun Feb 26 10:55:25 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 25 Feb 2017 16:55:25 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 Message-ID: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com> Hey, Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got damaged in a dehumidifier failure before they got to California. The only survivor was of all things...the QIC-24 tape (which I have read fine) sco-tape> tar tf file0 | more ./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1 Anyone know a good starting point for attempting to install it in to a VM? ;) -- Cory Smelosky b4 at gewt.net From jsteve at superglobalmegacorp.com Sun Feb 26 13:35:50 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sun, 26 Feb 2017 11:35:50 +0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com> References: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com> Message-ID: I've always added 'tape' images as 2nd disks and symlinked the devices. Like the old way of installing Xenix, it's not very sophisticated as it looks... On February 26, 2017 8:55:25 AM GMT+08:00, Cory Smelosky wrote: >Hey, > >Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got >damaged in a dehumidifier failure before they got to California. The >only survivor was of all things...the QIC-24 tape (which I have read >fine) > >sco-tape> tar tf file0 | more >./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1 > >Anyone know a good starting point for attempting to install it in to a >VM? ;) >-- > Cory Smelosky > b4 at gewt.net -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Sun Feb 26 13:46:27 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sat, 25 Feb 2017 19:46:27 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: References: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com> Message-ID: <1488080787.179627.892986096.7AD36438@webmail.messagingengine.com> On Sat, Feb 25, 2017, at 19:35, Jason Stevens wrote: > I've always added 'tape' images as 2nd disks and symlinked the > devices. Like the old way of installing Xenix, it's not very > sophisticated as it looks... > > On February 26, 2017 8:55:25 AM GMT+08:00, Cory Smelosky > wrote: >> Hey, >> >> >> >> Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got >> >> damaged in a dehumidifier failure before they got to California. The >> >> only survivor was of all things...the QIC-24 tape (which I have read >> >> fine) >> >> >> >> sco-tape> tar tf file0 | more >> >> ./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1 >> >> >> >> Anyone know a good starting point for attempting to install it >> in to a >> >> VM? ;) >> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. I'm also missing the floppies, though. -- Cory Smelosky b4 at gewt.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Sun Feb 26 14:06:37 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Sun, 26 Feb 2017 12:06:37 +0800 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> Message-ID: <94F9E951-9786-489E-97F7-C212925817B9@superglobalmegacorp.com> There is that emulator shoebill which can run A/UX, even the 0.7 version which has the lower level unisoft sysv source. But by the time they got around to version 3 it was an incredibly robust UNIX with a very simple UI, and by nature had access to an incredible amount of apps being source sysv compatible, and could run most sys6/7 apps, including SoftPC! It's crazy that Apple never ported it to the PowerPC, as they basically had a next gen OS right under their nose the whole time, and ended up paying to port NeXT to the PowerPC, and doing the carbon shuffle to get apps... But Apple has never been shy from doing things strange. On February 26, 2017 3:02:20 AM GMT+08:00, Al Kossow wrote: > > >On 2/25/17 6:17 AM, Arno Griffioen wrote: >> the original Apple A/UX (now *that* was an >> interesting oddball though..) > >The original release was based on Unisoft UniPlus+, with some boot >resiliency added. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.j.blom at gmail.com Sun Feb 26 15:31:45 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Sun, 26 Feb 2017 12:31:45 +0700 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 Message-ID: The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 Mail me if you're interested Cheers, rudi > Message: 1 > Date: Sat, 25 Feb 2017 16:55:25 -0800 > From: Cory Smelosky > To: tuhs at minnie.tuhs.org > Subject: [TUHS] SCO OpenDesktop 386 2.0.0 > Message-ID: > <1488070525.154368.892915216.18B7F7A4 at webmail.messagingengine.com> > Content-Type: text/plain; charset="utf-8" > > Hey, > > Does anyone have any of the floppies for OpenDesktop 2.0.0? Mine got > damaged in a dehumidifier failure before they got to California. The > only survivor was of all things...the QIC-24 tape (which I have read > fine) > > sco-tape> tar tf file0 | more > ./tmp/_lbl/prd=odtps/typ=u386/rel=2.0.0a/vol=1 > > Anyone know a good starting point for attempting to install it in to a > VM? ;) > -- > Cory Smelosky > b4 at gewt.net From pepe at naleco.com Sun Feb 26 20:50:00 2017 From: pepe at naleco.com (Josh Good) Date: Sun, 26 Feb 2017 11:50:00 +0100 Subject: [TUHS] Sun NFS version 2.0 In-Reply-To: <20170224205731.GA14701@minnie.tuhs.org> References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu> <20170221164728.GZ20341@mcvoy.com> <20170221192124.GO20341@mcvoy.com> <20170221203256.GF3250@mcvoy.com> <1487717888.58acc60090241@www.paradise.net.nz> <20170224205731.GA14701@minnie.tuhs.org> Message-ID: <20170226104958.GA15670@naleco.com> On 2017 Feb 25, 06:57, Warren Toomey wrote: > > I eyeballed it against the 4.3BSD from UWisc that is in the archive already. > It looks like the UWisc code is either a later version or a modified version > of this NFSv2 code. Therefore, I think it's safe to put the original NFSv2 > code into the archive. > > It's at http://www.tuhs.org/Archive/Distributions/Sun/ > > I'll add it and the early networking code to the Unix Tree soon. > > Thanks Arthur! > Warren Hi, Warren. Perhaps it's because of the ancient version of GnuPG that I am running, but your PGP-signed message I'm replying to does not verify with your public key you have published here: http://minnie.tuhs.org/warren.html I get this output from my GnuPG install: --------------------------------------- gpg: Signature made Fri Feb 24 21:57:31 2017 CET gpg: using RSA key 0xAC26979D28FF474E gpg: Can't check signature: public key not found --------------------------------------- I must be doing something wrong, I suppose. -- Josh Good From jnc at mercury.lcs.mit.edu Sun Feb 26 22:39:56 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 26 Feb 2017 07:39:56 -0500 (EST) Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? Message-ID: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> > From: Dave Horsfall > Another acronym is Esc Meta Alt Ctl Shift... Good one! And there was a pretty funny fake Exxx error code - I think it was "EMACS - Editor too big"? I was never happy with the size of EMACS, and it had nothing to do with the amount of memory resources used. That big a binary implies a very large amount of source, and the more lines of code, the more places for bugs... And it makes it harder to understand, for someone working on it (to make a change/improvement). Noel From michael at kjorling.se Sun Feb 26 22:46:57 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 26 Feb 2017 12:46:57 +0000 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: <20170226124657.GB21079@yeono.kjorling.se> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): > I was never happy with the size of EMACS, and it had nothing to do with the > amount of memory resources used. That big a binary implies a very large amount > of source, and the more lines of code, the more places for bugs... But remember; without Emacs, we might never have had _The Cuckoo's Egg_. Imagine the terror of that loss. Or not. (Though Stoll's book was one of the things that more or less introduced me to the idea of operating systems other than DOS/Windows. I don't remember how many times I borrowed that book from the local library, but it was probably in the double digits at least. Later I got my own copy, which I still have.) -- 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 jnc at mercury.lcs.mit.edu Sun Feb 26 22:50:50 2017 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 26 Feb 2017 07:50:50 -0500 (EST) Subject: [TUHS] BSDi Imaging Message-ID: <20170226125050.9691E18C09B@mercury.lcs.mit.edu> > From: Deborah Scherrer > On 2/25/17 11:25 AM, Cory Smelosky wrote: >> MtXinu is something I really want. > I worked there for 10 years (eventually becoming President). I'll try > to dig up a tape. Say what you will about RMS, but he really did change the world of software. Most code (except for very specialized applications) just isn't worth much anymore (because of competition from open source) - which is part of why all these old code packages are now freely available. Although I suppose the development of portabilty - which really took off with C and Unix, although it had existed to some degree before that, q.v. the tools collection in FORTRAN we just mentioned - was also a factor, it made it possible to amortize code writing over a number of different types of machines. There were in theory portable languages beforehand (e.g. PL/1), but I think it probably over-specified things - e.g. it would be impossible to port Multics to another architecture without almost completely re-writing it from scratch, the code is shot through with "fixed bin(18)"'s every other line... Noel From tfb at tfeb.org Sun Feb 26 23:32:27 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Sun, 26 Feb 2017 13:32:27 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: On 26 Feb 2017, at 12:39, Noel Chiappa wrote: > > I was never happy with the size of EMACS, and it had nothing to do with the > amount of memory resources used. That big a binary implies a very large amount > of source, and the more lines of code, the more places for bugs... And it > makes it harder to understand, for someone working on it (to make a > change/improvement). I think whether you think Emacs is large or small depends on what you think it is. If you think it's a text editor it's huge (by the standards of the 1970s, anyway: I have things which purport to be text editors which have python interpreters in and are significantly larger than Emacs, *on my phone*). But if you think of it as the userland of an operating system it's rather small. And many Emacs users do (or did: I used to but don't so much any more) treat it as the latter. From madcrow.maxwell at gmail.com Mon Feb 27 00:19:51 2017 From: madcrow.maxwell at gmail.com (Michael Kerpan) Date: Sun, 26 Feb 2017 09:19:51 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: Oops. Meant to send this to this list but sent it privately. Here's a second try: My supposition is that EMACS was basically Stallman's attempt to bring in all the things he liked about the LISP Machine environment into the Unix world through the back door. The original PDP-10 EMACS really was just a pile of macros which turned TECO into something usable by mere mortals. If all you wanted was an editor that worked the same way as PDP-10 EMACS, it would have been easy to create: several people have (MicroEMACS, etc). It's the fact that GNU EMACS was intended as a haven for MIT LISP hackers adrift in the bold new world of Unix that made it so huge for its time. Mike On Feb 26, 2017 8:40 AM, "Tim Bradshaw" wrote: > On 26 Feb 2017, at 12:39, Noel Chiappa wrote: > > > > I was never happy with the size of EMACS, and it had nothing to do with > the > > amount of memory resources used. That big a binary implies a very large > amount > > of source, and the more lines of code, the more places for bugs... And it > > makes it harder to understand, for someone working on it (to make a > > change/improvement). > > I think whether you think Emacs is large or small depends on what you > think it is. If you think it's a text editor it's huge (by the standards > of the 1970s, anyway: I have things which purport to be text editors which > have python interpreters in and are significantly larger than Emacs, *on my > phone*). But if you think of it as the userland of an operating system > it's rather small. And many Emacs users do (or did: I used to but don't so > much any more) treat it as the latter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From schily at schily.net Mon Feb 27 00:54:10 2017 From: schily at schily.net (Joerg Schilling) Date: Sun, 26 Feb 2017 15:54:10 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> Michael Kerpan wrote: > Oops. Meant to send this to this list but sent it privately. Here's a > second try: > > My supposition is that EMACS was basically Stallman's attempt to bring in > all the things he liked about the LISP Machine environment into the Unix > world through the back door. The original PDP-10 EMACS really was just a > pile of macros which turned TECO into something usable by mere mortals. If > all you wanted was an editor that worked the same way as PDP-10 EMACS, it > would have been easy to create: several people have (MicroEMACS, etc). It's > the fact that GNU EMACS was intended as a haven for MIT LISP hackers adrift > in the bold new world of Unix that made it so huge for its time. But the GNU EMACS is not a RMS invention... GNU EMACS is based on the Gosling EMACS and this did already include the LISP interpreter. When Gosling started to work for Sun, he did no longer have the time to maintain it and did hand it over to Unipress. RMS did take this code, added a few small changed and sold it under the name GNU emacs. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From corey at lod.com Mon Feb 27 01:07:22 2017 From: corey at lod.com (Corey Lindsly) Date: Sun, 26 Feb 2017 07:07:22 -0800 (PST) Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: Message-ID: <20170226150722.D6C8540B9@lod.com> > The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 > > Mail me if you're interested > > Cheers, > rudi I seem to have CD and floppy images for SCO 2.1. drwxr-xr-x 2 corey 1002 4096 Feb 3 2006 ./ drwxr-xr-x 27 corey 1002 20480 Feb 24 09:13 ../ -rw-r--r-- 1 corey 1002 156 Oct 9 2006 README -rwxr--r-- 1 corey 1002 564658176 Feb 2 2006 SCO-2.1-CD.iso* -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 hba.dd* -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 id.dd* -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu1.dd* -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu2.dd* I'm happy to provide them if anyone is interested. --corey From aap at papnet.eu Mon Feb 27 01:25:45 2017 From: aap at papnet.eu (Angelo Papenhoff) Date: Sun, 26 Feb 2017 16:25:45 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> Message-ID: <20170226152545.GA24045@indra.papnet.eu> Whoops, replied off list too accidentally, sorry Jörg. On 26/02/17, Joerg Schilling wrote: > But the GNU EMACS is not a RMS invention... > > GNU EMACS is based on the Gosling EMACS and this did already include the LISP > interpreter. > > When Gosling started to work for Sun, he did no longer have the time to > maintain it and did hand it over to Unipress. RMS did take this code, added a > few small changed and sold it under the name GNU emacs. As far as I know the original LISP implementation in Gosling EMACS had to be completely rewritten. I just don't remember where I've read this. aap From tfb at tfeb.org Mon Feb 27 01:37:10 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Sun, 26 Feb 2017 15:37:10 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> Message-ID: <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> > On 26 Feb 2017, at 14:54, Joerg Schilling wrote: > > GNU EMACS is based on the Gosling EMACS and this did already include the LISP > interpreter. Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one). There's no doubt that GNU Emacs had its roots in Gosling Emacs, but only in much the same way that FreeBSD has its roots in 6th edition Unix. There's also no real doubt that RMS was responsible for Emacs *as an idea* as opposed to any particular implementation (Guy Steele is I think the other person who might be held responsible, but I believe he's said that it was RMS, which is good enough for me). --tim From schily at schily.net Mon Feb 27 01:52:40 2017 From: schily at schily.net (Joerg Schilling) Date: Sun, 26 Feb 2017 16:52:40 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> Message-ID: <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> Tim Bradshaw wrote: > > > On 26 Feb 2017, at 14:54, Joerg Schilling wrote: > > > > GNU EMACS is based on the Gosling EMACS and this did already include the LISP > > interpreter. > > Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one). OK, then Gosling just had the idea of including lisp. > There's also no real doubt that RMS was responsible for Emacs *as an idea* as opposed to any particular implementation (Guy Steele is I think the other person who might be held responsible, but I believe he's said that it was RMS, which is good enough for me). I am sure that emacs would be unknown today in case that Gosling did not write the C-implementation. A macro set for a closed source editor on a dying architecture (PDP-11) would have died as well. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From schily at schily.net Mon Feb 27 01:55:27 2017 From: schily at schily.net (Joerg Schilling) Date: Sun, 26 Feb 2017 16:55:27 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170226152545.GA24045@indra.papnet.eu> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <20170226152545.GA24045@indra.papnet.eu> Message-ID: <58b2fa6f.lxYDRTAIh525gBIN%schily@schily.net> Angelo Papenhoff wrote: > Whoops, replied off list too accidentally, sorry Jörg. Woops replied off list as well... Angelo Papenhoff wrote: > On 26/02/17, Joerg Schilling wrote: > > GNU EMACS is based on the Gosling EMACS and this did already include the LISP > > interpreter. > > > > When Gosling started to work for Sun, he did no longer have the time to > > maintain it and did hand it over to Unipress. RMS did take this code, added a > > few small changed and sold it under the name GNU emacs. > > As far as I know the original LISP implementation in Gosling EMACS had > to be completely rewritten. I just don't remember where I've read this. Unipress asked RMS to rewrite the screen update code before distributing it as GNU emacs or they will sue RMS. It is not clear how much of the code was really rewritten. What I can tell is that the GNU emacs uses a screen update that is as slow as the original code from Gosling that Gosling took from another own project - an ASCII art editor that needed to be able to handle more than one simultaneous change at a time. My background is that I did a lot of benchmarking on Gosling Emacs, GNU Emacs, vi and my VED around 1985. It turned out that RMS may have rewritten the code but did not change the algorithm. My own screen update from VED is much faster even though it can only handle either a single deletion or a single insertion at a time. Changes are implemented as a delete operation followed by an insert operation ahd this turns out to be much faster than what emacs does. BTW: one reason why emacs is slow is that the status line is at the bottom rather than being the top line as in VED. If you use emacs on a real terminal, you see the status line hopping... The oldest changelog file in GNU emacs claims on the bottom line something like: "Now all Gosling code has been rewritten". Given the fact that the screen update still basically uses the same algorithm, it is not clear what this statement means. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From cym224 at gmail.com Mon Feb 27 02:05:19 2017 From: cym224 at gmail.com (Nemo) Date: Sun, 26 Feb 2017 11:05:19 -0500 Subject: [TUHS] The size of EMACS, and what hides in kLOCs Message-ID: On 26 February 2017 at 07:46, Michael Kjörling wrote: > On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): >> I was never happy with the size of EMACS, and it had nothing to do with the >> amount of memory resources used. That big a binary implies a very large amount >> of source, and the more lines of code, the more places for bugs... > > But remember; without Emacs, we might never have had _The Cuckoo's > Egg_. Imagine the terror of that loss. Hhhmmm.... I must dig my copy out of storage because I do not remember emacs in there. As for emac uses, my wife was on (non-CS) staff at a local college affiliated with U of T. At the time, DOS boxes sat on staff desks and email was via a telnet connection to an SGI box somewhere on campus. A BATch file connected and ran pine but shelled out to an external editor. What was the editor? Well, I saw her composing a message once and ending the editor session by ^X^C. N. From tfb at tfeb.org Mon Feb 27 02:06:07 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Sun, 26 Feb 2017 16:06:07 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: On 26 Feb 2017, at 14:19, Michael Kerpan wrote: > > My supposition is that EMACS was basically Stallman's attempt to bring in all the things he liked about the LISP Machine environment into the Unix world through the back door. I think this is at least partly right, although either RMS didn't like most of the really interesting things about the LispM environments or he was not involved in many of the developments which made them interesting: I suspect at least partly the latter as he presumably stopped being involved when Symbolics became seriously independent from the MIT AI lab and/or the hardware became too divergent (the 3600 I guess: I don't know if the AI lab had lots of those, they were certainly eye-wateringly expensive for those of us bought up on Suns). It may also be that a lot of the LispM stuff was genuinely hard to support on hardware which, for instance, wanted to distinguish between the OS and userland in any serious way until much later, although I'm reluctant to believe that. Slightly more on-topic, it seems to me really interesting that both the LispM & Unix environments really aim at providing comfortable places for programmers to work in, and specifically for the people writing the OS to work in (as opposed to some other OSs which clearly were more aimed at production applications) but they did it in such enormously different ways. Some of this has been fairly well-explored I think, by the famous 'worse is better' paper & its successors, but I don't think that's the whole answer. Both Unix and the LispMs encourage a way of working where you build little tools to do things, often things that get used only a few times, but the *way* you do that is completely different. And Unix is ultimately the better answer I think, because you can build a LispM-type environment on Unix but you can't realistically do it the other way around (the filesystem on LispMs was not up to what you'd want to run a Unix-style world on top of it, for one thing). So I don't think that this has really been sorted-out yet: certainly I'm confused and I've spent a lot of time in both worlds. --tim From tfb at tfeb.org Mon Feb 27 02:06:09 2017 From: tfb at tfeb.org (tfb at tfeb.org) Date: Sun, 26 Feb 2017 16:06:09 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> Message-ID: On 26 Feb 2017, at 15:52, Joerg Schilling wrote: > > OK, then Gosling just had the idea of including lisp. I'd have to check the chronology but I'm fairly sure that EINE predates Gosling Emacs by several years: I'd assume that either EINE is where Gosling got the idea, or that it was just obvious, since Emacs came from an environment where implementing things in Lisp was not a strange idea, to put it rather mildly. (Note I agree that Gosling Emacs is the root of Emacs-on-Unix and that without that Emacs would likely have died out with the platforms it lived on.) --tim From krewat at kilonet.net Mon Feb 27 02:13:25 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Sun, 26 Feb 2017 11:13:25 -0500 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <1488080787.179627.892986096.7AD36438@webmail.messagingengine.com> References: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com> <1488080787.179627.892986096.7AD36438@webmail.messagingengine.com> Message-ID: What filesystem type does it use for root/boot/whatever? Install operating system "X" that supports that filesystem type in the virtual guest, create a new disk, newfs/mkfs it, arrange the bits from the tape, take the newly-assembled disk and move to another VM and try to boot it. Not remembering anything about how SVR3.2 boots (I think that's what Opendesktop is?) that's the end of my help on the subject :) On 2/25/2017 10:46 PM, Cory Smelosky wrote: > > I'm also missing the floppies, though. > > -- > Cory Smelosky > b4 at gewt.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From madcrow.maxwell at gmail.com Mon Feb 27 02:22:42 2017 From: madcrow.maxwell at gmail.com (Michael Kerpan) Date: Sun, 26 Feb 2017 11:22:42 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> Message-ID: On Feb 26, 2017 10:52 AM, "Joerg Schilling" wrote: Tim Bradshaw wrote: > > > On 26 Feb 2017, at 14:54, Joerg Schilling wrote: > > > > GNU EMACS is based on the Gosling EMACS and this did already include the LISP > > interpreter. > > Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one). OK, then Gosling just had the idea of including lisp. IIRC, Gosling EMACS was mainly written in C, and Mocklisp was merely an extension language. GNU EMACS is mostly written in LISP, with the C mainly being used to implement the LISP interpreter. That's a pretty big architectural difference there. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Mon Feb 27 02:27:01 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 11:27:01 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> Message-ID: <008701d2904d$29d56c60$7d804520$@ronnatalie.com> Tim is right. EINE predates Gosling's EMACS by a few years. Of course, it uses LISP as an extension language not because they thought that would be novel but since the whole thing was implemented in LISP to begin with (much as you could extend the TECO EMACS with more TECO). And you are right, since EMACS (both the TECO and EINE and other variants) were coming out of the AI realm where LISP prevails, using LISP as a language certainly made sense. It was also really easy to implmenet a cheap mocklisp parser as Gosling did in the an otherwise C language implementation. I worked with Gosling and his successor Mike Gallaher (at Unipress) for years on the Unipress commercialization of Gosling's EMACS (I had been using the early non-commercial version at BRL). Gosling was a big fan of programmable interfaces. From the EMACS mocklisp, he went to developing the NeWS window system (which used a variant of PostScript as it's language) and then on to JAVA. I did a bunch of stuff with NeWS and Gallaher's subsequent similar extension module SoftWire (also commercially used by my company as PixScript). Even with Owen Densmore's (Sun Microsystems) object oriented changes, it was a horrendous language to actually write stuff in. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of tfb at tfeb.org I'd have to check the chronology but I'm fairly sure that EINE predates Gosling Emacs by several years: I'd assume that either EINE is where Gosling got the idea, or that it was just obvious, since Emacs came from an environment where implementing things in Lisp was not a strange idea, to put it rather mildly. From ron at ronnatalie.com Mon Feb 27 02:30:01 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 11:30:01 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: <008901d2904d$94af6590$be0e30b0$@ronnatalie.com> > Slightly more on-topic, it seems to me really interesting that both the LispM & Unix environments really aim at providing comfortable places for programmers to work in, and specifically for the people writing the OS to work in (as opposed to some other OSs which clearly were more aimed at production applications) but they did it in such enormously different ways. Isn't that what Programmer's WorkBench was alp about. We had picked up random stuff out of PWB (notably the shell) at JHU, but didn't really use the PWB aspects of it. My first job after college (intermixed with writing some design documents for the database system I was supposed to be working on ) was helping the QA department setup the procedures to use PWB (SCCS and various other things) to implement the software engineering environment. While PWB was sort of targeted on RJE submittal to IBM mainframes, we were using it to control the software development for a RSX-11M based intelligience system. From ron at ronnatalie.com Mon Feb 27 02:36:40 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 11:36:40 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> Message-ID: <008e01d2904e$82375980$86a60c80$@ronnatalie.com> Gosling Emacs was indeed written in C. But so is/was GNU EMACS. It started by outright stealing not only one of Gosling’s earlier (pre-commercial) releases but RMS made off with improvements done at UNIPRESS. However, after much wrangling between James, Unipress, and RMS, RMS backed out the stuff stolen from UNIPRESS and chucked out Gosling’s “mocklisp” interpretter for what RMS felt was a more correct “mlisp” implementation. Of course, most of the lisp stuff was largely original to RMS’s project. This accounts for the really anti-UNIX ugliness in some of his keybindings that is always the thing I program when I have to use a Xemacs implementation (who the hell thought using BACKSPACE for “help” was a good idea? Well I know who, his maloderous self used to show up at my house from time to time). My coworkers always used to laugh at me. If there was no EMACS-like editor on the machine (I also variously used Montgomery’s EMACS and finally JOVE) on smaller machines that GosMacs was too heavy for), I would just use “ed” (having been a master of that from when that was all there was). I never learned vi, and if I was stuck using it, I ran it in ex mode. I had a brief stint with the RandEditor AKA Interactive Systems editor derived from it (InED). From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Michael Kerpan Sent: Sunday, February 26, 2017 11:23 AM To: tuhs at tuhs.org Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years? On Feb 26, 2017 10:52 AM, "Joerg Schilling" wrote: Tim Bradshaw wrote: > > > On 26 Feb 2017, at 14:54, Joerg Schilling wrote: > > > > GNU EMACS is based on the Gosling EMACS and this did already include the LISP > > interpreter. > > Well, Gosling Emacs had mocklisp which, despite its name, isn't a Lisp. GNU Emacs has elisp which *is* a Lisp (albeit a fairly horrid one). OK, then Gosling just had the idea of including lisp. IIRC, Gosling EMACS was mainly written in C, and Mocklisp was merely an extension language. GNU EMACS is mostly written in LISP, with the C mainly being used to implement the LISP interpreter. That's a pretty big architectural difference there. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mutiny.mutiny at rediffmail.com Mon Feb 27 02:46:23 2017 From: mutiny.mutiny at rediffmail.com (Mutiny ) Date: 26 Feb 2017 16:46:23 -0000 Subject: [TUHS] =?utf-8?q?The_size_of_EMACS=2C_and_what_hides_in_kLOCs?= In-Reply-To: Message-ID: <1488125142.S.6508.12698.f4-234-213.1488127583.13977@webmail.rediffmail.com> > On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):>> I was never happy with the size of EMACS, and it had nothing to do with >> the amount of memory resources used. That big a binary implies a very >> large amount of source, and the more lines of code, the more places for >>bugs...GNU Emacs 26.0.50, GTK+ Version 3.22.8) of 2017-02-25 (Fedora25, Kernel: 4.9.11:Virtual: 794.6Resident:  36.8  -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Mon Feb 27 03:05:43 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 26 Feb 2017 17:05:43 +0000 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: References: <20170226124657.GB21079@yeono.kjorling.se> Message-ID: <20170226170543.GA21831@yeono.kjorling.se> On 26 Feb 2017 11:05 -0500, from cym224 at gmail.com (Nemo): > On 26 February 2017 at 07:46, Michael Kjörling wrote: >> But remember; without Emacs, we might never have had _The Cuckoo's >> Egg_. Imagine the terror of that loss. > > Hhhmmm.... I must dig my copy out of storage because I do not remember > emacs in there. In the translated text that I have, the hacker relied primarily on Emacs' mail feature to move the compromised atrun into place for execution, in order to gain temporary root privileges. It is possible that Stoll's original English text is more specific about which exact feature was used; the translation does leave a little to be desired in places where it's actually noticable even without having seen the original, so I would not hold it beyond the translator (in 1991; gosh, that's over a quarter of a century ago now) to not be completely familiar with the finer points of Unix editors, or possibly even wanting to simplify a little for a _readership_ that couldn't be expected to. -- 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 ron at ronnatalie.com Mon Feb 27 03:15:07 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 12:15:07 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> Message-ID: <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> RMS had pretty much left both the LISP machine and the DEC MAINFRAME (TOPS20 and ITS) by the time he got around to creating EMACS, he started GNU because he wanted a new super system and he figured starting with UNIX which he regarded (if you read the manifesto) as incredibly deficient. The idea was to come up with a new UNIX-ish kernel with all the crap he had come accustomed to on the LISP machines and iTS. Of course, he got run over by LINUX along the way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at kjorling.se Mon Feb 27 03:20:11 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 26 Feb 2017 17:20:11 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> Message-ID: <20170226172011.GC21831@yeono.kjorling.se> On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie): > Of course, he got run over by LINUX along the way. ...and even today, while the GNU userland sees reasonable use (just about every Linux distribution targetting the desktop or server niches use it, except for the few minimalistic ones that rely primarily on Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives a life of obscurity and few even know what it is, let alone knows anyone who uses it for anything even half-way serious. -- 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 ron at ronnatalie.com Mon Feb 27 03:23:01 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 12:23:01 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170226172011.GC21831@yeono.kjorling.se> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> Message-ID: <00c401d29054$fbdea210$f39be630$@ronnatalie.com> I didn't say that GNU wasn't a necessary part, it's just I think RMS feels he lost control of things when LINUX displaced his plans for the kernel. Obviously, much of the user mode is entirely beholden to the GNU project starting with GCC and the run tlime libraries. The only major system that really isn't is the display system which is X. -----Original Message----- From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Michael Kjörling Sent: Sunday, February 26, 2017 12:20 PM To: tuhs at minnie.tuhs.org Subject: Re: [TUHS] Un-released/internal/special UNIX versions/ports during the years? On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie): > Of course, he got run over by LINUX along the way. ...and even today, while the GNU userland sees reasonable use (just about every Linux distribution targetting the desktop or server niches use it, except for the few minimalistic ones that rely primarily on Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives a life of obscurity and few even know what it is, let alone knows anyone who uses it for anything even half-way serious. -- 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 usotsuki at buric.co Mon Feb 27 03:33:33 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 26 Feb 2017 12:33:33 -0500 (EST) Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <20170226172011.GC21831@yeono.kjorling.se> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> Message-ID: On Sun, 26 Feb 2017, Michael Kjörling wrote: > On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie): >> Of course, he got run over by LINUX along the way. > > ...and even today, while the GNU userland sees reasonable use (just > about every Linux distribution targetting the desktop or server niches > use it, except for the few minimalistic ones that rely primarily on > Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives > a life of obscurity and few even know what it is, let alone knows > anyone who uses it for anything even half-way serious. I've thought of implementing a system using musl, clang and the Solaris userland on Linux just to prove that not all Linux is GNU/Linux. (As if Android doesn't always prove that.) -uso. From michael at kjorling.se Mon Feb 27 03:39:18 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 26 Feb 2017 17:39:18 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> Message-ID: <20170226173918.GD21831@yeono.kjorling.se> On 26 Feb 2017 12:33 -0500, from usotsuki at buric.co (Steve Nickolas): > On Sun, 26 Feb 2017, Michael Kjörling wrote: >> ...so it's pretty hard to run Linux and not GNU... > > I've thought of implementing a system using musl, clang and the > Solaris userland on Linux just to prove that not all Linux is > GNU/Linux. (As if Android doesn't always prove that.) Yes, Android of course being the obvious counterexample to what I wrote, which I thought of only after hitting send. Sorry. -- 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 madcrow.maxwell at gmail.com Mon Feb 27 03:39:54 2017 From: madcrow.maxwell at gmail.com (Michael Kerpan) Date: Sun, 26 Feb 2017 12:39:54 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> Message-ID: Personally, I'd like to see something using the Heirloom Tools userspace. Heirloom *roff, in particular, is miles ahead of GNU (especially when dealing with fonts) while also being much lighter weight. The only bit of GNU that I'd keep in my "ideal" OS would be GCC, which still produces better output than Clang. Mike On Feb 26, 2017 12:33 PM, "Steve Nickolas" wrote: > On Sun, 26 Feb 2017, Michael Kjörling wrote: > > On 26 Feb 2017 12:15 -0500, from ron at ronnatalie.com (Ron Natalie): >> >>> Of course, he got run over by LINUX along the way. >>> >> >> ...and even today, while the GNU userland sees reasonable use (just >> about every Linux distribution targetting the desktop or server niches >> use it, except for the few minimalistic ones that rely primarily on >> Busybox, so it's pretty hard to run Linux and not GNU), GNU Hurd lives >> a life of obscurity and few even know what it is, let alone knows >> anyone who uses it for anything even half-way serious. >> > > I've thought of implementing a system using musl, clang and the Solaris > userland on Linux just to prove that not all Linux is GNU/Linux. (As if > Android doesn't always prove that.) > > -uso. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pechter at gmail.com Mon Feb 27 04:01:31 2017 From: pechter at gmail.com (William Pechter) Date: Sun, 26 Feb 2017 13:01:31 -0500 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <008e01d2904e$82375980$86a60c80$@ronnatalie.com> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> <008e01d2904e$82375980$86a60c80$@ronnatalie.com> Message-ID: <25536f85-cf80-bf01-4f9b-a4005da5caf6@gmail.com> Ron Natalie wrote: > > Gosling Emacs was indeed written in C. But so is/was GNU EMACS. It > started by outright stealing not only one of Gosling’s earlier > (pre-commercial) releases but RMS made off with improvements done at > UNIPRESS. > > However, after much wrangling between James, Unipress, and RMS, RMS > backed out the stuff stolen from UNIPRESS and chucked out Gosling’s > “mocklisp” interpretter for what RMS felt was a more correct “mlisp” > implementation. Of course, most of the lisp stuff was largely > original to RMS’s project. This accounts for the really anti-UNIX > ugliness in some of his keybindings that is always the thing I program > when I have to use a Xemacs implementation (who the hell thought using > BACKSPACE for “help” was a good idea? Well I know who, his > maloderous self used to show up at my house from time to time). > > My coworkers always used to laugh at me. If there was no EMACS-like > editor on the machine (I also variously used Montgomery’s EMACS and > finally JOVE) on smaller machines that GosMacs was too heavy for), I > would just use “ed” (having been a master of that from when that was > all there was). I never learned vi, and if I was stuck using it, I > ran it in ex mode. I had a brief stint with the RandEditor AKA > Interactive Systems editor derived from it (InED). > > Interesting how the Rand Editor seems to have been the choice of many. Perkin-Elmer (later Concurrent) based their in-house office automation software ("Paper Free in '83.") On dog-slow UniPlus SysIII (IIRC -- later MicroXelos UniPlus SysV based I think) on 68000 cpu 8 mhz machines. No virtual memory a dog-crap slow video subsystem. Of course I got a truck load of them when they dumped them and I used them to do the two county wide newsfeed until the PC Unix stuff became available. http://www.1000bit.it/ad/bro/perkin/PerkinElmer7350.pdf The nice one I had was an XF200 MicroXelos box -- which was RARE. It was a minitower without the graphics and with room for a pair of 80mb MFM drives. Did one of 'em for system and user accts and one for partial newsfeed. -- Digital had it then. Don't you wish you could buy it now! pechter-at-gmail.com http://xkcd.com/705/ From tfb at tfeb.org Mon Feb 27 04:23:55 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Sun, 26 Feb 2017 18:23:55 +0000 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: <20170226170543.GA21831@yeono.kjorling.se> References: <20170226124657.GB21079@yeono.kjorling.se> <20170226170543.GA21831@yeono.kjorling.se> Message-ID: <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org> On 26 Feb 2017, at 17:05, Michael Kjörling wrote: > > In the translated text that I have, the hacker relied primarily on > Emacs' mail feature to move the compromised atrun into place for > execution, in order to gain temporary root privileges. This was the movemail SUID bug, and it's indeed in the original although I'm not sure how much detail he goes into. From norman at oclsc.org Mon Feb 27 04:33:50 2017 From: norman at oclsc.org (Norman Wilson) Date: Sun, 26 Feb 2017 13:33:50 -0500 Subject: [TUHS] Mach for i386 / Mt Xinu or other Message-ID: <1488134034.25263.for-standards-violators@oclsc.org> Dave Horsfall: And if my failing memory serves me correctly, [Henry Spencer] wrote C-News in conjunction with Geoff Collier, as B-News was starting to show its age and limitations. ==== Your failing memory is correct, except that his name is spelt Collyer, not Collier. Norman Wilson Toronto ON From lars at nocrew.org Mon Feb 27 04:40:47 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 26 Feb 2017 19:40:47 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> (Tim Bradshaw's message of "Sun, 26 Feb 2017 15:37:10 +0000") References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> Message-ID: <868tosre1c.fsf@molnjunk.nocrew.org> Tim Bradshaw writes: > There's also no real doubt that RMS was responsible for Emacs *as an > idea* as opposed to any particular implementation (Guy Steele is I > think the other person who might be held responsible, but I believe > he's said that it was RMS, which is good enough for me). Here's what they wrote about that 6 Jul 1978. RMS: The work done by GLS was a) to consider a large number of possible command sets, and suggest many interesting possible commands, and b) to begin doing actual work (on the purifier and start-up). Although none of this code survived after a week or so, I might never have been able to start doing anything if left to myself. I often have trouble getting off the ground. GLS: The account of my involvement given by RMS is essentially accurate. I started [EMACS] because I was getting tired of the kludginess of the TCMAC command arrangement, and saw in other editors neat commands that could not be fit cleanly into TECMAC. I therefore decided to perform a total reorganization of the command structure, and carefully examine all the other existing TECO-based editors, such as RMODE, DOC, and the ever-popular TMACS. Most of my work involved playing with assignments of commands to keys, and running around organizing discussions and soliciting comments. I made an initial stab at a loader, and I think I invented (or re-invented) the notion of a compressing loader, and invented most of the specific conventions for the EMACS loader (such as using _ for a space), though these conventions were greatly refined later. It was at about this point that RMS and others took over the development work, and did a much better job, much faster, than I could have. For this reason, as well as the pressure of classes and the maintenance of LISP, I was happy to let others take over [EMACS]. Thus, while I provided initial impetus and much of the original user-level command structure, most of the development work and succeeding refinements is to the credit of other people. From b4 at gewt.net Mon Feb 27 04:50:24 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sun, 26 Feb 2017 10:50:24 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: References: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com> <1488080787.179627.892986096.7AD36438@webmail.messagingengine.com> Message-ID: <1488135024.322111.893394360.3CDE0335@webmail.messagingengine.com> On Sun, Feb 26, 2017, at 08:13, Arthur Krewat wrote: > What filesystem type does it use for root/boot/whatever? > > Install operating system "X" that supports that filesystem type in > the virtual guest, create a new disk, newfs/mkfs it, arrange the bits > from the tape, take the newly-assembled disk and move to another VM > and try to boot it. > > Not remembering anything about how SVR3.2 boots (I think that's what > Opendesktop is?) that's the end of my help on the > subject :) Now that's a bit of a bootstrap paradox. ;) I should be able to do that, actually. Just need...time. > > > > -- Cory Smelosky b4 at gewt.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Mon Feb 27 04:50:50 2017 From: b4 at gewt.net (Cory Smelosky) Date: Sun, 26 Feb 2017 10:50:50 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <20170226150722.D6C8540B9@lod.com> References: <20170226150722.D6C8540B9@lod.com> Message-ID: <1488135050.322146.893395000.197659CC@webmail.messagingengine.com> On Sun, Feb 26, 2017, at 07:07, Corey Lindsly wrote: > > > The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 > > > > Mail me if you're interested > > > > Cheers, > > rudi > > I seem to have CD and floppy images for SCO 2.1. > > drwxr-xr-x 2 corey 1002 4096 Feb 3 2006 ./ > drwxr-xr-x 27 corey 1002 20480 Feb 24 09:13 ../ > -rw-r--r-- 1 corey 1002 156 Oct 9 2006 README > -rwxr--r-- 1 corey 1002 564658176 Feb 2 2006 SCO-2.1-CD.iso* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 hba.dd* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 id.dd* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu1.dd* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu2.dd* > > I'm happy to provide them if anyone is interested. > > --corey I must archive EVERYTHING! ;) -- Cory Smelosky b4 at gewt.net From lars at nocrew.org Mon Feb 27 04:32:46 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Sun, 26 Feb 2017 19:32:46 +0100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <008701d2904d$29d56c60$7d804520$@ronnatalie.com> (Ron Natalie's message of "Sun, 26 Feb 2017 11:27:01 -0500") References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> <008701d2904d$29d56c60$7d804520$@ronnatalie.com> Message-ID: <86d1e4reep.fsf@molnjunk.nocrew.org> "Ron Natalie" writes: > > I'd have to check the chronology but I'm fairly sure that EINE > > predates Gosling Emacs by several years: I'd assume that either EINE > > is where Gosling got the idea, or that it was just obvious, since > > Emacs came from an environment where implementing things in Lisp was > > not a strange idea, to put it rather mildly. > Tim is right. EINE predates Gosling's EMACS by a few years. Of course, > it uses LISP as an extension language not because they thought that would be > novel but since the whole thing was implemented in LISP to begin with (much > as you could extend the TECO EMACS with more TECO). RMS credits Multics Emacs with the idea to use Lisp as the extension language: The language that you build your extensions on shouldn't be thought of as a programming language in afterthought; it should be designed as a programming language. In fact, we discovered that the best programming language for that purpose was Lisp. It was Bernie Greenberg, who discovered that it was. He wrote a version of Emacs in Multics MacLisp, and he wrote his commands in MacLisp in a straightforward fashion. The editor itself was written entirely in Lisp. Multics Emacs proved to be a success great programming new editing commands was so convenient that even the secretaries in his office started learning how to use it. https://www.gnu.org/gnu/rms-lisp.html From david at kdbarto.org Mon Feb 27 05:16:54 2017 From: david at kdbarto.org (David) Date: Sun, 26 Feb 2017 11:16:54 -0800 Subject: [TUHS] Emacs and undump In-Reply-To: References: Message-ID: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> I ported GNU Emacs to the Celerity product line mostly because most of the programmers there wanted it over vi. Not me, I’m a vi guy. I remember that GNU Emacs launched the first time and then dumped itself out as a core file. Each subsequent launch would then ‘undump’ itself back into memory. All this because launching emacs the first time required compiling all that lisp code. Does anyone else remember this? David From jim at deitygraveyard.com Mon Feb 27 05:19:08 2017 From: jim at deitygraveyard.com (Jim Carpenter) Date: Sun, 26 Feb 2017 14:19:08 -0500 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org> References: <20170226124657.GB21079@yeono.kjorling.se> <20170226170543.GA21831@yeono.kjorling.se> <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org> Message-ID: On Sun, Feb 26, 2017 at 1:23 PM, Tim Bradshaw wrote: > This was the movemail SUID bug, and it's indeed in the original although I'm not sure how much detail he goes into. Not much detail: """ In the way it was installed on our Unix computer, the Gnu-Emacs editor lets you forward a mail file from your own directory to anyone else in an unusual way. It doesn't check to see who's receiving it, or even whether they want the file. It just renames the file and changes its ownership label. You've just transferred ownership of the file from you to me. No problem to sent a file from your area to mine. But you'd better not be able to move a file into the protected systems area: only the system manager is allowed there. Stallman's software had better make sure this can't happen. Gnu didn't check. It let anyone move a file into protected systems space. The hacker knew this; we didn't. The hacker used Gnu to swap his special atrun file for the system's legitimate version. Five minutes later, the system hatched his egg, and he held the keys to my computer. """ Jim From grawity at gmail.com Mon Feb 27 05:28:25 2017 From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=) Date: Sun, 26 Feb 2017 21:28:25 +0200 Subject: [TUHS] Emacs and undump In-Reply-To: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> Message-ID: On Sun, Feb 26, 2017 at 9:16 PM, David wrote: > I ported GNU Emacs to the Celerity product line mostly because most of the > programmers there wanted it over vi. Not me, I’m a vi guy. > > I remember that GNU Emacs launched the first time and then dumped itself > out as a core file. Each subsequent launch would then ‘undump’ itself back > into memory. All this because launching emacs the first time required > compiling all that lisp code. > It still does that, doesn't it? https://lwn.net/Articles/673724/ -- Mantas Mikulėnas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lm at mcvoy.com Mon Feb 27 05:33:49 2017 From: lm at mcvoy.com (Larry McVoy) Date: Sun, 26 Feb 2017 11:33:49 -0800 Subject: [TUHS] roff In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> Message-ID: <20170226193349.GA24397@mcvoy.com> On Sun, Feb 26, 2017 at 12:39:54PM -0500, Michael Kerpan wrote: > Personally, I'd like to see something using the Heirloom Tools userspace. > Heirloom *roff, in particular, is miles ahead of GNU (especially when > dealing with fonts) while also being much lighter weight. What's better about the old roff? The new roff has some pic enhancements that I like. I suspect the old roff includes grap, be nice to have that. From ron at ronnatalie.com Mon Feb 27 05:34:30 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 14:34:30 -0500 Subject: [TUHS] roff In-Reply-To: <20170226193349.GA24397@mcvoy.com> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> Message-ID: <00e201d29067$5a42bc80$0ec83580$@ronnatalie.com> > What's better about the old roff? The new roff has some pic enhancements that I like. I suspect the old roff includes grap, be nice to have that. It's utterly frozen. From ron at ronnatalie.com Mon Feb 27 05:36:39 2017 From: ron at ronnatalie.com (Ron Natalie) Date: Sun, 26 Feb 2017 14:36:39 -0500 Subject: [TUHS] roff In-Reply-To: <00e201d29067$5a42bc80$0ec83580$@ronnatalie.com> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> <00e201d29067$5a42bc80$0ec83580$@ronnatalie.com> Message-ID: <00e401d29067$a6dfc600$f49f5200$@ronnatalie.com> Amusingly someone sent me a document not that far back with a table in it. I said "Did you use PIC and TBL with this?" He admitted he did. It had the little tell tail stray overshoots on the vertical lines. I would have thought someone would have fixed that in the interim. From michael at kjorling.se Mon Feb 27 05:39:27 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Sun, 26 Feb 2017 19:39:27 +0000 Subject: [TUHS] EMACS movemail suid root bug In-Reply-To: References: <20170226124657.GB21079@yeono.kjorling.se> <20170226170543.GA21831@yeono.kjorling.se> <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org> Message-ID: <20170226193927.GE21831@yeono.kjorling.se> On 26 Feb 2017 14:19 -0500, from jim at deitygraveyard.com (Jim Carpenter): > No problem to sent a file from your area to mine. But you'd better not > be able to move a file into the protected systems area: only the system > manager is allowed there. Stallman's software had better make sure this can't > happen. > > Gnu didn't check. It let anyone move a file into protected systems > space. The hacker knew this; we didn't. That agrees well with my translated version. So in a sense, everything that the Emacs movemail (thanks Tim) bug allowed you to do was _really_ enabled by the fact that there existed a user SOMEONE, for which ~SOMEONE was a directory, _used at least in part for privileged purposes by the operating system_, to which ordinary users were expected to not have any write access? Consequently, if system (as opposed to regular user) accounts had had a home directory set to something else, some place where it didn't really matter if an unprivileged user was able to drop files, then that bug would have been a nuisance (giving random users the ability to take up disk space unaccounted for, requiring clean-up) but not really the problem it became? Looking at my modern Debian system, I see users in /etc/passwd with home directories like /bin, /usr/sbin, /var/spool/postfix, /proc, /var/run/sshd, within but not actually /etc, ... So in effect, we are still to a large degree relying on people not making the same kind of mistake that was made in movemail when writing code that runs suid root. I know that anything running as suid root is potentially very dangerous, but that seems like a trivial mitigative strategy. (When was the last time anyone logged in as "daemon" on a modern Linux system, let alone needed their home directory then to be /usr/sbin?) -- 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 madcrow.maxwell at gmail.com Mon Feb 27 05:41:44 2017 From: madcrow.maxwell at gmail.com (Michael Kerpan) Date: Sun, 26 Feb 2017 14:41:44 -0500 Subject: [TUHS] roff In-Reply-To: <20170226193349.GA24397@mcvoy.com> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> Message-ID: Heirloom roff, as maintained at https://github.com/n-t-roff/heirloom-doctools, started with the code released as part of OpenSolaris and added UTF-8 support, support for various key bits added by groff, and then support for various modern "smartfont" features, as well as the ability to use modern font files directly rather than having to jump through various hoops. The whole package is much lighter than groff while also having more (useful) features and not having --very-long-options-like-this Mike On Sun, Feb 26, 2017 at 2:33 PM, Larry McVoy wrote: > On Sun, Feb 26, 2017 at 12:39:54PM -0500, Michael Kerpan wrote: >> Personally, I'd like to see something using the Heirloom Tools userspace. >> Heirloom *roff, in particular, is miles ahead of GNU (especially when >> dealing with fonts) while also being much lighter weight. > > What's better about the old roff? The new roff has some pic enhancements > that I like. I suspect the old roff includes grap, be nice to have that. From crossd at gmail.com Mon Feb 27 05:46:14 2017 From: crossd at gmail.com (Dan Cross) Date: Sun, 26 Feb 2017 14:46:14 -0500 Subject: [TUHS] roff In-Reply-To: <00e401d29067$a6dfc600$f49f5200$@ronnatalie.com> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> <00e201d29067$5a42bc80$0ec83580$@ronnatalie.com> <00e401d29067$a6dfc600$f49f5200$@ronnatalie.com> Message-ID: On Sun, Feb 26, 2017 at 2:36 PM, Ron Natalie wrote: > Amusingly someone sent me a document not that far back with a table in it. > I said "Did you use PIC and TBL with this?" He admitted he did. It > had > the little tell tail stray overshoots on the vertical lines. I would have > thought someone would have fixed that in the interim. > When I was getting deployed to Afghanistan, we were given a little laminated card with a "cheat sheet" of important bits of radio protocol on it: how to call for a casualty evacuation, unexploded ordinance (I had to use that one once, btw...), a thing called a MIST report that detailed injuries, etc. Anyway, something about the fonts and I *knew* it had been written using troff. Of course, we didn't have the source, just the card...so I sat down and recreated it. I printed a whole bunch out, laminated them and gave them to my Marines to hang onto. I probably still have the PIC file laying around my directory somewhere. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From grog at lemis.com Mon Feb 27 06:49:00 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 27 Feb 2017 07:49:00 +1100 Subject: [TUHS] Portability (was: BSDi Imaging) In-Reply-To: <20170226125050.9691E18C09B@mercury.lcs.mit.edu> References: <20170226125050.9691E18C09B@mercury.lcs.mit.edu> Message-ID: <20170226204900.GC15516@eureka.lemis.com> On Sunday, 26 February 2017 at 7:50:50 -0500, Noel Chiappa wrote: > > There were in theory portable languages beforehand (e.g. PL/1), but > I think it probably over-specified things - e.g. it would be > impossible to port Multics to another architecture without almost > completely re-writing it from scratch, the code is shot through with > "fixed bin(18)"'s every other line... That may be coloured by your perspective. C was never designed to be portable, while much older languages like Algol and Cobol were. There were quite different reasons for C's success. To quote "The Programmer's ABC's” from Datamation, April 1976: C is for Cobol What a pity It was designed By a committee 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 schily at schily.net Mon Feb 27 07:27:32 2017 From: schily at schily.net (Joerg Schilling) Date: Sun, 26 Feb 2017 22:27:32 +0100 Subject: [TUHS] roff In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> Message-ID: <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net> Michael Kerpan wrote: > Heirloom roff, as maintained at > https://github.com/n-t-roff/heirloom-doctools, started with the code This is where troff used to be maintained until around summer 2011. While most heirloom programs did only get attention for aprox. 3 months, troff, mailx and vi have been maintained for a longer time. Then, since aprox. 6 years ago no traces to Gunnar Ritter have been seen in the net anymore. Fortunately, mailx and troff now have new maintainers and can be found on github. troff now is at: https://github.com/n-t-roff/heirloom-doctools Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From schily at schily.net Mon Feb 27 07:28:53 2017 From: schily at schily.net (Joerg Schilling) Date: Sun, 26 Feb 2017 22:28:53 +0100 Subject: [TUHS] roff In-Reply-To: <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net> Message-ID: <58b34895.eLW6WgZ6wDmxHqbV%schily@schily.net> schily at schily.net (Joerg Schilling) wrote: > Michael Kerpan wrote: > > > Heirloom roff, as maintained at > > https://github.com/n-t-roff/heirloom-doctools, started with the code > > This is where troff used to be maintained until around summer 2011. Sorry for my fault, I thought I did see sourceforge here instead of github. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From steve at quintile.net Mon Feb 27 10:19:32 2017 From: steve at quintile.net (Steve Simon) Date: Mon, 27 Feb 2017 00:19:32 +0000 Subject: [TUHS] troff, flo Message-ID: <4cef0a0d14718c2e60b108c6b0d16034@quintile.net> Hi, On the subject of Troff, this package seems to have disappeared: flo—A Language for Typesetting Flowcharts Anthony P. Wolfman and Daniel M. Berry Computer Science, Technion, Haifa 32000, ISRAEL 1989 The paper about it is available but the code has gone. Anyone have an archive of it? -Steve From rudi.j.blom at gmail.com Mon Feb 27 10:44:33 2017 From: rudi.j.blom at gmail.com (Rudi Blom) Date: Mon, 27 Feb 2017 07:44:33 +0700 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 Message-ID: Wasn't the default FS type S51K? Limitations like 14 chars directory names only. No symbolic link ? >Date: Sun, 26 Feb 2017 11:13:25 -0500 >From: Arthur Krewat >To: Cory Smelosky , Jason Stevens > , tuhs at minnie.tuhs.org >Subject: Re: [TUHS] SCO OpenDesktop 386 2.0.0 >Message-ID: >Content-Type: text/plain; charset="utf-8"; Format="flowed" > >What filesystem type does it use for root/boot/whatever? > >Install operating system "X" that supports that filesystem type in the >virtual guest, create a new disk, newfs/mkfs it, arrange the bits from >the tape, take the newly-assembled disk and move to another VM and try >to boot it. > >Not remembering anything about how SVR3.2 boots (I think that's what >Opendesktop is?) that's the end of my help on the subject :) From cym224 at gmail.com Mon Feb 27 11:00:15 2017 From: cym224 at gmail.com (Nemo) Date: Sun, 26 Feb 2017 20:00:15 -0500 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: References: Message-ID: On 26 February 2017 at 12:28, Andy Kosela wrote: [...] > Are you sure it was emacs? Most probably it was pico, which was the default > editor for pine. We used pine/pico for all email at our university in the > 90's. It was wildly popular. Ah well, I am not sure -- that betrayed my emacs bias. I saw ^X^C and assumed emacs. N. From scj at yaccman.com Mon Feb 27 11:08:39 2017 From: scj at yaccman.com (Steve Johnson) Date: Sun, 26 Feb 2017 17:08:39 -0800 Subject: [TUHS] Portability (was: BSDi Imaging) In-Reply-To: <20170226204900.GC15516@eureka.lemis.com> Message-ID: <3f132e39d3cca090ac41a0766c159548121f1e54@webmail.yaccman.com> I couldn't disagree more.  Here is some background. I didn't have much experience with COBOL or Algol -- Bell Labs was a FORTRAN shop.  And we had a strong need to run FORTRAN programs on many different kinds of computers.  So the portability of FORTRAN programs was very important.  Barbara Ryder built a program (in FORTRAN!) called the PFORT verifier that verified that a FORTRAN program could be run on any of the six dominant machines of the day (this was an inspiration for Lint, by the way).  It was incredible what differences she found in this "portable" language when different implementations encountered the programs.  My favorite was a bug in one compiler that would cause a program that began with 50 comment cards to abort.  The FORTRAN program produced a title line on the listing (remember those?) that was printed out, and it used the first function name to get the title.  50 lines => new page, no title => blam.   The subtle bugs caused by copy-in/copy-out argument passing were especially icky. So portability was much in our minds in the late sixties and early seventies.  As Unix began to catch on, there was a desire to move some utilities to other systems.  Neither B nor the original C was really up to the job.  Remember that machines of the day had different character sets, different floating point implementations, and different byte and word sizes, word address vs. byte addressed, and with different word orders.  It was a zoo.  Moving programs in any language was difficult, not least because the operating systems were so different (remember JCL?). Late in 1974, as I recall, Dennis mused "You know, I think it would be easier to move Unix to a new machine than to change a large application to run on another operating system."  I thought about this for a few minutes, and then offered to write a portable C compiler.  I had already moved B and/or C from the PDP-11 to the Honeywell (36-bit words, 9 bit bytes, word addressed) and the IBM/360 (32-bits, byte addressed, but bizarre difficulties accessing memory in a reasonable fashion), so I had some idea what I was getting into.   We also persuaded the company to buy us a 32-bit minicomputer (the Interdata 4/32) with the goal of porting C and Unix to it. With so many different kinds of opcodes and data formats, Dennis made what I think was an inspired solution.   + meant "add" on whatever computer it was running on.   int was the natural word size.  etc. This had three very good properties: 1) it kept the language simple.   In particular, it kept us from having to specify bit widths for everything, which would then need to be changed when the program was ported to avoid inefficiency. 2) It kept the compiler simple.  This was essential on the small PDP-11. 3) It turned out that with the addition of Lint, many problems that could result from porting could be found, without preventing the program from running well on the host system. So C was indisputably intended to be portable, at least in that sense.  And in practice it was highly portable while sacrificing little in performance on different systems (unlike some other languages). There were drawbacks -- it wasn't perfect.  Cross compiling from one machine to a much different one still had its challenges.  Adopting the target machine's byte order made networking code harder to write.  And machines that considered character constants to be signed produced a lot of irritation (and a lot of Lint messages).  But it wasn't from lack of trying... Steve ----- Original Message ----- From: "Greg 'groggy' Lehey" To:"Noel Chiappa" Cc: Sent:Mon, 27 Feb 2017 07:49:00 +1100 Subject:[TUHS] Portability (was: BSDi Imaging) On Sunday, 26 February 2017 at 7:50:50 -0500, Noel Chiappa wrote: > > There were in theory portable languages beforehand (e.g. PL/1), but > I think it probably over-specified things - e.g. it would be > impossible to port Multics to another architecture without almost > completely re-writing it from scratch, the code is shot through with > "fixed bin(18)"'s every other line... That may be coloured by your perspective. C was never designed to be portable, while much older languages like Algol and Cobol were. There were quite different reasons for C's success. To quote "The Programmer's ABC'sâ from Datamation, April 1976: C is for Cobol What a pity It was designed By a committee 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 -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Mon Feb 27 11:19:07 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Mon, 27 Feb 2017 09:19:07 +0800 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: References: Message-ID: Emacs was the central exploit that "Jagger" used to gain root access once he got his way on a box. It's a fantastic book, with good lessons in there that still ring true, such as keeping a log, documenting what you did and why, not emailing passwords and running a honeypot. It also showed that if you weren't in the clique you didn't get source access and that finding even part of it was a big deal. It's a shame his next book, silicone snake oil missed the mark by so much. On February 27, 2017 12:05:19 AM GMT+08:00, Nemo wrote: >On 26 February 2017 at 07:46, Michael Kjörling >wrote: >> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel >Chiappa): >>> I was never happy with the size of EMACS, and it had nothing to do >with the >>> amount of memory resources used. That big a binary implies a very >large amount >>> of source, and the more lines of code, the more places for bugs... >> >> But remember; without Emacs, we might never have had _The Cuckoo's >> Egg_. Imagine the terror of that loss. > >Hhhmmm.... I must dig my copy out of storage because I do not remember >emacs in there. > >As for emac uses, my wife was on (non-CS) staff at a local college >affiliated with U of T. At the time, DOS boxes sat on staff desks and >email was via a telnet connection to an SGI box somewhere on campus. >A BATch file connected and ran pine but shelled out to an external >editor. What was the editor? Well, I saw her composing a message >once and ending the editor session by ^X^C. > >N. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From usotsuki at buric.co Mon Feb 27 11:48:59 2017 From: usotsuki at buric.co (Steve Nickolas) Date: Sun, 26 Feb 2017 20:48:59 -0500 (EST) Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: References: Message-ID: On Sun, 26 Feb 2017, Nemo wrote: > On 26 February 2017 at 12:28, Andy Kosela wrote: > [...] >> Are you sure it was emacs? Most probably it was pico, which was the default >> editor for pine. We used pine/pico for all email at our university in the >> 90's. It was wildly popular. > > Ah well, I am not sure -- that betrayed my emacs bias. I saw ^X^C and > assumed emacs. > > N. > Huh. pico's exit is just ^X, not ^X^C. -uso. From downing.nick at gmail.com Mon Feb 27 12:13:10 2017 From: downing.nick at gmail.com (Nick Downing) Date: Mon, 27 Feb 2017 13:13:10 +1100 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: References: Message-ID: Hmmm Emacs... Editor too large :) Well I don't use Emacs because it is the opposite of minimal, I mean partly from a purist standpoint, partly from a practical standpoint since we often have to do things like editing fstab before the system is fully up. I think Joerg mentioned use of vi "for emergencies" and that is always gonna be necessary, even for the Emacs people here. But if I'm gonna learn something "for emergencies" I'd probably rather just standardize on it, as I have done with vi. That's not to say I like vi, in fact I detest it, it is clunky and counterintuitive and modal and... I just can't stand the way it puts the cursor "on" the current character, so that you have to use "i" to insert before or "a" to insert after... and you can't standardize on "i" or "a" since "i" is needed at the start of the line and "a" at the end of the line... I can't stand the way it's line-oriented (obviously to do with its "ex" heritage) and so you can't search on ^M (can replace, luckily). I also have never fully bothered to learn the "vi" command set since I felt I was kind of "camping" until I found a better alternative, so I have improvised some truly strange sequences to do common things like deleting a line. Haha. And recently when I was working in the simulator with "old vi" rather than vim, I discovered it has some really bad limitations like line length... HOPEFULLY these are removed in "new vi", I will have to try reno in the simulator some time. But now to the point of my post, which is a bit of a convoluted story that DOES touch on Emacs at the end. Well way back in the early 80s when people believed that MSDOS would be distributed with a custom BIOS per machine like CP/M was... and each manufacturer had their MSDOS solution which was generally an 8086 or 8088 at around 5 MHz and wasn't IBM compatible... various relatives of mine did their own market research and bought interesting MSDOS machines. The most interesting and powerful at the time was my uncle's Victor 9000 aka Apricot ACT, it was a very futuristic machine for its time, with an 800x600 monochrome text and graphic display, variable speed floppies, I think he had 256k or maybe 512k in it, but it could go up to about 768k or more, unlike IBM's later PC. And, with the Victor 9000 was shipped a pretty good development system including... a text editor of TRULY AMAZING abilities. So the text editor was called PMATE, and it was supplied by Phoenix Software Associates (P=Phoenix MATE=Original name of the editor before they licensed it from its author). Yep that's Phoenix that later became famous for BIOSes. Later on they ported PMATE to IBM XT as well, basically they just changed the memory mapped screen to B000 or B800 as required by IBM's MDA or CGA respectively. I used PMATE for many years, it had an unbelievably great macro language, it had 10 buffers, you could put macros or text in each buffer, buffers could execute each other, it could grab text into a buffer and reinsert it somewhere else in your document, it could do search and replace with wildcards (not regular expressions unfortunately), it could do integer math (without operator precedence), it had various stacks and variables and control flow and looping constructs, various disk buffering modes and other settings. So using PMATE I was unbelievably productive, it was great for software development and for stuff like data entry or letter writing too. For instance my mum was secretary of the basketball club that myself and my brothers played for, we used to manage team lists and mailing lists and fixtures etc, as text files in PMATE, and when we were ready to do a mailout, we would have PMATE do a very specialized merge of all kinds of data from different files, and then generate an output that would be imported into WordPerfect 5.1 and laser printed. Another time a guy was doing an election campaign and he wanted all the electoral rolls for our district typed in (paper form was available from public record). So I got a bunch of friends together and we spent a week typing stuff into PMATE, after I implemented an autocomplete facility in macros that significantly sped things up by copying stuff from the previous line entered, etc etc. (The guy paid us about $4000 for this, and we spent part of the money buying a Streetfighter II arcade machine that was then communally owned by the group which I had got together to do the data entry job, very fun times for all :) ) Sad to say, the day came when PMATE had to be retired as I had switched over my primary development first to Windows (where PMATE worked but limped a bit due to its 64K limitation, despite all the tricky disk buffering it had), and then to Linux where PMATE did not work. I briefly tried running it under emulation. I did use the configuration utility to patch it to generate ANSI type scape sequences instead of using the memory mapped screen, and I even did some CP/M to native disk access translation (I was using the Z80 version which was called ZMATE, since the 8088 port didn't offer significant advantages in this setting). It was more or less useable, but just too clunky for everyday use compared with vi. Anyway I deeply mourned the loss and spent years trying to reverse engineer it, I did at one stage make a 386 version that worked under a DOS extender, but it would occasionally crash and I never got it debugged. In the course of all this I was VERY VERY keen to understand more about PMATE, finding the 8080 and Z80 versions on a little used CP/M archive was helpful, anyway it is written by a guy called Michael Aronsen (Arunsen?) and hence got it's name "Michael Aronsen's Text Editor". I was thinking what a genius this guy is and wondering why he dropped out of the scene and is no longer to be found anywhere online. I guess it was just a college project he did because he needed an editor, and eventually he sold it to Phoenix and washed his hands of it. WELL strangely whenever I searched for MATE or PMATE, as well as lots of advertisements for the Pee-Mate (a device which allows women to pee into a bottle during lectures or long train trips etc), it would often come up on lists of TECO implementations. I ignored this, having no idea what TECO was, or if I briefly looked at it, then I missed the true significance. Well lately, there was a reference on this list to LUSERing and the Incompatible Timesharing System (ITS), and I was idly browsing Wikipedia etc about ITS, reading some technical documents etc, and there was a lot of mention of Teco, this piqued my interest so I downloaded something like Tecoc or Video Teco and compiled it and gave it a shot... LO AND BEHOLD, PMATE IS REINCARNATED!!!! On Mon, Feb 27, 2017 at 12:19 PM, Jason Stevens wrote: > Emacs was the central exploit that "Jagger" used to gain root access once he > got his way on a box. > > It's a fantastic book, with good lessons in there that still ring true, such > as keeping a log, documenting what you did and why, not emailing passwords > and running a honeypot. > > It also showed that if you weren't in the clique you didn't get source > access and that finding even part of it was a big deal. > > It's a shame his next book, silicone snake oil missed the mark by so much. > > > On February 27, 2017 12:05:19 AM GMT+08:00, Nemo wrote: >> >> On 26 February 2017 at 07:46, Michael Kjörling >> wrote: >>> >>> On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa): >>>> >>>> I was never happy with the size of EMACS, and it had nothing to do with >>>> the >>>> amount of memory resources used. That big a binary implies a very large >>>> amount >>>> of source, and the more lines of code, the more places for bugs... >>> >>> >>> But remember; without Emacs, we might never have had _The Cuckoo's >>> Egg_. Imagine the terror of that loss. >> >> >> Hhhmmm.... I must dig my copy out of storage because I do not remember >> emacs in there. >> >> As for emac uses, my wife was on (non-CS) staff at a local college >> affiliated with U of T. At the time, DOS boxes sat on staff desks and >> email was via a telnet connection to an SGI box somewhere on campus. >> A BATch file connected and ran pine but shelled out to an external >> editor. What was the editor? Well, I saw her composing a message >> once and ending the editor session by ^X^C. >> >> N. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From dave at horsfall.org Mon Feb 27 15:08:16 2017 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 27 Feb 2017 16:08:16 +1100 (EST) Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <773222BF-B109-4EC0-8E55-F022AE7B69DA@tfeb.org> References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org> <20170225143255.GH21761@mcvoy.com> <773222BF-B109-4EC0-8E55-F022AE7B69DA@tfeb.org> Message-ID: On Sat, 25 Feb 2017, Tim Bradshaw wrote: > (Although why anyone who has looked at the tail of some bit of C-derived > language with its apparently endless sequence of close braces, carefully > arranged one-per line to maximise the wasted screen real-estate would > say this is beyond me.  One of Python's few good features is that it is > impossible to do this when writing Python -- although somewhere, no > doubt, there are coding style guidelines which say that Python > definitions must be separated from the following definition by 1 + > number-of-nesting-levels blank lines.) The last language I used where white-space was syntactical was FORTRAN... Death to Python! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer." From grog at lemis.com Mon Feb 27 16:31:42 2017 From: grog at lemis.com (Greg 'groggy' Lehey) Date: Mon, 27 Feb 2017 17:31:42 +1100 Subject: [TUHS] Portability (was: BSDi Imaging) In-Reply-To: <3f132e39d3cca090ac41a0766c159548121f1e54@webmail.yaccman.com> References: <20170226204900.GC15516@eureka.lemis.com> <3f132e39d3cca090ac41a0766c159548121f1e54@webmail.yaccman.com> Message-ID: <20170227063142.GD15516@eureka.lemis.com> On Sunday, 26 February 2017 at 17:08:39 -0800, Steve Johnson wrote: > I couldn't disagree more. I think you could have :-) But thanks for the followup and the details. > Late in 1974, as I recall, Dennis mused "You know, I think it would > be easier to move Unix to a new machine than to change a large > application to run on another operating system." I ... offered to > write a portable C compiler. By that time C on the PDP-11 had been round for a couple of years, right? And then you go on to be portable. On the other hand, my understanding of Algol and Cobol is that they didn't start with any specific architecture in mind. And it was that difference that I was thinking of when I said that C wasn't designed to be portable. A matter of viewpoint, maybe. I'm not belittling the design of C, nor your or Dennis' work, but there's nothing you've said here that suggested that C was designed from the outset to be portable. > So C was indisputably intended to be portable, at least in that > sense.  And in practice it was highly portable while sacrificing > little in performance on different systems (unlike some other > languages). That certainly applied to the difference between C and Algol. In defence of Algol, it had no prior art to build on. 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 tfb at tfeb.org Mon Feb 27 16:41:56 2017 From: tfb at tfeb.org (Tim Bradshaw) Date: Mon, 27 Feb 2017 06:41:56 +0000 Subject: [TUHS] Emacs and undump In-Reply-To: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> Message-ID: <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> > On 26 Feb 2017, at 19:16, David wrote: > > I remember that GNU Emacs launched the first time and then dumped itself out as a core file. Each subsequent launch would then ‘undump’ itself back into memory. All this because launching emacs the first time required compiling all that lisp code. It still works like that. Indeed that's the conventional way that Lisp systems tend to work for delivering applications: you compile and load your code into a running image and then dump that image in a form where it can be reloaded quickly. The dumped image is either directly executable or is loaded by some small bootstrap loader which might also provide some low-level support (but might not: all that can be in the dumped image). What you call these dumped images depends on your culture: they might be 'worlds', 'bands' or 'sysouts' among other things. (There are often also compiled files which are generally called fasl files, though in emacs they are elc files.) From lars at nocrew.org Mon Feb 27 17:19:17 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 27 Feb 2017 08:19:17 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> (Tim Bradshaw's message of "Mon, 27 Feb 2017 06:41:56 +0000") References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> Message-ID: <86y3wsp0cq.fsf@molnjunk.nocrew.org> Tim Bradshaw wrote: >> David wrote: >> I remember that GNU Emacs launched the first time and then dumped >> itself out as a core file. Each subsequent launch would then ‘undump’ >> itself back into memory. All this because launching emacs the first >> time required compiling all that lisp code. > It still works like that. Indeed that's the conventional way that > Lisp systems tend to work for delivering applications Emacs came from ITS, and many Lisps derive from Maclisp which also came from ITS. In ITS, it was common for applications to be dumped into a loadable core image, even if they were written in assembly language. From imp at bsdimp.com Mon Feb 27 17:26:08 2017 From: imp at bsdimp.com (Warner Losh) Date: Mon, 27 Feb 2017 00:26:08 -0700 Subject: [TUHS] Emacs and undump In-Reply-To: <86y3wsp0cq.fsf@molnjunk.nocrew.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> Message-ID: On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff wrote: > Tim Bradshaw wrote: >>> David wrote: >>> I remember that GNU Emacs launched the first time and then dumped >>> itself out as a core file. Each subsequent launch would then ‘undump’ >>> itself back into memory. All this because launching emacs the first >>> time required compiling all that lisp code. >> It still works like that. Indeed that's the conventional way that >> Lisp systems tend to work for delivering applications > > Emacs came from ITS, and many Lisps derive from Maclisp which also came > from ITS. In ITS, it was common for applications to be dumped into a > loadable core image, even if they were written in assembly language. Unix systems are retiring sbrk(2), so emacs is breaking on those systems. Trouble is, sbrk is kinda hard to implement on systems that allocate memory for processes from multiple pools and other crazy things. So now Emacs has no way of knowing where the upper limit was so it can't start allocating with its own custom allocator... At least GNU Emacs... Warner From rp at servium.ch Mon Feb 27 17:53:28 2017 From: rp at servium.ch (Rico Pajarola) Date: Sun, 26 Feb 2017 23:53:28 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <20170226150722.D6C8540B9@lod.com> References: <20170226150722.D6C8540B9@lod.com> Message-ID: Hi Corey can I have a copy? thanks Rico On Sun, Feb 26, 2017 at 7:07 AM, Corey Lindsly wrote: > > > The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 > > > > Mail me if you're interested > > > > Cheers, > > rudi > > I seem to have CD and floppy images for SCO 2.1. > > drwxr-xr-x 2 corey 1002 4096 Feb 3 2006 ./ > drwxr-xr-x 27 corey 1002 20480 Feb 24 09:13 ../ > -rw-r--r-- 1 corey 1002 156 Oct 9 2006 README > -rwxr--r-- 1 corey 1002 564658176 Feb 2 2006 SCO-2.1-CD.iso* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 hba.dd* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 id.dd* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu1.dd* > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu2.dd* > > I'm happy to provide them if anyone is interested. > > --corey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From downing.nick at gmail.com Mon Feb 27 18:12:09 2017 From: downing.nick at gmail.com (Nick Downing) Date: Mon, 27 Feb 2017 19:12:09 +1100 Subject: [TUHS] Emacs and undump In-Reply-To: References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> Message-ID: I've been having a bit of trouble with /bin/sh (Bourne's original one) for the same reason. I described my projects in more detail earlier, but in a nutshell I have intercepted open() and other syscalls, and I have implemented replacements so that old code like /bin/sh doesn't have to change, it sees a pretty BSD-like system. So one thing I had to do was check if the thing being opened is a directory, and if so I vacuum up the contents using the modern readdir() supplied in glibc or whatever, and then write a tempfile in a format which the old style readdir() understands. Then I return a handle to the tempfile instead of the directory. Trouble is, this makes a non-stdio-using program be stdio-using, in the worst case it's a non-stdio-using program that has its own malloc() based on sbrk()... so we get another malloc() happening in the middle, I temporarily fixed this by redirecting the modern system's malloc() into the ancient system's malloc() but this is a very non desirable solution. As another possibility I was thinking of changing the ancient system's sbrk() into realloc() and implementing a routine to relocate the heap, it obviously would have to understand everything on the heap and everything that can point into it. It's a real mess. But ultimately if I could get this right, I could implement a lightweight system with no memory manager where all processes share the malloc(). cheers, Nick On Mon, Feb 27, 2017 at 6:26 PM, Warner Losh wrote: > On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff wrote: >> Tim Bradshaw wrote: >>>> David wrote: >>>> I remember that GNU Emacs launched the first time and then dumped >>>> itself out as a core file. Each subsequent launch would then ‘undump’ >>>> itself back into memory. All this because launching emacs the first >>>> time required compiling all that lisp code. >>> It still works like that. Indeed that's the conventional way that >>> Lisp systems tend to work for delivering applications >> >> Emacs came from ITS, and many Lisps derive from Maclisp which also came >> from ITS. In ITS, it was common for applications to be dumped into a >> loadable core image, even if they were written in assembly language. > > Unix systems are retiring sbrk(2), so emacs is breaking on those > systems. Trouble is, sbrk is kinda hard to implement on systems that > allocate memory for processes from multiple pools and other crazy > things. So now Emacs has no way of knowing where the upper limit was > so it can't start allocating with its own custom allocator... > > At least GNU Emacs... > > Warner From michael at kjorling.se Mon Feb 27 18:26:13 2017 From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=) Date: Mon, 27 Feb 2017 08:26:13 +0000 Subject: [TUHS] The size of EMACS, and what hides in kLOCs In-Reply-To: References: Message-ID: <20170227082613.GA18184@yeono.kjorling.se> On 26 Feb 2017 20:48 -0500, from usotsuki at buric.co (Steve Nickolas): >> On 26 February 2017 at 12:28, Andy Kosela wrote: >>> Are you sure it was emacs? Most probably it was pico, which was the default >>> editor for pine. >> >> Ah well, I am not sure -- that betrayed my emacs bias. I saw ^X^C and >> assumed emacs. > > Huh. pico's exit is just ^X, not ^X^C. Yes. Pico and Nano have pretty much the same key bindings for everything that both have (there may be some minor exception), and ^X triggers an exit. If there are any unsaved changes, it will ask what to do; hitting ^C at that point brings you right back to the editor. Wikipedia puts Pine's birth at 1989, and public announcement in 1992, so that would be reasonably believable with DOS boxen as terminals... -- 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 wes.parish at paradise.net.nz Mon Feb 27 19:51:18 2017 From: wes.parish at paradise.net.nz (Wesley Parish) Date: Mon, 27 Feb 2017 22:51:18 +1300 (NZDT) Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: References: <20170226150722.D6C8540B9@lod.com> Message-ID: <1488189078.58b3f6960b9b5@www.paradise.net.nz> Count me in. I put my hand up for a copy of SCO when they were offering free samplers in the early 2000s, but never heard back from them. I wanted to compare it with Linux ... Thanks Wesley Parish Quoting Rico Pajarola : > Hi Corey > > can I have a copy? > > thanks > Rico > > > On Sun, Feb 26, 2017 at 7:07 AM, Corey Lindsly wrote: > > > > > > The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 > > > > > > Mail me if you're interested > > > > > > Cheers, > > > rudi > > > > I seem to have CD and floppy images for SCO 2.1. > > > > drwxr-xr-x 2 corey 1002 4096 Feb 3 2006 ./ > > drwxr-xr-x 27 corey 1002 20480 Feb 24 09:13 ../ > > -rw-r--r-- 1 corey 1002 156 Oct 9 2006 README > > -rwxr--r-- 1 corey 1002 564658176 Feb 2 2006 SCO-2.1-CD.iso* > > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 hba.dd* > > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 id.dd* > > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu1.dd* > > -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu2.dd* > > > > I'm happy to provide them if anyone is interested. > > > > --corey > > > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, Method for Guitar "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn From bqt at update.uu.se Mon Feb 27 20:24:47 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 27 Feb 2017 11:24:47 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: References: Message-ID: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> On 2017-02-27 08:26, Lars Brinkhoff wrote: > Tim Bradshaw wrote: >>> David wrote: >>> I remember that GNU Emacs launched the first time and then dumped >>> itself out as a core file. Each subsequent launch would then ‘undump’ >>> itself back into memory. All this because launching emacs the first >>> time required compiling all that lisp code. >> It still works like that. Indeed that's the conventional way that >> Lisp systems tend to work for delivering applications > Emacs came from ITS, and many Lisps derive from Maclisp which also came > from ITS. In ITS, it was common for applications to be dumped into a > loadable core image, even if they were written in assembly language. Not only i ITS. This is how things work in OS/8, for example. I believe it is also how things work in TOPS-10 and quite possible also in TOPS-20. Not sure about RT-11, but I wouldn't be surprised if that's the way there too. Essentially, the linker leaves the image in memory. It does not write it to a file. And then, the command decode have a command for dumping your memory to disk, as a runable image. There is some information kept around that the linker sets up, which means you don't normally have to tell the command decoder which parts of memory to save, or what the start address is, and so on. But you can also give that information in your save command. One of the nice things of this approach is that you can load an image into memory, and then use the debugger to look around in it, change it, or run it. And if the program exists, it is still in memory, including all data, which means you can check the state of everything at exit time. And of course, if you want to, you can load a program, patch around in it, in memory, and then run it. And, of course, you can load a program, run some part of it, and dump it to disk at that stage, so all initializations have been done. Your memory is always around, and is not tied to a process that comes and goes. Of course, the back side of that is that you can't really run several programs at once. But it's not hard to see that RMS and GNU Emacs (coming from these systems) wanted the same thing again. It do have some points. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From lars at nocrew.org Mon Feb 27 20:30:45 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 27 Feb 2017 11:30:45 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> (Johnny Billquist's message of "Mon, 27 Feb 2017 11:24:47 +0100") References: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> Message-ID: <86mvd8orhm.fsf@molnjunk.nocrew.org> Johnny Billquist writes: > Of course, the back side of that is that you can't really run several > programs at once. In ITS you can. You have one active job to which your command apply by default. But you can create new jobs and switch beteen them. From schily at schily.net Mon Feb 27 20:35:21 2017 From: schily at schily.net (Joerg Schilling) Date: Mon, 27 Feb 2017 11:35:21 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> Message-ID: <58b400e9.dJ2hxgoDSpv/lfTa%schily@schily.net> David wrote: > I ported GNU Emacs to the Celerity product line mostly because most of the programmers there wanted it over vi. Not me, I???m a vi guy. > > I remember that GNU Emacs launched the first time and then dumped itself out as a core file. Each subsequent launch would then ???undump??? itself back into memory. All this because launching emacs the first time required compiling all that lisp code. The file "sendmail.fc" is just the dump of the heap from sendmail. This method existed since a long time. BTW: undump(1) has been announced on a Sun User Group in 1987, but the next year, SunOS-4.0 came out and made things much harder to implement. I did never see an updated undump(1) source that would be able to deal with SunOS-4.0 and it's shared libraries. Does it exist? Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From bqt at update.uu.se Mon Feb 27 20:47:53 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 27 Feb 2017 11:47:53 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <86mvd8orhm.fsf@molnjunk.nocrew.org> References: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> <86mvd8orhm.fsf@molnjunk.nocrew.org> Message-ID: <95085781-7de7-1658-6150-ce9145d5ee49@update.uu.se> On 2017-02-27 11:30, Lars Brinkhoff wrote: > Johnny Billquist writes: >> Of course, the back side of that is that you can't really run several >> programs at once. > > In ITS you can. You have one active job to which your command apply by > default. But you can create new jobs and switch beteen them. Ah. It was so long ago, and I never learned ITS that well. However, I don't think you can have several jobs in Tops-10, and I know you can't in OS/8 or RT-11. But that's an interesting capability. To have several jobs around, with the memory intact, and you can switch between them, and play with their memory. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From tfb at tfeb.org Mon Feb 27 22:59:01 2017 From: tfb at tfeb.org (tfb at tfeb.org) Date: Mon, 27 Feb 2017 12:59:01 +0000 Subject: [TUHS] Emacs and undump In-Reply-To: <86y3wsp0cq.fsf@molnjunk.nocrew.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> Message-ID: <23910FC1-18D7-4B5F-8DF3-28CFBAEEDC6C@tfeb.org> On 27 Feb 2017, at 07:19, Lars Brinkhoff wrote: > > Emacs came from ITS, and many Lisps derive from Maclisp which also came > from ITS. In ITS, it was common for applications to be dumped into a > loadable core image, even if they were written in assembly language. I think the history of this must go back beyond ITS. InterLisp did the same thing, and it's a west-coast Lisp so probably not influenced by ITS (and it probably predates ITS in its beginnings). So either the idea was just pervasive (which is at least plausible I think) or it has its roots somewhere further back: I wonder what Lisp 1.5 did? Oddly I once learned something important about TCP because of this. I had a Xerox D-machine (an 1186, which was a Daybreak I think), which I needed to move somewhere. I was logged into it and running a Lisp image with lots of state, so I did whatever incantation was needed to write all the dirty pages to disk halt Lisp, turned the machine off and carried it wherever it needed to go, plugged power and network back in and restarted the image. Unbeknownst to me I had a couple of telnet windows open to Unix machines: when I turned the machine back on they were not only still open but they still had live sessions in them. Well, it seems obvious now, but that was the moment when I understood how TCP worked. --tim From krewat at kilonet.net Mon Feb 27 23:57:28 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 27 Feb 2017 08:57:28 -0500 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <1488189078.58b3f6960b9b5@www.paradise.net.nz> References: <20170226150722.D6C8540B9@lod.com> <1488189078.58b3f6960b9b5@www.paradise.net.nz> Message-ID: I'm in if it can be distributed. Is it something TUHS can archive? Sorry if that's a newbie question. On 2/27/2017 4:51 AM, Wesley Parish wrote: > Count me in. I put my hand up for a copy of SCO when they were offering free > samplers in the early 2000s, but never heard back from them. > > I wanted to compare it with Linux ... > > Thanks > > Wesley Parish > > Quoting Rico Pajarola : > >> Hi Corey >> >> can I have a copy? >> >> thanks >> Rico >> >> >> On Sun, Feb 26, 2017 at 7:07 AM, Corey Lindsly wrote: >> >>>> The 'oldest' I have is a set of SCO UNIX 3.2V4.0 and V4.2 >>>> >>>> Mail me if you're interested >>>> >>>> Cheers, >>>> rudi >>> I seem to have CD and floppy images for SCO 2.1. >>> >>> drwxr-xr-x 2 corey 1002 4096 Feb 3 2006 ./ >>> drwxr-xr-x 27 corey 1002 20480 Feb 24 09:13 ../ >>> -rw-r--r-- 1 corey 1002 156 Oct 9 2006 README >>> -rwxr--r-- 1 corey 1002 564658176 Feb 2 2006 SCO-2.1-CD.iso* >>> -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 hba.dd* >>> -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 id.dd* >>> -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu1.dd* >>> -rwxr--r-- 1 corey 1002 1474560 Feb 3 2006 niu2.dd* >>> >>> I'm happy to provide them if anyone is interested. >>> >>> --corey >>> >> > > > "I have supposed that he who buys a Method means to learn it." - Ferdinand Sor, > Method for Guitar > > "A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn > From steffen at sdaoden.eu Mon Feb 27 23:59:11 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 27 Feb 2017 14:59:11 +0100 Subject: [TUHS] roff In-Reply-To: <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com> <20170226172011.GC21831@yeono.kjorling.se> <20170226193349.GA24397@mcvoy.com> <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net> Message-ID: <20170227135911.L2U2M%steffen@sdaoden.eu> schily at schily.net (Joerg Schilling) wrote: .. |Fortunately, mailx and troff now have new maintainers and can be found on |github. We, the former and i that is, are not on github. I was shortly in i think 2011, and i wanted to pay (because they paid (at least) a developer, Jeff King, for working on Git), but they rejected my clouts and only desired virtual clowds, but you know, the low-payment sector is already flooded, in our local bank we not longer than ten years ago had bank tellers, you know, that Arthur Hailey Money-Changers story that i have read on the seventies, these targets for Bonnie and Clyde, and other cicadas, now all that robots instead, i think the tellers are now licking the runway of Frankfurt airport speckless or something. No. --steffen From krewat at kilonet.net Tue Feb 28 00:04:47 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 27 Feb 2017 09:04:47 -0500 Subject: [TUHS] Emacs and undump In-Reply-To: <95085781-7de7-1658-6150-ce9145d5ee49@update.uu.se> References: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> <86mvd8orhm.fsf@molnjunk.nocrew.org> <95085781-7de7-1658-6150-ce9145d5ee49@update.uu.se> Message-ID: In TOPS-10, you could detach from your current job, login again, and keep going. Then, attach to the previous job, and go back and forth endlessly. As for keeping memory around, it was very common on TOPS-10 to put code in a "hiseg" that would stick around, and was shareable between "jobs". For something like EMACS, it would be very efficient to have the first person run it "compile" all the LISP, leave it in the hiseg, and other jobs can then run that code. Not knowing anything about EMACS, I'm not sure that compiled code was actually shareable if it was customized, just thinking out loud. But even without leveraging the hiseg capability, it was relatively easy to save an entire core image back to a .SAV or .LOW or later a .EXE. I don't remember how easy it was to do that programmatically, but it was easy from the terminal and if it saves a lot of processor time (and elapsed time) people would have been happy to do it manually. On 2/27/2017 5:47 AM, Johnny Billquist wrote: > > Ah. It was so long ago, and I never learned ITS that well. However, I > don't think you can have several jobs in Tops-10, and I know you can't > in OS/8 or RT-11. > > But that's an interesting capability. To have several jobs around, > with the memory intact, and you can switch between them, and play with > their memory. > > Johnny > From dfawcus+lists-tuhs at employees.org Tue Feb 28 00:33:02 2017 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Mon, 27 Feb 2017 14:33:02 +0000 Subject: [TUHS] Emacs and undump In-Reply-To: References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> Message-ID: <20170227143302.GA15427@cowbell.employees.org> On Mon, Feb 27, 2017 at 07:12:09PM +1100, Nick Downing wrote: > I've been having a bit of trouble with /bin/sh (Bourne's original one) > for the same reason. [snip] > Trouble is, this makes a non-stdio-using program be > stdio-using, in the worst case it's a non-stdio-using program that has > its own malloc() based on sbrk()... so we get another malloc() > happening in the middle, I temporarily fixed this by redirecting the > modern system's malloc() into the ancient system's malloc() but this > is a very non desirable solution. As another possibility I was > thinking of changing the ancient system's sbrk() into realloc() and > implementing a routine to relocate the heap, it obviously would have > to understand everything on the heap and everything that can point > into it. How about applying Geoff Collyer's change to the shell memory management routine available here: http://www.collyer.net/who/geoff/stak.port.c DF From downing.nick at gmail.com Tue Feb 28 00:50:55 2017 From: downing.nick at gmail.com (Nick Downing) Date: Tue, 28 Feb 2017 01:50:55 +1100 Subject: [TUHS] Emacs and undump In-Reply-To: <20170227143302.GA15427@cowbell.employees.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> <20170227143302.GA15427@cowbell.employees.org> Message-ID: Thanks for the stak.c it's a good idea. I'm not sure about the stack freeing routine at the end of the file as it seems to rely on a bit of pointer voodoo but I think I could rationalize all that. cheers, Nick On Feb 28, 2017 1:33 AM, "Derek Fawcus" wrote: > On Mon, Feb 27, 2017 at 07:12:09PM +1100, Nick Downing wrote: > > I've been having a bit of trouble with /bin/sh (Bourne's original one) > > for the same reason. > [snip] > > Trouble is, this makes a non-stdio-using program be > > stdio-using, in the worst case it's a non-stdio-using program that has > > its own malloc() based on sbrk()... so we get another malloc() > > happening in the middle, I temporarily fixed this by redirecting the > > modern system's malloc() into the ancient system's malloc() but this > > is a very non desirable solution. As another possibility I was > > thinking of changing the ancient system's sbrk() into realloc() and > > implementing a routine to relocate the heap, it obviously would have > > to understand everything on the heap and everything that can point > > into it. > > How about applying Geoff Collyer's change to the shell memory management > routine available here: > > http://www.collyer.net/who/geoff/stak.port.c > > DF > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dot at dotat.at Tue Feb 28 01:13:08 2017 From: dot at dotat.at (Tony Finch) Date: Mon, 27 Feb 2017 15:13:08 +0000 Subject: [TUHS] Emacs and undump In-Reply-To: <58b400e9.dJ2hxgoDSpv/lfTa%schily@schily.net> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <58b400e9.dJ2hxgoDSpv/lfTa%schily@schily.net> Message-ID: Joerg Schilling wrote: > > BTW: undump(1) has been announced on a Sun User Group in 1987, but the > next year, SunOS-4.0 came out and made things much harder to implement. > > I did never see an updated undump(1) source that would be able to deal with > SunOS-4.0 and it's shared libraries. Does it exist? Emacs uses a thing called "unexec", or rather several things, one for each OS, with varying complexity and fearsomeness. The SunOS one was deleted in 2008: http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2a5cb2584f9ca171ad4310a464d6236e5f005b0e The Solaris one is the easiest, because dldump() is part of the OS: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexsol.c?id=4daca38d5c673c5b6862e10cfade9559852cce12 Of course, the most popular systems (generic ELF, Windows, and Mac OS) have the most complicated implementations of unexec. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Hebrides, Bailey: Cyclonic 7 to severe gale 9, occasionally storm 10 later. Very rough or high, occasionally very high. Rain or showers. Good, occasionally poor. From dfawcus+lists-tuhs at employees.org Tue Feb 28 01:43:50 2017 From: dfawcus+lists-tuhs at employees.org (Derek Fawcus) Date: Mon, 27 Feb 2017 15:43:50 +0000 Subject: [TUHS] Emacs and undump In-Reply-To: References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> <20170227143302.GA15427@cowbell.employees.org> Message-ID: <20170227154350.GA55334@cowbell.employees.org> On Tue, Feb 28, 2017 at 01:50:55a.m. +1100, Nick Downing wrote: > Thanks for the stak.c it's a good idea. I'm not sure about the stack > freeing routine at the end of the file as it seems to rely on a bit of > pointer voodoo but I think I could rationalize all that. Have a look at the shorter/parent url, he also has a paper describing what he's done, a port of the v7 shell (de-ALGOL'ed), and a few small enhancements. DF From dot at dotat.at Tue Feb 28 02:04:41 2017 From: dot at dotat.at (Tony Finch) Date: Mon, 27 Feb 2017 16:04:41 +0000 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: <86d1e4reep.fsf@molnjunk.nocrew.org> References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> <008701d2904d$29d56c60$7d804520$@ronnatalie.com> <86d1e4reep.fsf@molnjunk.nocrew.org> Message-ID: Lars Brinkhoff wrote: > > RMS credits Multics Emacs with the idea to use Lisp as the extension > language: [snip] https://www.gnu.org/gnu/rms-lisp.html There's a nice history / retrospective of Multics Emacs at http://www.multicians.org/mepap.html Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Dogger, Fisher: South becoming cyclonic 5 to 7, occasionally gale 8 later. Moderate or rough, occasionally very rough later. Rain or showers. Moderate or good. From schily at schily.net Tue Feb 28 02:43:18 2017 From: schily at schily.net (Joerg Schilling) Date: Mon, 27 Feb 2017 17:43:18 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <20170227143302.GA15427@cowbell.employees.org> References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> <20170227143302.GA15427@cowbell.employees.org> Message-ID: <58b45726.8IrjRMpQiO8gmqst%schily@schily.net> Derek Fawcus wrote: > How about applying Geoff Collyer's change to the shell memory management > routine available here: > > http://www.collyer.net/who/geoff/stak.port.c Depends on what shell you are talking about. The code named by you only works with a very old Bourne Shell that can be retrieved from the server of Geoff Collyer. If you are interested in the recent Bourne Shell (SVr4 + Solaris changes), you better use my Bourne Shell sources that can be found inside the schily-tools: http://sourceforge.net/projects/schilytools/files/ The code from above will not work in a recent Bourne Shell without changes in both, Geoff Collyer's stak.c and the rest of the Bourne Shell. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/ From corey at lod.com Tue Feb 28 02:49:45 2017 From: corey at lod.com (Corey Lindsly) Date: Mon, 27 Feb 2017 08:49:45 -0800 (PST) Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <1488189078.58b3f6960b9b5@www.paradise.net.nz> Message-ID: <20170227164945.B85704115@lod.com> > > Count me in. I put my hand up for a copy of SCO when they were offering free > samplers in the early 2000s, but never heard back from them. > > I wanted to compare it with Linux ... > > Thanks > > Wesley Parish For anyone interested, the SCO 2.1 images are available for download here: http://lod.com/sco A few things: 1. I am having some difficulty getting it to install in VMWare ESXi 5. The floppy image boots, and I get some way into the install process, but SCO install does not see the virtual CD-ROM drive. Thus, I'm presented with network install options only. At this point, there are a few options: (a) Track down the driver and/or VMWare settings to fix the CD-ROM visibility, and proceed with the install. (b) Set up a SCO network install server, and proceed. (c) Try the install on legacy physical hardware instead. Of course, your experience may differ. 2. There's actually an installation guide available for this OS here: ftp://ftp.sco.com/pub/UW21/upd211/eng211.txt As well as a lot of driver updates and other good stuff: ftp://ftp.sco.com/pub/UW21/ 3. Anyone who wants to try SCO for the first time may find 5.0.7 a much easier go. It will install directly from CD in VMWare, and there is more driver support for it. To me, it has a very "pure" UNIX feel to it, other than the gratuitous and absurd use of symbolic links all over the file system. If you're interested in trying-out that version, let me know and I'll put up those images for download too. Regards, --corey From b4 at gewt.net Tue Feb 28 03:12:37 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 09:12:37 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <20170227164945.B85704115@lod.com> References: <20170227164945.B85704115@lod.com> Message-ID: <58B45E05.1080205@gewt.net> Corey Lindsly wrote: >> Count me in. I put my hand up for a copy of SCO when they were offering free >> samplers in the early 2000s, but never heard back from them. >> >> I wanted to compare it with Linux ... >> >> Thanks >> >> Wesley Parish > > For anyone interested, the SCO 2.1 images are available for download here: > > http://lod.com/sco > > A few things: > > 1. I am having some difficulty getting it to install in VMWare ESXi 5. The > floppy image boots, and I get some way into the install process, but SCO > install does not see the virtual CD-ROM drive. Thus, I'm presented with > network install options only. At this point, there are a few options: > > (a) Track down the driver and/or VMWare settings to fix the CD-ROM > visibility, and proceed with the install. > > (b) Set up a SCO network install server, and proceed. > > (c) Try the install on legacy physical hardware instead. > > Of course, your experience may differ. > > > 2. There's actually an installation guide available for this OS here: > > ftp://ftp.sco.com/pub/UW21/upd211/eng211.txt > > As well as a lot of driver updates and other good stuff: > > ftp://ftp.sco.com/pub/UW21/ > > > 3. Anyone who wants to try SCO for the first time may find 5.0.7 a much > easier go. It will install directly from CD in VMWare, and there is more > driver support for it. To me, it has a very "pure" UNIX feel to it, > other than the gratuitous and absurd use of symbolic links all over the > file system. If you're interested in trying-out that version, let me know > and I'll put up those images for download too. > > Regards, > > --corey I have a note to myself to try an install in PCem later today. From krewat at kilonet.net Tue Feb 28 05:59:01 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 27 Feb 2017 14:59:01 -0500 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <58B45E05.1080205@gewt.net> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> Message-ID: <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> I've been trying this myself today, both on ESXi 6.0U2, and I went and installed ESXi 5.0 as a guest under 6.0U2 :) I notice that when I put the CD as IDE 1:0 (bus 1, master) it doesn't find it. When I put it as 0:0 (bus 0, master), it hangs loading the IDE driver. I suspect it doesn't know about bus 1, so it doesn't hang but also doesn't find it, and there's something wrong with either VMware's implementation of IDE, or SCO's handling of it - or both. I've read where lots of devices in VMware are just to "perfect" for some device drivers to deal with. One glaring example was you couldn't use the LSI SAS driver with Solaris 11. It would either hang or panic, I forget which. Switch to LSI Parallel SCSI, and it was fine. Anyway, I suspect that there's something in the IDE driver that's ignoring bus1, and hanging with VMware's implementation of it. I'm going to try installing ESXi 4.0 and see what happens. On another note, it's possible I just need to install the hard drive as IDE from the get-go, have the CDROM as slave on bus 0 and see what happens. Any pointers? thanks! art k. On 2/27/2017 12:12 PM, Cory Smelosky wrote: > Corey Lindsly wrote: >>> Count me in. I put my hand up for a copy of SCO when they were >>> offering free >>> samplers in the early 2000s, but never heard back from them. >>> >>> I wanted to compare it with Linux ... >>> >>> Thanks >>> >>> Wesley Parish >> >> For anyone interested, the SCO 2.1 images are available for download >> here: >> >> http://lod.com/sco >> >> A few things: >> >> 1. I am having some difficulty getting it to install in VMWare ESXi >> 5. The >> floppy image boots, and I get some way into the install process, but SCO >> install does not see the virtual CD-ROM drive. Thus, I'm presented with >> network install options only. At this point, there are a few options: >> >> (a) Track down the driver and/or VMWare settings to fix the CD-ROM >> visibility, and proceed with the install. >> >> (b) Set up a SCO network install server, and proceed. >> >> (c) Try the install on legacy physical hardware instead. >> >> Of course, your experience may differ. >> >> >> 2. There's actually an installation guide available for this OS here: >> >> ftp://ftp.sco.com/pub/UW21/upd211/eng211.txt >> >> As well as a lot of driver updates and other good stuff: >> >> ftp://ftp.sco.com/pub/UW21/ >> >> >> 3. Anyone who wants to try SCO for the first time may find 5.0.7 a much >> easier go. It will install directly from CD in VMWare, and there is more >> driver support for it. To me, it has a very "pure" UNIX feel to it, >> other than the gratuitous and absurd use of symbolic links all over the >> file system. If you're interested in trying-out that version, let me >> know >> and I'll put up those images for download too. >> >> Regards, >> >> --corey > > I have a note to myself to try an install in PCem later today. > From b4 at gewt.net Tue Feb 28 06:06:08 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 12:06:08 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> Message-ID: <58B486B0.5020509@gewt.net> Arthur Krewat wrote: > I've been trying this myself today, both on ESXi 6.0U2, and I went and > installed ESXi 5.0 as a guest under 6.0U2 :) > > I notice that when I put the CD as IDE 1:0 (bus 1, master) it doesn't > find it. When I put it as 0:0 (bus 0, master), it hangs loading the IDE > driver. > > I suspect it doesn't know about bus 1, so it doesn't hang but also > doesn't find it, and there's something wrong with either VMware's > implementation of IDE, or SCO's handling of it - or both. I've read > where lots of devices in VMware are just to "perfect" for some device > drivers to deal with. One glaring example was you couldn't use the LSI > SAS driver with Solaris 11. It would either hang or panic, I forget > which. Switch to LSI Parallel SCSI, and it was fine. > > Anyway, I suspect that there's something in the IDE driver that's > ignoring bus1, and hanging with VMware's implementation of it. > > I'm going to try installing ESXi 4.0 and see what happens. > > On another note, it's possible I just need to install the hard drive as > IDE from the get-go, have the CDROM as slave on bus 0 and see what happens. > > Any pointers? > > thanks! > art k. > > > On 2/27/2017 12:12 PM, Cory Smelosky wrote: >> Corey Lindsly wrote: >>>> Count me in. I put my hand up for a copy of SCO when they were >>>> offering free >>>> samplers in the early 2000s, but never heard back from them. >>>> >>>> I wanted to compare it with Linux ... >>>> >>>> Thanks >>>> >>>> Wesley Parish >>> >>> For anyone interested, the SCO 2.1 images are available for download >>> here: >>> >>> http://lod.com/sco >>> >>> A few things: >>> >>> 1. I am having some difficulty getting it to install in VMWare ESXi >>> 5. The >>> floppy image boots, and I get some way into the install process, but SCO >>> install does not see the virtual CD-ROM drive. Thus, I'm presented with >>> network install options only. At this point, there are a few options: >>> >>> (a) Track down the driver and/or VMWare settings to fix the CD-ROM >>> visibility, and proceed with the install. >>> >>> (b) Set up a SCO network install server, and proceed. >>> >>> (c) Try the install on legacy physical hardware instead. >>> >>> Of course, your experience may differ. >>> >>> >>> 2. There's actually an installation guide available for this OS here: >>> >>> ftp://ftp.sco.com/pub/UW21/upd211/eng211.txt >>> >>> As well as a lot of driver updates and other good stuff: >>> >>> ftp://ftp.sco.com/pub/UW21/ >>> >>> >>> 3. Anyone who wants to try SCO for the first time may find 5.0.7 a much >>> easier go. It will install directly from CD in VMWare, and there is more >>> driver support for it. To me, it has a very "pure" UNIX feel to it, >>> other than the gratuitous and absurd use of symbolic links all over the >>> file system. If you're interested in trying-out that version, let me >>> know >>> and I'll put up those images for download too. >>> >>> Regards, >>> >>> --corey >> >> I have a note to myself to try an install in PCem later today. >> > bochs' IDE implementation results in it crashing and in qemu it panic()s before loading the installer. From b4 at gewt.net Tue Feb 28 06:08:55 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 12:08:55 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <58B486B0.5020509@gewt.net> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> Message-ID: <58B48757.4090408@gewt.net> Cory Smelosky wrote: > Arthur Krewat wrote: >> I've been trying this myself today, both on ESXi 6.0U2, and I went and >> installed ESXi 5.0 as a guest under 6.0U2 :) >> >> I notice that when I put the CD as IDE 1:0 (bus 1, master) it doesn't >> find it. When I put it as 0:0 (bus 0, master), it hangs loading the IDE >> driver. >> >> I suspect it doesn't know about bus 1, so it doesn't hang but also >> doesn't find it, and there's something wrong with either VMware's >> implementation of IDE, or SCO's handling of it - or both. I've read >> where lots of devices in VMware are just to "perfect" for some device >> drivers to deal with. One glaring example was you couldn't use the LSI >> SAS driver with Solaris 11. It would either hang or panic, I forget >> which. Switch to LSI Parallel SCSI, and it was fine. >> >> Anyway, I suspect that there's something in the IDE driver that's >> ignoring bus1, and hanging with VMware's implementation of it. >> >> I'm going to try installing ESXi 4.0 and see what happens. >> >> On another note, it's possible I just need to install the hard drive as >> IDE from the get-go, have the CDROM as slave on bus 0 and see what >> happens. >> >> Any pointers? >> >> thanks! >> art k. >> >> > > bochs' IDE implementation results in it crashing and in qemu it panic()s > before loading the installer. I believe VirtualBox crashed at about the same point as qemu. From bqt at update.uu.se Tue Feb 28 06:09:33 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 27 Feb 2017 21:09:33 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: References: Message-ID: <31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se> Ooo. Fun. We're talking PDP-10s on a Unix list... :-) On 2017-02-27 16:13, Arthur Krewat wrote: > In TOPS-10, you could detach from your current job, login again, and > keep going. Then, attach to the previous job, and go back and forth > endlessly. Right. But that is a different thing. Each terminal session only have one job. The fact that you can detach that, and log in as a new session is a different concept. > As for keeping memory around, it was very common on TOPS-10 to put code > in a "hiseg" that would stick around, and was shareable between "jobs". Yes. Again, that is a different thing as well. Hisegs are more related to shared memory. I assume you know all this, so I'm not going to go into details. But having the memory around for a program, even if it is not running, is actually sometimes very useful. If ITS could handle that, while treating them as separate processes, all associated to one terminal, and let you select which one you were currently fooling around in, while the others stayed around, that is something I don't think I've seen elsewhere. > For something like EMACS, it would be very efficient to have the first > person run it "compile" all the LISP, leave it in the hiseg, and other > jobs can then run that code. That would work, but it would then require that all other users be suspended until the first user actually completes the initialization, and after that, all the memory must be readonly. > Not knowing anything about EMACS, I'm not sure that compiled code was > actually shareable if it was customized, just thinking out loud. You can certainly customize and save your own image. But the general bootstrapping of Emacs consists of starting up the core system, and then loading a whole bunch of modules and configurations. All that loading and parsing of those files into data structures in memory is quite cpu intensive. Once all that processing is finished, you can start editing. Each person essentially wants all that work done, no matter what they'd like to do later. So, Emacs does it once, and then saves the state at the point where you can start editing. But it does not mean that the memory is shareable. It's full of various data structures, and code, and that will change as you go along editing things as well. > But even without leveraging the hiseg capability, it was relatively easy > to save an entire core image back to a .SAV or .LOW or later a .EXE. I > don't remember how easy it was to do that programmatically, but it was > easy from the terminal and if it saves a lot of processor time (and > elapsed time) people would have been happy to do it manually. Indeed. Like I said, Tops-10 have the same concept as Emacs does today. But there it was essentially what you always did. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From krewat at kilonet.net Tue Feb 28 06:18:00 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 27 Feb 2017 15:18:00 -0500 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <58B48757.4090408@gewt.net> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> <58B48757.4090408@gewt.net> Message-ID: <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> Same result with IDE hard drive on bus 0 master, and CD on bus 0 slave. Hang loading ide driver. On 2/27/2017 3:08 PM, Cory Smelosky wrote: > Cory Smelosky wrote: >> bochs' IDE implementation results in it crashing and in qemu it panic()s >> before loading the installer. > > I believe VirtualBox crashed at about the same point as qemu. > From lars at nocrew.org Tue Feb 28 06:26:01 2017 From: lars at nocrew.org (Lars Brinkhoff) Date: Mon, 27 Feb 2017 21:26:01 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se> (Johnny Billquist's message of "Mon, 27 Feb 2017 21:09:33 +0100") References: <31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se> Message-ID: <86efyjpehy.fsf@molnjunk.nocrew.org> Johnny Billquist wrote: > But having the memory around for a program, even if it is not running, > is actually sometimes very useful. If ITS could handle that, while > treating them as separate processes, all associated to one terminal, > and let you select which one you were currently fooling around in, > while the others stayed around, that is something I don't think I've > seen elsewhere. And it's not just a list structure, but a tree. You can e.g. start a new DDT, which itself can have inferior jobs (subprocesses). To bring this slightly back on topic, ITS job handling was John Kulp's inspiration for Unix job control. Control-Z does pretty much the same thing in both ITS and Unix. > So, Emacs does it once, and then saves the state at the point where > you can start editing. But it does not mean that the memory is > shareable. It's full of various data structures, and code, and that > will change as you go along editing things as well. Much is sharable. There's a concept of purification (which also comes from ITS). A purecopy() function is used in temacs to put read-only data in a special memory area. That area will become sharable in the dumped Emacs. From bqt at update.uu.se Tue Feb 28 07:06:10 2017 From: bqt at update.uu.se (Johnny Billquist) Date: Mon, 27 Feb 2017 22:06:10 +0100 Subject: [TUHS] Emacs and undump In-Reply-To: <86efyjpehy.fsf@molnjunk.nocrew.org> References: <31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se> <86efyjpehy.fsf@molnjunk.nocrew.org> Message-ID: On 2017-02-27 21:26, Lars Brinkhoff wrote: > Johnny Billquist wrote: >> But having the memory around for a program, even if it is not running, >> is actually sometimes very useful. If ITS could handle that, while >> treating them as separate processes, all associated to one terminal, >> and let you select which one you were currently fooling around in, >> while the others stayed around, that is something I don't think I've >> seen elsewhere. > > And it's not just a list structure, but a tree. You can e.g. start a > new DDT, which itself can have inferior jobs (subprocesses). Hmm. That sounds similar to TOPS-20 then maybe. >> So, Emacs does it once, and then saves the state at the point where >> you can start editing. But it does not mean that the memory is >> shareable. It's full of various data structures, and code, and that >> will change as you go along editing things as well. > > Much is sharable. There's a concept of purification (which also comes > from ITS). A purecopy() function is used in temacs to put read-only > data in a special memory area. That area will become sharable in the > dumped Emacs. There are definitely some shareable things, but you need to remember that even some pure, read-only data can be problematic in a shared segment, as not all people might even have that data loaded, even if the data itself is readonly. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol From pepe at naleco.com Tue Feb 28 07:31:58 2017 From: pepe at naleco.com (Josh Good) Date: Mon, 27 Feb 2017 22:31:58 +0100 Subject: [TUHS] troff, flo In-Reply-To: <4cef0a0d14718c2e60b108c6b0d16034@quintile.net> References: <4cef0a0d14718c2e60b108c6b0d16034@quintile.net> Message-ID: <20170227213158.GC16910@naleco.com> On 2017 Feb 27, 00:19, Steve Simon wrote: > > On the subject of Troff, this package seems to have disappeared: > > flo???A Language for Typesetting Flowcharts > Anthony P. Wolfman and Daniel M. Berry > Computer Science, Technion, Haifa 32000, ISRAEL > 1989 My system is not configured to read UTF-8. Is it possible to represent the name "flo???A" in 7 bit ASCII, or perhaps in ISO-8859-*? Regards, -- Josh Good From downing.nick at gmail.com Tue Feb 28 09:51:21 2017 From: downing.nick at gmail.com (Nick Downing) Date: Tue, 28 Feb 2017 10:51:21 +1100 Subject: [TUHS] Un-released/internal/special UNIX versions/ports during the years? In-Reply-To: References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu> <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net> <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org> <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net> <008701d2904d$29d56c60$7d804520$@ronnatalie.com> <86d1e4reep.fsf@molnjunk.nocrew.org> Message-ID: Really fascinating reading (the emacs history essay). I had more or less gone through a similar thought process in my own editor experiments, such as a failed attempt to provide full screen editing for email in TheMajorBBS, it's a difficult and fascinating problem and the dicussion of FNP char-at-a-time patches is quite revealing in regards to the limitations (both physical and idealogical) that prevailed with early mainframes. cheers, Nick On Feb 28, 2017 3:05 AM, "Tony Finch" wrote: > Lars Brinkhoff wrote: > > > > RMS credits Multics Emacs with the idea to use Lisp as the extension > > language: [snip] https://www.gnu.org/gnu/rms-lisp.html > > There's a nice history / retrospective of Multics Emacs at > http://www.multicians.org/mepap.html > > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h > punycode > Dogger, Fisher: South becoming cyclonic 5 to 7, occasionally gale 8 later. > Moderate or rough, occasionally very rough later. Rain or showers. > Moderate or > good. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From downing.nick at gmail.com Tue Feb 28 10:02:40 2017 From: downing.nick at gmail.com (Nick Downing) Date: Tue, 28 Feb 2017 11:02:40 +1100 Subject: [TUHS] Emacs and undump In-Reply-To: References: <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org> <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org> <86y3wsp0cq.fsf@molnjunk.nocrew.org> <20170227143302.GA15427@cowbell.employees.org> <58b45726.8IrjRMpQiO8gmqst%schily@schily.net> Message-ID: Hmm well I am more interested in the ancient code, I am not averse to adding improvements but I want to do so in a controlled way. Also I prefer not to use any Sys3~5 interfaces in my current project which is exclusively BSD. Haha, well I de-algoled /bin/sh twice so far, first time was for my uzi to Z180 port about 10yrs back, and second time was for my 4.3BSD to Linux porting library project last month. In the intervening time I became quite a sed wizard and my latest de-algolizer is completely automated and produces very nice results. Could possibly be improved by astyle's removal of braces around single statements, I considered this too risky at the time but I have since realized I can compare the stripped executables to convince myself that it does not change the logic, indeed I should check the basic de-algolizer in this way also. Lately I have been thinking of running all of 4.3BSD through astyle but I hesitate to do unnecessary changes, one always regrets them when doing any bisecting or rebasing stuff... Nick On Feb 28, 2017 3:43 AM, "Joerg Schilling" wrote: Derek Fawcus wrote: > How about applying Geoff Collyer's change to the shell memory management > routine available here: > > http://www.collyer.net/who/geoff/stak.port.c Depends on what shell you are talking about. The code named by you only works with a very old Bourne Shell that can be retrieved from the server of Geoff Collyer. If you are interested in the recent Bourne Shell (SVr4 + Solaris changes), you better use my Bourne Shell sources that can be found inside the schily-tools: http://sourceforge.net/projects/schilytools/files/ The code from above will not work in a recent Bourne Shell without changes in both, Geoff Collyer's stak.c and the rest of the Bourne Shell. Jörg -- EMail:joerg at schily.net (home) Jörg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/ projects/schilytools/files/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From krewat at kilonet.net Tue Feb 28 10:19:37 2017 From: krewat at kilonet.net (Arthur Krewat) Date: Mon, 27 Feb 2017 19:19:37 -0500 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> <58B48757.4090408@gewt.net> <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> Message-ID: <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net> Same result with ESXi 4.0, and CDROM on bus 0 slave or master. Hung on ide driver load. On 2/27/2017 3:18 PM, Arthur Krewat wrote: > Same result with IDE hard drive on bus 0 master, and CD on bus 0 slave. > > Hang loading ide driver. > > > > On 2/27/2017 3:08 PM, Cory Smelosky wrote: >> Cory Smelosky wrote: >>> bochs' IDE implementation results in it crashing and in qemu it >>> panic()s >>> before loading the installer. >> >> I believe VirtualBox crashed at about the same point as qemu. >> > From madcrow.maxwell at gmail.com Tue Feb 28 11:15:48 2017 From: madcrow.maxwell at gmail.com (Michael Kerpan) Date: Mon, 27 Feb 2017 20:15:48 -0500 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> <58B48757.4090408@gewt.net> <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net> Message-ID: Has anyone tried this on Virtualbox? If not, I'll try it out tomorrow morning. On Feb 27, 2017 7:20 PM, "Arthur Krewat" wrote: > Same result with ESXi 4.0, and CDROM on bus 0 slave or master. > > Hung on ide driver load. > > > > On 2/27/2017 3:18 PM, Arthur Krewat wrote: > >> Same result with IDE hard drive on bus 0 master, and CD on bus 0 slave. >> >> Hang loading ide driver. >> >> >> >> On 2/27/2017 3:08 PM, Cory Smelosky wrote: >> >>> Cory Smelosky wrote: >>> >>>> bochs' IDE implementation results in it crashing and in qemu it panic()s >>>> before loading the installer. >>>> >>> >>> I believe VirtualBox crashed at about the same point as qemu. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dscherrer at solar.stanford.edu Tue Feb 28 11:31:54 2017 From: dscherrer at solar.stanford.edu (Deborah Scherrer) Date: Mon, 27 Feb 2017 17:31:54 -0800 Subject: [TUHS] mt Xinu tapes Message-ID: <57fe046a-d427-9e38-f0d5-af5d478e6af2@solar.stanford.edu> Sorry, the search has failed to dig up any old mt Xinu tapes. None of us were smart enough to save them... Sorry. Debbie From b4 at gewt.net Tue Feb 28 11:31:54 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 17:31:54 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> <58B48757.4090408@gewt.net> <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net> Message-ID: I did. Didn't even get to the installer. Sent from my iPhone > On Feb 27, 2017, at 17:15, Michael Kerpan wrote: > > Has anyone tried this on Virtualbox? If not, I'll try it out tomorrow morning. > >> On Feb 27, 2017 7:20 PM, "Arthur Krewat" wrote: >> Same result with ESXi 4.0, and CDROM on bus 0 slave or master. >> >> Hung on ide driver load. >> >> >> >>> On 2/27/2017 3:18 PM, Arthur Krewat wrote: >>> Same result with IDE hard drive on bus 0 master, and CD on bus 0 slave. >>> >>> Hang loading ide driver. >>> >>> >>> >>>> On 2/27/2017 3:08 PM, Cory Smelosky wrote: >>>> Cory Smelosky wrote: >>>>> bochs' IDE implementation results in it crashing and in qemu it panic()s >>>>> before loading the installer. >>>> >>>> I believe VirtualBox crashed at about the same point as qemu. >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsteve at superglobalmegacorp.com Tue Feb 28 12:30:57 2017 From: jsteve at superglobalmegacorp.com (Jason Stevens) Date: Tue, 28 Feb 2017 10:30:57 +0800 Subject: [TUHS] mt Xinu tapes In-Reply-To: <57fe046a-d427-9e38-f0d5-af5d478e6af2@solar.stanford.edu> References: <57fe046a-d427-9e38-f0d5-af5d478e6af2@solar.stanford.edu> Message-ID: <6986013E-3195-45B5-B9C9-CA4362274CF7@superglobalmegacorp.com> Thanks for trying. On February 28, 2017 9:31:54 AM GMT+08:00, Deborah Scherrer wrote: >Sorry, the search has failed to dig up any old mt Xinu tapes. None of >us were smart enough to save them... > >Sorry. >Debbie -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Tue Feb 28 12:52:17 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 18:52:17 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <20170227164945.B85704115@lod.com> References: <20170227164945.B85704115@lod.com> Message-ID: <1488250337.677968.895007064.186BAB37@webmail.messagingengine.com> On Mon, Feb 27, 2017, at 08:49, Corey Lindsly wrote: > (a) Track down the driver and/or VMWare settings to fix the CD-ROM > visibility, and proceed with the install. > > (b) Set up a SCO network install server, and proceed. > > (c) Try the install on legacy physical hardware instead. > > Of course, your experience may differ. > > > 2. There's actually an installation guide available for this OS here: > > ftp://ftp.sco.com/pub/UW21/upd211/eng211.txt > > As well as a lot of driver updates and other good stuff: > > ftp://ftp.sco.com/pub/UW21/ > > > 3. Anyone who wants to try SCO for the first time may find 5.0.7 a much > easier go. It will install directly from CD in VMWare, and there is more > driver support for it. To me, it has a very "pure" UNIX feel to it, > other than the gratuitous and absurd use of symbolic links all over the > file system. If you're interested in trying-out that version, let me know > and I'll put up those images for download too. > I would grab it from Xinuous' website but I seem to have forgotten what the hell I provided for "first phone number"....so can't log in. > Regards, > > --corey -- Cory Smelosky b4 at gewt.net From b4 at gewt.net Tue Feb 28 12:55:12 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 18:55:12 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <1488250337.677968.895007064.186BAB37@webmail.messagingengine.com> References: <20170227164945.B85704115@lod.com> <1488250337.677968.895007064.186BAB37@webmail.messagingengine.com> Message-ID: <1488250512.678200.895008712.09986013@webmail.messagingengine.com> On Mon, Feb 27, 2017, at 18:52, Cory Smelosky wrote: > > I would grab it from Xinuous' website but I seem to have forgotten what > the hell I provided for "first phone number"....so can't log in. > I found the password, at least...phone number on file is still a mystery however. Seems you just need an account to grab 5...I have no support contract. > > Regards, > > > > --corey > > > -- > Cory Smelosky > b4 at gewt.net -- Cory Smelosky b4 at gewt.net From b4 at gewt.net Tue Feb 28 13:54:34 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 19:54:34 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> <58B48757.4090408@gewt.net> <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net> Message-ID: <1488254074.690176.895047888.7A0983F2@webmail.messagingengine.com> I have had great success with PCem (http://pcem-emulator.co.uk/) Config: gameblaster = 0 gus = 0 ssi2001 = 0 voodoo = 0 model = 39 cpu_manufacturer = 0 cpu = 27 cpu_use_dynarec = 1 cpu_waitstates = 0 gfxcard = 15 video_speed = 5 sndcard = 0 cpu_speed = 21 has_fpu = 1 disc_a = Z:\Users\\id.ima disc_b = mem_size = 262144 cdrom_drive = 200 cdrom_enabled = 1 cdrom_channel = 1 cdrom_path = Z:\Users\\SCO-2.1-CD.iso vid_resize = 0 vid_api = 1 video_fullscreen_scale = 0 video_fullscreen_first = 1 hdc_sectors = 63 hdc_heads = 16 hdc_cylinders = 511 hdc_fn = sco-testing.img hdd_sectors = 0 hdd_heads = 0 hdd_cylinders = 0 hdd_fn = hde_sectors = 0 hde_heads = 0 hde_cylinders = 0 hde_fn = hdf_sectors = 0 hdf_heads = 0 hdf_cylinders = 0 hdf_fn = drive_a_type = 5 drive_b_type = 7 window_w = 0 window_h = 0 window_x = 0 window_y = 0 window_remember = 0 joystick_type = 0 mouse_type = 0 enable_sync = 1 [Joysticks] joystick_0_nr = 0 joystick_1_nr = 0 cdrom_channel MUST be 1, and the floppy MUST end with an extension of .ima It runs on windows and linux, and happily in wine in macos. Once the install completes I am confident it will work on bochs et al: file sco-testing.img sco-testing.img: DOS/MBR boot sector; partition 4 : ID=0x63, active, start- CHS (0x0,1,1), end-CHS (0xfe,31,63), startsector 63, 514017 sectors It's not a special image format, but a raw image. -- Cory Smelosky b4 at gewt.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From b4 at gewt.net Tue Feb 28 16:50:10 2017 From: b4 at gewt.net (Cory Smelosky) Date: Mon, 27 Feb 2017 22:50:10 -0800 Subject: [TUHS] SCO OpenDesktop 386 2.0.0 In-Reply-To: <1488254074.690176.895047888.7A0983F2@webmail.messagingengine.com> References: <20170227164945.B85704115@lod.com> <58B45E05.1080205@gewt.net> <16b6c61c-cc91-14e3-46d9-e83a198fd2c8@kilonet.net> <58B486B0.5020509@gewt.net> <58B48757.4090408@gewt.net> <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net> <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net> <1488254074.690176.895047888.7A0983F2@webmail.messagingengine.com> Message-ID: After a ridiculous method of copying the update 1440k at a time, I upgraded to 2.1.3 and now it boots in qemu. Sent from my iPhone > On Feb 27, 2017, at 19:54, Cory Smelosky wrote: > > > I have had great success with PCem (http://pcem-emulator.co.uk/) > > Config: > gameblaster = 0 > gus = 0 > ssi2001 = 0 > voodoo = 0 > model = 39 > cpu_manufacturer = 0 > cpu = 27 > cpu_use_dynarec = 1 > cpu_waitstates = 0 > gfxcard = 15 > video_speed = 5 > sndcard = 0 > cpu_speed = 21 > has_fpu = 1 > disc_a = Z:\Users\\id.ima > disc_b = > mem_size = 262144 > cdrom_drive = 200 > cdrom_enabled = 1 > cdrom_channel = 1 > cdrom_path = Z:\Users\\SCO-2.1-CD.iso > vid_resize = 0 > vid_api = 1 > video_fullscreen_scale = 0 > video_fullscreen_first = 1 > hdc_sectors = 63 > hdc_heads = 16 > hdc_cylinders = 511 > hdc_fn = sco-testing.img > hdd_sectors = 0 > hdd_heads = 0 > hdd_cylinders = 0 > hdd_fn = > hde_sectors = 0 > hde_heads = 0 > hde_cylinders = 0 > hde_fn = > hdf_sectors = 0 > hdf_heads = 0 > hdf_cylinders = 0 > hdf_fn = > drive_a_type = 5 > drive_b_type = 7 > window_w = 0 > window_h = 0 > window_x = 0 > window_y = 0 > window_remember = 0 > joystick_type = 0 > mouse_type = 0 > enable_sync = 1 > > [Joysticks] > joystick_0_nr = 0 > joystick_1_nr = 0 > > cdrom_channel MUST be 1, and the floppy MUST end with an extension of .ima > > It runs on windows and linux, and happily in wine in macos. Once the install completes I am confident it will work on bochs et al: > file sco-testing.img > sco-testing.img: DOS/MBR boot sector; partition 4 : ID=0x63, active, start-CHS (0x0,1,1), end-CHS (0xfe,31,63), startsector 63, 514017 sectors > > It's not a special image format, but a raw image. > -- > Cory Smelosky > b4 at gewt.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at ronnatalie.com Tue Feb 28 21:55:19 2017 From: ron at ronnatalie.com (Ronald Natalie) Date: Tue, 28 Feb 2017 06:55:19 -0500 Subject: [TUHS] Emacs and undump In-Reply-To: References: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se> <86mvd8orhm.fsf@molnjunk.nocrew.org> <95085781-7de7-1658-6150-ce9145d5ee49@update.uu.se> Message-ID: <0C7E9021-5412-4038-AA83-5677640AC8DE@ronnatalie.com> > On Feb 27, 2017, at 9:04 AM, Arthur Krewat wrote: > > In TOPS-10, you could detach from your current job, login again, and keep going. Then, attach to the previous job, and go back and forth endlessly. > ITS had this feature as well. I actually implemented this for UNIX in a crude way. I put a program as my login shell that spawned off a shell on a PTY and the program did sort of a lightweight “telnet” between the PTY and my login terminal. I could then make the intermediary program go away (effectively logging out of the system) while leaving the shell running on the PTY. The subsequent login, the program would notice I still had my previous session running and offer to reconnect it for me. From arnold at skeeve.com Tue Feb 28 21:58:07 2017 From: arnold at skeeve.com (arnold at skeeve.com) Date: Tue, 28 Feb 2017 04:58:07 -0700 Subject: [TUHS] troff, flo In-Reply-To: <4cef0a0d14718c2e60b108c6b0d16034@quintile.net> References: <4cef0a0d14718c2e60b108c6b0d16034@quintile.net> Message-ID: <201702281158.v1SBw7Et000810@freefriends.org> "Steve Simon" wrote: > Hi, > > On the subject of Troff, this package seems to have disappeared: > > flo—A Language for Typesetting Flowcharts > Anthony P. Wolfman and Daniel M. Berry > Computer Science, Technion, Haifa 32000, ISRAEL > 1989 > > The paper about it is available but the code has gone. > > Anyone have an archive of it? > > -Steve Daniel Berry's home page appears to be https://cs.uwaterloo.ca/~dberry/ Maybe you can ask him if he still has the source. Arnold