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: <CMM.0.96.0.1485824178.beebe@gamma.math.utah.edu>
 <867f5b8yn9.fsf@molnjunk.nocrew.org>
 <20170131081255.GA30074@server.rulingia.com>
Message-ID: <CAC20D2P4aS5-8zM440YZ9pryQ3OgCPtcRRbCBHuH4Nphbi2iEA@mail.gmail.com>

On Tue, Jan 31, 2017 at 3:12 AM, Peter Jeremy <peter at rulingia.com> 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
<http://minnie.tuhs.org/PUPS/> says it is out of date and tells people to
go to TUHS and the mailing list URL  Subscribe to the PUPS mailing list
<http://minnie.tuhs.org/mailman/listinfo/pups> comes back as "No such list:
*pups*"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170131/e824e7a1/attachment.html>

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: <CAC20D2P4aS5-8zM440YZ9pryQ3OgCPtcRRbCBHuH4Nphbi2iEA@mail.gmail.com>
References: <CMM.0.96.0.1485824178.beebe@gamma.math.utah.edu>
 <867f5b8yn9.fsf@molnjunk.nocrew.org>
 <20170131081255.GA30074@server.rulingia.com>
 <CAC20D2P4aS5-8zM440YZ9pryQ3OgCPtcRRbCBHuH4Nphbi2iEA@mail.gmail.com>
Message-ID: <20170131193303.GA30737@minnie.tuhs.org>

On Tue, Jan 31, 2017 at 3:12 AM, Peter Jeremy <peter at rulingia.com> 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: <CMM.0.96.0.1485824178.beebe@gamma.math.utah.edu>
 <867f5b8yn9.fsf@molnjunk.nocrew.org>
 <20170131081255.GA30074@server.rulingia.com>
 <CAC20D2P4aS5-8zM440YZ9pryQ3OgCPtcRRbCBHuH4Nphbi2iEA@mail.gmail.com>
 <20170131193303.GA30737@minnie.tuhs.org>
Message-ID: <CACCFpdz7G808rODwcTuRY-26HpO4U=HWg3S4uu3oOMY=FPjUoA@mail.gmail.com>

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: <CMM.0.96.0.1485897436.beebe@gamma.math.utah.edu>

Nigel Williams <nw at retrocomputingtasmania.com> 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: <CAC20D2NNsyUirYe+Z835O71yJBPc1aH4Sd3_DXVB84V180wY9Q@mail.gmail.com>

On Tue, Jan 31, 2017 at 4:33 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170131/e050c624/attachment.html>

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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>


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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
Message-ID: <CAC20D2N0aC=SuTy0HLWSAtKr5yJFa7q=6JtQj4DqPfPsUxCz+w@mail.gmail.com>

​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 <mah at mhorton.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/0dc4c0f7/attachment.html>

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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
Message-ID: <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>

Mary Ann Horton <mah at mhorton.net> 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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
Message-ID: <CAOkr1zVY_WLOa+r8FbeZ8+N4aVs9YZeqFd6eem-HnrFbiZdSzw@mail.gmail.com>

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 <schily at schily.net> wrote:

> Mary Ann Horton <mah at mhorton.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/e4191bac/attachment.html>

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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
Message-ID: <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>

On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling <schily at schily.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/923e2e70/attachment.html>

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: <CAOkr1zVY_WLOa+r8FbeZ8+N4aVs9YZeqFd6eem-HnrFbiZdSzw@mail.gmail.com>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAOkr1zVY_WLOa+r8FbeZ8+N4aVs9YZeqFd6eem-HnrFbiZdSzw@mail.gmail.com>
Message-ID: <CAC20D2P_nBJD5WDSQeEqYA+eWC67HZThouJY8g7Y_fUYTm0kEA@mail.gmail.com>

On Wed, Feb 1, 2017 at 12:39 PM, Marc Rochkind <rochkind at basepath.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/5344832e/attachment.html>

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: <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
Message-ID: <CAOkr1zVE+uz7xC6AyzyVdV6Uif-id4asET34gDXSmDwygejAXQ@mail.gmail.com>

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 <clemc at ccc.com> wrote:

>
> On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling <schily at schily.net>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/25e84346/attachment.html>

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: <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
Message-ID: <589225b2.YZDGL8idi2AuxrxR%schily@schily.net>

Clem Cole <clemc at ccc.com> wrote:

> On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling <schily at schily.net> 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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
 <589225b2.YZDGL8idi2AuxrxR%schily@schily.net>
Message-ID: <CAOkr1zXcohxNBhqNVp8yQQcMwf2dOHyiX+86K3An+HCqUaaVpg@mail.gmail.com>

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 <schily at schily.net> wrote:

> Clem Cole <clemc at ccc.com> wrote:
>
> > On Wed, Feb 1, 2017 at 12:24 PM, Joerg Schilling <schily at schily.net>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/03edc32f/attachment.html>

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: <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
Message-ID: <201702011833.v11IX5Yu017326@freefriends.org>

Clem Cole <clemc at ccc.com> 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: <CAOkr1zXcohxNBhqNVp8yQQcMwf2dOHyiX+86K3An+HCqUaaVpg@mail.gmail.com>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
 <589225b2.YZDGL8idi2AuxrxR%schily@schily.net>
 <CAOkr1zXcohxNBhqNVp8yQQcMwf2dOHyiX+86K3An+HCqUaaVpg@mail.gmail.com>
Message-ID: <58922a86.5PutwR+d+Mom82Bd%schily@schily.net>

Marc Rochkind <rochkind at basepath.com> 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: <a6fd9db397bf0f6e2d68887c431b98510c4b85bc@webmail.yaccman.com>

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:<schily at schily.net>, <clemc at ccc.com>
Cc:<tuhs at minnie.tuhs.org>
Sent:Wed, 01 Feb 2017 11:33:05 -0700
Subject:Re: [TUHS] shared memory on Unix

 Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/e9f5bd4f/attachment.html>

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: <a6fd9db397bf0f6e2d68887c431b98510c4b85bc@webmail.yaccman.com>
References: <201702011833.v11IX5Yu017326@freefriends.org>
 <a6fd9db397bf0f6e2d68887c431b98510c4b85bc@webmail.yaccman.com>
Message-ID: <CAOkr1zVTcc4Y_Zhz3y5QJip_HGTsGBkwS2_QjsnpGOjJtd=fGg@mail.gmail.com>

@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 <scj at yaccman.com> 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:
> <schily at schily.net>, <clemc at ccc.com>
> Cc:
> <tuhs at minnie.tuhs.org>
> Sent:
> Wed, 01 Feb 2017 11:33:05 -0700
> Subject:
> Re: [TUHS] shared memory on Unix
>
>
>
> Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/d729c5ca/attachment.html>

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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
 <201702011833.v11IX5Yu017326@freefriends.org>
Message-ID: <CAC20D2OdA4muuXCNY7CO1pstKUACQhPcuPrMiJERwrT8WrNH-w@mail.gmail.com>

On Wed, Feb 1, 2017 at 1:33 PM, <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/4dd34ee2/attachment.html>

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: <CAP6exYLuNenMQTWmV2cM9qiQTO5Ru94QHG5G8FuBektU-2jWbw@mail.gmail.com>

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 <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/fc3d7a28/attachment.html>

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: <CAC20D2ONGbsWzvY9zceCUOuuWS_f-20UA5xPmKa3ZR-3y6RwzQ@mail.gmail.com>

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 <michael at kjorling.se>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/93d6e966/attachment.html>

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: <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>

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 <michael at kjorling.se>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/e00d55ed/attachment.html>

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: <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>
 (Clem Cole's message of "Wed, 1 Feb 2017 15:50:14 -0500")
References: <20170201204327.GU21797@yeono.kjorling.se>
 <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>
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: <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>
 <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: <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>
 <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <20170201214208.GV21797@yeono.kjorling.se>
Message-ID: <a5eaecd2-34f3-4fa0-974a-f7c90b86d6f4.maildroid@localhost>

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" <michael at kjorling.se>
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: <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>
 <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <20170201214208.GV21797@yeono.kjorling.se>
Message-ID: <E50B9CD1-F66F-4F36-B91E-67706C5C3C65@gewt.net>

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 <michael at kjorling.se> 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: <CAC20D2PXDZPa7QMSfaBCMYPYpJ6ZBPnM+Ym1CesNpfUr6aZWuw@mail.gmail.com>

On Wed, Feb 1, 2017 at 4:33 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/e9c27396/attachment.html>

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: <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>

On Wed, Feb 1, 2017 at 4:20 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/f1f47b24/attachment.html>

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: <CAC20D2PXDZPa7QMSfaBCMYPYpJ6ZBPnM+Ym1CesNpfUr6aZWuw@mail.gmail.com>
References: <20170201204327.GU21797@yeono.kjorling.se>
 <20170201213331.GD880@mcvoy.com>
 <CAC20D2PXDZPa7QMSfaBCMYPYpJ6ZBPnM+Ym1CesNpfUr6aZWuw@mail.gmail.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 <lm at mcvoy.com> 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: <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
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: <E50B9CD1-F66F-4F36-B91E-67706C5C3C65@gewt.net>
References: <CAC20D2NezNRsCGVUHh5w8hTTH+RUG=n86L7jRctQmkWrW6Cgqw@mail.gmail.com>
 <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <20170201214208.GV21797@yeono.kjorling.se>
 <E50B9CD1-F66F-4F36-B91E-67706C5C3C65@gewt.net>
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 <michael at kjorling.se> 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>
 <CAC20D2PXDZPa7QMSfaBCMYPYpJ6ZBPnM+Ym1CesNpfUr6aZWuw@mail.gmail.com>
 <20170201220848.GH880@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1702011719520.11360@frieza.hoshinet.org>

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>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
Message-ID: <CAC20D2NqOqARhP_sp0cruKZk4VKcj3=qe1VMWNYJb=WZ0=pmbQ@mail.gmail.com>

On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/6282d31b/attachment.html>

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: <c3b82692-cd47-12a5-3fbb-963d7b880fdf@kilonet.net>

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 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/46596fdc/attachment.html>

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>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
Message-ID: <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>

On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/4ef3cddb/attachment.html>

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: <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
 <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
Message-ID: <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>

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 <clemc at ccc.com>
To: Larry McVoy <lm at mcvoy.com>
Cc: TUHS main list <tuhs at minnie.tuhs.org>, 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 <lm at mcvoy.com> 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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <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 <mah at mhorton.net
> > 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: <cbd9b78839d2f75f95c9f7f4048b88b3a3281a9c@webmail.yaccman.com>
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: <CAC20D2OdA4muuXCNY7CO1pstKUACQhPcuPrMiJERwrT8WrNH-w@mail.gmail.com>
References: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <589219b1.U4yqSQ1D6ZJhjhk0%schily@schily.net>
 <CAC20D2PJY7yAGARJFsQCOsqiZXKbW-158=kDgHS1V1PHt5YYGw@mail.gmail.com>
 <201702011833.v11IX5Yu017326@freefriends.org>
 <CAC20D2OdA4muuXCNY7CO1pstKUACQhPcuPrMiJERwrT8WrNH-w@mail.gmail.com>
Message-ID: <CAH1jEzYe4z5emE7+b1R_0hMcVhZsAfq_BkQBLQZNEkm1HrusBA@mail.gmail.com>

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" <clemc at ccc.com> wrote:

>
> On Wed, Feb 1, 2017 at 1:33 PM, <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170202/e7348b64/attachment.html>

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: <E198DD1D-4C01-4EF1-AAF4-F3230C28979F@planet.nl>
 <1b4095d8-047e-fa23-fc34-b1f8eb5c9d02@mhorton.net>
 <82F3421B-9EF3-4752-B4E6-E2F15529FCDE@planet.nl>
Message-ID: <CAC20D2PDXUDe624yAw_9D7nMqPD8geyL8xHo6iYPjC=zHhK5fQ@mail.gmail.com>

On Wed, Feb 1, 2017 at 6:11 PM, Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/38f42744/attachment.html>

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: <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
 <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
 <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>
Message-ID: <CACwAiQkoEh71ONUd=CtwqS2RVuu833VOKNrLabfOxSGMKanKsA@mail.gmail.com>

On Wed, Feb 1, 2017 at 11:44 PM, William Pechter <pechter at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170202/d7982ba8/attachment.html>

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: <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
 <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
 <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>
Message-ID: <CAC20D2MH5y+1S--uAehEyc1_oX+pBqq7VP+Evw2F8ShOV_6x5g@mail.gmail.com>

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 <pechter at gmail.com> 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 <clemc at ccc.com>
> To: Larry McVoy <lm at mcvoy.com>
> Cc: TUHS main list <tuhs at minnie.tuhs.org>, 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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/65ccfd93/attachment.html>

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: <CAC20D2MH5y+1S--uAehEyc1_oX+pBqq7VP+Evw2F8ShOV_6x5g@mail.gmail.com>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
 <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
 <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>
 <CAC20D2MH5y+1S--uAehEyc1_oX+pBqq7VP+Evw2F8ShOV_6x5g@mail.gmail.com>
Message-ID: <CAC20D2O=J4-Hyx6MZOeExuFj5UfV+ABZoNMsFs-=_7aTVrb09Q@mail.gmail.com>

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 <clemc at ccc.com> 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 <pechter at gmail.com> 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 <clemc at ccc.com>
>> To: Larry McVoy <lm at mcvoy.com>
>> Cc: TUHS main list <tuhs at minnie.tuhs.org>, 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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/7cd54105/attachment.html>

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: <CACwAiQkoEh71ONUd=CtwqS2RVuu833VOKNrLabfOxSGMKanKsA@mail.gmail.com>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
 <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
 <a66a842a-0f00-4e1f-8278-e75bb488b703.maildroid@localhost>
 <CACwAiQkoEh71ONUd=CtwqS2RVuu833VOKNrLabfOxSGMKanKsA@mail.gmail.com>
Message-ID: <CAC20D2OqBLtppTaQXJNCtzv5ScXEzGFtMyvyuE03qSLfyQuR1g@mail.gmail.com>

On Wed, Feb 1, 2017 at 8:14 PM, Rico Pajarola <rp at servium.ch> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170201/c8910edc/attachment.html>

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: <c3b82692-cd47-12a5-3fbb-963d7b880fdf@kilonet.net> (Arthur
 Krewat's message of "Wed, 1 Feb 2017 17:26:45 -0500")
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <c3b82692-cd47-12a5-3fbb-963d7b880fdf@kilonet.net>
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: <CAMYpm85kfQ6Zb3W=TE03NK5ow++7kS3TeWL6nrSR8K+-_2Mj4Q@mail.gmail.com>

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: <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
References: <20170201212040.C273118C0DD@mercury.lcs.mit.edu>
 <CAC20D2NwRz6wo7WBwTy6hBCF9RZXrJ4s83yL+5TeMZUXVHEyoQ@mail.gmail.com>
 <20170201221112.GI880@mcvoy.com>
 <CAC20D2PjB3iatBO8TW2eQbR9+pfFofuk_yenis803imuGDzuJw@mail.gmail.com>
Message-ID: <201702021311.v12DBNoa004846@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy <lm at mcvoy.com> 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: <mailman.182.1485985948.3779.tuhs@minnie.tuhs.org>
References: <mailman.182.1485985948.3779.tuhs@minnie.tuhs.org>
Message-ID: <E996268F-435C-46BC-A334-EA60C6D531ED@kdbarto.org>

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 <lm at mcvoy.com>
> To: Noel Chiappa <jnc at mercury.lcs.mit.edu>
> 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: <alpine.BSF.2.20.1702031233560.46495@aneurin.horsfall.org>

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: <mailman.1.1486087201.3876.tuhs@minnie.tuhs.org>
References: <mailman.1.1486087201.3876.tuhs@minnie.tuhs.org>
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: <C78C3CAB-11DD-4018-9CC4-410766370C51@tfeb.org>

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 <dugo at xs4all.nl> 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: <alpine.BSF.2.20.1702040052140.46495@aneurin.horsfall.org>

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: <alpine.BSF.2.20.1702040052140.46495@aneurin.horsfall.org>
References: <20170201204327.GU21797@yeono.kjorling.se>
 <28ebecfb41ed0b72b45f1cd2ae99c3a4@xs4all.nl>
 <alpine.BSF.2.20.1702040052140.46495@aneurin.horsfall.org>
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>
 <alpine.BSF.2.20.1702040052140.46495@aneurin.horsfall.org>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170203/455704e9/attachment.html>

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: <alpine.BSF.2.20.1702040653440.46495@aneurin.horsfall.org>

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: <fa16db67d666b506fc08a62b50a84b95f06d932a@webmail.yaccman.com>

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:<lm at mcvoy.com>, <clemc at ccc.com>
Cc:<tuhs at minnie.tuhs.org>, <jnc at mercury.lcs.mit.edu>
Sent:Thu, 02 Feb 2017 06:11:23 -0700
Subject:Re: [TUHS] Names of famous, historical UNIX machines?

 Clem Cole <clemc at ccc.com> wrote:

 > On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170203/10fa7c35/attachment.html>

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: <fa16db67d666b506fc08a62b50a84b95f06d932a@webmail.yaccman.com>
References: <201702021311.v12DBNoa004846@freefriends.org>
 <fa16db67d666b506fc08a62b50a84b95f06d932a@webmail.yaccman.com>
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:<lm at mcvoy.com>, <clemc at ccc.com>
> Cc:<tuhs at minnie.tuhs.org>, <jnc at mercury.lcs.mit.edu>
> Sent:Thu, 02 Feb 2017 06:11:23 -0700
> Subject:Re: [TUHS] Names of famous, historical UNIX machines?
> 
>  Clem Cole <clemc at ccc.com> wrote:
> 
>  > On Wed, Feb 1, 2017 at 5:11 PM, Larry McVoy <lm at mcvoy.com> 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: <alpine.BSF.2.20.1702040653440.46495@aneurin.horsfall.org>
References: <alpine.BSF.2.20.1702040653440.46495@aneurin.horsfall.org>
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: <alpine.BSF.2.20.1702040653440.46495@aneurin.horsfall.org>
 <20170204123851.GF21797@yeono.kjorling.se>
Message-ID: <alpine.BSF.2.02.1702040740380.37497@frieza.hoshinet.org>

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: <alpine.BSF.2.02.1702040740380.37497@frieza.hoshinet.org>
References: <alpine.BSF.2.20.1702040653440.46495@aneurin.horsfall.org>
 <20170204123851.GF21797@yeono.kjorling.se>
 <alpine.BSF.2.02.1702040740380.37497@frieza.hoshinet.org>
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>
 <fa16db67d666b506fc08a62b50a84b95f06d932a@webmail.yaccman.com>
 <20170204035613.GC28573@mcvoy.com>
Message-ID: <CAJfiPzy5uT+ij2v9qWFvj0LsSHObra1iR1TzbGN2grVRRVArdw@mail.gmail.com>

On 3 February 2017 at 22:56, Larry McVoy <lm at mcvoy.com> 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: <CAF12ZDTmuCk-9AdRU1nD1xrKihchB5=ntAukP1TDa7L7VZTLqw@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170205/7877de49/attachment.html>

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: <CAF12ZDTmuCk-9AdRU1nD1xrKihchB5=ntAukP1TDa7L7VZTLqw@mail.gmail.com>
References: <CAF12ZDTmuCk-9AdRU1nD1xrKihchB5=ntAukP1TDa7L7VZTLqw@mail.gmail.com>
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: <CAF12ZDT+318H+OT-mSJXEm=Zc9nzy5zW5zpRCR3579qwwhfXfw@mail.gmail.com>

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 <jnc at mercury.lcs.mit.edu> 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 <markhare at buffalo.edu>

    > 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: <E996268F-435C-46BC-A334-EA60C6D531ED@kdbarto.org>
References: <mailman.182.1485985948.3779.tuhs@minnie.tuhs.org>
 <E996268F-435C-46BC-A334-EA60C6D531ED@kdbarto.org>
Message-ID: <alpine.BSF.2.20.1702060857070.46495@aneurin.horsfall.org>

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>
 <alpine.BSF.2.20.1702040052140.46495@aneurin.horsfall.org>
 <67b5fc0baf200260db0f035f858929ed@xs4all.nl>
Message-ID: <alpine.BSF.2.20.1702061640320.46495@aneurin.horsfall.org>

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: <alpine.BSF.2.20.1702060857070.46495@aneurin.horsfall.org>
References: <mailman.182.1485985948.3779.tuhs@minnie.tuhs.org>
 <E996268F-435C-46BC-A334-EA60C6D531ED@kdbarto.org>
 <alpine.BSF.2.20.1702060857070.46495@aneurin.horsfall.org>
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 <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170207/d8720dcf/attachment.html>

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: <alpine.BSF.2.20.1702060857070.46495@aneurin.horsfall.org>
References: <mailman.182.1485985948.3779.tuhs@minnie.tuhs.org>
 <E996268F-435C-46BC-A334-EA60C6D531ED@kdbarto.org>
 <alpine.BSF.2.20.1702060857070.46495@aneurin.horsfall.org>
Message-ID: <CAP6exYLNg5uiog362OSdEcL0VbueS=Q5tnxfqzK0asubHmj5gg@mail.gmail.com>

On Sun, Feb 5, 2017 at 2:11 PM Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170206/9d175fef/attachment.html>

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: <CAOkr1zWHg2Ni1qt8cMm9c0jO9NUPg5eG6poN-xRkqB3KuPNeQQ@mail.gmail.com>

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 <doug at cs.dartmouth.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170206/1c64496f/attachment.html>

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: <CAOkr1zWHg2Ni1qt8cMm9c0jO9NUPg5eG6poN-xRkqB3KuPNeQQ@mail.gmail.com>
References: <201702070303.v1733qvF011648@coolidge.cs.Dartmouth.EDU>
 <CAOkr1zWHg2Ni1qt8cMm9c0jO9NUPg5eG6poN-xRkqB3KuPNeQQ@mail.gmail.com>
Message-ID: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>

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 <rochkind at basepath.com>
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 <doug at cs.dartmouth.edu>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170207/c4150dfc/attachment.html>

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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
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" <clemc at ccc.com>

To:
"Marc Rochkind" <rochkind at basepath.com>
Cc:
"TUHS main list" <tuhs at minnie.tuhs.org>
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 <rochkind at basepath.com
[1]>
 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 <doug at cs.dartmouth.edu
[2]>
 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170207/3866b843/attachment.html>

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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/0c1ee58e/attachment.sig>

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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
Message-ID: <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>

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 <grog at lemis.com> 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: <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
Message-ID: <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>

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 <downing.nick at gmail.com> 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 <grog at lemis.com>
>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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/22bf1237/attachment.html>

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: <CAH1jEzYMLO==yP9xpDUmsessy4odqkrXOp5yX6kiB3zrvKRhtQ@mail.gmail.com>
References: <20170130025003.1CAEA18C0BA@mercury.lcs.mit.edu>
 <CAH1jEzYMLO==yP9xpDUmsessy4odqkrXOp5yX6kiB3zrvKRhtQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1702081456260.46495@aneurin.horsfall.org>

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: <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
Message-ID: <20170208053752.GA6039@server.rulingia.com>

On 2017-Feb-08 14:47:03 +1100, Nick Downing <downing.nick at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/55ad5618/attachment.sig>

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: <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.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 <jsteve at superglobalmegacorp.com>:

> 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.
> 
<snip>



"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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <1486542344.589ad6086611d@www.paradise.net.nz>
Message-ID: <alpine.BSF.2.02.1702080455500.64702@frieza.hoshinet.org>

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: <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
Message-ID: <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>

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
<jsteve at superglobalmegacorp.com> 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
> <downing.nick at gmail.com> 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 <grog at lemis.com>
>> 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: <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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
<jsteve at superglobalmegacorp.com> 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
> <downing.nick at gmail.com> 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 <grog at lemis.com>
>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/1639d009/attachment.html>

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: <F209B8F0-1247-4BD4-AA94-3EF2E7EF3387@cheswick.com>

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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <609dee92-753d-4d9b-8586-97839620c8d2@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAH1jEzZVS=nmPL_PL=0Ho6-8G_XcGRBoAq92oNkk0kXBF_tgJQ@mail.gmail.com>

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,  <jsteve at superglobalmegacorp.com> 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
>
> <jsteve at superglobalmegacorp.com> 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
>
>> <downing.nick at gmail.com> 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 <grog at lemis.com>
>
>>> 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: <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
Message-ID: <CAH1jEzb9miz4Nopf12fMN-Gb34TATmwh4otxnOnB23ZE7KKCyQ@mail.gmail.com>

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 <dugo at xs4all.nl> 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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/4aa9a69e/attachment.html>

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: <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
Message-ID: <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>

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
> <jsteve at superglobalmegacorp.com> 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
>> <downing.nick at gmail.com> 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 <grog at lemis.com>
>>> 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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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: <CAEoi9W7hEi8WANeYdWvMt4jkjzk98uAKqykLqWH6a9Z0Vx3JKw@mail.gmail.com>

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 <ron at ronnatalie.com> wrote:

> Anybody have a copy of Rob Pike's "Cat -v considered harmful" paper?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/f4ec780b/attachment.html>

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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com>
 <72f15b962c85b6e584ef1f15965af55b@xs4all.nl>
Message-ID: <C51C2867-61E0-467C-86A3-D748879B03DC@superglobalmegacorp.com>

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 <dugo at xs4all.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/62f77fbb/attachment.html>

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: <CAEoi9W7hEi8WANeYdWvMt4jkjzk98uAKqykLqWH6a9Z0Vx3JKw@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <4b06386d-6000-4d22-bbb1-2719479b5320@SG2APC01FT060.eop-APC01.prod.protection.outlook.com>
 <72f15b962c85b6e584ef1f15965af55b@xs4all.nl>
 <03f901d28218$78ad6060$6a082120$@ronnatalie.com>
 <CAEoi9W7hEi8WANeYdWvMt4jkjzk98uAKqykLqWH6a9Z0Vx3JKw@mail.gmail.com>
Message-ID: <CAH1jEza1OjhtCWUfnw2Xo=5m2rD=d-h2rurH9URmxUStmrCPsA@mail.gmail.com>

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 <crossd at gmail.com> 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 <ron at ronnatalie.com> 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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.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 <ron at ronnatalie.com> 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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
Message-ID: <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>

Jacob Goense <dugo at xs4all.nl> 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  <dot at dotat.at>  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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/2b97e431/attachment.html>

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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
References: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
Message-ID: <CAFCBnZvwnnOq3JgdcA+O=FAeOBc_WrGSrZXtXyh=zUq1J+x6BA@mail.gmail.com>

On 2/8/17, ron minnich <rminnich at gmail.com> 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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
References: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
Message-ID: <201702081817.v18IHShk031735@freefriends.org>

ron minnich <rminnich at gmail.com> 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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
References: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/6828e370/attachment.sig>

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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <20170208224556.GG65698@eureka.lemis.com>
Message-ID: <CAP6exYLM0cKUBT_JjXA5+pgqdTnErpRAGQdNkgois7-M2t++pw@mail.gmail.com>

On Wed, Feb 8, 2017 at 2:45 PM Greg 'groggy' Lehey <grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/0b7f82bf/attachment.html>

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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/18593a3a/attachment.sig>

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: <CAP6exYLM0cKUBT_JjXA5+pgqdTnErpRAGQdNkgois7-M2t++pw@mail.gmail.com>
References: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <20170208224556.GG65698@eureka.lemis.com>
 <CAP6exYLM0cKUBT_JjXA5+pgqdTnErpRAGQdNkgois7-M2t++pw@mail.gmail.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 <grog at lemis.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/f4fb6719/attachment.sig>

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:<tuhs at minnie.tuhs.org>, <rminnich at gmail.com>
Cc:
Sent:Wed, 08 Feb 2017 11:17:28 -0700
Subject:Re: [TUHS] // comment in C++

 ron minnich <rminnich at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/d8a7449b/attachment.html>

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: <CANV78LSSV6XiOZ1vh-8mHbkc_jvnh86ps92jswzpDZ-E9NCvcw@mail.gmail.com>

On Wed, Feb 8, 2017 at 3:16 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/5c3eb94f/attachment.html>

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: <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org>
References: <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org>
Message-ID: <C4318F2B-0041-4BDE-9885-AE3389929C38@mcjones.org>

> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/7c07a996/attachment.html>

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: <CANV78LSSV6XiOZ1vh-8mHbkc_jvnh86ps92jswzpDZ-E9NCvcw@mail.gmail.com>
References: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu>
 <CANV78LSSV6XiOZ1vh-8mHbkc_jvnh86ps92jswzpDZ-E9NCvcw@mail.gmail.com>
Message-ID: <CANV78LTwpdTxFLBsJXzh=QkOtdb-35imHMo9JGud930nTYbjxw@mail.gmail.com>

On Wed, Feb 8, 2017 at 3:47 PM, Charles Anthony <charles.unix.pro at gmail.com>
wrote:

>
>
> On Wed, Feb 8, 2017 at 3:16 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/db3c222d/attachment.html>

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: <CANV78LTwpdTxFLBsJXzh=QkOtdb-35imHMo9JGud930nTYbjxw@mail.gmail.com>
References: <20170208231633.40D8A18C11A@mercury.lcs.mit.edu>
 <CANV78LSSV6XiOZ1vh-8mHbkc_jvnh86ps92jswzpDZ-E9NCvcw@mail.gmail.com>
 <CANV78LTwpdTxFLBsJXzh=QkOtdb-35imHMo9JGud930nTYbjxw@mail.gmail.com>
Message-ID: <efc56ad9-99bd-fd2c-e1cc-a1c79ab4c905@case.edu>

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: <alpine.BSF.2.20.1702091043290.46495@aneurin.horsfall.org>

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: <CAEoi9W5S-0BqZMZ2V1CumW0-J_YS8FGD7XPOkhdOGekvdSUksw@mail.gmail.com>

Sorry, I can't resist: https://youtu.be/0_HGqPGp9iY


On Feb 8, 2017 8:32 PM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/6b33c96b/attachment.html>

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: <C4318F2B-0041-4BDE-9885-AE3389929C38@mcjones.org>
References: <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org>
 <C4318F2B-0041-4BDE-9885-AE3389929C38@mcjones.org>
Message-ID: <CAOkr1zX2qytjfEf4kdgzYnHBiAq0zgsm1Wkn3vbcGURiA1PMhg@mail.gmail.com>

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 <paul at mcjones.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/9a9f3b72/attachment.html>

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: <alpine.BSF.2.20.1702091043290.46495@aneurin.horsfall.org>
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: <alpine.BSF.2.20.1702091343120.46495@aneurin.horsfall.org>

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: <alpine.BSF.2.20.1702091043290.46495@aneurin.horsfall.org>
References: <10bc76e824e441f031dc541ab4d50a51bfb89638@webmail.yaccman.com>
 <alpine.BSF.2.20.1702091043290.46495@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>

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: <alpine.BSF.2.20.1702091343120.46495@aneurin.horsfall.org>
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: <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
Message-ID: <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>

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 <pnr at planet.nl> 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
>> <jsteve at superglobalmegacorp.com> 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
>>> <downing.nick at gmail.com> 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 <grog at lemis.com>
>>>> 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: <alpine.BSF.2.20.1702091343120.46495@aneurin.horsfall.org>
References: <20170209021136.9BDEA40B9@lod.com>
 <alpine.BSF.2.20.1702091343120.46495@aneurin.horsfall.org>
Message-ID: <CANCZdfrR0X23AwuZWe3hOssZFq=dWwUtCEus55gM3ZK24PRGDg@mail.gmail.com>

On Wed, Feb 8, 2017 at 7:46 PM, Dave Horsfall <dave at horsfall.org> 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: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
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" <usotsuki at buric.co>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/a6dd92a5/attachment.html>

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: <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
Message-ID: <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>


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 <jnc at mercury.lcs.mit.edu> 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: <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <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: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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 <michael at kjorling.se> 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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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 <michael at kjorling.se> 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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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 <pnr at planet.nl> wrote:
 |> On 9 Feb 2017, at 13:12, Michael Kjörling <michael at kjorling.se> 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: <C4318F2B-0041-4BDE-9885-AE3389929C38@mcjones.org>
References: <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org>
 <C4318F2B-0041-4BDE-9885-AE3389929C38@mcjones.org>
Message-ID: <alpine.DEB.2.11.1702091304360.23062@grey.csi.cam.ac.uk>

Paul McJones <paul at mcjones.org> 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  <dot at dotat.at>  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 <scj at yaccman.com> 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" <usotsuki at buric.co>
> 
> To:
> "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
> 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: <CAH1jEzZGafPhu6qJ4z6v2koda6EDCKf0jZ65YcQ1_sLoS+-93Q@mail.gmail.com>

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 <brantleycoile at me.com> 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 <scj at yaccman.com> 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" <usotsuki at buric.co>
>>
>> To:
>> "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
>> 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 <random832 at fastmail.com> wrote:
 |On Wed, Jan 4, 2017, at 11:22, Steffen Nurpmeso wrote:
 |> Random832 <random832 at fastmail.com> 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: <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
Message-ID: <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>

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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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 <michael at kjorling.se> 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: <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
Message-ID: <fcca8d9a-2c74-4a83-a80a-45e6bc1076f3@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/bec2a538/attachment.html>

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 `-<DEL> is missing
the DEL. So if you just take a CTRL character and set the 0100 bit, and print
it as "^<char>", 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: <CAP6exYJ_ifC=9zLTwq99fXt+nFAt2SSoPzdQKZwTHEG0NBcoSg@mail.gmail.com>
 <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: <fcca8d9a-2c74-4a83-a80a-45e6bc1076f3@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
 <fcca8d9a-2c74-4a83-a80a-45e6bc1076f3@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>
Message-ID: <e174cc4bf97bc4b7553419546685bc7b@xs4all.nl>

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: <e174cc4bf97bc4b7553419546685bc7b@xs4all.nl>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
 <fcca8d9a-2c74-4a83-a80a-45e6bc1076f3@SG2APC01FT042.eop-APC01.prod.protection.outlook.com>
 <e174cc4bf97bc4b7553419546685bc7b@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 <dugo at xs4all.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/f5864753/attachment.html>

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: <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
Message-ID: <alpine.DEB.2.11.1702091524130.23970@grey.csi.cam.ac.uk>

Jacob Goense <dugo at xs4all.nl> 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  <dot at dotat.at>  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: <alpine.DEB.2.11.1702091524130.23970@grey.csi.cam.ac.uk>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
 <alpine.DEB.2.11.1702091524130.23970@grey.csi.cam.ac.uk>
Message-ID: <CANCZdfrE-bCQYUryP9yfwHMTW5VaGak9wGG5O=s0A_jMKr-JfQ@mail.gmail.com>

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 <dot at dotat.at> wrote:
> Jacob Goense <dugo at xs4all.nl> 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  <dot at dotat.at>  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: <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
Message-ID: <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.com>

On Thu, Feb 9, 2017 at 9:36 AM, Larry McVoy <lm at mcvoy.com> 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: <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.com>
References: <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
 <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.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 <lm at mcvoy.com> 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 `-<DEL> is missing
 |the DEL. So if you just take a CTRL character and set the 0100 bit, \
 |and print
 |it as "^<char>", 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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <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 <random832 at fastmail.com> 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>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
 <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.com>
 <20170209164953.GQ25691@mcvoy.com>
Message-ID: <20170209172412.se1JH%steffen@sdaoden.eu>

Larry McVoy <lm at mcvoy.com> 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: <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
 <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.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 <lm at mcvoy.com> 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: <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
 <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.com>
 <20170209164953.GQ25691@mcvoy.com> <20170209172412.se1JH%steffen@sdaoden.eu>
 <20170209172752.GY25691@mcvoy.com>
Message-ID: <20170209190534.UrJ6L%steffen@sdaoden.eu>

Larry McVoy <lm at mcvoy.com> wrote:
 |On Thu, Feb 09, 2017 at 06:24:12PM +0100, Steffen Nurpmeso wrote:
 |> Larry McVoy <lm at mcvoy.com> 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 <steffen at sdaoden.eu> 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: <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
Message-ID: <CAC20D2P24-S9VNKyQ+d2yGhBqy+AbXWtV9q5DA+MX_Fwydxr8g@mail.gmail.com>

On Thu, Feb 9, 2017 at 4:19 AM, Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/e123f85b/attachment.html>

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: <aab7a9fa-c07e-411f-a7b4-2089cd7f8793.maildroid@localhost>

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 <corey at lod.com>
To: Larry McVoy <lm at mcvoy.com>
Cc: TUHS main list <tuhs at minnie.tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/520086eb/attachment.html>

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: <a730d3b4-fcb7-1304-8344-b0188ef5dad5@kilonet.net>

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  <removed> (<removed>)  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>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
 <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.com>
 <20170209164953.GQ25691@mcvoy.com>
Message-ID: <589cd8fb.vc2jul9CHdiubSCD%schily@schily.net>

Larry McVoy <lm at mcvoy.com> 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: <mailman.220.1486670111.3779.tuhs@minnie.tuhs.org>
References: <mailman.220.1486670111.3779.tuhs@minnie.tuhs.org>
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: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
Message-ID: <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.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.

// 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: <alpine.BSF.2.20.1702100928100.46495@aneurin.horsfall.org>

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: <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <B747F0D5-A896-4088-A506-B7F63063DD21@planet.nl>
 <CAH1jEzZqRPYenwzBbUwFVanA-NVvWMGzYiADVoAXCDOqnUrMrg@mail.gmail.com>
 <CAH1jEzZ9d4ZEWMdx_R5_TZ4CFYFzrG-V83rS21S1z-LPC0fMCw@mail.gmail.com>
 <C7E0FD3B-59FD-4E51-BCB9-01A14DB7FB99@planet.nl>
 <20170209163658.GO25691@mcvoy.com>
 <CANCZdfrd0VciZXCnGZEq0vCyBEEu3XKygn091_mDz2uChnSArQ@mail.gmail.com>
 <20170209164953.GQ25691@mcvoy.com>
 <20170209172412.se1JH%steffen@sdaoden.eu>
 <20170209172752.GY25691@mcvoy.com>
Message-ID: <589cf1c4.kBD9YOKLENXfOL4u%schily@schily.net>

Larry McVoy <lm at mcvoy.com> 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: <mailman.220.1486670111.3779.tuhs@minnie.tuhs.org>
 <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se>
Message-ID: <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net>

Johnny Billquist <bqt at update.uu.se> 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: <mailman.220.1486670111.3779.tuhs@minnie.tuhs.org>
 <5ba92030-a44e-bfd1-6d41-195fc42b46c1@update.uu.se>
 <589cf55f.iRet/QQ0ldgevhz6%schily@schily.net>
Message-ID: <c47713e3-23f3-544b-05ef-77dc644c32a6@update.uu.se>

On 2017-02-10 00:03, Joerg Schilling wrote:
> Johnny Billquist <bqt at update.uu.se> 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: <CANCZdfrE-bCQYUryP9yfwHMTW5VaGak9wGG5O=s0A_jMKr-JfQ@mail.gmail.com>
References: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
 <alpine.DEB.2.11.1702091524130.23970@grey.csi.cam.ac.uk>
 <CANCZdfrE-bCQYUryP9yfwHMTW5VaGak9wGG5O=s0A_jMKr-JfQ@mail.gmail.com>
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: <a730d3b4-fcb7-1304-8344-b0188ef5dad5@kilonet.net>
References: <20170209195457.373C940B9@lod.com>
 <a730d3b4-fcb7-1304-8344-b0188ef5dad5@kilonet.net>
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: <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
References: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
 <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
Message-ID: <CAEoi9W7g--QoT2wziamyY882MvEPftLNMwZTWYanCWv5GVq4Xg@mail.gmail.com>

On Thu, Feb 9, 2017 at 4:56 PM, Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/f341dc71/attachment.html>

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: <CAEoi9W7g--QoT2wziamyY882MvEPftLNMwZTWYanCWv5GVq4Xg@mail.gmail.com>
References: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
 <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
 <CAEoi9W7g--QoT2wziamyY882MvEPftLNMwZTWYanCWv5GVq4Xg@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1702101253400.46495@aneurin.horsfall.org>

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: <mailman.220.1486670111.3779.tuhs@minnie.tuhs.org>
 <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 <schily at schily.net> wrote:
>Johnny Billquist <bqt at update.uu.se> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170210/bc469499/attachment.html>

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: <alpine.BSF.2.20.1702101253400.46495@aneurin.horsfall.org>
References: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
 <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
 <CAEoi9W7g--QoT2wziamyY882MvEPftLNMwZTWYanCWv5GVq4Xg@mail.gmail.com>
 <alpine.BSF.2.20.1702101253400.46495@aneurin.horsfall.org>
Message-ID: <CAJfiPzwF1a7pQ2grkFhEBaCiRz_ynnfpUBKfkJkVjEoZxkjHNw@mail.gmail.com>

On 9 February 2017 at 20:58, Dave Horsfall <dave at horsfall.org> 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: <CAJfiPzwF1a7pQ2grkFhEBaCiRz_ynnfpUBKfkJkVjEoZxkjHNw@mail.gmail.com>
References: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
 <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
 <CAEoi9W7g--QoT2wziamyY882MvEPftLNMwZTWYanCWv5GVq4Xg@mail.gmail.com>
 <alpine.BSF.2.20.1702101253400.46495@aneurin.horsfall.org>
 <CAJfiPzwF1a7pQ2grkFhEBaCiRz_ynnfpUBKfkJkVjEoZxkjHNw@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1702101348350.46495@aneurin.horsfall.org>

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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
 <alpine.DEB.2.11.1702091524130.23970@grey.csi.cam.ac.uk>
 <CANCZdfrE-bCQYUryP9yfwHMTW5VaGak9wGG5O=s0A_jMKr-JfQ@mail.gmail.com>
 <59edd244efc6fca1609f5707dd39833e@xs4all.nl>
Message-ID: <CANCZdfqGSwNfO+r4OZsae0dX-7zQC98SboTG8uFPsza-EsgU5g@mail.gmail.com>

On Thu, Feb 9, 2017 at 4:38 PM, Jacob Goense <dugo at xs4all.nl> 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: <CAC20D2O8dXan9hX5Sv6LyBD6dEFPwpV5wYZJ_XsFCHtVw6Gb3Q@mail.gmail.com>
 <930c52a0c279cdd7d44953aa403a504a8622bb83@webmail.yaccman.com>
 <20170208025538.GE65698@eureka.lemis.com>
 <CAH1jEzbpOUC2OFjZ9oHodg0DdzQUk2R+3XPdn0RgE9dX7yD5nA@mail.gmail.com>
 <F2A7F638-CC2F-4D0E-B191-0F301DDDA46F@superglobalmegacorp.com>
 <CAH1jEza0j2wLwOY7QpW=T0CMoseNmhmBV8Qp-5gU-W+buE1z2Q@mail.gmail.com>
 <90190d89aaeefbf0b540a28436468835@xs4all.nl>
 <alpine.DEB.2.11.1702081612230.23062@grey.csi.cam.ac.uk>
 <f5b3538ec4d95b73a6ca8bee10f2c009@xs4all.nl>
 <alpine.DEB.2.11.1702091524130.23970@grey.csi.cam.ac.uk>
 <CANCZdfrE-bCQYUryP9yfwHMTW5VaGak9wGG5O=s0A_jMKr-JfQ@mail.gmail.com>
 <59edd244efc6fca1609f5707dd39833e@xs4all.nl>
Message-ID: <CANCZdfp6qh=TnET_TEj27zbqTOcKrRXartR=8wxNJvW7LnkB1g@mail.gmail.com>

On Thu, Feb 9, 2017 at 4:38 PM, Jacob Goense <dugo at xs4all.nl> 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: <mailman.220.1486670111.3779.tuhs@minnie.tuhs.org>
 <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 <http://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 <http://4.2.2.2> or 4.2.2.4 <http://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
> <schily at schily.net> wrote:
>
>     Johnny Billquist <bqt at update.uu.se> wrote:
>
>         Meh. From Uppsala in Sweden I seem to have about 2ms ping time
>         to 8.8.8.8 <http://8.8.8.8>...
>
>         Psilocybe:update/bqt> ping 8.8.8.8 <http://8.8.8.8>
>         PING 8.8.8.8 <http://8.8.8.8> (8.8.8.8 <http://8.8.8.8>) 56(84)
>         bytes of data.
>         64 bytes from 8.8.8.8 <http://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: <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
References: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
 <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
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 <dave at horsfall.org> 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: <alpine.BSF.2.20.1702101253400.46495@aneurin.horsfall.org>
References: <alpine.BSF.2.02.1702082144540.24162@frieza.hoshinet.org>
 <466b9b582736cb809ecabc7702b74914b27be4b6@webmail.yaccman.com>
 <20170209115922.GH5418@yeono.kjorling.se>
 <alpine.BSF.2.20.1702100832410.46495@aneurin.horsfall.org>
 <CAEoi9W7g--QoT2wziamyY882MvEPftLNMwZTWYanCWv5GVq4Xg@mail.gmail.com>
 <alpine.BSF.2.20.1702101253400.46495@aneurin.horsfall.org>
Message-ID: <201702100930.v1A9Ueds017224@freefriends.org>

Dave Horsfall <dave at horsfall.org> 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 <doug at cs.dartmouth.edu> 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: <CACytpF89ZPqtxE+LQ4JBLDe2XAH=mr2kV6Otyf=EX3sTjXm5Cw@mail.gmail.com>

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 <jnc at 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 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: <E0B12DFA-482C-4F6D-A9C4-380F898D8B14@planet.nl>


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: <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>

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 <pnr at planet.nl> 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: <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl>
 <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
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>
 <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
 <0B8503D7-D696-4BB6-A2C7-75A95B603036@planet.nl>
Message-ID: <CAH1jEzY6t9p0TsbuEEDisQHpypaGB1_7NUaWHt+7mTUsmdcTAw@mail.gmail.com>

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 <pnr at planet.nl> 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: <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
 (Nick Downing's message of "Tue, 14 Feb 2017 22:27:40 +1100")
References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl>
 <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
Message-ID: <868tp8kgxo.fsf@molnjunk.nocrew.org>

Nick Downing <downing.nick at gmail.com> 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>
 <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
 <868tp8kgxo.fsf@molnjunk.nocrew.org>
Message-ID: <CAH1jEzYCWh7ZGMfhFKeObdkSJN09AO9PUq6S-3Npv_Jdvndvsg@mail.gmail.com>

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 <lars at nocrew.org> wrote:
> Nick Downing <downing.nick at gmail.com> 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 <downing.nick at gmail.com> 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: <CAH1jEzYCWh7ZGMfhFKeObdkSJN09AO9PUq6S-3Npv_Jdvndvsg@mail.gmail.com>
References: <378063CD-9B94-4AE3-B4BB-F41D2F6BFBF6@planet.nl>
 <CAH1jEzZsHqxEJpiMizkg6-cLDaaEhzjb9vzicrK0AJaRQT8muQ@mail.gmail.com>
 <868tp8kgxo.fsf@molnjunk.nocrew.org>
 <CAH1jEzYCWh7ZGMfhFKeObdkSJN09AO9PUq6S-3Npv_Jdvndvsg@mail.gmail.com>
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: <CAEoi9W5sC1jbMVkuF76En82=A7+JXTRR9cnD8FF3Y60+xSTWuw@mail.gmail.com>

On Tue, Feb 14, 2017 at 10:48 AM, Random832 <random832 at fastmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170214/499f1760/attachment.html>

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: <CAJfiPzyu0C+DskvuSVyZOhZSH2EyXn-tsV07HvbBx7=WVCjPGw@mail.gmail.com>

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: <CAJfiPzyu0C+DskvuSVyZOhZSH2EyXn-tsV07HvbBx7=WVCjPGw@mail.gmail.com>
References: <CAJfiPzyu0C+DskvuSVyZOhZSH2EyXn-tsV07HvbBx7=WVCjPGw@mail.gmail.com>
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: <CAJfiPzyu0C+DskvuSVyZOhZSH2EyXn-tsV07HvbBx7=WVCjPGw@mail.gmail.com>
 <20170215150139.GC16647@mcvoy.com>
Message-ID: <CAL4LZyisjmmjKv7-UjZ63PW0mhP1f4ZcmFkmR1oX+6k5ZPtwQA@mail.gmail.com>

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" <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170215/5fd4c16e/attachment.html>

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: <CAJfiPzyu0C+DskvuSVyZOhZSH2EyXn-tsV07HvbBx7=WVCjPGw@mail.gmail.com>
 <20170215150139.GC16647@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1702151025120.84714@frieza.hoshinet.org>

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: <CAH1jEzbmP+WqWkyN8U=oz04hw6faChy-9T09aiEsZYqhyzUciw@mail.gmail.com>

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" <jnc at mercury.lcs.mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170216/49bdf86b/attachment.html>

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: <CAH1jEzbmP+WqWkyN8U=oz04hw6faChy-9T09aiEsZYqhyzUciw@mail.gmail.com>
References: <20170215153008.5381F18C0BA@mercury.lcs.mit.edu>
 <CAH1jEzbmP+WqWkyN8U=oz04hw6faChy-9T09aiEsZYqhyzUciw@mail.gmail.com>
Message-ID: <CAJfiPzxdAG12qADMuGtvmYbGT_6J5cJOri26z_bB-J-pDgKGZg@mail.gmail.com>

On 15 February 2017 at 11:13, Nick Downing <downing.nick at gmail.com> 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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>

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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170216/9c3c2259/attachment.html>

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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>

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,  <jsteve at superglobalmegacorp.com> 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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
Message-ID: <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>

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 <downing.nick at gmail.com> 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,  <jsteve at superglobalmegacorp.com> 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: <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/aec17263/attachment.html>

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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAC20D2O7cPtAq=h8U8w-9CVkg3JVMfR3qyh4qk14+q9VWtA1JQ@mail.gmail.com>

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, <jsteve at superglobalmegacorp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/d5ae52fe/attachment.html>

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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>

On Fri, Feb 17, 2017 at 6:30 AM, <jsteve at superglobalmegacorp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/1f1bfe9a/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/02f3998b/attachment.html>

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: <CAC20D2O7cPtAq=h8U8w-9CVkg3JVMfR3qyh4qk14+q9VWtA1JQ@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2O7cPtAq=h8U8w-9CVkg3JVMfR3qyh4qk14+q9VWtA1JQ@mail.gmail.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: <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
Message-ID: <CANCZdfoZKYor5ucp2vb84x+VgJUCZxewB98VvbJ=VN1z+=uhDA@mail.gmail.com>

On Fri, Feb 17, 2017 at 7:29 AM, Clem Cole <clemc at ccc.com> wrote:
>
> On Fri, Feb 17, 2017 at 6:30 AM, <jsteve at superglobalmegacorp.com> 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: <CAC20D2NGUfCFeUFZgDd2nkSYPpCw=yfx5smFk8Z1cg25KRFPLQ@mail.gmail.com>

On Fri, Feb 17, 2017 at 11:55 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/422d9417/attachment.html>

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: <CAC20D2O7FWLZe9XvB+h3Zo2_jE6ui7Xso4gGyKpB6Q3Cze70gQ@mail.gmail.com>

On Fri, Feb 17, 2017 at 7:12 PM, Warren Toomey <wkt at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170217/732be838/attachment.html>

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: <CAC20D2O7FWLZe9XvB+h3Zo2_jE6ui7Xso4gGyKpB6Q3Cze70gQ@mail.gmail.com>
References: <20170218001244.GB17910@minnie.tuhs.org>
 <CAC20D2O7FWLZe9XvB+h3Zo2_jE6ui7Xso4gGyKpB6Q3Cze70gQ@mail.gmail.com>
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 <organisation>. 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 <organisation> 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 <organisation> directories, or do we
have a heap of Systems/<organisation> 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 <doug at cs.dartmouth.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170218/bf93b320/attachment.html>

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: <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
Message-ID: <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>

On 17 February 2017 at 09:29, Clem Cole <clemc at ccc.com> 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: <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.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 <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/709363ee/attachment.html>

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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
Message-ID: <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>

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: <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
Message-ID: <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.com>

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 <usotsuki at buric.co> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/53c9ec93/attachment.html>

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: <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
Message-ID: <CAC20D2PraTNVKRTz0x1wJ1YUkeqbHVp-vd647PKAEsxAMuHGGg@mail.gmail.com>

On Sun, Feb 19, 2017 at 1:20 AM, <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….
>
​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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/0750fd70/attachment.html>

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: <CAC20D2PraTNVKRTz0x1wJ1YUkeqbHVp-vd647PKAEsxAMuHGGg@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <CAC20D2PraTNVKRTz0x1wJ1YUkeqbHVp-vd647PKAEsxAMuHGGg@mail.gmail.com>
Message-ID: <CAH1jEzYD17qeQd2k=2_PhfEE2m2VsgkkDgrT3e5F8oZ8dwXfLw@mail.gmail.com>

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 <clemc at ccc.com> wrote:
>
>
> On Sun, Feb 19, 2017 at 1:20 AM, <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….
>
> 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: <CAC20D2PraTNVKRTz0x1wJ1YUkeqbHVp-vd647PKAEsxAMuHGGg@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <CAC20D2PraTNVKRTz0x1wJ1YUkeqbHVp-vd647PKAEsxAMuHGGg@mail.gmail.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,
> <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….
> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/412abed1/attachment.html>

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 <doug at cs.dartmouth.edu> 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: <CAH1jEzYD17qeQd2k=2_PhfEE2m2VsgkkDgrT3e5F8oZ8dwXfLw@mail.gmail.com>
References: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <CAC20D2PraTNVKRTz0x1wJ1YUkeqbHVp-vd647PKAEsxAMuHGGg@mail.gmail.com>
 <CAH1jEzYD17qeQd2k=2_PhfEE2m2VsgkkDgrT3e5F8oZ8dwXfLw@mail.gmail.com>
Message-ID: <CAC20D2NM_oyDz0tAM2o5_vJ8Ky_3fHoAmPHn8+DOqNwKoMyqfQ@mail.gmail.com>

On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing <downing.nick at gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170219/7da88585/attachment.html>

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 <b4 at gewt.net>:

> 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: <FEF22850-8CE8-4B40-8A4E-3A3ADE7EC120@superglobalmegacorp.com>

As always, I sure am!

On February 20, 2017 6:39:57 AM GMT+08:00, Cory Smelosky <b4 at gewt.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/597ff60b/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/3fa50200/attachment.html>

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: <CAMYpm85Rkxob7LdKM9jNq2gc8Ls=Lj9a5VHOwqurwAtQkTSNmg@mail.gmail.com>

>Date: Sun, 19 Feb 2017 20:58:59 -0500
>From: Clem Cole <clemc at ccc.com>
>To: Nick Downing <downing.nick at gmail.com>
>Cc: Jason Stevens <jsteve at superglobalmegacorp.com>,
>        "tuhs at minnie.tuhs.org" <tuhs at minnie.tuhs.org>
>Subject: Re: [TUHS] Mach for i386 / Mt Xinu or other
>Message-ID:      <CAC20D2NM_oyDz0tAM2o5_vJ8Ky_3fHoAmPHn8+DOqNwKoMyqfQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
>
>On Sun, Feb 19, 2017 at 7:29 PM, Nick Downing <downing.nick at gmail.com> 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: <CAH1jEzbCb2X=xmmys5Pk2pE5EnaUXr-vyRezOivOz8EYx8+MuA@mail.gmail.com>

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 <wkt at tuhs.org> 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 <jsteve at superglobalmegacorp.com> 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 <lars at nocrew.org> wrote:
>Jason Stevens <jsteve at superglobalmegacorp.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/56c65468/attachment.html>

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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.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 <wkt at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/1302091f/attachment.html>

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 <jsteve at superglobalmegacorp.com> 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 <wkt at tuhs.org> 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: <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>

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 <jsteve at superglobalmegacorp.com> 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 <wkt at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/9c9debe8/attachment.html>

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: <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
References: <4FBE38B7-39C6-4391-9E0B-D5E72C77EC84@superglobalmegacorp.com>
 <20170220065013.GB19194@minnie.tuhs.org>
 <3DFEF92B-A41D-4023-B098-5E7E33944446@superglobalmegacorp.com>
 <201702200908.v1K983DP011135@freefriends.org>
 <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
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


<jsteve at superglobalmegacorp.com> 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 <jsteve at superglobalmegacorp.com> 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 <wkt at tuhs.org> 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>
 <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
 <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
>
>
> <jsteve at superglobalmegacorp.com> 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 <jsteve at superglobalmegacorp.com> 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 <wkt at tuhs.org> 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 <wlc at jctaylor.com> 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: <CAMYpm84Z7SLWZmBgz4X4SVAOGw2wHdMYQ2avq4kcMACU0M-ZxA@mail.gmail.com>
 <1c400c16-5f18-4475-a8e2-99976e571a37@SG2APC01FT039.eop-APC01.prod.protection.outlook.com>
 <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.com>
 <20170219154432.GA19243@mcvoy.com>
Message-ID: <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net>

Larry McVoy <lm at mcvoy.com> 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>
 <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
 <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 <dscherrer at solar.stanford.edu> 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>
 <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
 <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 <dscherrer at solar.stanford.edu> 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 <dscherrer at solar.stanford.edu> 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>
 <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
 <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 <dscherrer at solar.stanford.edu> 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
>> 
>> 
>> <jsteve at superglobalmegacorp.com> 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 <jsteve at superglobalmegacorp.com> 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 <wkt at tuhs.org> 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>
 <c749e965-732e-49a7-8c29-3cf3e5f47990@SG2APC01FT012.eop-APC01.prod.protection.outlook.com>
 <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 <dscherrer at solar.stanford.edu> 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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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 <lm at mcvoy.com> 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" <lm at mcvoy.com>
To:"Joerg Schilling" <schily at schily.net>
Cc:<tuhs at minnie.tuhs.org>
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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/b910235f/attachment.html>

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" <lm at mcvoy.com>
> To:"Joerg Schilling" <schily at schily.net>
> Cc:<tuhs at minnie.tuhs.org>
> 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 <lm at mcvoy.com> 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: <alpine.BSF.2.02.1702201819160.34891@frieza.hoshinet.org>

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" <lm at mcvoy.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"Larry McVoy" <lm at mcvoy.com>, "Joerg Schilling"
<schily at schily.net>, <tuhs at minnie.tuhs.org>
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" <lm at mcvoy.com>
 > To:"Joerg Schilling" <schily at schily.net>
 > Cc:<tuhs at minnie.tuhs.org>
 > 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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170220/849b673f/attachment.html>

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: <alpine.BSF.2.02.1702201819160.34891@frieza.hoshinet.org>
References: <52c439ec481a196ab88d8a85cd4b1c69303fe5bd@webmail.yaccman.com>
 <alpine.BSF.2.02.1702201819160.34891@frieza.hoshinet.org>
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 <usotsuki at buric.co>:

> On Mon, 20 Feb 2017, Steve Johnson wrote:
> 
<snip>
> 
> > 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>
 <alpine.BSF.2.02.1702201819160.34891@frieza.hoshinet.org>
 <1487635966.58ab85fec0716@www.paradise.net.nz>
Message-ID: <alpine.BSF.2.02.1702202000580.41003@frieza.hoshinet.org>

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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.com>
 <20170219154432.GA19243@mcvoy.com>
 <58ab3214.+jRaJEWVki5gYHFz%schily@schily.net>
 <20170220222457.GB3163@mcvoy.com>
Message-ID: <58ac16ca.V0zEZijwK0rh0Cyr%schily@schily.net>

Larry McVoy <lm at mcvoy.com> 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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>

On Tue, Feb 21, 2017 at 7:02 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
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?
<https://www.quora.com/Would-it-be-possible-advantageous-to-rewrite-the-Linux-kernel-in-Rust-when-the-language-is-stable>
 &
 Why did Unix succeed and not Multics
<https://www.quora.com/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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/1c38eef3/attachment.html>

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: <a6253ace-a77d-d826-4cce-91992bf2459d@case.edu>

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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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 <random832 at fastmail.com> 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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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 <dds at aueb.gr> 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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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 <random832 at fastmail.com> 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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAEoi9W53YR1QUdN923p0zOYykiP=LHG_P3CRuYcRR29OYnv3AQ@mail.gmail.com>

On Feb 21, 2017 11:55 AM, "Joerg Schilling" <schily at schily.net> wrote:

Random832 <random832 at fastmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/304ba76c/attachment.html>

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: <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>

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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/2424ba36/attachment.html>

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: <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.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: <CAEoi9W53YR1QUdN923p0zOYykiP=LHG_P3CRuYcRR29OYnv3AQ@mail.gmail.com>
References: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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>
 <CAEoi9W53YR1QUdN923p0zOYykiP=LHG_P3CRuYcRR29OYnv3AQ@mail.gmail.com>
Message-ID: <58ac98ab.afYqPbvivuKUTFMJ%schily@schily.net>

Dan Cross <crossd at gmail.com> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
Message-ID: <CAC20D2MHuvqd-=ZAdejs+XXEzur1axF-TPp5gXMcbSA8s43Yxw@mail.gmail.com>

On Tue, Feb 21, 2017 at 2:21 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/ecaed4ce/attachment.html>

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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>

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: <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
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: <CAH1jEzYFv6bfN9i8qSSpy4dJhGg-WbZsyvVwxXro4dd4_RgCgw@mail.gmail.com>
 <CAMYpm851jyAUG271r4431fv8pvPhqB2ufM9OafAUzwpx+kVSEg@mail.gmail.com>
 <635c06b4-0048-4951-95ca-283c64c30fed@SG2APC01FT017.eop-APC01.prod.protection.outlook.com>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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>
 <CAEoi9W53YR1QUdN923p0zOYykiP=LHG_P3CRuYcRR29OYnv3AQ@mail.gmail.com>
 <58ac98ab.afYqPbvivuKUTFMJ%schily@schily.net>
Message-ID: <CAEoi9W6p8n_CjkWc5SRmi34HqWst9PpHuLG6XoUbbR=WFahjZg@mail.gmail.com>

On Tue, Feb 21, 2017 at 2:44 PM, Joerg Schilling <schily at schily.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/dd74917b/attachment.html>

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>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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 <lm at mcvoy.com> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <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 <lm at 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).
>  



"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: <CAH1jEzZQg=s=QygbCVv-kqDHAmc-Dea1yOuj1QzxLDTAnCXWKQ@mail.gmail.com>

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 <jnc at mercury.lcs.mit.edu> 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: <b1e76fcc-00f6-cb39-acb5-f52836945b75@kilonet.net>

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 <doug at cs.dartmouth.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/5b4ff36c/attachment.sig>

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: <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>

On Tuesday, February 21, 2017, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/294e5437/attachment.html>

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: <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
Message-ID: <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/1da3aba5/attachment.html>

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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
Message-ID: <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>

​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 <wes.parish at paradise.net.nz>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/26def03b/attachment.html>

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: <CAMYpm84mujTaywoQxJ+=8FgZ7dj6Mu0pqEuH-QxMkn1Nxmuz5Q@mail.gmail.com>

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: <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
Message-ID: <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>

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: <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
 <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>
Message-ID: <alpine.LRH.2.20.1702211717530.610@waffle.shalott.net>


> 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: <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
Message-ID: <CAC20D2P0mNVfRGA+NaHGfwvubONm0ErLxw8yf0vvpU1H-HJfbQ@mail.gmail.com>

On Tue, Feb 21, 2017 at 8:35 PM, Arthur Krewat <krewat at kilonet.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/bcdc3f3c/attachment.html>

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: <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
Message-ID: <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>

On Tue, Feb 21, 2017 at 10:02 AM, Clem Cole <clemc at ccc.com> wrote:
>
> On Tue, Feb 21, 2017 at 7:02 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> 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?
> <https://www.quora.com/Would-it-be-possible-advantageous-to-rewrite-the-Linux-kernel-in-Rust-when-the-language-is-stable>
>  &
>  Why did Unix succeed and not Multics
> <https://www.quora.com/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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/14bbffb2/attachment.html>

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: <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
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: <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1702212122510.32238@frieza.hoshinet.org>

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: <CAMYpm84mujTaywoQxJ+=8FgZ7dj6Mu0pqEuH-QxMkn1Nxmuz5Q@mail.gmail.com>
References: <CAMYpm84mujTaywoQxJ+=8FgZ7dj6Mu0pqEuH-QxMkn1Nxmuz5Q@mail.gmail.com>
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: <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
Message-ID: <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>

On Tue, Feb 21, 2017 at 8:50 PM, Dan Cross <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/bc3d72fa/attachment.html>

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: <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
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: <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
 <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>

On Tue, Feb 21, 2017 at 9:25 PM, Steve Nickolas <usotsuki at buric.co> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/f70908f6/attachment.html>

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>
 <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
 <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>
 <20170222031836.GH9439@mcvoy.com>
Message-ID: <CAP6exYL8DYJ7QO-b=9DJAKDFgRWye4D_sSUcqtGu1Li-csaM5A@mail.gmail.com>

On Tue, Feb 21, 2017 at 7:18 PM Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/e46105ef/attachment.html>

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: <CAMYpm85TL59yyyf2woCLF8JHZaQGwne09=18k06KmygMcv+Eaw@mail.gmail.com>

>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: <CAP6exYL8DYJ7QO-b=9DJAKDFgRWye4D_sSUcqtGu1Li-csaM5A@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
 <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>
 <20170222031836.GH9439@mcvoy.com>
 <CAP6exYL8DYJ7QO-b=9DJAKDFgRWye4D_sSUcqtGu1Li-csaM5A@mail.gmail.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 <lm at mcvoy.com> 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: <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
Message-ID: <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>

On Tue, Feb 21, 2017 at 10:11 PM, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/c83262ec/attachment.html>

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>
 <CALMnNGhO+bnqrYPdTHSbdmsWHZewmrruqpR8Ctnv=9G0z6UWdg@mail.gmail.com>
 <CAP6exYLxRUQmoJcuW2FYheiRQeue3VqoULaCUxCW9XC7Fcm20g@mail.gmail.com>
 <20170222031836.GH9439@mcvoy.com>
 <CAP6exYL8DYJ7QO-b=9DJAKDFgRWye4D_sSUcqtGu1Li-csaM5A@mail.gmail.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: <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
Message-ID: <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>

On Tue, Feb 21, 2017 at 10:38 PM, Clem Cole <clemc at ccc.com> wrote:
>
> On Tue, Feb 21, 2017 at 9:25 PM, Steve Nickolas <usotsuki at buric.co> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170221/bf1afbe3/attachment.html>

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1702220054580.44550@frieza.hoshinet.org>

On Tue, 21 Feb 2017, Clem Cole wrote:

> On Tue, Feb 21, 2017 at 9:25 PM, Steve Nickolas <usotsuki at buric.co> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <20170222031758.GG9439@mcvoy.com>
Message-ID: <201702220843.v1M8hx2t017602@freefriends.org>

Larry McVoy <lm at mcvoy.com> 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>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/0a781c09/attachment.html>

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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <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 <lm at 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).
>  



"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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/c6ab3bf2/attachment.html>

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: <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
Message-ID: <aeeb7513-688b-41ad-aead-35817a55f890@SG2APC01FT029.eop-APC01.prod.protection.outlook.com>

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 <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/0621b9f6/attachment.html>

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: <alpine.DEB.2.11.1702220947560.23970@grey.csi.cam.ac.uk>

Norman Wilson <norman at oclsc.org> 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  <dot at dotat.at>  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: <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/5a1192a4/attachment.html>

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>
 <CAC20D2NStqm47mfSFUvtVaLZfB-cdWUfc7r4RoZBWUp4fTmaOw@mail.gmail.com>
 <CAJfiPzz3Wvvgye0rRjZG4HAGWLU3ZtpGnii3KOBzOWkV4r5zvg@mail.gmail.com>
 <1ba0f584-6478-4332-bcae-63ac6cedf2f6@SG2APC01FT041.eop-APC01.prod.protection.outlook.com>
 <alpine.BSF.2.02.1702190200300.94021@frieza.hoshinet.org>
 <F28F6A9F-F0C3-43AE-A1A6-1335998AAE38@superglobalmegacorp.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>

<jsteve at superglobalmegacorp.com> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <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: <CAC20D2P0mNVfRGA+NaHGfwvubONm0ErLxw8yf0vvpU1H-HJfbQ@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <CAC20D2P0mNVfRGA+NaHGfwvubONm0ErLxw8yf0vvpU1H-HJfbQ@mail.gmail.com>
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 <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/5151f57e/attachment.html>

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: <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
Message-ID: <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>

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 <crossd at gmail.com> 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 <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/62d60db3/attachment.html>

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: <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
Message-ID: <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>

On Wed, Feb 22, 2017 at 11:11 AM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/c0b143d9/attachment.html>

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: <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/89f3d153/attachment.html>

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: <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
Message-ID: <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>

On Wed, Feb 22, 2017 at 1:24 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/f0c1f6ac/attachment.html>

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: <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.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: <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
Message-ID: <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/cecb3424/attachment.html>

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: <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>
 <201702222018.v1MKIUKO030787@freefriends.org>
Message-ID: <CAC20D2Ok_WyZV2K1gL9vaqOG7ndhtOJn2X-wNiyBv=BDsc1RAw@mail.gmail.com>

On Wed, Feb 22, 2017 at 3:18 PM, <arnold at skeeve.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/fdb46268/attachment.html>

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: <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
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: <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
Message-ID: <CAC20D2Mv5cXfp7BccGGCypV34mL9Duffyz8P4UX4mMSK+==0SA@mail.gmail.com>

On Wed, Feb 22, 2017 at 4:00 PM, Michael Kerpan <madcrow.maxwell at gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/560950e7/attachment.html>

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
 <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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>
 <20170222213405.GJ9439@mcvoy.com>
Message-ID: <CAC20D2MCmmi3HrG65CN=vnmyPzkb0s6hCLkKZM8=NQC=Y=YyRA@mail.gmail.com>

On Wed, Feb 22, 2017 at 4:34 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/c2f5bc64/attachment.html>

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: <CAC20D2MCmmi3HrG65CN=vnmyPzkb0s6hCLkKZM8=NQC=Y=YyRA@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>
 <20170222213405.GJ9439@mcvoy.com>
 <CAC20D2MCmmi3HrG65CN=vnmyPzkb0s6hCLkKZM8=NQC=Y=YyRA@mail.gmail.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: <alpine.BSF.2.20.1702231019130.48029@aneurin.horsfall.org>

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
 <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org>
Message-ID: <CAC20D2MdbKk1=n4J1CVhYsuY75BxvnH-b+5XH=eRX5z6SQXxDA@mail.gmail.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/7798de4f/attachment.html>

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <CAC20D2MK=hrhYP=AQn4PKZMXt_KLPCZu4R+D+FOuXLLPssiecw@mail.gmail.com>
 <20170222213405.GJ9439@mcvoy.com>
 <CAC20D2MCmmi3HrG65CN=vnmyPzkb0s6hCLkKZM8=NQC=Y=YyRA@mail.gmail.com>
 <20170222231320.GM9439@mcvoy.com>
Message-ID: <CAC20D2MW_0w_pByDrwU9aTYsmFdztnNC4E2Ea11tEnUMeJEpKA@mail.gmail.com>

On Wed, Feb 22, 2017 at 6:13 PM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170222/b16dc572/attachment.html>

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: <alpine.BSF.2.20.1702231019130.48029@aneurin.horsfall.org>
References: <1487543997.751282.886126728.48CE1043@webmail.messagingengine.com>
 <alpine.BSF.2.20.1702231019130.48029@aneurin.horsfall.org>
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 <dave at horsfall.org> 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: <CAC20D2MdbKk1=n4J1CVhYsuY75BxvnH-b+5XH=eRX5z6SQXxDA@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <CAHfSdrX-Sr3C60+c+jdGJjEEVnkpPTagxuJQe3T2T9Ndsm8oBQ@mail.gmail.com>
 <20170222220320.mxcjnenf5y2k25qt@ancienthardware.org>
 <CAC20D2MdbKk1=n4J1CVhYsuY75BxvnH-b+5XH=eRX5z6SQXxDA@mail.gmail.com>
Message-ID: <CAC5iaNGMs6BidR5yEeMYm+puzXtFJHrmGoHSWAGgV+aa2pbMQw@mail.gmail.com>

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 <clemc at ccc.com> 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>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
Message-ID: <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>

On 21 February 2017 at 23:17, Larry McVoy <lm at mcvoy.com> 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: <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
 <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
Message-ID: <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/8b153e3c/attachment.html>

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: <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
 <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
 <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
Message-ID: <CAJfiPzy4GkUdv+zn=uZYCfVfcSN7Hdm8jgba=FCshY5z35djig@mail.gmail.com>

On 23 February 2017 at 11:00, Clem Cole <clemc at ccc.com> 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.

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl>
Message-ID: <CAC20D2MnDo8U8AYR2mgH+m_kRRMDQ8H8k6nSDyDbz8AhBymw1Q@mail.gmail.com>

On Wed, Feb 22, 2017 at 6:51 PM, Paul Ruizendaal <pnr at planet.nl> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/d0b435d6/attachment.html>

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: <CAC20D2MnDo8U8AYR2mgH+m_kRRMDQ8H8k6nSDyDbz8AhBymw1Q@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl>
 <CAC20D2MnDo8U8AYR2mgH+m_kRRMDQ8H8k6nSDyDbz8AhBymw1Q@mail.gmail.com>
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 <pnr at planet.nl> 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" <pssawyer at comcast.net.INVALID> 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: <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
 <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
 <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1702240858570.48029@aneurin.horsfall.org>

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl>
 <CAC20D2MnDo8U8AYR2mgH+m_kRRMDQ8H8k6nSDyDbz8AhBymw1Q@mail.gmail.com>
 <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com>
Message-ID: <58af66a8.RixQ2R2YtVU32E8p%schily@schily.net>

Random832 <random832 at fastmail.com> 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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl>
 <CAC20D2MnDo8U8AYR2mgH+m_kRRMDQ8H8k6nSDyDbz8AhBymw1Q@mail.gmail.com>
 <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 <random832 at fastmail.com>:

> On Thu, Feb 23, 2017, at 14:15, Clem Cole wrote:
> > On Wed, Feb 22, 2017 at 6:51 PM, Paul Ruizendaal <pnr at planet.nl>
> 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" <pssawyer at comcast.net.INVALID> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <CAC20D2P0mNVfRGA+NaHGfwvubONm0ErLxw8yf0vvpU1H-HJfbQ@mail.gmail.com>
 <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 <krewat at kilonet.net 
>> <mailto:krewat at kilonet.net>> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/93cdc569/attachment.html>

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: <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
 <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
 <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
Message-ID: <C5B717AE-E203-4885-99F5-8536BB33A10F@superglobalmegacorp.com>

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 <clemc at ccc.com> wrote:
>
>
>On Thu, Feb 23, 2017 at 10:31 AM, Nemo < cym224 at gmail.com
><mailto: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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/dc525062/attachment.html>

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: <alpine.BSF.2.20.1702240858570.48029@aneurin.horsfall.org>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
 <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
 <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
 <alpine.BSF.2.20.1702240858570.48029@aneurin.horsfall.org>
Message-ID: <CAC20D2O5DqW_gkwRRHpHq2X4AQMRiuCqYZMau+3-2z+e1Na4aA@mail.gmail.com>

On Thu, Feb 23, 2017 at 5:02 PM, Dave Horsfall <dave at horsfall.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/aa7b029f/attachment.html>

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: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
 <20170222161114.GT9439@mcvoy.com>
 <CAC20D2N74KiRfBzmiGmvyHTgaaMQfPd9QBYc_iUt6nCz7wdA3A@mail.gmail.com>
 <20170222182440.GE9439@mcvoy.com>
 <0793B069-8A80-450E-9E49-68C19448C2E9@planet.nl>
 <CAC20D2MnDo8U8AYR2mgH+m_kRRMDQ8H8k6nSDyDbz8AhBymw1Q@mail.gmail.com>
 <1487881864.3245413.890885432.69DE979F@webmail.messagingengine.com>
 <58af66a8.RixQ2R2YtVU32E8p%schily@schily.net>
Message-ID: <BE423CA1-2D95-42CC-BE5D-68B7F13B324E@superglobalmegacorp.com>

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 <schily at schily.net> wrote:
>Random832 <random832 at fastmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/ab092751/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/6a18de91/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/8decc2a0/attachment.sig>

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: <f2908019-f998-4881-886f-3fd72d91dde9@SG2APC01FT059.eop-APC01.prod.protection.outlook.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/97ed30ba/attachment.html>

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: <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <CAEoi9W4A-FGPVYtsiO4pMVjeMA5rkB7WAMJcDK8SL6LrGOe5zw@mail.gmail.com>
 <CAC20D2M=ucsTTXx7P8c+P7vd17fDAmEhgR9Qy_q-DHtjVoXxVA@mail.gmail.com>
Message-ID: <CAEoi9W5tkD+cyJ2Pj+7yeACD0C22qyZRXxciAAiDgd0iekuvxQ@mail.gmail.com>

[Apologies in advance for this enormous wall of text]

On Wed, Feb 22, 2017 at 10:36 AM, Clem Cole <clemc at ccc.com> 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 <crossd at gmail.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/16ff0f74/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/5188c858/attachment.sig>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/d44b2a8a/attachment.html>

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: <e05bedb7-01ec-41b7-a088-50098cf89564@SG2APC01FT056.eop-APC01.prod.protection.outlook.com>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/4b128c42/attachment.html>

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: <e05bedb7-01ec-41b7-a088-50098cf89564@SG2APC01FT056.eop-APC01.prod.protection.outlook.com>
References: <28418.1487910189@cesium.clock.org>
 <1487910430.2910579.891270784.53290BC0@webmail.messagingengine.com>
 <e05bedb7-01ec-41b7-a088-50098cf89564@SG2APC01FT056.eop-APC01.prod.protection.outlook.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170223/f6746f4f/attachment.html>

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: <alpine.BSF.2.02.1702220054580.44550@frieza.hoshinet.org>
References: <CAC20D2O3M0OorMW63iSz3vTpeOXHyg4KS0dLOTekngXnVULe5A@mail.gmail.com>
 <alpine.BSF.2.02.1702220054580.44550@frieza.hoshinet.org>
Message-ID: <F57EDCB6-62B4-437B-8FC2-9839F178C8F2@johnlabovitz.com>

> On Feb 21, 2017, at 9:56 PM, Steve Nickolas <usotsuki at buric.co> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170224/4b95ddf3/attachment.sig>

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 <b4 at gewt.net> 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 <lars at nocrew.org> wrote:
> 
> Cory Smelosky <b4 at gewt.net> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <CAC20D2P0mNVfRGA+NaHGfwvubONm0ErLxw8yf0vvpU1H-HJfbQ@mail.gmail.com>
 <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 <krewat at kilonet.net> 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 <krewat at kilonet.net 
> >> <mailto:krewat at kilonet.net>> 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: <CACytpF9XGJu6E3CH32v1a7b1fgnD6Be2UAEbASLYOd1jZ5Gjdw@mail.gmail.com>

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 <jnc at 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 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: <CAC20D2O5DqW_gkwRRHpHq2X4AQMRiuCqYZMau+3-2z+e1Na4aA@mail.gmail.com>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <CAC20D2O6QxqBjQ4KKpG1u3U60KQbvHmRJR+NHhy3W4s-aCyRqA@mail.gmail.com>
 <CAEoi9W5fRdTfUWM3gMs6oxYQdjGnPu3p8ipD-jQZbrNseEEHQw@mail.gmail.com>
 <CAC20D2NYHo1EOg7AVXs5gQKMMoxY=brf+9xSoSaSFRBkLwQidg@mail.gmail.com>
 <CAEoi9W6O0nN2O8LmiogkkpJ5YpTOBjum557O_K2FDj16gu7PsQ@mail.gmail.com>
 <20170222041734.GP9439@mcvoy.com>
 <CAJfiPzzPO2fve9zokdr9JEQghtkLHRrL-Vk0qS-VpWyUeF+4QQ@mail.gmail.com>
 <CAC20D2NUBfe_VkMOrEPxcZzX+szzvJNEORg+v6T1qQqxTuHYYw@mail.gmail.com>
 <alpine.BSF.2.20.1702240858570.48029@aneurin.horsfall.org>
 <CAC20D2O5DqW_gkwRRHpHq2X4AQMRiuCqYZMau+3-2z+e1Na4aA@mail.gmail.com>
Message-ID: <alpine.BSF.2.20.1702250729060.48029@aneurin.horsfall.org>

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: <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
References: <20170221120218.E07BA18C10B@mercury.lcs.mit.edu>
 <20170221164728.GZ20341@mcvoy.com>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/aacef22f/attachment.sig>

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: <alpine.BSF.2.20.1702250810120.48029@aneurin.horsfall.org>

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: <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.org>

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: <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.org>
References: <20170224063744.GB2239@minnie.tuhs.org>
 <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/428dbff3/attachment.sig>

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: <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.org>
References: <20170224063744.GB2239@minnie.tuhs.org>
 <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/bcdd2155/attachment.sig>

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: <CB197A41-8C0B-4CF5-9D4F-9B5E3A667EFD@superglobalmegacorp.com>

I think like the UTZOO archives, it would be incredibly invaluable

On February 24, 2017 2:37:44 PM GMT+08:00, Warren Toomey <wkt at tuhs.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/b4087f99/attachment.html>

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: <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.org>
References: <20170224063744.GB2239@minnie.tuhs.org>
 <alpine.BSF.2.20.1702250836370.48029@aneurin.horsfall.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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/cae48007/attachment.html>

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: <alpine.BSF.2.02.1702251133340.37420@frieza.hoshinet.org>

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: <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>

On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/f286ba59/attachment.html>

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: <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>
References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org>
 <20170225143255.GH21761@mcvoy.com>
 <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>
Message-ID: <CANV78LRPBcGsJuGrUcc+iV3zjWubYRDhBsx5+3uSSrRM31by_Q@mail.gmail.com>

On Sat, Feb 25, 2017 at 9:31 AM, Clem Cole <clemc at ccc.com> wrote:

>
> On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm at mcvoy.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/c466b567/attachment.html>

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: <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>
References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org>
 <20170225143255.GH21761@mcvoy.com>
 <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.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 <clemc at ccc.com> wrote:
> 
> 
> On Sat, Feb 25, 2017 at 9:32 AM, Larry McVoy <lm at mcvoy.com> 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: <CAJfiPzw7u7gdks68SVqHU0HwXRBaNkUM60K6by7g=Nua7hfjgQ@mail.gmail.com>

On 25 February 2017 at 09:32, Larry McVoy <lm at mcvoy.com> 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: <CAJfiPzw7u7gdks68SVqHU0HwXRBaNkUM60K6by7g=Nua7hfjgQ@mail.gmail.com>
References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org>
 <20170225143255.GH21761@mcvoy.com>
 <CAJfiPzw7u7gdks68SVqHU0HwXRBaNkUM60K6by7g=Nua7hfjgQ@mail.gmail.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 <cym224 at gmail.com> wrote:
> 
> On 25 February 2017 at 09:32, Larry McVoy <lm at mcvoy.com> 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: <alpine.BSF.2.02.1702251133340.37420@frieza.hoshinet.org>
References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org>
 <20170225143255.GH21761@mcvoy.com>
 <alpine.BSF.2.02.1702251133340.37420@frieza.hoshinet.org>
Message-ID: <58b1c8ed.cS2tH2WxK2fCGUgD%schily@schily.net>

Steve Nickolas <usotsuki at buric.co> 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>
 <alpine.BSF.2.02.1702251133340.37420@frieza.hoshinet.org>
 <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 <schily at schily.net> wrote:
> 
> Steve Nickolas <usotsuki at buric.co> 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: <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>
References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org>
 <20170225143255.GH21761@mcvoy.com>
 <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>
Message-ID: <773222BF-B109-4EC0-8E55-F022AE7B69DA@tfeb.org>

On 25 Feb 2017, at 17:31, Clem Cole <clemc at ccc.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/b98790c7/attachment.html>

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: <adf70328-3833-86cf-3280-d288f2de1be2@bitsavers.org>



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: <B3D2698B-CD7F-46E4-98CA-49D679FF3B7D@gewt.net>

Argh!

MtXinu is something I really want.

Sent from my iPhone

> On Feb 25, 2017, at 10:57, Al Kossow <aek at bitsavers.org> 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: <B3D2698B-CD7F-46E4-98CA-49D679FF3B7D@gewt.net>
References: <1487994739.4144700.892331856.072026AC@webmail.messagingengine.com>
 <3d863863-b788-b372-cc2d-3ab116b8244e@bitsavers.org>
 <B3D2698B-CD7F-46E4-98CA-49D679FF3B7D@gewt.net>
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 <aek at bitsavers.org> 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: <alpine.BSF.2.20.1702261020320.70093@aneurin.horsfall.org>

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: <CC706592-325B-4EFD-A920-49F33D82DE5A@superglobalmegacorp.com>

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 <b4 at gewt.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/851256ae/attachment.html>

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: <CC706592-325B-4EFD-A920-49F33D82DE5A@superglobalmegacorp.com>
References: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com>
 <CC706592-325B-4EFD-A920-49F33D82DE5A@superglobalmegacorp.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
> <b4 at gewt.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170225/cc7382ac/attachment.html>

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: <adf70328-3833-86cf-3280-d288f2de1be2@bitsavers.org>
References: <20170225141738.f3uauxhasru7gsb3@ancienthardware.org>
 <adf70328-3833-86cf-3280-d288f2de1be2@bitsavers.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 <aek at bitsavers.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/57c6b59e/attachment.html>

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: <CAMYpm85=YKn3YSboi-ZwGhUhAqh6dO3kh44didL=q5sT=rwGvw@mail.gmail.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
> Message: 1
> Date: Sat, 25 Feb 2017 16:55:25 -0800
> From: Cory Smelosky <b4 at gewt.net>
> 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>
 <CAC20D2O5q5b2RsyiR41Cpy67GaPvXdOrc3_U=1tfJ=7TJTRcdg@mail.gmail.com>
 <20170221192124.GO20341@mcvoy.com>
 <alpine.BSF.2.02.1702211526080.10391@frieza.hoshinet.org>
 <20170221203256.GF3250@mcvoy.com>
 <1487717888.58acc60090241@www.paradise.net.nz>
 <CAC20D2MVD-5xVVgX43EGLG_ktJFMqPFTuczOVe4+iRj0OHYy5Q@mail.gmail.com>
 <bae1857b-0612-737b-eda1-ae133c028a6e@kilonet.net>
 <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: <alpine.BSF.2.20.1702261020320.70093@aneurin.horsfall.org>
 <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: <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>

On 26 Feb 2017, at 12:39, Noel Chiappa <jnc at mercury.lcs.mit.edu> 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: <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
Message-ID: <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>

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" <tfb at tfeb.org> wrote:

> On 26 Feb 2017, at 12:39, Noel Chiappa <jnc at mercury.lcs.mit.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/89b49fd0/attachment.html>

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: <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
Message-ID: <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>

Michael Kerpan <madcrow.maxwell at gmail.com> 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: <CAMYpm85=YKn3YSboi-ZwGhUhAqh6dO3kh44didL=q5sT=rwGvw@mail.gmail.com>
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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
Message-ID: <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>


> On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
Message-ID: <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>

Tim Bradshaw <tfb at tfeb.org> wrote:

>
> > On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <20170226152545.GA24045@indra.papnet.eu>
Message-ID: <58b2fa6f.lxYDRTAIh525gBIN%schily@schily.net>

Angelo Papenhoff <aap at papnet.eu> wrote:

> Whoops, replied off list too accidentally, sorry Jörg.

Woops replied off list as well...

Angelo Papenhoff <aap at papnet.eu> 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: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>

On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se> 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: <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
Message-ID: <D9FEED81-2BE3-430E-ADF3-CDAA7DC25F24@tfeb.org>

On 26 Feb 2017, at 14:19, Michael Kerpan <madcrow.maxwell at gmail.com> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
Message-ID: <FBE55275-7730-4F9E-81AF-A585F5AC6328@tfeb.org>

On 26 Feb 2017, at 15:52, Joerg Schilling <schily at schily.net> 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>
 <CC706592-325B-4EFD-A920-49F33D82DE5A@superglobalmegacorp.com>
 <1488080787.179627.892986096.7AD36438@webmail.messagingengine.com>
Message-ID: <f5a1d513-3cc1-6a4d-64a3-669b49d7226f@kilonet.net>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/6ca54ee8/attachment.html>

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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
Message-ID: <CAHfSdrVWgC==1vRafMBhFuoEHSDFFFxfmrNycNUrRz9vfLH8pg@mail.gmail.com>

On Feb 26, 2017 10:52 AM, "Joerg Schilling" <schily at schily.net> wrote:

Tim Bradshaw <tfb at tfeb.org> wrote:

>
> > On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/dbdbb9ba/attachment.html>

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: <FBE55275-7730-4F9E-81AF-A585F5AC6328@tfeb.org>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
 <FBE55275-7730-4F9E-81AF-A585F5AC6328@tfeb.org>
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: <D9FEED81-2BE3-430E-ADF3-CDAA7DC25F24@tfeb.org>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <D9FEED81-2BE3-430E-ADF3-CDAA7DC25F24@tfeb.org>
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: <CAHfSdrVWgC==1vRafMBhFuoEHSDFFFxfmrNycNUrRz9vfLH8pg@mail.gmail.com>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
 <CAHfSdrVWgC==1vRafMBhFuoEHSDFFFxfmrNycNUrRz9vfLH8pg@mail.gmail.com>
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" <schily at schily.net> wrote:

Tim Bradshaw <tfb at tfeb.org> wrote:

>
> > On 26 Feb 2017, at 14:54, Joerg Schilling <schily at schily.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/894131ae/attachment.html>

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: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk
 pg@mail.gmail.com>
Message-ID: <1488125142.S.6508.12698.f4-234-213.1488127583.13977@webmail.rediffmail.com>

&gt; On 26 Feb 2017 07:39 -0500, from jnc at mercury.lcs.mit.edu (Noel Chiappa):&gt;&gt; I was never happy with the size of EMACS, and it had nothing to do with &gt;&gt; the amount of memory resources used. That big a binary implies a very &gt;&gt; large amount of source, and the more lines of code, the more places for &gt;&gt;bugs...GNU Emacs 26.0.50, GTK+ Version 3.22.8) of 2017-02-25 (Fedora25, Kernel: 4.9.11:Virtual: 794.6Resident:&nbsp; 36.8&nbsp;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/360cae85/attachment.html>

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: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
References: <20170226124657.GB21079@yeono.kjorling.se>
 <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
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 <michael at kjorling.se> 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: <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/a5dc51ef/attachment.html>

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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
Message-ID: <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>

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: <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
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: <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
Message-ID: <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>

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" <usotsuki at buric.co> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/c0ea68f3/attachment.html>

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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
 <CAHfSdrVWgC==1vRafMBhFuoEHSDFFFxfmrNycNUrRz9vfLH8pg@mail.gmail.com>
 <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>
 <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <20170226170543.GA21831@yeono.kjorling.se>
Message-ID: <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org>

On 26 Feb 2017, at 17:05, Michael Kjörling <michael at kjorling.se> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
Message-ID: <868tosre1c.fsf@molnjunk.nocrew.org>

Tim Bradshaw <tfb at tfeb.org> 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: <f5a1d513-3cc1-6a4d-64a3-669b49d7226f@kilonet.net>
References: <1488070525.154368.892915216.18B7F7A4@webmail.messagingengine.com>
 <CC706592-325B-4EFD-A920-49F33D82DE5A@superglobalmegacorp.com>
 <1488080787.179627.892986096.7AD36438@webmail.messagingengine.com>
 <f5a1d513-3cc1-6a4d-64a3-669b49d7226f@kilonet.net>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/73df2e44/attachment.html>

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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
 <FBE55275-7730-4F9E-81AF-A585F5AC6328@tfeb.org>
 <008701d2904d$29d56c60$7d804520$@ronnatalie.com>
Message-ID: <86d1e4reep.fsf@molnjunk.nocrew.org>

"Ron Natalie" <ron at ronnatalie.com> 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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
References: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
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>
 <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <20170226170543.GA21831@yeono.kjorling.se>
 <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org>
Message-ID: <CA+oaVqwf2xaTnKoiQiBQDYizeWo8De1Ncao+Gp__hjirbCja7A@mail.gmail.com>

On Sun, Feb 26, 2017 at 1:23 PM, Tim Bradshaw <tfb at tfeb.org> 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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
Message-ID: <CAPWNY8WOMidgV9W=ynDqjXbif9eRikFqF5pOUPiR5qdZm+reJQ@mail.gmail.com>

On Sun, Feb 26, 2017 at 9:16 PM, David <david at kdbarto.org> 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 <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/acdb500a/attachment.html>

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: <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <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: <CA+oaVqwf2xaTnKoiQiBQDYizeWo8De1Ncao+Gp__hjirbCja7A@mail.gmail.com>
References: <20170226124657.GB21079@yeono.kjorling.se>
 <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <20170226170543.GA21831@yeono.kjorling.se>
 <22DFC2A3-0279-43FD-BBD6-9A1BF32E5E80@tfeb.org>
 <CA+oaVqwf2xaTnKoiQiBQDYizeWo8De1Ncao+Gp__hjirbCja7A@mail.gmail.com>
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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <20170226193349.GA24397@mcvoy.com>
Message-ID: <CAHfSdrUb2Z-W6WMVAx91UOmVFobi6+FCig=amwtmy5sP2WkMAA@mail.gmail.com>

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 <lm at mcvoy.com> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <20170226193349.GA24397@mcvoy.com>
 <00e201d29067$5a42bc80$0ec83580$@ronnatalie.com>
 <00e401d29067$a6dfc600$f49f5200$@ronnatalie.com>
Message-ID: <CAEoi9W72b83wtJ8CNS5RiGY2+zujwihJipZoQGFxi8ZFXwYhXQ@mail.gmail.com>

On Sun, Feb 26, 2017 at 2:36 PM, Ron Natalie <ron at ronnatalie.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/482034f5/attachment.html>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/6664de35/attachment.sig>

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: <CAHfSdrUb2Z-W6WMVAx91UOmVFobi6+FCig=amwtmy5sP2WkMAA@mail.gmail.com>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <20170226193349.GA24397@mcvoy.com>
 <CAHfSdrUb2Z-W6WMVAx91UOmVFobi6+FCig=amwtmy5sP2WkMAA@mail.gmail.com>
Message-ID: <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net>

Michael Kerpan <madcrow.maxwell at gmail.com> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <20170226193349.GA24397@mcvoy.com>
 <CAHfSdrUb2Z-W6WMVAx91UOmVFobi6+FCig=amwtmy5sP2WkMAA@mail.gmail.com>
 <58b34844.HoTA1xfvtZOgVnx8%schily@schily.net>
Message-ID: <58b34895.eLW6WgZ6wDmxHqbV%schily@schily.net>

schily at schily.net (Joerg Schilling) wrote:

> Michael Kerpan <madcrow.maxwell at gmail.com> 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: <CAMYpm85UeJjowDvvr6kuDHUE1JbuwqG5fLh7RvEGuXhK=eSb3A@mail.gmail.com>

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 <krewat at kilonet.net>
>To: Cory Smelosky <b4 at gewt.net>, Jason Stevens
>        <jsteve at superglobalmegacorp.com>, tuhs at minnie.tuhs.org
>Subject: Re: [TUHS] SCO OpenDesktop 386 2.0.0
>Message-ID: <f5a1d513-3cc1-6a4d-64a3-669b49d7226f at kilonet.net>
>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: <CALMnNGg3dRV0yPV1GgeqaOFG0Mb5PSNuqgPs8pLKOHYzurYEOg@mail.gmail.com>
References: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <CALMnNGg3dRV0yPV1GgeqaOFG0Mb5PSNuqgPs8pLKOHYzurYEOg@mail.gmail.com>
Message-ID: <CAJfiPzwpjk12WC6HpCJH1eY-42T4WeGmiLjfsFC3Lf0GZCMW6w@mail.gmail.com>

On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> 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" <grog at lemis.com>
To:"Noel Chiappa" <jnc at mercury.lcs.mit.edu>
Cc:<tuhs at minnie.tuhs.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/a890d04c/attachment.html>

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: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
References: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
Message-ID: <EAAB73F0-6D4E-4534-A49B-AD69CFE41F6C@superglobalmegacorp.com>

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 <cym224 at gmail.com> wrote:
>On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se>
>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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/b1b9a5e1/attachment.html>

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: <CAJfiPzwpjk12WC6HpCJH1eY-42T4WeGmiLjfsFC3Lf0GZCMW6w@mail.gmail.com>
References: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <CALMnNGg3dRV0yPV1GgeqaOFG0Mb5PSNuqgPs8pLKOHYzurYEOg@mail.gmail.com>
 <CAJfiPzwpjk12WC6HpCJH1eY-42T4WeGmiLjfsFC3Lf0GZCMW6w@mail.gmail.com>
Message-ID: <alpine.BSF.2.02.1702262048390.56395@frieza.hoshinet.org>

On Sun, 26 Feb 2017, Nemo wrote:

> On 26 February 2017 at 12:28, Andy Kosela <andy.kosela at gmail.com> 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: <EAAB73F0-6D4E-4534-A49B-AD69CFE41F6C@superglobalmegacorp.com>
References: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <EAAB73F0-6D4E-4534-A49B-AD69CFE41F6C@superglobalmegacorp.com>
Message-ID: <CAH1jEzbyN6gKzrTMmNs+SOHq-uv91poxF8yovgXuBgbCFTwAGA@mail.gmail.com>

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
<jsteve at superglobalmegacorp.com> 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 <cym224 at gmail.com> wrote:
>>
>> On 26 February 2017 at 07:46, Michael Kjörling <michael at kjorling.se>
>> 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>
 <CAC20D2Pu+MrZ540LsWHZZCZDtOnEBn_Ft8Bekc3+BDLeVmhsiQ@mail.gmail.com>
 <773222BF-B109-4EC0-8E55-F022AE7B69DA@tfeb.org>
Message-ID: <alpine.BSF.2.20.1702271603520.78237@aneurin.horsfall.org>

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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/94a9bec3/attachment.sig>

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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
Message-ID: <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>

> On 26 Feb 2017, at 19:16, David <david at kdbarto.org> 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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
Message-ID: <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>

On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff <lars at nocrew.org> 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: <CAMYpm85=YKn3YSboi-ZwGhUhAqh6dO3kh44didL=q5sT=rwGvw@mail.gmail.com>
 <20170226150722.D6C8540B9@lod.com>
Message-ID: <CACwAiQ=ZLboLaOkpnimtrAZYs7c4f+1w8_qj3zaKu2-QdjLDdw@mail.gmail.com>

Hi Corey

can I have a copy?

thanks
Rico


On Sun, Feb 26, 2017 at 7:07 AM, Corey Lindsly <corey at lod.com> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170226/c35b24b3/attachment.html>

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: <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
References: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
 <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
Message-ID: <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>

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 <imp at bsdimp.com> wrote:
> On Mon, Feb 27, 2017 at 12:19 AM, Lars Brinkhoff <lars at nocrew.org> 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: <alpine.BSF.2.02.1702262048390.56395@frieza.hoshinet.org>
References: <CAJfiPzzDKemjamKHP8rpC3j-hW_K3NY-D7oQ3D0k8DGzUpk+pg@mail.gmail.com>
 <CALMnNGg3dRV0yPV1GgeqaOFG0Mb5PSNuqgPs8pLKOHYzurYEOg@mail.gmail.com>
 <CAJfiPzwpjk12WC6HpCJH1eY-42T4WeGmiLjfsFC3Lf0GZCMW6w@mail.gmail.com>
 <alpine.BSF.2.02.1702262048390.56395@frieza.hoshinet.org>
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 <andy.kosela at gmail.com> 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: <CACwAiQ=ZLboLaOkpnimtrAZYs7c4f+1w8_qj3zaKu2-QdjLDdw@mail.gmail.com>
References: <CAMYpm85=YKn3YSboi-ZwGhUhAqh6dO3kh44didL=q5sT=rwGvw@mail.gmail.com>
 <20170226150722.D6C8540B9@lod.com>
 <CACwAiQ=ZLboLaOkpnimtrAZYs7c4f+1w8_qj3zaKu2-QdjLDdw@mail.gmail.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 <rp at servium.ch>:

> Hi Corey
> 
> can I have a copy?
> 
> thanks
> Rico
> 
> 
> On Sun, Feb 26, 2017 at 7:07 AM, Corey Lindsly <corey at lod.com> 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: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
References: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
Message-ID: <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se>

On 2017-02-27 08:26, Lars Brinkhoff <lars at nocrew.org> 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: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
 <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se>
Message-ID: <86mvd8orhm.fsf@molnjunk.nocrew.org>

Johnny Billquist <bqt at update.uu.se> 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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
Message-ID: <58b400e9.dJ2hxgoDSpv/lfTa%schily@schily.net>

David <david at kdbarto.org> 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: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
 <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 <bqt at update.uu.se> 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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <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 <lars at nocrew.org> 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: <CAMYpm85=YKn3YSboi-ZwGhUhAqh6dO3kh44didL=q5sT=rwGvw@mail.gmail.com>
 <20170226150722.D6C8540B9@lod.com>
 <CACwAiQ=ZLboLaOkpnimtrAZYs7c4f+1w8_qj3zaKu2-QdjLDdw@mail.gmail.com>
 <1488189078.58b3f6960b9b5@www.paradise.net.nz>
Message-ID: <dcfc7073-f85f-56a7-4c38-464293dd524e@kilonet.net>

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 <rp at servium.ch>:
>
>> Hi Corey
>>
>> can I have a copy?
>>
>> thanks
>> Rico
>>
>>
>> On Sun, Feb 26, 2017 at 7:07 AM, Corey Lindsly <corey at lod.com> 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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <00a701d29053$e13f40f0$a3bdc2d0$@ronnatalie.com>
 <20170226172011.GC21831@yeono.kjorling.se>
 <alpine.BSF.2.02.1702261232310.26193@frieza.hoshinet.org>
 <CAHfSdrV13J5Gr69NtT_Hv7VpiqkRehQT=F_cYxwP0M54iYHa6w@mail.gmail.com>
 <20170226193349.GA24397@mcvoy.com>
 <CAHfSdrUb2Z-W6WMVAx91UOmVFobi6+FCig=amwtmy5sP2WkMAA@mail.gmail.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: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
 <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se>
 <86mvd8orhm.fsf@molnjunk.nocrew.org>
 <95085781-7de7-1658-6150-ce9145d5ee49@update.uu.se>
Message-ID: <f5e54bab-fc7c-11cf-4ee4-a1c9dc459342@kilonet.net>

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: <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>
References: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
 <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
 <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>
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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
 <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
 <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>
 <20170227143302.GA15427@cowbell.employees.org>
Message-ID: <CAH1jEzbZrOKxMKJOgDy=N8Tv-A+Dy4rkQOXOr3SFadn5J5vMCw@mail.gmail.com>

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" <dfawcus+lists-tuhs at employees.org>
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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/b79ae204/attachment.html>

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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <58b400e9.dJ2hxgoDSpv/lfTa%schily@schily.net>
Message-ID: <alpine.DEB.2.11.1702271505230.13590@grey.csi.cam.ac.uk>

Joerg Schilling <schily at schily.net> 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  <dot at dotat.at>  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: <CAH1jEzbZrOKxMKJOgDy=N8Tv-A+Dy4rkQOXOr3SFadn5J5vMCw@mail.gmail.com>
References: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
 <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
 <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>
 <20170227143302.GA15427@cowbell.employees.org>
 <CAH1jEzbZrOKxMKJOgDy=N8Tv-A+Dy4rkQOXOr3SFadn5J5vMCw@mail.gmail.com>
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>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
 <FBE55275-7730-4F9E-81AF-A585F5AC6328@tfeb.org>
 <008701d2904d$29d56c60$7d804520$@ronnatalie.com>
 <86d1e4reep.fsf@molnjunk.nocrew.org>
Message-ID: <alpine.DEB.2.11.1702271603370.13590@grey.csi.cam.ac.uk>

Lars Brinkhoff <lars at nocrew.org> 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  <dot at dotat.at>  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: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
 <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
 <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>
 <20170227143302.GA15427@cowbell.employees.org>
Message-ID: <58b45726.8IrjRMpQiO8gmqst%schily@schily.net>

Derek Fawcus <dfawcus+lists-tuhs at employees.org> 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: <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>
References: <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>
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 <krewat at kilonet.net> 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: <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>
 <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: <mailman.346.1488208394.3779.tuhs@minnie.tuhs.org>
 <31f9e532-c59a-2d3d-1e9b-cef9a216d68e@update.uu.se>
 <86efyjpehy.fsf@molnjunk.nocrew.org>
Message-ID: <d3652fe6-7e96-c97f-629a-b43ffbeee592@update.uu.se>

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: <alpine.DEB.2.11.1702271603370.13590@grey.csi.cam.ac.uk>
References: <20170226123956.DBD3C18C088@mercury.lcs.mit.edu>
 <BA1995BD-B9D1-4F88-9690-45B36CE59347@tfeb.org>
 <CAHfSdrUsMzu-KB6fFGp9XeZbr5ecxvnEPzGS-CQ+jRQqGuFDGg@mail.gmail.com>
 <58b2ec12.PWETi07hYb+bxrO0%schily@schily.net>
 <13D1D81F-F878-4D23-922A-279AADF29CFE@tfeb.org>
 <58b2f9c8.N21HJWDG1ABXGZ/w%schily@schily.net>
 <FBE55275-7730-4F9E-81AF-A585F5AC6328@tfeb.org>
 <008701d2904d$29d56c60$7d804520$@ronnatalie.com>
 <86d1e4reep.fsf@molnjunk.nocrew.org>
 <alpine.DEB.2.11.1702271603370.13590@grey.csi.cam.ac.uk>
Message-ID: <CAH1jEzbkJTgRi7Yn36CowY_+NUVnpRiGT8QMTZo_+LibS3dq3A@mail.gmail.com>

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" <dot at dotat.at> wrote:

> Lars Brinkhoff <lars at nocrew.org> 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  <dot at dotat.at>  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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/5067acb7/attachment.html>

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: <CAH1jEzZjvOhHnbvsWcw8gbx9d_W47DbBidYd_tteCr5dC6H2ng@mail.gmail.com>
References: <mailman.334.1488132096.3779.tuhs@minnie.tuhs.org>
 <141DC1F7-C4AA-4EF4-8CBE-E99845326D7B@kdbarto.org>
 <3FA64C9B-4EBB-4EDA-8BD7-B59DAE6BF650@tfeb.org>
 <86y3wsp0cq.fsf@molnjunk.nocrew.org>
 <CANCZdfoW0a+VQaABaCfNTO2QAN95hqcY=QXv3rC7oukCcUXk=A@mail.gmail.com>
 <CAH1jEzbRbAOWkZz8+DR7zRLpUUR4f0UcJZfV8fS=DMYCYDgQvw@mail.gmail.com>
 <20170227143302.GA15427@cowbell.employees.org>
 <58b45726.8IrjRMpQiO8gmqst%schily@schily.net>
 <CAH1jEzZjvOhHnbvsWcw8gbx9d_W47DbBidYd_tteCr5dC6H2ng@mail.gmail.com>
Message-ID: <CAH1jEzaXYGEi8tbKxOFwesj5EgYYbXtkSqHHRPyiEb_xS4w13g@mail.gmail.com>

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" <schily at schily.net> wrote:

Derek Fawcus <dfawcus+lists-tuhs at employees.org> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/84760fd9/attachment.html>

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: <CAHfSdrVBG_wUdMKnkpqi9uysh8TXniHte3r82Pe+QceNHAaJjQ@mail.gmail.com>

Has anyone tried this on Virtualbox? If not, I'll try it out tomorrow
morning.

On Feb 27, 2017 7:20 PM, "Arthur Krewat" <krewat at kilonet.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/fb6e0c19/attachment.html>

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: <CAHfSdrVBG_wUdMKnkpqi9uysh8TXniHte3r82Pe+QceNHAaJjQ@mail.gmail.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>
 <CAHfSdrVBG_wUdMKnkpqi9uysh8TXniHte3r82Pe+QceNHAaJjQ@mail.gmail.com>
Message-ID: <D024D577-B0BE-4D53-AB92-64A0E26AFA12@gewt.net>

I did. Didn't even get to the installer.

Sent from my iPhone

> On Feb 27, 2017, at 17:15, Michael Kerpan <madcrow.maxwell at gmail.com> 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" <krewat at kilonet.net> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/5ac8fe57/attachment.html>

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 <dscherrer at solar.stanford.edu> 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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170228/c7a8cb34/attachment.html>

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: <D024D577-B0BE-4D53-AB92-64A0E26AFA12@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>
 <0ead969b-73ec-74df-a451-2eca602b0f74@kilonet.net>
 <7f4534a0-40d5-4595-a5f0-3059193ddb0c@kilonet.net>
 <CAHfSdrVBG_wUdMKnkpqi9uysh8TXniHte3r82Pe+QceNHAaJjQ@mail.gmail.com>
 <D024D577-B0BE-4D53-AB92-64A0E26AFA12@gewt.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\<redacted>\id.ima

disc_b =

mem_size = 262144

cdrom_drive = 200

cdrom_enabled = 1

cdrom_channel = 1

cdrom_path = Z:\Users\<redacted>\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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/6a68bdab/attachment.html>

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>
 <CAHfSdrVBG_wUdMKnkpqi9uysh8TXniHte3r82Pe+QceNHAaJjQ@mail.gmail.com>
 <D024D577-B0BE-4D53-AB92-64A0E26AFA12@gewt.net>
 <1488254074.690176.895047888.7A0983F2@webmail.messagingengine.com>
Message-ID: <F182BD5E-B1A7-4EF8-A95E-AD56D32A7322@gewt.net>

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 <b4 at gewt.net> 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\<redacted>\id.ima
> disc_b =
> mem_size = 262144
> cdrom_drive = 200
> cdrom_enabled = 1
> cdrom_channel = 1
> cdrom_path = Z:\Users\<redacted>\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: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170227/8b3bafa6/attachment.html>

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: <f5e54bab-fc7c-11cf-4ee4-a1c9dc459342@kilonet.net>
References: <mailman.342.1488180370.3779.tuhs@minnie.tuhs.org>
 <145bd49e-7390-034b-f8c3-002e6e6f15fe@update.uu.se>
 <86mvd8orhm.fsf@molnjunk.nocrew.org>
 <95085781-7de7-1658-6150-ce9145d5ee49@update.uu.se>
 <f5e54bab-fc7c-11cf-4ee4-a1c9dc459342@kilonet.net>
Message-ID: <0C7E9021-5412-4038-AA83-5677640AC8DE@ronnatalie.com>


> On Feb 27, 2017, at 9:04 AM, Arthur Krewat <krewat at kilonet.net> 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" <steve at quintile.net> 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


