From tfb at tfeb.org  Thu Jan  1 00:58:38 2015
From: tfb at tfeb.org (Tim Bradshaw)
Date: Wed, 31 Dec 2014 14:58:38 +0000
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
Message-ID: <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>

On 31 Dec 2014, at 06:36, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source code form?  I know many "sysadmins" still deserving of it.

If I remember they worked by talking to the framebuffer so they were happy to work with either.  By the same token they probably won't work on anything that's not a 1980s Sun framebuffer, sadly.


From arnold at skeeve.com  Thu Jan  1 01:31:03 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 31 Dec 2014 08:31:03 -0700
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
 <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>
Message-ID: <201412311531.sBVFV3gA012941@freefriends.org>

> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source
> code form?  I know many "sysadmins" still deserving of it.

It appears to have been posted in comp.sources.misc/volume4 if you can
find that. :-)

Arnold


From milov at cs.uwlax.edu  Thu Jan  1 01:37:26 2015
From: milov at cs.uwlax.edu (Milo Velimirovic)
Date: Wed, 31 Dec 2014 09:37:26 -0600
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <201412311531.sBVFV3gA012941@freefriends.org>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
 <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>
 <201412311531.sBVFV3gA012941@freefriends.org>
Message-ID: <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu>

It appears to be available here
http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/

On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote:

>> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source
>> code form?  I know many "sysadmins" still deserving of it.
> 
> It appears to have been posted in comp.sources.misc/volume4 if you can
> find that. :-)
> 
> Arnold
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From mah at mhorton.net  Thu Jan  1 02:11:15 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 31 Dec 2014 08:11:15 -0800
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
Message-ID: <54A42023.4000500@mhorton.net>

I loved my Ambassador!  Still have one.  I remember performing the 
"twisted mode" mod to be able to run it in 60x80 portrait mode, before 
Ann Arbor released a portrait product.

http://stargatemuseum.org/html/cubix_and_dumb_terminal.html

Forgive me if I didn't do a lot of EMACS on it, though.  :)

     Mary Ann

On 12/30/2014 10:36 PM, Lyndon Nerenberg wrote:
> And speaking of kick-ass terminals, who else remembers chiselling 
> emacs commands into the keyboard of an Ann Arbor Ambassador in 60x132 
> mode?!? I loved that keyboard. They could hear me pounding on it a 
> mile down the road :-) --lyndon 



From jnc at mercury.lcs.mit.edu  Thu Jan  1 02:25:43 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 31 Dec 2014 11:25:43 -0500 (EST)
Subject: [TUHS] I swear! I rtfm'ed
Message-ID: <20141231162543.9216718C0F8@mercury.lcs.mit.edu>

    > From: Mary Ann Horton <mah at mhorton.net>

    > I loved my Ambassador!

Ditto!

    > Still have one.

Argh! Now you've made me want one for my vintage -11's! Alas, I don't see one
on eBay.... :-(

	Noel


From dwalker at doomd.net  Thu Jan  1 03:37:53 2015
From: dwalker at doomd.net (Derrik Walker v2.0)
Date: Wed, 31 Dec 2014 12:37:53 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
 <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>
 <201412311531.sBVFV3gA012941@freefriends.org>
 <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu>
Message-ID: <1420047473.23152.3.camel@sagan>

On Wed, 2014-12-31 at 09:37 -0600, Milo Velimirovic wrote:
> It appears to be available here
> http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/
> 
> On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote:
> 
> >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source
> >> code form?  I know many "sysadmins" still deserving of it.
> > 
> > It appears to have been posted in comp.sources.misc/volume4 if you can
> > find that. :-)
> >

I just happen to have all these usenet posts archived on my local
system.  I found the program in question, and it appears to require a
Sun box, and judging by the date, a Sun 3 or early Sparc running Sun OS
4.  

Since my Linux box doesn't have the 'suntools' headers, I wont even try
to compile it.  

Now, if only I still had that IPX I use to have :-/

- Derrik 



From dds at aueb.gr  Thu Jan  1 03:42:23 2015
From: dds at aueb.gr (Diomidis Spinellis)
Date: Wed, 31 Dec 2014 19:42:23 +0200
Subject: [TUHS] Illumos )
In-Reply-To: <20141231131335.GA26926@mercury.ccil.org>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
Message-ID: <54A4357F.9040703@aueb.gr>

On 31/12/2014 15:13, John Cowan wrote:
> Wesley Parish scripsit:
>
>> [The] primary importance [of Solaris forks], from my POV, is that they
>> keep the POSIX space open for experimentation: a Linux monoculture's
>> as deadening as a MS Windows monoculture or a \[choose your own poison\]
>> monoculture ...
>
> Well, BSD does that.  But Solaris is the only descendant of System V for
> which we have source, which means that in non-Posix cases it can give
> us helpful information how the original Unix code fared after leaving
> the Labs.  By comparison, both Linux and BSD are clones.

Thank you for stressing the importance of Solaris as a Unix descendant 
for which source code is available.  It's a pity that we don't have 
public source code for the Solaris versions 2.1 to 10, so there's a 15 
year gap between System V R4 and the first release of Open Solaris.

I don't agree that BSD systems are a clone of Unix.  There are bits in 
them that were written at Bell Labs.  The earliest example I've found up 
to now comes from timezone.c, and was written at least 36 years ago 
(1979-01-10 14:58:45).

Compare the 7th Edition implementation of timezone()

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/gen/timezone.c

with lines 110-128 of the current FreeBSD _tztab() implementation.

https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/timezone.c

(How did I find it?  For the past six months I've been running git blame 
on various tags of https://github.com/dspinellis/unix-history-repo.)

Happy new year everybody!

-- 
Diomidis Spinellis      http://www.spinellis.gr


From lm at mcvoy.com  Thu Jan  1 06:09:09 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 31 Dec 2014 12:09:09 -0800
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <1420047473.23152.3.camel@sagan>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
 <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>
 <201412311531.sBVFV3gA012941@freefriends.org>
 <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu>
 <1420047473.23152.3.camel@sagan>
Message-ID: <20141231200909.GC2280@mcvoy.com>

On Wed, Dec 31, 2014 at 12:37:53PM -0500, Derrik Walker v2.0 wrote:
> On Wed, 2014-12-31 at 09:37 -0600, Milo Velimirovic wrote:
> > It appears to be available here
> > http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/
> > 
> > On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote:
> > 
> > >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in source
> > >> code form?  I know many "sysadmins" still deserving of it.
> > > 
> > > It appears to have been posted in comp.sources.misc/volume4 if you can
> > > find that. :-)
> > >
> 
> I just happen to have all these usenet posts archived on my local
> system.  I found the program in question, and it appears to require a
> Sun box, and judging by the date, a Sun 3 or early Sparc running Sun OS
> 4.  
> 
> Since my Linux box doesn't have the 'suntools' headers, I wont even try
> to compile it.  
> 
> Now, if only I still had that IPX I use to have :-/

http://www.ebay.com/itm/Sun-SPARCstation-LX-/201238223990?pt=LH_DefaultDomain_0&hash=item2edabb9c76

Not an IPX but it will sun sunos 4.x if I recall correctly.


From clemc at ccc.com  Thu Jan  1 06:14:00 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Dec 2014 15:14:00 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
Message-ID: <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>

Jake - you have lots of help from others and using curses(3) is definitely
the right way to program.

But to answer your specific question about printf(string), according to
Chapter 3 (Programmer's Info) of my old VT-100 user's guide, I think what
is you are doing wrong is that "\033c" is not the ANSI clear to end of
screen command.

When I saw your message on my iPhone last night, the cache said - wait that
can't be correct.   But I could not remember why.   So I had to wait until
I got back home today to look in my basement.

As I suspected, it's not an ANSI sequence.  So are you running in VT-100
(ANSI) mode or VT52 mode?  I ask because it is close to the VT52 cursor
right command which is actually:  "\033C"  but I do not remember is case
mattered.

In VT52 mode you need to send the terminal:  "\033H\033J" to clear the
screen.

In ANSI mode, it becomes:  "\033[1;1\033[0J"

A few things to remember:
1.) Clear takes the current cursor position and clears from there to end of
X (where X depends on mode, and type of clear).  So you need to move the
cursor to home position (aka 1,1).

2.) VT-100's did not implement the full ANSI spec like Ann Arbor, Heathkit,
Wyse etc.  So there are a number of things that those terminals did
better.  A really good reason to you curses(3) because all the knowledge is
keep in the termcap and as a programmer you don't need to worry about it.

3.) I saw sites were VT52 mode was sometimes preferred because it was good
enough for most editing, and needed fewer chars to do manipulation.  On
slow serial lines, this sometimes was helpful.  That said, give me an AAA
any day.  Like others, I still miss that terminal. :-)

Clem

On Tue, Dec 30, 2014 at 5:56 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> , but I can't see how you're supposed to clear the screen on a vt100 in
> 2.9BSD.  I guess printf'ing ("\033c") would do the trick, but I assumed
> there was a more proper way; something that leverages the vt100 termcap
> entry and does the right thing.  Anyone?
>
> thx
> jake
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/75ed2bb9/attachment.html>

From clemc at ccc.com  Thu Jan  1 06:32:07 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Dec 2014 15:32:07 -0500
Subject: [TUHS] Illumos )
In-Reply-To: <54A4357F.9040703@aueb.gr>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
Message-ID: <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>

On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds at aueb.gr> wrote:

> Thank you for stressing the importance of Solaris as a Unix descendant for
> which source code is available.
>
​Amen​.   BTW:
I really don't consider Solaris a pure System V ​either.  Larry and his
siblings hacked on it pretty heavily.    SGI's Iris and NCR's RAS were much
closer to "pure" Summit code and that was not "Research" UNIX.   They all
devolved.




> It's a pity that we don't have public source code for the Solaris versions
> 2.1 to 10, so there's a 15 year gap between System V R4 and the first
> release of Open Solaris.
>
> I don't agree that BSD systems are a clone of Unix.
>
​Ditto.   To me, anything post First Edition of Research UNIX is UNIX.
Where hacking started and was slowly changed.   But the core BTL DNA was is
left intact.    Idris, Linux, Minux, etc. were clones, where the API was
followed and the DNS regenerated.

​Either way, it really does not matter too much.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/06392d71/attachment.html>

From lm at mcvoy.com  Thu Jan  1 06:36:17 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 31 Dec 2014 12:36:17 -0800
Subject: [TUHS] Illumos )
In-Reply-To: <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
Message-ID: <20141231203617.GB3922@mcvoy.com>

On Wed, Dec 31, 2014 at 03:32:07PM -0500, Clem Cole wrote:
> On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds at aueb.gr> wrote:
> 
> > Thank you for stressing the importance of Solaris as a Unix descendant for
> > which source code is available.
> >
> ???Amen???.   BTW:
> I really don't consider Solaris a pure System V either.

Nope, not by a long stretch.  System V had an awful VM / file system layer,
Solaris took the one from SunOS 4 and wedged it in there.

> Larry and his siblings hacked on it pretty heavily.

Not me, man.  I hated Solaris with a passion.  I liked SunOS 4.x, I hacked
the heck out of that.


From fair-tuhs at netbsd.org  Thu Jan  1 06:45:16 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 31 Dec 2014 12:45:16 -0800
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
Message-ID: <25524.1420058716@cesium.clock.org>

The sequence ESC-c is ANSI X3.64 for "reset to initial state" which
happens to clear the screen, among other things. I still use it
frequently to reset Mac OS X "Terminal" windows to a sane state,
manually entered.

	Erik <fair at netbsd.org>


From clemc at ccc.com  Thu Jan  1 07:05:43 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Dec 2014 16:05:43 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <25524.1420058716@cesium.clock.org>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>
 <25524.1420058716@cesium.clock.org>
Message-ID: <CAC20D2M12JbShwso_zPt5jit22DevxxGr8sRecRgsXsVm1hFwg@mail.gmail.com>

Ah - that makes sense,  and since VT-100 are not fully ANSI, that's likely
why it's not listed in my circa 1976 VT-100 programmers manual and probably
why it does not work for Jacob. ;-)

Clem

On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:

> The sequence ESC-c is ANSI X3.64 for "reset to initial state" which
> happens to clear the screen, among other things. I still use it
> frequently to reset Mac OS X "Terminal" windows to a sane state,
> manually entered.
>
>         Erik <fair at netbsd.org>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/88b0863d/attachment.html>

From jacob.ritorto at gmail.com  Thu Jan  1 08:19:15 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 31 Dec 2014 17:19:15 -0500
Subject: [TUHS] Illumos )
In-Reply-To: <20141231203617.GB3922@mcvoy.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
Message-ID: <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>

Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?

  Sorry for the late answer to your original question about why we should
care about Illumos, but here's my take and some personal observations /
conclusions to boot:


  With a huge sustained effort by many of the people who wrote and/or
maintained it, Solaris was finally mostly open-sourced just before Sun
died.  There was so much good technology in the OS that it would've been a
real shame to relegate it to the Oracle people who would (did) eventually
close it, effectively killing Solaris.

 Illumos is the OS/net piece, not a distro, and takes the reins from the
moment that Oracle re-closed Solaris as the base and repo-of-record for a
number of distributions, such as the ones mentioned above, OpenIndiana,
OpenSXCE, Tribblix and most importantly to me, SmartOS from Joyent.  I
don't (yet) work for Joyent, so don't take this as a sales spin or anything
-- it's just that the company I worked for last year underwent a rather
amazing and inspirational cultural as well as technology / performance
growth when we switched the stack from CentOS to SmartOS.  It was really
cool to see the eyes opening while working with some pretty brilliant
programmers who effectively 'grew up on linux' when they saw how
engineered, featureful and just generally "sorted out" SmartOS was.  They
started using dtrace to dig into performance problems, smf to manage
services, speed of containers / zones instead of full linux VMs everywhere,
real (not hypervisor-emulated) I/O using zfs straight to SSD arrays, etc.
They saw that, in fact, a well written and architected operating system
actually does matter quite a lot for their day to day work.

  And it's all seriously free and open source.  Like, Real Actual unix, not
a clone.  The way it was meant to be.  They actually really care, not just
about being "good enough", but about continuing to develop the operating
system in an artful, elegantly simple, efficient and practical way.

  This, to me, is the perfect contrast to the Linux culture that seems to
wantonly embrace the 'copy/paste coding' / 'bazaar' / 'good enough'
mentality and seems to do no innovation but just produce knockoff,
un-architected partial functional clones of what the unix people invented.
But they miss the interacting, distributed, tolerant and very polyclutural
computing environment concepts every time.  I think they're effectively
dragging the unix ecosystem into the shitter.  Not that this hasn't been
done before, but at least before it was ill-thought-out litigious zeal, not
junk code and minimum-viable-product quality problems.  This brings to mind
the one major, albeit non-technical, problem I recognize Linux (actually,
perhaps it was just GNU) as having truly solved - they made it really
stinking clear that your license has to be open.  OSI approved open
source.  And that accomplishment, of itself, makes it totally worth
tolerating its existence.

  Please accept my apologies if I've offended you with the opinionated
content there.  These are my honest observations after four decades of
doing this, but may seem like flame bait to many.  I don't write about this
stuff often and I figure: if anyone's going to be able to understand and
respond with constructive input to this train of thought, it's the unix
historians here.

  Anyway, a friend I admire quite a lot took the time to put some of this
Sun history and Illumos fork stuff into a talk at LISA a few years back and
I think he did a really nice job.  Have a look if you like:
www.youtube.com/watch?v=-zRN7XLCRhc

  Some other interesting reading from another brilliant guy I worked with a
little, who got so disheartened about the failure of tech -- partially
Linux monoculture, partially other sad moves -- just walked away from tech
to farming instead: http://dtrace.org/blogs/wesolows/2014/12/29/fin/

  Then there's Kamp's recent article:
https://queue.acm.org/detail.cfm?id=2349257

Thanks for your time and interest; In earnest,
jake


On Wed, Dec 31, 2014 at 3:36 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Dec 31, 2014 at 03:32:07PM -0500, Clem Cole wrote:
> > On Wed, Dec 31, 2014 at 12:42 PM, Diomidis Spinellis <dds at aueb.gr>
> wrote:
> >
> > > Thank you for stressing the importance of Solaris as a Unix descendant
> for
> > > which source code is available.
> > >
> > ???Amen???.   BTW:
> > I really don't consider Solaris a pure System V either.
>
> Nope, not by a long stretch.  System V had an awful VM / file system layer,
> Solaris took the one from SunOS 4 and wedged it in there.
>
> > Larry and his siblings hacked on it pretty heavily.
>
> Not me, man.  I hated Solaris with a passion.  I liked SunOS 4.x, I hacked
> the heck out of that.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/29783dc5/attachment.html>

From jacob.ritorto at gmail.com  Thu Jan  1 08:25:39 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 31 Dec 2014 17:25:39 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <20141231200909.GC2280@mcvoy.com>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <0CD3A100-6CDD-449C-8FD0-A3F93F421A0D@tuhs.org>
 <alpine.BSF.2.11.1412311711210.25268@aneurin.horsfall.org>
 <54AEAFD8-1B3E-4327-98E3-D897B4045C20@orthanc.ca>
 <59014A39-8A70-45F2-BF6D-36CF0AAA30F8@tfeb.org>
 <201412311531.sBVFV3gA012941@freefriends.org>
 <4CAC989D-2E2C-40BA-BC35-B705C334B0FB@cs.uwlax.edu>
 <1420047473.23152.3.camel@sagan> <20141231200909.GC2280@mcvoy.com>
Message-ID: <CAHYQbfCDkSV-XpAccgjTYPUqn4ro-njHDH-wTxAHY1XMU6qoVQ@mail.gmail.com>

I have at least one of these and some other old SPARCstations, keyboards,
mice, etc. here that could use a good home if you (or others on list) want
'em to run SunOS 4.1.3 or somesuch.  I think I have install media for that
OS as well.

On Wed, Dec 31, 2014 at 3:09 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Dec 31, 2014 at 12:37:53PM -0500, Derrik Walker v2.0 wrote:
> > On Wed, 2014-12-31 at 09:37 -0600, Milo Velimirovic wrote:
> > > It appears to be available here
> > > http://ftp.sunet.se/pub/usenet/ftp.uu.net/comp.sources.misc/volume4/
> > >
> > > On Dec 31, 2014, at 9:31 AM, arnold at skeeve.com wrote:
> > >
> > > >> Does the infamous (X11 or was it Sunview) 'crumble' still exist in
> source
> > > >> code form?  I know many "sysadmins" still deserving of it.
> > > >
> > > > It appears to have been posted in comp.sources.misc/volume4 if you
> can
> > > > find that. :-)
> > > >
> >
> > I just happen to have all these usenet posts archived on my local
> > system.  I found the program in question, and it appears to require a
> > Sun box, and judging by the date, a Sun 3 or early Sparc running Sun OS
> > 4.
> >
> > Since my Linux box doesn't have the 'suntools' headers, I wont even try
> > to compile it.
> >
> > Now, if only I still had that IPX I use to have :-/
>
>
> http://www.ebay.com/itm/Sun-SPARCstation-LX-/201238223990?pt=LH_DefaultDomain_0&hash=item2edabb9c76
>
> Not an IPX but it will sun sunos 4.x if I recall correctly.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/24121c3e/attachment.html>

From jacob.ritorto at gmail.com  Thu Jan  1 08:30:16 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 31 Dec 2014 17:30:16 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <CAC20D2M12JbShwso_zPt5jit22DevxxGr8sRecRgsXsVm1hFwg@mail.gmail.com>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>
 <25524.1420058716@cesium.clock.org>
 <CAC20D2M12JbShwso_zPt5jit22DevxxGr8sRecRgsXsVm1hFwg@mail.gmail.com>
Message-ID: <CAHYQbfDOZwzcwCesrBk=OjMbstVnkr39CJm-80wM=Bq4JRQpWA@mail.gmail.com>

I'm actually running an old CIT-101 from c.itoh.  The pdp11 is currently
just simh on a raspberry pi, but I have a lot of pdp11 hardware in various
states of disrepair.  my 11/73 ran 2.11bsd nicely has a burned out power
supply and I haven't been able to fix it.

I checked out the curses man page in 2.11 and tried to use curses clear,
but it really does tack on a lot of overhead & slows things down.  So I'm
now tempted to just cheat, keep it simple, find a simple escape string that
works on real vt100s as well as xterms, etc. and just printf it.


On Wed, Dec 31, 2014 at 4:05 PM, Clem Cole <clemc at ccc.com> wrote:

> Ah - that makes sense,  and since VT-100 are not fully ANSI, that's likely
> why it's not listed in my circa 1976 VT-100 programmers manual and probably
> why it does not work for Jacob. ;-)
>
> Clem
>
> On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair <fair-tuhs at netbsd.org>
> wrote:
>
>> The sequence ESC-c is ANSI X3.64 for "reset to initial state" which
>> happens to clear the screen, among other things. I still use it
>> frequently to reset Mac OS X "Terminal" windows to a sane state,
>> manually entered.
>>
>>         Erik <fair at netbsd.org>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/bc5908bb/attachment.html>

From lm at mcvoy.com  Thu Jan  1 08:42:49 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 31 Dec 2014 14:42:49 -0800
Subject: [TUHS] Illumos )
In-Reply-To: <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
Message-ID: <20141231224249.GA5833@mcvoy.com>

On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote:
> Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
> Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?

Over and over and over again.  You have no idea.

>   Anyway, a friend I admire quite a lot took the time to put some of this
> Sun history and Illumos fork stuff into a talk at LISA a few years back and
> I think he did a really nice job.  Have a look if you like:
> www.youtube.com/watch?v=-zRN7XLCRhc

Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley
and have spent a fair amount of time discussing OS stuff.  Here's 
Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz 
mountains:

http://www.mcvoy.com/lm/photos/2007/05/257.html

and Bill and Linus talking file systems at the same party:

http://www.mcvoy.com/lm/photos/2007/05/255.html

The best shot was the next morning when the women were gathered around
Linus asking him how he lost weight:

http://www.mcvoy.com/lm/photos/2007/05/276.html

His answer?  "Eat less."  "Did you stop drinking?"  Hell no, I like my beer!"

Fun times.  

I don't agree that Linux is as bad as you have described,
Linus has pretty reasonable taste.

Solaris may be sorted but /proc in Linux is oh-so-much-more-useful.

My view is Linux is pragmatic about stuff, Solaris was dogmatic about it.
Yeah, the latter leads to better thought out stuff but the former tends
to be useful sooner.

--lm


From lm at mcvoy.com  Thu Jan  1 08:50:35 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 31 Dec 2014 14:50:35 -0800
Subject: [TUHS] Illumos )
In-Reply-To: <20141231224249.GA5833@mcvoy.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
Message-ID: <20141231225035.GB5833@mcvoy.com>

On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote:
> On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote:
> > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
> > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?
> 
> Over and over and over again.  You have no idea.
> 
> >   Anyway, a friend I admire quite a lot took the time to put some of this
> > Sun history and Illumos fork stuff into a talk at LISA a few years back and
> > I think he did a really nice job.  Have a look if you like:
> > www.youtube.com/watch?v=-zRN7XLCRhc
> 
> Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley
> and have spent a fair amount of time discussing OS stuff.  Here's 
> Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz 
> mountains:
> 
> http://www.mcvoy.com/lm/photos/2007/05/257.html

Sorry, I should assume people know who is who, that's Bryan on the left,
Jeff is making like a chicken, Bill on the right.

Jeff and Bill were the main ZFS guys (I hired Jeff at Sun, he was one of
my students at Stanford; Bill worked for me on BitKeeper and went on to
do ZFS and then a storage startup that EMC bought for a bazillion dollars,
Bill now lives on the largest lot in Los Altos :)

Smart guys, it was fun listening to that crowd chat.


From aek at bitsavers.org  Thu Jan  1 09:00:52 2015
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 31 Dec 2014 15:00:52 -0800
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <alpine.GSO.2.03.1412210057280.627@gewt.net>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
Message-ID: <54A48024.8020800@bitsavers.org>

On 12/20/14 10:01 PM, Cory Smelosky wrote:
> Evening all,
>
> Am I correct in my guess that 4.4BSD was built cross on an HP300? I have never found a binary dist of anything other than HP300 4.4...and my attempts to build 4.4 on ULTRIX/SunOS have so far not
> succeeded...it had to have been built SOMEHOW.
>

Wasn't all the 9000/300 work done at the University of Utah?
They had a pile of machines there running it, and it was self-hosting there.

Or was that just 4.3?





From mah at mhorton.net  Thu Jan  1 09:06:14 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Wed, 31 Dec 2014 15:06:14 -0800
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <CAHYQbfDOZwzcwCesrBk=OjMbstVnkr39CJm-80wM=Bq4JRQpWA@mail.gmail.com>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>
 <25524.1420058716@cesium.clock.org>
 <CAC20D2M12JbShwso_zPt5jit22DevxxGr8sRecRgsXsVm1hFwg@mail.gmail.com>
 <CAHYQbfDOZwzcwCesrBk=OjMbstVnkr39CJm-80wM=Bq4JRQpWA@mail.gmail.com>
Message-ID: <54A48166.9060007@mhorton.net>

Jacob,

Are you just clearing the screen in an otherwise scroll-oriented 
program, or are you doing graphics by clearing and repainting a similar 
screen when something changes?

The termcap "cl" method is perfect for the former, but curses is better 
suited for the latter.

     Mary Ann

On 12/31/2014 02:30 PM, Jacob Ritorto wrote:
> I'm actually running an old CIT-101 from c.itoh.  The pdp11 is 
> currently just simh on a raspberry pi, but I have a lot of pdp11 
> hardware in various states of disrepair.  my 11/73 ran 2.11bsd nicely 
> has a burned out power supply and I haven't been able to fix it.
>
> I checked out the curses man page in 2.11 and tried to use curses 
> clear, but it really does tack on a lot of overhead & slows things 
> down.  So I'm now tempted to just cheat, keep it simple, find a simple 
> escape string that works on real vt100s as well as xterms, etc. and 
> just printf it.
>
>
> On Wed, Dec 31, 2014 at 4:05 PM, Clem Cole <clemc at ccc.com 
> <mailto:clemc at ccc.com>> wrote:
>
>     Ah - that makes sense,  and since VT-100 are not fully ANSI,
>     that's likely why it's not listed in my circa 1976 VT-100
>     programmers manual and probably why it does not work for Jacob. ;-)
>
>     Clem
>
>     On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair
>     <fair-tuhs at netbsd.org <mailto:fair-tuhs at netbsd.org>> wrote:
>
>         The sequence ESC-c is ANSI X3.64 for "reset to initial state"
>         which
>         happens to clear the screen, among other things. I still use it
>         frequently to reset Mac OS X "Terminal" windows to a sane state,
>         manually entered.
>
>                 Erik <fair at netbsd.org <mailto:fair at netbsd.org>>
>
>
>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/ad3df8cf/attachment.html>

From b4 at gewt.net  Thu Jan  1 09:09:10 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Wed, 31 Dec 2014 18:09:10 -0500 (EST)
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <54A48024.8020800@bitsavers.org>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org>
Message-ID: <alpine.GSO.2.03.1412311807120.627@gewt.net>

On Wed, 31 Dec 2014, Al Kossow wrote:

>
> Wasn't all the 9000/300 work done at the University of Utah?
> They had a pile of machines there running it, and it was self-hosting there.
>

I don't know about all...but some certainly was.

> Or was that just 4.3?

Bostic's nameserver seems to have run 4.4 at one point...at least one of 
them anyway.

Some method for compiling it for non-HP300 had to exist somehow.

>
>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From jacob.ritorto at gmail.com  Thu Jan  1 09:11:28 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 31 Dec 2014 18:11:28 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A48166.9060007@mhorton.net>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>
 <25524.1420058716@cesium.clock.org>
 <CAC20D2M12JbShwso_zPt5jit22DevxxGr8sRecRgsXsVm1hFwg@mail.gmail.com>
 <CAHYQbfDOZwzcwCesrBk=OjMbstVnkr39CJm-80wM=Bq4JRQpWA@mail.gmail.com>
 <54A48166.9060007@mhorton.net>
Message-ID: <CAHYQbfACyyXW=txMSKthNeranYex4Rc+oWi9oyW7V1MbDpUWWw@mail.gmail.com>

Well, it's just me teaching my kid recursion in c, so it's kind of informal
and I'm just clearing the screen to repaint it a second later with
changes.  It's too bad that curses adds so much overhead.  I'll have to
compare the resultant a.outs to confirm exactly how much..  Not that it
matters for a play program, really, more of a curiosity..

Thanks again Mary Ann!

On Wed, Dec 31, 2014 at 6:06 PM, Mary Ann Horton <mah at mhorton.net> wrote:

>  Jacob,
>
> Are you just clearing the screen in an otherwise scroll-oriented program,
> or are you doing graphics by clearing and repainting a similar screen when
> something changes?
>
> The termcap "cl" method is perfect for the former, but curses is better
> suited for the latter.
>
>     Mary Ann
>
>
> On 12/31/2014 02:30 PM, Jacob Ritorto wrote:
>
>  I'm actually running an old CIT-101 from c.itoh.  The pdp11 is currently
> just simh on a raspberry pi, but I have a lot of pdp11 hardware in various
> states of disrepair.  my 11/73 ran 2.11bsd nicely has a burned out power
> supply and I haven't been able to fix it.
>
>  I checked out the curses man page in 2.11 and tried to use curses clear,
> but it really does tack on a lot of overhead & slows things down.  So I'm
> now tempted to just cheat, keep it simple, find a simple escape string that
> works on real vt100s as well as xterms, etc. and just printf it.
>
>
> On Wed, Dec 31, 2014 at 4:05 PM, Clem Cole <clemc at ccc.com> wrote:
>
>>  Ah - that makes sense,  and since VT-100 are not fully ANSI, that's
>> likely why it's not listed in my circa 1976 VT-100 programmers manual and
>> probably why it does not work for Jacob. ;-)
>>
>>  Clem
>>
>> On Wed, Dec 31, 2014 at 3:45 PM, Erik E. Fair <fair-tuhs at netbsd.org>
>> wrote:
>>
>>> The sequence ESC-c is ANSI X3.64 for "reset to initial state" which
>>> happens to clear the screen, among other things. I still use it
>>> frequently to reset Mac OS X "Terminal" windows to a sane state,
>>> manually entered.
>>>
>>>         Erik <fair at netbsd.org>
>>>
>>
>>
>
>
> _______________________________________________
> TUHS mailing listTUHS at minnie.tuhs.orghttps://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20141231/5b30924e/attachment.html>

From aek at bitsavers.org  Thu Jan  1 09:29:55 2015
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 31 Dec 2014 15:29:55 -0800
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <alpine.GSO.2.03.1412311807120.627@gewt.net>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org> <alpine.GSO.2.03.1412311807120.627@gewt.net>
Message-ID: <54A486F3.4090403@bitsavers.org>

On 12/31/14 3:09 PM, Cory Smelosky wrote:

> Bostic's nameserver seems to have run 4.4 at one point...at least one of them anyway.
>

Sorry, misunderstood the question. By the time of 4.4, weren't the distributions coming out
of Mt Xinu and BSDI? I was just looking at press releases from around that time trying to
track down BSD with NFS for VAX for someone and that seemed to be what was going on.

The 4.4 release from Utah I was thinking of was
http://www.flux.utah.edu/~mike/hpbsd/hpbsd.html






From b4 at gewt.net  Thu Jan  1 09:52:33 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Wed, 31 Dec 2014 18:52:33 -0500 (EST)
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <54A486F3.4090403@bitsavers.org>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org> <alpine.GSO.2.03.1412311807120.627@gewt.net>
 <54A486F3.4090403@bitsavers.org>
Message-ID: <alpine.GSO.2.03.1412311850400.627@gewt.net>

On Wed, 31 Dec 2014, Al Kossow wrote:

>
> Sorry, misunderstood the question. By the time of 4.4, weren't the 
> distributions coming out
> of Mt Xinu and BSDI? I was just looking at press releases from around that 
> time trying to
> track down BSD with NFS for VAX for someone and that seemed to be what was 
> going on.
>

4.4's documentation from the CSRG hinted at the existence of SPARC and 
MIPS disributions...and mentions them being different from the Utah stuff.

NFS for BSD on VAX would be 4.3BSD-UWisc+NFS or later.

> The 4.4 release from Utah I was thinking of was
> http://www.flux.utah.edu/~mike/hpbsd/hpbsd.html
>

HPBSD 1.x was 4.3, 2.x was part 4.4 part 4.3, IIRC...according to CSRG 
installation guides.

>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From bqt at update.uu.se  Thu Jan  1 09:52:42 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 01 Jan 2015 00:52:42 +0100
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
Message-ID: <54A48C4A.90307@update.uu.se>

On 2014-12-31 21:14, Clem Cole<clemc at ccc.com> wrote:
>
> Jake - you have lots of help from others and using curses(3) is definitely
> the right way to program.
>
> But to answer your specific question about printf(string), according to
> Chapter 3 (Programmer's Info) of my old VT-100 user's guide, I think what
> is you are doing wrong is that "\033c" is not the ANSI clear to end of
> screen command.

Right...

> When I saw your message on my iPhone last night, the cache said - wait that
> can't be correct.   But I could not remember why.   So I had to wait until
> I got back home today to look in my basement.
>
> As I suspected, it's not an ANSI sequence.  So are you running in VT-100
> (ANSI) mode or VT52 mode?  I ask because it is close to the VT52 cursor
> right command which is actually:  "\033C"  but I do not remember is case
> mattered.

Case do matter.

> In VT52 mode you need to send the terminal:  "\033H\033J" to clear the
> screen.
>
> In ANSI mode, it becomes:  "\033[1;1\033[0J"

Shorter form: "\033[H\033[J"

> A few things to remember:
> 1.) Clear takes the current cursor position and clears from there to end of
> X (where X depends on mode, and type of clear).  So you need to move the
> cursor to home position (aka 1,1).

Not really. It's way more advanced than that.

If we start with the generic clear screen, it is CSI Pn J

Where CSI can be expressed as ESC [ (or "\033[" in the same parlance as 
above.)

Pn, then is an argument to the function, while J is the actual function 
(clear screen in this case).

Now, Pn can cause many things:

0	Clear from cursor to end of screen
1	Clear from cursor to end of screen
2	Clear from beginning of screen to cursor
3	Clear whole screen

If no argument is given, the default is 0.

> 2.) VT-100's did not implement the full ANSI spec like Ann Arbor, Heathkit,
> Wyse etc.  So there are a number of things that those terminals did
> better.  A really good reason to you curses(3) because all the knowledge is
> keep in the termcap and as a programmer you don't need to worry about it.

Probably true. However, I'm not sure Ann Arbor or Heathkit did much 
better. As far as I can remember, they were always more "weird", but I 
might just be confused. However, curses(3) is definitely a good way of 
not having to care about different terminal oddities.

> 3.) I saw sites were VT52 mode was sometimes preferred because it was good
> enough for most editing, and needed fewer chars to do manipulation.  On
> slow serial lines, this sometimes was helpful.  That said, give me an AAA
> any day.  Like others, I still miss that terminal.:-)

Yeah, the VT52 was simpler, and had shorter control strings. But of 
course, with the additional limitations that came with that.

Personally, I'd give an AAA or a Heathkit away if one was dropped on me. 
A VT100 I would keep. :-)

	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 lm at mcvoy.com  Thu Jan  1 11:17:16 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 31 Dec 2014 17:17:16 -0800
Subject: [TUHS] Illumos )
In-Reply-To: <20141231225035.GB5833@mcvoy.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com> <20141231225035.GB5833@mcvoy.com>
Message-ID: <20150101011716.GC9254@mcvoy.com>

On Wed, Dec 31, 2014 at 02:50:35PM -0800, Larry McVoy wrote:
> On Wed, Dec 31, 2014 at 02:42:49PM -0800, Larry McVoy wrote:
> > On Wed, Dec 31, 2014 at 05:19:15PM -0500, Jacob Ritorto wrote:
> > > Wow, Larry, were you one of the guys in Sun who actually lobbied to abandon
> > > Solaris 2 and resurrect SunOS 4.x when Solaris 2.3 flopped?
> > 
> > Over and over and over again.  You have no idea.
> > 
> > >   Anyway, a friend I admire quite a lot took the time to put some of this
> > > Sun history and Illumos fork stuff into a talk at LISA a few years back and
> > > I think he did a really nice job.  Have a look if you like:
> > > www.youtube.com/watch?v=-zRN7XLCRhc
> > 
> > Yeah, I know Bryan pretty well, we used to be neighbors in Noe Valley
> > and have spent a fair amount of time discussing OS stuff.  Here's 
> > Bryan, Jeff Bonwick, and Bill Moore at my place in the Santa Cruz 
> > mountains:
> > 
> > http://www.mcvoy.com/lm/photos/2007/05/257.html
> 
> Sorry, I should assume people know who is who, that's Bryan on the left,

s/should/shouldn't/

Sigh.  I swear I wasn't drinking, just a brain fart.

> Jeff is making like a chicken, Bill on the right.
> 
> Jeff and Bill were the main ZFS guys (I hired Jeff at Sun, he was one of
> my students at Stanford; Bill worked for me on BitKeeper and went on to
> do ZFS and then a storage startup that EMC bought for a bazillion dollars,
> Bill now lives on the largest lot in Los Altos :)
> 
> Smart guys, it was fun listening to that crowd chat.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From fair-tuhs at netbsd.org  Thu Jan  1 11:29:54 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 31 Dec 2014 17:29:54 -0800
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A48C4A.90307@update.uu.se>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
Message-ID: <13336.1420075794@cesium.clock.org>

All those terminal quirks made writing termcap entries challenging
(I wrote a few), and made the comments in the termcap file interesting
reading for the frustration and cursing of terminal firmware authors.
All kinds of history of the evolution of terminals is captured therein.

The removal of the ability to read the source is - IMHO - what
greatly impeded adoption of the AT&T "termlib" replacement for
termcap: they stopped distributing the terminal database source
(they distributed just the binary "compiled" versions), and made it
harder to write new entries.

	Erik <fair at netbsd.org>


From fair-tuhs at netbsd.org  Thu Jan  1 11:34:09 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Wed, 31 Dec 2014 17:34:09 -0800
Subject: [TUHS] Illumos )
In-Reply-To: <20150101011716.GC9254@mcvoy.com>
References: <20141231225035.GB5833@mcvoy.com>
Message-ID: <29950.1420076049@cesium.clock.org>

> Date: Wed, 31 Dec 2014 17:17:16 -0800
> From: Larry McVoy <lm at mcvoy.com>

> Sigh.  I swear I wasn't drinking, just a brain fart.

Tonight's the night for drinking - wash away 2014 in a bath of your
favored libation!

	Happy New Year from blustery Lake Tahoe,

	Erik <fair at netbsd.org>


From reed at reedmedia.net  Thu Jan  1 10:59:34 2015
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Wed, 31 Dec 2014 18:59:34 -0600 (CST)
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <alpine.GSO.2.03.1412311850400.627@gewt.net>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org> <alpine.GSO.2.03.1412311807120.627@gewt.net>
 <54A486F3.4090403@bitsavers.org> <alpine.GSO.2.03.1412311850400.627@gewt.net>
Message-ID: <alpine.NEB.2.02.1412311852260.2334@t1.m.reedmedia.net>

On Wed, 31 Dec 2014, Cory Smelosky wrote:

> NFS for BSD on VAX would be 4.3BSD-UWisc+NFS or later.

The UWisc+NFS is Sun's NFS (with Sun's permission via academic use 
license).  The HPBSD also included the Sun NFS implementation via 
Lebeck's Univ. of Wisconsin 4.3BSD fork.

NFS for BSD was a clean implementation done by Rick Macklem which was 
contributed to CSRG.

(I have several pages about this in my book in progress.)


From arnold at skeeve.com  Thu Jan  1 13:37:45 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 31 Dec 2014 20:37:45 -0700
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <54A486F3.4090403@bitsavers.org>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org>
 <alpine.GSO.2.03.1412311807120.627@gewt.net>
 <54A486F3.4090403@bitsavers.org>
Message-ID: <201501010337.t013bjSM012715@freefriends.org>

Al  Kossow <aek at bitsavers.org> wrote:

> Sorry, misunderstood the question. By the time of 4.4, weren't the
> distributions coming out of Mt Xinu and BSDI? I was just looking at
> press releases from around that time trying to track down BSD with NFS
> for VAX for someone and that seemed to be what was going on.

Mt. Xinu did 4.3 + Sun NFS for the vax. It required owning Unix
licenses before being able to get it from them. I ran it on vaxen
at Emory University in the mid-80s. Initialy it was 4.2 + NFS and
then a few months after 4.3 came out it was 4.3 + NFS. We saw a huge
performance gain in moving to 4.3; I'm convinced we'd have had to
buy another vax if we hadn't switched to 4.3.

That was a good company to work with. Nice folks, very responsive,
and they knew what they were doing.

UCB did the 4.4 distributions - both 4.4 and 4.4-lite. The latter
had all the AT&T code removed but wasn't fully bootable.

BSDI came along later and did Unix for the '386; their ads started
the whole lawsuit stuff. :-(  (Let's not rehash that, please!)

Arnold


From aek at bitsavers.org  Thu Jan  1 15:58:56 2015
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 31 Dec 2014 21:58:56 -0800
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <201501010337.t013bjSM012715@freefriends.org>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org> <alpine.GSO.2.03.1412311807120.627@gewt.net>
 <54A486F3.4090403@bitsavers.org>
 <201501010337.t013bjSM012715@freefriends.org>
Message-ID: <54A4E220.9040502@bitsavers.org>

On 12/31/14 7:37 PM, arnold at skeeve.com wrote:

> BSDI came along later and did Unix for the '386; their ads started
> the whole lawsuit stuff. :-(  (Let's not rehash that, please!)
>

well, here is a history

http://www.softpanorama.org/People/Torvalds/Finland_period/att_lawsuit_as_a_launcher_for_linux.shtml

with this in it:

Trent[ Hein] was a student at the University of Colorado, where he was a co-author of both the UNIX and the Linux system administration handbooks. He worked on the 4.4BSD port to the MIPS architecture.





From b4 at gewt.net  Thu Jan  1 16:04:43 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Thu, 1 Jan 2015 01:04:43 -0500 (EST)
Subject: [TUHS] HP300/4.4BSD stuff
In-Reply-To: <54A4E220.9040502@bitsavers.org>
References: <alpine.GSO.2.03.1412210057280.627@gewt.net>
 <54A48024.8020800@bitsavers.org> <alpine.GSO.2.03.1412311807120.627@gewt.net>
 <54A486F3.4090403@bitsavers.org>
 <201501010337.t013bjSM012715@freefriends.org>
 <54A4E220.9040502@bitsavers.org>
Message-ID: <alpine.GSO.2.03.1501010103240.627@gewt.net>

On Wed, 31 Dec 2014, Al Kossow wrote:

> On 12/31/14 7:37 PM, arnold at skeeve.com wrote:
>
>> BSDI came along later and did Unix for the '386; their ads started
>> the whole lawsuit stuff. :-(  (Let's not rehash that, please!)
>> 
>
> well, here is a history
>
> http://www.softpanorama.org/People/Torvalds/Finland_period/att_lawsuit_as_a_launcher_for_linux.shtml
>
> with this in it:
>
> Trent[ Hein] was a student at the University of Colorado, where he was a 
> co-author of both the UNIX and the Linux system administration handbooks. He 
> worked on the 4.4BSD port to the MIPS architecture.
>

I have the first edition of the UNIX book series!

>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From ron at ronnatalie.com  Thu Jan  1 21:44:18 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Thu, 1 Jan 2015 06:44:18 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
Message-ID: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>

A prosperous New Years to all us old UNIX farts.

Years ago the USENIX conference was in Atlanta.    It was a stark contrast between us and the Southern Baptists who were in town for their conference as well (punctuated at some goofball Baptist standing up in the middle of one of the restaurants to sing God Bless America or some such).

Anyhow, right before the conference someone (I think it was Dennis) made some comment about nobody ever having asked him for a cast of his genitals.   A couple of friends decided we needed to issue genital casting kits to certain of the UNIX notables.    I went out to an art supply store and bought plaster, paper cups, popsicle sticks to mix with, etc…   Gould computers let me use one of their booth machines and a printer to print out the instructions.   I purloined some bags from the hotel.   It was pointed out that you need vaseline in order for the plaster to not stick to the skin.    Great, I head into the hotel gift shop and grab ten tiny jars of vaseline.   As I plop these on the counter at the cashier, she looks at me for a minute and then announces…

I guess y’all aren’t with the baptists.

People took it pretty tongue in cheek when they were presented.    All except Redman who flew off the handle. 

From clemc at ccc.com  Fri Jan  2 00:30:45 2015
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Jan 2015 09:30:45 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
Message-ID: <CAC20D2N=ncp1K2yMJcv2=EFoHbavG3_SOWJ5ewtm0k_1GdAFJw@mail.gmail.com>

Love it.  IIRC that was the conference a number of us with BSD daemon
t-shirts were accosted for the wearing them.

A story I like to tell was in the early 1980s at the Toronto USENIX.  This
was just as when the US was going through AIDS reaction similar to the
current ebola over-worries.  I was wearing a "Sex, Drugs & UNIX" button
when I got on the hotel elevator with Mike Krueger when your basic midwest
family of 4 or 5 got on at the same time.   The mother sees my button and
asks, what's "UNIX." Krueger looks at her and replies:  "It's like AIDS --
only worse."

She immediately takes her kids and cowers in the corner while I'm
alternating being wanting to kick Krueger and laughing.

On Thu, Jan 1, 2015 at 6:44 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

> A prosperous New Years to all us old UNIX farts.
>
> Years ago the USENIX conference was in Atlanta.    It was a stark contrast
> between us and the Southern Baptists who were in town for their conference
> as well (punctuated at some goofball Baptist standing up in the middle of
> one of the restaurants to sing God Bless America or some such).
>
> Anyhow, right before the conference someone (I think it was Dennis) made
> some comment about nobody ever having asked him for a cast of his
> genitals.   A couple of friends decided we needed to issue genital casting
> kits to certain of the UNIX notables.    I went out to an art supply store
> and bought plaster, paper cups, popsicle sticks to mix with, etc…   Gould
> computers let me use one of their booth machines and a printer to print out
> the instructions.   I purloined some bags from the hotel.   It was pointed
> out that you need vaseline in order for the plaster to not stick to the
> skin.    Great, I head into the hotel gift shop and grab ten tiny jars of
> vaseline.   As I plop these on the counter at the cashier, she looks at me
> for a minute and then announces…
>
> I guess y’all aren’t with the baptists.
>
> People took it pretty tongue in cheek when they were presented.    All
> except Redman who flew off the handle.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150101/bceb625f/attachment.html>

From bqt at update.uu.se  Fri Jan  2 01:03:05 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 01 Jan 2015 16:03:05 +0100
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <13336.1420075794@cesium.clock.org>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <13336.1420075794@cesium.clock.org>
Message-ID: <54A561A9.6030808@update.uu.se>

On 2015-01-01 02:29, Erik E. Fair wrote:
> All those terminal quirks made writing termcap entries challenging
> (I wrote a few), and made the comments in the termcap file interesting
> reading for the frustration and cursing of terminal firmware authors.
> All kinds of history of the evolution of terminals is captured therein.
>
> The removal of the ability to read the source is - IMHO - what
> greatly impeded adoption of the AT&T "termlib" replacement for
> termcap: they stopped distributing the terminal database source
> (they distributed just the binary "compiled" versions), and made it
> harder to write new entries.

I was way to removed from the action to know, but why did people slowly 
move over to termlib? Was there really any advantages over termcap?

	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 clemc at ccc.com  Fri Jan  2 01:45:37 2015
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Jan 2015 10:45:37 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <CAHYQbfDOZwzcwCesrBk=OjMbstVnkr39CJm-80wM=Bq4JRQpWA@mail.gmail.com>
References: <CAHYQbfBF5ro-SCebomP0MOnC9ngSXmX59S6wsC=tZEcMdhzT_A@mail.gmail.com>
 <CAC20D2MfLEhHhkfrH1E8QKo1__nALTWfFBtrhEXoX60NzC05TA@mail.gmail.com>
 <25524.1420058716@cesium.clock.org>
 <CAC20D2M12JbShwso_zPt5jit22DevxxGr8sRecRgsXsVm1hFwg@mail.gmail.com>
 <CAHYQbfDOZwzcwCesrBk=OjMbstVnkr39CJm-80wM=Bq4JRQpWA@mail.gmail.com>
Message-ID: <CAC20D2PmK9zJAXEHv75DKOD-2gWJkGbR9A+C0hXonescC3_C6g@mail.gmail.com>

On Wed, Dec 31, 2014 at 5:30 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> CIT-101 from c.itoh

​I remember those, but I do not have a manual for it.
I reasonable guess is they tried to clone the VT-100 which means its ANSI
sequences but not full ANSI and lots of strangeness - Thank you to my old
friend Tom Kent who had a lot to do with the original FW and the keyboard.
In his defense, the ANSI sequences were not yet a standard when then
started that project.   So they took what they knew was going to be there,
add a ton of DEC specific stuff and the result is history.

BTW: If you even wanted to know why the original Masscomp keyboard worked
as it did, was because Tom had the "second systems effect" when he did the
MC-500  and I always tease him about it all the time - although unlike the
MC-500 you could not use the VT-100 as a weapon ;-)​

Anyway - I just looked in the original VT-100 programmer guide again and
could not find the sequence "\033c" defined in it.  So I'm >>guessing<< Tom
and team did not implement it, and thus c.itoh did not either when they
cloned it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150101/cf020c77/attachment.html>

From mah at mhorton.net  Fri Jan  2 01:59:51 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Thu, 01 Jan 2015 07:59:51 -0800
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A561A9.6030808@update.uu.se>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <13336.1420075794@cesium.clock.org> <54A561A9.6030808@update.uu.se>
Message-ID: <54A56EF7.60204@mhorton.net>

The move was from termcap to terminfo.  Termlib was the library for termcap.

There were two problems with termcap.  One was that the two-character 
name space was running out of room, and the codes were becoming less and 
less mnemonic.

But the big motivator was performance.  Reading in a termcap entry from 
/etc/termcap was terribly slow.  First you had to scan all the way 
through the (ever-growing) termcap file to find the correct entry.  Once 
you had it, every tgetstr (etc) had to scan from the beginning of the 
entry, so starting up a program like vi involved quadratic performance 
(time grew as the square of the length of the termcap entry.)  The VAX 
11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and 
was shared among dozens of timesharing users, and some of the other 
machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.  
It took forever to start up vi or more or any of the termcap-based 
programs people were using a lot.

I wrote a paper about it for Usenix in 1982, but it seems to be lost to 
Google.  Here is a nice write-up Pavel Curtis posted about it with more 
detail about the motivation:

http://www.informatica.co.cr/unix-source-code/research/1982/0711.html

     Mary Ann

On 01/01/2015 07:03 AM, Johnny Billquist wrote:
> On 2015-01-01 02:29, Erik E. Fair wrote:
>> All those terminal quirks made writing termcap entries challenging
>> (I wrote a few), and made the comments in the termcap file interesting
>> reading for the frustration and cursing of terminal firmware authors.
>> All kinds of history of the evolution of terminals is captured therein.
>>
>> The removal of the ability to read the source is - IMHO - what
>> greatly impeded adoption of the AT&T "termlib" replacement for
>> termcap: they stopped distributing the terminal database source
>> (they distributed just the binary "compiled" versions), and made it
>> harder to write new entries.
>
> I was way to removed from the action to know, but why did people 
> slowly move over to termlib? Was there really any advantages over 
> termcap?
>
>     Johnny
>



From clemc at ccc.com  Fri Jan  2 02:01:19 2015
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Jan 2015 11:01:19 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A48C4A.90307@update.uu.se>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <54A48C4A.90307@update.uu.se>
Message-ID: <CAC20D2NwdqrhPQjav8VqqxutTuTn+BQcYbuM=YP4SpCW5SBNiA@mail.gmail.com>

below ..

On Wed, Dec 31, 2014 at 6:52 PM, Johnny Billquist <bqt at update.uu.se> wrote:

>
> Case do matter.

​I thought so, but it's been years since I played with any of this.​




>
> Shorter form: "\033[H\033[J"

​right - that looks much more what I remember.



>
>  2.) VT-100's did not implement the full ANSI spec like Ann Arbor,
>> Heathkit,
>> Wyse etc.  So there are a number of things that those terminals did
>> better.  A really good reason to you curses(3) because all the knowledge
>> is
>> keep in the termcap and as a programmer you don't need to worry about it.
>>
>
> Probably true. However, I'm not sure Ann Arbor or Heathkit did much better.

​They did - but they had the advantage of complete spec, which when then
VT-100 team did their thing, was working with a proposal.​




> As far as I can remember, they were always more "weird"

​I guess.   Maybe the were not too go at running programs like EDT on VMS.
which used the DEC private sequences.  As I recall you grew up on RSX and
VMS so would not have had the same affinity that we in the UNIX side did.

VMS folks tended to stay with something that looked a lot like VT-100,
whereas UNIX folks often chose more functionality in the terminal.



>
>
> Personally, I'd give an AAA or a Heathkit away if one was dropped on me. A
> VT100 I would keep. :-)


​To each each his own.  I still have an H19 and a Wyse-60.  Would love to
find an old AAA, but I personally would not bother with any member of
VT-100 family since most SW emulators are "good enough" for my use when I
might want VT-100 specifics.​

​  I heard that some folks in the VMS world gripe about the emulators not
being good enough, but my use has never been that much and certainly there
are lots of other issues with the newer VT-xxx's that drove me bonkers.

​I've sometimes toyed with the thought of taking one of the Mac Terminal
emulators and hacking it in AAA features, but it's never been​ high on my
list. I have always had too many other worthy projects in front of it.
Truth is the programmable keyboard macros of the Tek 4025 and AAA are what
I miss in modern systems more than anything else.

Then again, if I had one, I'd probably hate the keyboard layout these days.
Once the ANSI/ECMA keyboard layout came out, I forced myself to key used to
it and actually now prefer it.   But that took years to reprogram the ROMS
in my fingers. ;-)

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150101/5c6fc9d3/attachment.html>

From bqt at update.uu.se  Fri Jan  2 02:11:06 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 01 Jan 2015 17:11:06 +0100
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <CAC20D2NwdqrhPQjav8VqqxutTuTn+BQcYbuM=YP4SpCW5SBNiA@mail.gmail.com>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <54A48C4A.90307@update.uu.se>
 <CAC20D2NwdqrhPQjav8VqqxutTuTn+BQcYbuM=YP4SpCW5SBNiA@mail.gmail.com>
Message-ID: <54A5719A.9000606@update.uu.se>

On 2015-01-01 17:01, Clem Cole wrote:
> below ..
>
> On Wed, Dec 31, 2014 at 6:52 PM, Johnny Billquist <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>
>         2.) VT-100's did not implement the full ANSI spec like Ann
>         Arbor, Heathkit,
>         Wyse etc.  So there are a number of things that those terminals did
>         better.  A really good reason to you curses(3) because all the
>         knowledge is
>         keep in the termcap and as a programmer you don't need to worry
>         about it.
>
>
>     Probably true. However, I'm not sure Ann Arbor or Heathkit did much
>     better.
>
> ​They did - but they had the advantage of complete spec, which when then
> VT-100 team did their thing, was working with a proposal.​

True. Not sure how much changed though. Do you have any list of things 
that differs, and things that AA or Heathkit did better?

>     As far as I can remember, they were always more "weird"
>
> ​I guess.   Maybe the were not too go at running programs like EDT on
> VMS. which used the DEC private sequences.  As I recall you grew up on
> RSX and VMS so would not have had the same affinity that we in the UNIX
> side did.

True that I grew up on DEC OSes, but I never used EDT. Always Emacs. 
(Proper Emacs, that is, not the GNU stuff... :-) )

> VMS folks tended to stay with something that looked a lot like VT-100,
> whereas UNIX folks often chose more functionality in the terminal.

Possible. But people in general seems to have preferred the VT100 to 
most other stuff on Unix as well, judging by history.

>     Personally, I'd give an AAA or a Heathkit away if one was dropped on
>     me. A VT100 I would keep. :-)
>
>
> ​To each each his own.  I still have an H19 and a Wyse-60.  Would love
> to find an old AAA, but I personally would not bother with any member of
> VT-100 family since most SW emulators are "good enough" for my use when
> I might want VT-100 specifics.​

Indeed. To each his own. No problem with that.
And yes, most VT-100 emulators suck seriously. I usually identifies the 
first problem within 10 seconds, and almost all emulators do some of the 
common simple stuff wrong.

xterm is my savior. It actually do things pretty might right all the time.

> ​  I heard that some folks in the VMS world gripe about the emulators
> not being good enough, but my use has never been that much and certainly
> there are lots of other issues with the newer VT-xxx's that drove me
> bonkers.

Let me guess - the missing escape key? :-)
(That one drove almost everyone bonkers...)

	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 bqt at update.uu.se  Fri Jan  2 02:21:07 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Thu, 01 Jan 2015 17:21:07 +0100
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <mailman.125.1420128672.3354.tuhs@minnie.tuhs.org>
References: <mailman.125.1420128672.3354.tuhs@minnie.tuhs.org>
Message-ID: <54A573F3.4050503@update.uu.se>

On 2015-01-01 17:11, Mary Ann Horton<mah at mhorton.net> wrote:
>
> The move was from termcap to terminfo.  Termlib was the library for termcap.

Doh! Thanks for the correction. Finger fart.

> There were two problems with termcap.  One was that the two-character
> name space was running out of room, and the codes were becoming less and
> less mnemonic.

Ah. Yes, that could definitely be a problem.

> But the big motivator was performance.  Reading in a termcap entry from
> /etc/termcap was terribly slow.  First you had to scan all the way
> through the (ever-growing) termcap file to find the correct entry.  Once
> you had it, every tgetstr (etc) had to scan from the beginning of the
> entry, so starting up a program like vi involved quadratic performance
> (time grew as the square of the length of the termcap entry.)  The VAX
> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
> was shared among dozens of timesharing users, and some of the other
> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
> It took forever to start up vi or more or any of the termcap-based
> programs people were using a lot.

Hum. That seems like it would be more of an implementation issue. Why 
wouldn't you just cache all the entries for the terminal once and for 
all? terminfo never came to 16-bit systems anyway, so we're talking 
about systems with plenty of memory. Caching the terminal information 
would not be a big memory cost.

Thanks for the insight.

	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 clemc at ccc.com  Fri Jan  2 02:59:04 2015
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Jan 2015 11:59:04 -0500
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A5719A.9000606@update.uu.se>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <54A48C4A.90307@update.uu.se>
 <CAC20D2NwdqrhPQjav8VqqxutTuTn+BQcYbuM=YP4SpCW5SBNiA@mail.gmail.com>
 <54A5719A.9000606@update.uu.se>
Message-ID: <CAC20D2PDconUu77h2L-Mww=Q9C2-AgwaA=yrHKY5B__Sn58Htg@mail.gmail.com>

below...

On Thu, Jan 1, 2015 at 11:11 AM, Johnny Billquist <bqt at update.uu.se> wrote:

>
> True. Not sure how much changed though. Do you have any list of things
> that differs, and things that AA or Heathkit did better?

​I've forgotten the specifics. MaryAnn may remember - having lived much of
the brain-damage with so many manufactures.  IIRC: Erase and line
operations was one of them.  Tom implemented the regions stuff which again,
if I remember could be dorked into doing some of the stuff that was
missing/different.   Unfortunately, they deviated it as hard to come back
to what the rest of the world did.   Plus Tom left DEC for Masscomp around
the time of 102 FW and I suspect that sort of sealed it a little.

I've lost track of him, but I heard at a party a week before Christmas that
he is still knocking around the area, so if I can dig him up, I'll try to
remember to ask him.




>
>  Always Emacs. (Proper Emacs, that is, not the GNU stuff... :-) )

​Fair enough.   FYI: I learned Emacs on the 10s before I ever saw UNIX.
Gosling would not come to CMU for another couple of years, so we used ed
and later "Fred" which was the first screen editor for UNIX I saw.  By the
time CMU and MIT Emacs made it to UNIX I was at Berkeley and vi was burned
into the roms.

​


> Possible. But people in general seems to have preferred the VT100 to most
> other stuff on Unix as well, judging by history.

​I'm not so sure.  My experience is otherwise.  There were two vectors at
the time - cheap/simple (think ADM3A and later Wyse) and smart/expensive
(think HP & Tek and later AA).  The VT-100 family fell in-between.   You
are right, it was incredibly successful and the fact is there were lots of
clones​ of the VT-100 - so you did see them on UNIX boxes sometimes.

But as Horton mentioned on the termcap/terminfo thread - there were a ton
of players in the cheap/simple side.   I think more UNIX sites tended to
play out the cheap and simple over anything else, so most sites would get a
deal on a one or another.   CMU went with PK's Fox with smattering of ADMs.
  UCB was ADMs or something very high end.  I saw most of the smart HP &
Tek terminals at the BTL sites.

My experience was that VMS/RSX, and to some extent, Twinex, shops tended to
migrate to the VT-100s or clones - probably because the native DEC SW were
well intregrated, but Unix folks either wanted cheap or as much
functionality as possible.   Curses(3) really allowed that occur.   I think
"cheap and simple" came first, but once termcap existed, it really allowed
the UNIX folks to use what ever they wanted.   But as Erik mentioned, we
all had to hack termcap entries (usually by hacking on an existing one).


> xterm is my savior. It actually do things pretty might right all the time.

​Twas for me too for a long time.   iterm2 on the Mac is that pretty much
my standard these days.

​

> Let me guess - the missing escape key? :-)
> (That one drove almost everyone bonkers...)

​Just one of many :-)  Control and Caps were in wrong place.

BTW: Tek had a layout was worse - it had the 0 next to 1 which caused me to
make a painful screw up.  I've forgotten which terminal it was, but we had
one of them as console on the Teklab 11/60 and I typo-ed and wiped out a
bunch of Fred Park's life work.​

​   Thus creating the infamous "guts in the bucket/​ball on a platter"
comment in the bugs section of the RT-PIP man page that got me in trouble a
few years later.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150101/977125c3/attachment.html>

From imp at bsdimp.com  Fri Jan  2 03:04:04 2015
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 1 Jan 2015 10:04:04 -0700
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <54A573F3.4050503@update.uu.se>
References: <mailman.125.1420128672.3354.tuhs@minnie.tuhs.org>
 <54A573F3.4050503@update.uu.se>
Message-ID: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>


> On Jan 1, 2015, at 9:21 AM, Johnny Billquist <bqt at update.uu.se> wrote:
> 
> On 2015-01-01 17:11, Mary Ann Horton<mah at mhorton.net> wrote:
>> 
>> The move was from termcap to terminfo.  Termlib was the library for termcap.
> 
> Doh! Thanks for the correction. Finger fart.
> 
>> There were two problems with termcap.  One was that the two-character
>> name space was running out of room, and the codes were becoming less and
>> less mnemonic.
> 
> Ah. Yes, that could definitely be a problem.
> 
>> But the big motivator was performance.  Reading in a termcap entry from
>> /etc/termcap was terribly slow.  First you had to scan all the way
>> through the (ever-growing) termcap file to find the correct entry.  Once
>> you had it, every tgetstr (etc) had to scan from the beginning of the
>> entry, so starting up a program like vi involved quadratic performance
>> (time grew as the square of the length of the termcap entry.)  The VAX
>> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
>> was shared among dozens of timesharing users, and some of the other
>> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
>> It took forever to start up vi or more or any of the termcap-based
>> programs people were using a lot.
> 
> Hum. That seems like it would be more of an implementation issue. Why wouldn't you just cache all the entries for the terminal once and for all? terminfo never came to 16-bit systems anyway, so we're talking about systems with plenty of memory. Caching the terminal information would not be a big memory cost.

BSD solved this problem that way: parse /etc/termcap and put all the entries into termcap.db. :)

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150101/ae4a3d87/attachment.sig>

From dave at horsfall.org  Fri Jan  2 06:11:30 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 2 Jan 2015 07:11:30 +1100 (EST)
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A561A9.6030808@update.uu.se>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <13336.1420075794@cesium.clock.org> <54A561A9.6030808@update.uu.se>
Message-ID: <alpine.BSF.2.11.1501020708550.58880@aneurin.horsfall.org>

On Thu, 1 Jan 2015, Johnny Billquist wrote:

> I was way to removed from the action to know, but why did people slowly 
> move over to termlib? Was there really any advantages over termcap?

It was a lot more flexible; attribute names could be of arbitrary length, 
whereas Termcap confined you to two characters IIRC.  You had to get a bit 
imaginative in the naming of new attributes...


-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From dave at horsfall.org  Fri Jan  2 06:18:06 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 2 Jan 2015 07:18:06 +1100 (EST)
Subject: [TUHS] I swear! I rtfm'ed
In-Reply-To: <54A56EF7.60204@mhorton.net>
References: <mailman.116.1420056874.3354.tuhs@minnie.tuhs.org>
 <13336.1420075794@cesium.clock.org> <54A561A9.6030808@update.uu.se>
 <54A56EF7.60204@mhorton.net>
Message-ID: <alpine.BSF.2.11.1501020716530.58880@aneurin.horsfall.org>

On Thu, 1 Jan 2015, Mary Ann Horton wrote:

> The move was from termcap to terminfo.  Termlib was the library for 
> termcap.

Oops - ignore my subsequent contribution (it *was* some years ago...).

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From scj at yaccman.com  Fri Jan  2 09:48:24 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Thu, 1 Jan 2015 15:48:24 -0800
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <CAC20D2N=ncp1K2yMJcv2=EFoHbavG3_SOWJ5ewtm0k_1GdAFJw@mail.gmail.com>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <CAC20D2N=ncp1K2yMJcv2=EFoHbavG3_SOWJ5ewtm0k_1GdAFJw@mail.gmail.com>
Message-ID: <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com>

Oh that brings back memories!  It seems that every Baptist read Usenix as
Unisex (Freud would have something to say about that...).  Families with
children would pass up an elevator rather than get on it with Usenix
folks...


> Love it.  IIRC that was the conference a number of us with BSD daemon
> t-shirts were accosted for the wearing them.
>
> A story I like to tell was in the early 1980s at the Toronto USENIX.  This
> was just as when the US was going through AIDS reaction similar to the
> current ebola over-worries.  I was wearing a "Sex, Drugs & UNIX" button
> when I got on the hotel elevator with Mike Krueger when your basic midwest
> family of 4 or 5 got on at the same time.   The mother sees my button and
> asks, what's "UNIX." Krueger looks at her and replies:  "It's like AIDS --
> only worse."
>
> She immediately takes her kids and cowers in the corner while I'm
> alternating being wanting to kick Krueger and laughing.
>
> On Thu, Jan 1, 2015 at 6:44 AM, Ronald Natalie <ron at ronnatalie.com> wrote:
>
>> A prosperous New Years to all us old UNIX farts.
>>
>> Years ago the USENIX conference was in Atlanta.    It was a stark
>> contrast
>> between us and the Southern Baptists who were in town for their
>> conference
>> as well (punctuated at some goofball Baptist standing up in the middle
>> of
>> one of the restaurants to sing God Bless America or some such).
>>
>> Anyhow, right before the conference someone (I think it was Dennis) made
>> some comment about nobody ever having asked him for a cast of his
>> genitals.   A couple of friends decided we needed to issue genital
>> casting
>> kits to certain of the UNIX notables.    I went out to an art supply
>> store
>> and bought plaster, paper cups, popsicle sticks to mix with, etcâ¦
>> Gould
>> computers let me use one of their booth machines and a printer to print
>> out
>> the instructions.   I purloined some bags from the hotel.   It was
>> pointed
>> out that you need vaseline in order for the plaster to not stick to the
>> skin.    Great, I head into the hotel gift shop and grab ten tiny jars
>> of
>> vaseline.   As I plop these on the counter at the cashier, she looks at
>> me
>> for a minute and then announcesâ¦
>>
>> I guess yâall arenât with the baptists.
>>
>> People took it pretty tongue in cheek when they were presented.    All
>> except Redman who flew off the handle.
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>




From wes.parish at paradise.net.nz  Fri Jan  2 10:46:12 2015
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Fri, 02 Jan 2015 13:46:12 +1300 (NZDT)
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <CAC20D2N=ncp1K2yMJcv2=EFoHbavG3_SOWJ5ewtm0k_1GdAFJw@mail.gmail.com>
 <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com>
Message-ID: <1420159572.54a5ea545ea1f@www.paradise.net.nz>

And nobody thought to pronounce the word UNIX (EUNUCHS) to the Very Reverend Baptist-folk? :)

That would've made it even funnier!

Quoting scj at yaccman.com:

> Oh that brings back memories! It seems that every Baptist read Usenix
> as
> Unisex (Freud would have something to say about that...). Families with
> children would pass up an elevator rather than get on it with Usenix
> folks...
> 
> 
> > Love it. IIRC that was the conference a number of us with BSD daemon
> > t-shirts were accosted for the wearing them.
> >
> > A story I like to tell was in the early 1980s at the Toronto USENIX.
> This
> > was just as when the US was going through AIDS reaction similar to
> the
> > current ebola over-worries. I was wearing a "Sex, Drugs & UNIX"
> button
> > when I got on the hotel elevator with Mike Krueger when your basic
> midwest
> > family of 4 or 5 got on at the same time. The mother sees my button
> and
> > asks, what's "UNIX." Krueger looks at her and replies: "It's like AIDS
> --
> > only worse."
> >
> > She immediately takes her kids and cowers in the corner while I'm
> > alternating being wanting to kick Krueger and laughing.
> >
> > On Thu, Jan 1, 2015 at 6:44 AM, Ronald Natalie <ron at ronnatalie.com>
> wrote:
> >
> >> A prosperous New Years to all us old UNIX farts.
> >>
> >> Years ago the USENIX conference was in Atlanta. It was a stark
> >> contrast
> >> between us and the Southern Baptists who were in town for their
> >> conference
> >> as well (punctuated at some goofball Baptist standing up in the
> middle
> >> of
> >> one of the restaurants to sing God Bless America or some such).
> >>
> >> Anyhow, right before the conference someone (I think it was Dennis)
> made
> >> some comment about nobody ever having asked him for a cast of his
> >> genitals. A couple of friends decided we needed to issue genital
> >> casting
> >> kits to certain of the UNIX notables. I went out to an art supply
> >> store
> >> and bought plaster, paper cups, popsicle sticks to mix with, etcâ¦
> >> Gould
> >> computers let me use one of their booth machines and a printer to
> print
> >> out
> >> the instructions. I purloined some bags from the hotel. It was
> >> pointed
> >> out that you need vaseline in order for the plaster to not stick to
> the
> >> skin. Great, I head into the hotel gift shop and grab ten tiny jars
> >> of
> >> vaseline. As I plop these on the counter at the cashier, she looks
> at
> >> me
> >> for a minute and then announcesâ¦
> >>
> >> I guess yâall arenât with the baptists.
> >>
> >> People took it pretty tongue in cheek when they were presented. All
> >> except Redman who flew off the handle.
> >> _______________________________________________
> >> TUHS mailing list
> >> TUHS at minnie.tuhs.org
> >> https://minnie.tuhs.org/mailman/listinfo/tuhs
> >>
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> >
> 
> 
> __________________ _____________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuh s
>  



From lyndon at orthanc.ca  Fri Jan  2 11:53:21 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Thu, 1 Jan 2015 17:53:21 -0800
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <1420159572.54a5ea545ea1f@www.paradise.net.nz>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <CAC20D2N=ncp1K2yMJcv2=EFoHbavG3_SOWJ5ewtm0k_1GdAFJw@mail.gmail.com>
 <5a94ba4be13b879314b92467eb129cfc.squirrel@webmail.yaccman.com>
 <1420159572.54a5ea545ea1f@www.paradise.net.nz>
Message-ID: <1426610E-0D07-42DD-AF66-6F1708FFEF88@orthanc.ca>


On Jan 1, 2015, at 4:46 PM, Wesley Parish <wes.parish at paradise.net.nz> wrote:

> And nobody thought to pronounce the word UNIX (EUNUCHS) to the Very Reverend Baptist-folk? :)

"Are you the police?"

"No ma'am, we're UNIX."



From mah at mhorton.net  Fri Jan  2 11:50:25 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Thu, 01 Jan 2015 17:50:25 -0800
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
References: <mailman.125.1420128672.3354.tuhs@minnie.tuhs.org>
 <54A573F3.4050503@update.uu.se>
 <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
Message-ID: <20150101175025.18876dpnq938daap@webmail.mhorton.net>

Quoting Warner Losh <imp at bsdimp.com>:


>>
>>> But the big motivator was performance.  Reading in a termcap entry from
>>> /etc/termcap was terribly slow.  First you had to scan all the way
>>> through the (ever-growing) termcap file to find the correct entry.  Once
>>> you had it, every tgetstr (etc) had to scan from the beginning of the
>>> entry, so starting up a program like vi involved quadratic performance
>>> (time grew as the square of the length of the termcap entry.)  The VAX
>>> 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and
>>> was shared among dozens of timesharing users, and some of the other
>>> machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower.
>>> It took forever to start up vi or more or any of the termcap-based
>>> programs people were using a lot.
>>
>> Hum. That seems like it would be more of an implementation issue.  
>> Why wouldn't you just cache all the entries for the terminal once  
>> and for all? terminfo never came to 16-bit systems anyway, so we're  
>> talking about systems with plenty of memory. Caching the terminal  
>> information would not be a big memory cost.
>
> BSD solved this problem that way: parse /etc/termcap and put all the  
> entries into termcap.db. :)

That's essentially what terminfo's binary files are: a parsed, cached  
version of the source.




From fair-tuhs at netbsd.org  Sat Jan  3 05:13:28 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Fri, 02 Jan 2015 11:13:28 -0800
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <20150101175025.18876dpnq938daap@webmail.mhorton.net>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
Message-ID: <3578.1420226008@cesium.clock.org>

"terminfo" - that was the name I was reaching for and couldn't
quite remember (and google-fu failed me)!

The other BSD answer to the "searching /etc/termcap takes too long"
problem (and I recall it being noticeable on the heavily loaded
Cory Hall PDP-11/70 when you used a terminal whose entry was farther
from the top of the termcap file) was to put the termcap entry for
your terminal into the TERMCAP environment variable at login time,
which my .login does to this day - that puts it already in RAM,
ready to go, no banging on the disk required - you only pay for
the /etc/termcap (or, excuse me, /usr/share/misc/termcap in NetBSD
5 - it seems NetBSD 6 finally moved to a BSD-ified terminfo and I
should probably update my .login ...) search once.

	Erik <fair at netbsd.org>


From dave at horsfall.org  Sat Jan  3 05:49:14 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 3 Jan 2015 06:49:14 +1100 (EST)
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
Message-ID: <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>

On Thu, 1 Jan 2015, Ronald Natalie wrote:

> I guess y’all aren’t with the baptists.

Hilarious!

The AUUG conferences seem pretty tame by comparison; one year, we used the 
menu holders as catapults (I don't know where we got the rubber bands) and 
dotted the ceiling with toothpicks (they were still there at a subsequent 
conference).  Or am I confusing that with a Caving conference?

At another (Warren will remember this one, as he was involved) we refaced 
a Pyramid poster (KNOW UNIX, THINK PYRAMID) to "NO UNIX IN PYRAMID", with 
the strategic application of napkins and some gaffer tape that we'd dug up 
from somewhere...  Gary Jackson took it well.

At an early one, when Gould first came out, we social-engineered their 
booth-marketoid into giving us root access; the buggers never did pay the 
bounty, claiming that we'd cheated.  Well, yeah...

At yet another, we had a Sun 3/50 window connected to a Convex, and acted 
all innocent when various dweebs did the old "echo 99k2vp..." etc trick.

Sigh; I miss the AUUG conferences.

> People took it pretty tongue in cheek when they were presented.  All 
> except Redman who flew off the handle.

Some people have no sense of humour.  Did anyone actually, err, avail 
themselves of this unique opportunity?

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

From sdaoden at yandex.com  Sat Jan  3 06:12:58 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Fri, 02 Jan 2015 21:12:58 +0100
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
References: <mailman.125.1420128672.3354.tuhs@minnie.tuhs.org>
 <54A573F3.4050503@update.uu.se>
 <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
Message-ID: <20150102201258.44QU13Nq%sdaoden@yandex.com>

Warner Losh <imp at bsdimp.com> wrote:
 |> On Jan 1, 2015, at 9:21 AM, Johnny Billquist <bqt at update.uu.se> wrote:
 |> On 2015-01-01 17:11, Mary Ann Horton<mah at mhorton.net> wrote:
 |>> 
 |>> The move was from termcap to terminfo.  Termlib was the \
 |>> library for termcap.

 |>> But the big motivator was performance.  Reading in a termcap entry from
 |>> /etc/termcap was terribly slow.  First you had to scan all the way

 |BSD solved this problem that way: parse /etc/termcap and put \
 |all the entries into termcap.db. :)

I like the current approach of FreeBSD: having a super-minimalized
version in /etc and a completely outdated (compared to the termcap
that Thomas Dickey maintains) stale version in /usr/share.

--steffen


From lm at mcvoy.com  Sat Jan  3 06:14:27 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 2 Jan 2015 12:14:27 -0800
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
Message-ID: <20150102201427.GD15302@mcvoy.com>

On Sat, Jan 03, 2015 at 06:49:14AM +1100, Dave Horsfall wrote:
> On Thu, 1 Jan 2015, Ronald Natalie wrote:
> 
> > I guess y???all aren???t with the baptists.
> 
> At an early one, when Gould first came out, we social-engineered their 
> booth-marketoid into giving us root access; the buggers never did pay the 
> bounty, claiming that we'd cheated.  Well, yeah...

Wasn't that Guy Harris?  He noticed root had dot in their path and wrote
an ls that dumped core if (!getuid()) and else tried to stash away a 
setuid shell only to realize that Gould had killed setuid so he had to
copy the file (/usr/lib/secure or something like that) and chmod it so
he could read it.  As I recall it said "Gould makes fire breathing 
secure systems" or similar.

The reason I remember all of this is I blasted gould on comp.unix-wizards
for not coming through with the prize, I thought that was lame in the 
extreme.

Funny ending to that story is that I actually interviewed at Gould and when
I showed up there everyone's head was sticking out of their office to see
the asshole who had the balls to show up and ask for a job.  Much to my 
surprise, after an uncomfortable day of interviews, they offered me one.
Didn't take it, went to work for Lachman instead which turned out better
for me, had a blast.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From cowan at mercury.ccil.org  Sat Jan  3 07:31:08 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 2 Jan 2015 16:31:08 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
Message-ID: <20150102213108.GF28115@mercury.ccil.org>

Dave Horsfall scripsit:

> At an early one, when Gould first came out, we social-engineered their 
> booth-marketoid into giving us root access; the buggers never did pay the 
> bounty, claiming that we'd cheated.  Well, yeah...

In a former life, my employer was looking to have its Internet connection
audited by an outside party, and brought in Bellcore.  As the insider
most concerned with such things (which was why they didn't trust me),
I sat in on the kickoff meeting.  After they detailed the list of
penetration attacks they were going to use, I raised my hand and said
"What about social engineering?"  I feel morally certain that nobody
from $EMPLOYER except me and my boss knew what that was.

The Bellcore rep did, however:  "Oh, we never do that."

"Why not?"

"It always succeeds, so it doesn't form the basis of actionable
recommendations."

> At yet another, we had a Sun 3/50 window connected to a Convex, and acted 
> all innocent when various dweebs did the old "echo 99k2vp..." etc trick.

High-precision approximation to sqrt(2).  What's the trick?

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If I read "upcoming" in [the newspaper] once more, I will be downcoming
and somebody will be outgoing.


From norman at oclsc.org  Sat Jan  3 08:36:43 2015
From: norman at oclsc.org (Norman Wilson)
Date: Fri,  2 Jan 2015 17:36:43 -0500 (EST)
Subject: [TUHS] Happy New Year and an amusing story from the past
Message-ID: <20150102223643.A89FA1DE415@lignose.oclsc.org>

Dave Horsfall:

> At yet another, we had a Sun 3/50 window connected to a Convex, and acted 
> all innocent when various dweebs did the old "echo 99k2vp..." etc trick.

John Cowan:

  High-precision approximation to sqrt(2).  What's the trick?

======

Not really a trick, just a hoary old zero-order CPU benchmark:

	echo 99k2vp | time dc

You can see why letting people type that on a Convex thinking it was
a Sun 3/50 might have entertainment value.

Modern systems are far too fast for that to be worth while, though.
I still use a variant of it: a shell script called dc-N, containing

dc <<!
99k[2vszla1-dsa0<b]sb${1-500}salbx
!

meant to be invoked as

	time dc-N 10000

or the like.  (The internal default of 500 has long since gone
stale too, of course.)

Norman Wilson
Toronto ON


From cowan at mercury.ccil.org  Sat Jan  3 09:00:20 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Fri, 2 Jan 2015 18:00:20 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <20150102223643.A89FA1DE415@lignose.oclsc.org>
References: <20150102223643.A89FA1DE415@lignose.oclsc.org>
Message-ID: <20150102230019.GG28115@mercury.ccil.org>

Norman Wilson scripsit:

> Dave Horsfall:
> 
> > At yet another, we had a Sun 3/50 window connected to a Convex, and acted 
> > all innocent when various dweebs did the old "echo 99k2vp..." etc trick.
> 
> You can see why letting people type that on a Convex thinking it was
> a Sun 3/50 might have entertainment value.

Ah.  I interpreted what Dave said as the other way around: you walked
up to the Convex but were teleported to the Sun, and ended up thinking
"Ghu, this Convex is slow".

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Half the lies they tell about me are true.
        --Tallulah Bankhead, American actress


From gregg.drwho8 at gmail.com  Sat Jan  3 09:59:58 2015
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Fri, 2 Jan 2015 18:59:58 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
Message-ID: <CAC5iaNEhggXkQ3btTUAA+SGRWYERrysWZVjEdRt-DCSJtg0cew@mail.gmail.com>

Hello!
Dave can you explain how all of you managed to connect a Sun 3/50
window to a Convex? I can of course imagine how those dweebs did that
trick.

As for annoying marketing droids, I did that myself back when the
original RS/6000 came out. Interesting contraption and I never did
appreciate what it grew up into.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Fri, Jan 2, 2015 at 2:49 PM, Dave Horsfall <dave at horsfall.org> wrote:
> On Thu, 1 Jan 2015, Ronald Natalie wrote:
>
>> I guess y’all aren’t with the baptists.
>
> Hilarious!
>
> The AUUG conferences seem pretty tame by comparison; one year, we used the
> menu holders as catapults (I don't know where we got the rubber bands) and
> dotted the ceiling with toothpicks (they were still there at a subsequent
> conference).  Or am I confusing that with a Caving conference?
>
> At another (Warren will remember this one, as he was involved) we refaced
> a Pyramid poster (KNOW UNIX, THINK PYRAMID) to "NO UNIX IN PYRAMID", with
> the strategic application of napkins and some gaffer tape that we'd dug up
> from somewhere...  Gary Jackson took it well.
>
> At an early one, when Gould first came out, we social-engineered their
> booth-marketoid into giving us root access; the buggers never did pay the
> bounty, claiming that we'd cheated.  Well, yeah...
>
> At yet another, we had a Sun 3/50 window connected to a Convex, and acted
> all innocent when various dweebs did the old "echo 99k2vp..." etc trick.
>
> Sigh; I miss the AUUG conferences.
>
>> People took it pretty tongue in cheek when they were presented.  All
>> except Redman who flew off the handle.
>
> Some people have no sense of humour.  Did anyone actually, err, avail
> themselves of this unique opportunity?
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>


From ron at ronnatalie.com  Sat Jan  3 10:49:17 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 2 Jan 2015 19:49:17 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <20150102201427.GD15302@mcvoy.com>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
 <20150102201427.GD15302@mcvoy.com>
Message-ID: <BA7C704C-0F43-4E63-868B-C87AB0B8DA70@ronnatalie.com>

Never had to social engineer anything.    I think we cracked the Gould booth systems using the WIZ sendmail hack.

I remember another time IBM loaned me an RS6000 but didn’t send along the root password.   I left a message wanting to know if they knew the root password or should I just break in.   It took me about 20 minutes and I called back and told them I’d solved the problem (the RS6000 had a MAINTENANCE mode on the keyswitch that booted up a maintenance program as root which displayed documentation using more, which had a shell escape….).

I remember one day showing up at an office I had been working in the pentagon and I my sponsor was on the phone and I asked if I should knock down the screen saver and he said sure go at it.   After he realized that I actually could do that he told the guy on the phone that he needed to check on how I’d done that.

My old boss (Steve Wolff later of NSFNet and Cisco fame) volunteered me for the Army Tiger Team.   Mostly they were physical security guys so I was about the only computer guy with them, but we had a lot of fun, some through breaking UNIX security and others just physical games.    I was down at White Sands Missile Range one time and had already pretty much gotten into all the systems there when someone had noticed the physical security guys wandering around and put a warning in MOTD (of course I let them know right away that they were on to them).    I heard years later that anytime a machine went down at WSMR they still blamed me.




From dds at aueb.gr  Sat Jan  3 20:29:59 2015
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sat, 03 Jan 2015 12:29:59 +0200
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <BA7C704C-0F43-4E63-868B-C87AB0B8DA70@ronnatalie.com>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
 <20150102201427.GD15302@mcvoy.com>
 <BA7C704C-0F43-4E63-868B-C87AB0B8DA70@ronnatalie.com>
Message-ID: <54A7C4A7.9060009@aueb.gr>

On 03/01/2015 02:49, Ronald Natalie wrote:
> I asked if I should knock down the screen saver and he said sure go at it.

At the university we were a few hundred undergraduates using two VAX 
780s through about 40 serial terminals.  They were running 4.3BSD.  It 
was common for students who would leave their terminal for a few minutes 
to lock(1) it, so that others wouldn't mess with their account. 
Sometimes terminals were forgotten with the lock program running, and 
then a staff member would come, type some magic characters, and exit the 
lock program.  Through shoulder surfing a student had found that magic 
sequence, and some of us were led into this secret.  What we didn't know 
at the time, was that the magic character sequence was the root password.

#ifndef lint
static char sccsid[] = "@(#)lock.c      8.1 (Berkeley) 6/6/93";
#endif /* not lint */

/*
  * Lock a terminal up until the given key is entered, until the root
  * password is entered, or the given interval times out.
  *



From ron at ronnatalie.com  Sat Jan  3 22:56:25 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 3 Jan 2015 07:56:25 -0500
Subject: [TUHS] Happy New Year and an amusing story from the past
In-Reply-To: <54A7C4A7.9060009@aueb.gr>
References: <6A488816-8384-4AA0-A9EA-0340DCDA9009@ronnatalie.com>
 <alpine.BSF.2.11.1501030635010.58880@aneurin.horsfall.org>
 <20150102201427.GD15302@mcvoy.com>
 <BA7C704C-0F43-4E63-868B-C87AB0B8DA70@ronnatalie.com>
 <54A7C4A7.9060009@aueb.gr>
Message-ID: <B863E6CA-1CFA-425A-B6D2-AD117664BE51@ronnatalie.com>

It was the old suntools lock program, which was nothing more than a full size window that covered up the screen.     You could use the hotkeys to iconify it but you had a fraction of a second before it replaced itself.     However, if you were fast you could as you kept iconifying it find a terminal  window, do a ps, and kill the screen saver.    You’d get like 2 characters typed on each iteration.

That was the time I scared all my old BRL buddies because the account they gave me was ron at hq.af.mil <mailto:ron at hq.af.mil>.      I don’t recall the root password that time, but the password on the cisco routers we were working on was “DickCheney” (this was back when he was secy of defense).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150103/d9597185/attachment.html>

From b4 at gewt.net  Sun Jan  4 18:30:14 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 4 Jan 2015 03:30:14 -0500 (EST)
Subject: [TUHS] VAX faxing?
Message-ID: <alpine.GSO.2.03.1501040328400.627@gewt.net>

Friend asked an odd question:

Were VAXen ever used to send/receive faxes large-scale?  What software was 
used and how was it configured?

Was any of this run on any of the UCB VAXen?

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From dave at horsfall.org  Mon Jan  5 03:50:40 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Jan 2015 04:50:40 +1100 (EST)
Subject: [TUHS] VAX faxing?
In-Reply-To: <alpine.GSO.2.03.1501040328400.627@gewt.net>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
Message-ID: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>

On Sun, 4 Jan 2015, Cory Smelosky wrote:

> Were VAXen ever used to send/receive faxes large-scale?  What software 
> was used and how was it configured?

I don't think fax modems were even invented then, were they?

I remember using FlexFax (then renamed to Hylafax) quite a lot, sometimes 
for nefarious purposes (it was trivial to fake the CSID)...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From clemc at ccc.com  Mon Jan  5 08:40:39 2015
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Jan 2015 17:40:39 -0500
Subject: [TUHS] VAX faxing?
In-Reply-To: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
 <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
Message-ID: <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>

Yeah - some of the modems were.  IIRC: Sam Leffler  (sam "usual email
punctuation" errno.com) did the original FlexFax SW and we had a couple
kicking around.  My memory is that the modems that could also support Fax
in those days, sucked at UUCP, so most of us did want to dedicate a phone
line to one of them.

Also the scanner interface was not very easy.   We tried to replace an HP
fax machine with SW, including a scanner and fax modem, but it was not very
satisfactory for the non-technical types.

I don't have any memory of "large-scale" use however.   What was cool was
some of the printers knew how to use PS as the format, instead of the
1860's style scanning [yes, FAX was invented for the US civil war and
originally ran over telegram lines - the current format is just a super-set
of the old mechanical scan system from those days].

On Sun, Jan 4, 2015 at 12:50 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 4 Jan 2015, Cory Smelosky wrote:
>
> > Were VAXen ever used to send/receive faxes large-scale?  What software
> > was used and how was it configured?
>
> I don't think fax modems were even invented then, were they?
>
> I remember using FlexFax (then renamed to Hylafax) quite a lot, sometimes
> for nefarious purposes (it was trivial to fake the CSID)...
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150104/d2062c21/attachment.html>

From fair-tuhs at netbsd.org  Mon Jan  5 09:15:51 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Sun, 04 Jan 2015 15:15:51 -0800
Subject: [TUHS] VAX faxing?
In-Reply-To: <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>
References: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
Message-ID: <19446.1420413351@cesium.clock.org>

It amazes and annoys me to this day how many PDFs purported to be "electronic documents" are merely pictures of paper. Not only am I missing my 2000's-era personal jetpack, I'm still waiting for my fully paperless office.

Though given the incredible state of computer security, perhaps that's a good thing.

	Erik <fair at netbsd.org>


From jacob.ritorto at gmail.com  Mon Jan  5 09:36:51 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 4 Jan 2015 18:36:51 -0500
Subject: [TUHS] VAX faxing?
In-Reply-To: <19446.1420413351@cesium.clock.org>
References: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>
 <19446.1420413351@cesium.clock.org>
Message-ID: <CAHYQbfBkNseO0tZU3JJOnGd0BP3ajewUe2qyxhqa1kQbQej5+A@mail.gmail.com>

sorry to troll, but i think we lost at least three decades to microsoft,
so, now that that's almost over we should be able to get on with things :D

On Sun, Jan 4, 2015 at 6:15 PM, Erik E. Fair <fair-tuhs at netbsd.org> wrote:

> It amazes and annoys me to this day how many PDFs purported to be
> "electronic documents" are merely pictures of paper. Not only am I missing
> my 2000's-era personal jetpack, I'm still waiting for my fully paperless
> office.
>
> Though given the incredible state of computer security, perhaps that's a
> good thing.
>
>         Erik <fair at netbsd.org>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150104/9f016363/attachment.html>

From lyndon at orthanc.ca  Mon Jan  5 11:02:24 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 4 Jan 2015 17:02:24 -0800
Subject: [TUHS] VAX faxing?
In-Reply-To: <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
 <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>
Message-ID: <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca>


On Jan 4, 2015, at 2:40 PM, Clem Cole <clemc at ccc.com> wrote:

> Yeah - some of the modems were.  IIRC: Sam Leffler  (sam "usual email punctuation" errno.com) did the original FlexFax SW and we had a couple kicking around.  My memory is that the modems that could also support Fax in those days, sucked at UUCP, so most of us did want to dedicate a phone line to one of them. 

In what sense?  Telebit came along early with their UUCP g-protocol spoofing, but that predated all the Hayes et al FAX support.  By the time modems grew (good) FAX support, UUCP was dying out in favour of PPP over V.xxx 56kb/s.  I had banks of Hayes (and other) V.x modems that handled dialup 38.4 + FAX quite cheerfully.  The Telebit UUCP-aware modems died out quite quickly once V.32 hit the streets.

--lyndon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150104/53cb39d9/attachment.sig>

From clemc at ccc.com  Mon Jan  5 11:48:26 2015
From: clemc at ccc.com (Clem Cole)
Date: Sun, 4 Jan 2015 20:48:26 -0500
Subject: [TUHS] VAX faxing?
In-Reply-To: <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
 <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>
 <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca>
Message-ID: <CAC20D2P0FhS_V52zaJutAQe=0_HJKmFVK656=M56wg6qmAKWpw@mail.gmail.com>

On Sun, Jan 4, 2015 at 8:02 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> Telebit came along early with their UUCP g-protocol spoofing, but that
> predated all the Hayes et al FAX support.


​I don't think so.  I think it was about the same time.   We had both in
the early 1980s when 120 cps was the fastest.  Hayes may have been later
with Fax support, certainly with the 56K stuff, but we had fax support with
the slower modems from another manufacturer who's name escapes me now [IIRC
it started with a C, they were black and the SW interface was
terrible/buggy].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150104/561684cc/attachment.html>

From lyndon at orthanc.ca  Mon Jan  5 14:10:56 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 4 Jan 2015 20:10:56 -0800
Subject: [TUHS] VAX faxing?
In-Reply-To: <CAC20D2P0FhS_V52zaJutAQe=0_HJKmFVK656=M56wg6qmAKWpw@mail.gmail.com>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
 <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <CAC20D2PoQ=Fvdjdfmc-+Xsun5Lj=8PZCyv5mKKDwpdrJzctWig@mail.gmail.com>
 <2147E845-AAD6-4575-B57F-E89C814F88AD@orthanc.ca>
 <CAC20D2P0FhS_V52zaJutAQe=0_HJKmFVK656=M56wg6qmAKWpw@mail.gmail.com>
Message-ID: <D7B72B72-9B9B-4A33-B27A-F63632730688@orthanc.ca>

> Telebit came along early with their UUCP g-protocol spoofing, but that predated all the Hayes et al FAX support. 
> 
> ​I don't think so.  I think it was about the same time.   We had both in the early 1980s when 120 cps was the fastest.  Hayes may have been later with Fax support, certainly with the 56K stuff, but we had fax support with the slower modems from another manufacturer who's name escapes me now [IIRC it started with a C, they were black and the SW interface was terrible/buggy].   

Okay, nailing it down a bit more, according to my fuzzy memory ...

1982 ish:  1200 bps hayes (the black slab)

1084-5 ish: 2400 bps

1986 ish (telebit trailblazer)

1988 ish: trailblazer 2, v.32

I don't recall commodity FAX modem support until the V.34 stuff started rolling out circa 1994(?).  I'm curious to know of anyone shipping (interoperable) modem FAX bits before then.  I admit to not knowing of anyone or thing using V.17.

--lyndon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150104/426d461e/attachment.sig>

From dave at horsfall.org  Mon Jan  5 14:31:15 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Jan 2015 15:31:15 +1100 (EST)
Subject: [TUHS] VAX faxing?
In-Reply-To: <19446.1420413351@cesium.clock.org>
References: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <19446.1420413351@cesium.clock.org>
Message-ID: <alpine.BSF.2.11.1501051530130.58880@aneurin.horsfall.org>

On Sun, 4 Jan 2015, Erik E. Fair wrote:

> It amazes and annoys me to this day how many PDFs purported to be 
> "electronic documents" are merely pictures of paper. Not only am I 
> missing my 2000's-era personal jetpack, I'm still waiting for my fully 
> paperless office.

Right after we get the paperless toilet...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From lyndon at orthanc.ca  Mon Jan  5 14:31:56 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sun, 4 Jan 2015 20:31:56 -0800
Subject: [TUHS] VAX faxing?
In-Reply-To: <alpine.BSF.2.11.1501051530130.58880@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <19446.1420413351@cesium.clock.org>
 <alpine.BSF.2.11.1501051530130.58880@aneurin.horsfall.org>
Message-ID: <047E47F1-354F-4825-A7B0-FE70483C258B@orthanc.ca>


On Jan 4, 2015, at 8:31 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Right after we get the paperless toilet...

It's called an air compressor.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150104/e1a178f5/attachment.sig>

From fair-tuhs at netbsd.org  Mon Jan  5 14:54:55 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Sun, 04 Jan 2015 20:54:55 -0800
Subject: [TUHS] VAX faxing?
In-Reply-To: <alpine.BSF.2.11.1501051530130.58880@aneurin.horsfall.org>
References: <19446.1420413351@cesium.clock.org>
Message-ID: <26843.1420433695@cesium.clock.org>

I hear tell that the Japanese have paperless toilets ...

They even appear to be sold in the USA: http://www.totousa.com/products/washlets

	Erik <fair at netbsd.org>


From peter at rulingia.com  Mon Jan  5 17:06:13 2015
From: peter at rulingia.com (Peter Jeremy)
Date: Mon, 5 Jan 2015 18:06:13 +1100
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <3578.1420226008@cesium.clock.org>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
Message-ID: <20150105070613.GB10940@server.rulingia.com>

On 2015-Jan-02 11:13:28 -0800, "Erik E. Fair" <fair-tuhs at netbsd.org> wrote:
>your terminal into the TERMCAP environment variable at login time,
>which my .login does to this day - that puts it already in RAM,

But you pay for the size of $TERMCAP in every process you run.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150105/e0b501a8/attachment.sig>

From dugo at xs4all.nl  Mon Jan  5 19:59:26 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Mon, 05 Jan 2015 10:59:26 +0100
Subject: [TUHS] =?utf-8?q?VAX_faxing=3F?=
In-Reply-To: <alpine.GSO.2.03.1501040328400.627@gewt.net>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
Message-ID: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl>

On 2015-01-04 09:30, Cory Smelosky wrote:
> Friend asked an odd question:
> 
> Were VAXen ever used to send/receive faxes large-scale?  What software
> was used and how was it configured?
> 
> Was any of this run on any of the UCB VAXen?

Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills'
fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax
machines.

Dedicating VAXen to do this kind of thing might have been overkill for
a long time.

/Jacob


From sdaoden at yandex.com  Mon Jan  5 21:11:42 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Mon, 05 Jan 2015 12:11:42 +0100
Subject: [TUHS] VAX faxing?
In-Reply-To: <26843.1420433695@cesium.clock.org>
References: <19446.1420413351@cesium.clock.org>
 <26843.1420433695@cesium.clock.org>
Message-ID: <20150105111142.9_hj3zig%sdaoden@yandex.com>

"Erik E. Fair" <fair-tuhs at netbsd.org> wrote:
 |I hear tell that the Japanese have paperless toilets ...

To the best of my knowledge civilized tribes never used paper, but
their hands and either sand or water.
Then a little bit of (creme or) oil for the rosette muscle.

On what i hear, the thing about japanese toilets seems to be that
they are so clean that you can drink their water.  (I hope this
sentence isn't inappriate.)

--steffen


From tfb at tfeb.org  Mon Jan  5 22:02:59 2015
From: tfb at tfeb.org (Tim Bradshaw)
Date: Mon, 5 Jan 2015 12:02:59 +0000
Subject: [TUHS] Illumos )
In-Reply-To: <20141231224249.GA5833@mcvoy.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
Message-ID: <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>

On 31 Dec 2014, at 22:42, Larry McVoy <lm at mcvoy.com> wrote:

> My view is Linux is pragmatic about stuff, Solaris was dogmatic about it.
> Yeah, the latter leads to better thought out stuff but the former tends
> to be useful sooner.

I think that this is exactly right. I used Solaris for pretty much my whole 
career (BSD then SunOS then Solaris) and eventually I had to give up and just admit that, for reasons I don't understand but are probably to do with culture at Sun, Solaris was making a lot of decisions which smelt like ones that an academic who didn't need to actually care about use in the real world might make, while Linux almost never did that (it had/has other problems, specifically long-term interface stability).

The case that made me finally realise that Solaris Had Lost was ZFS, and specifically ZFS consistency check.  There is (was in ~2010) *no way to check a zpool outside the kernel*, so if you had a zpool which you thought might be damaged you were supposed to check it by importing it.  So all that check code which had to deal with possibly completely random crap in the pool ran in the kernel where any kind of serious mistake involved, if you're lucky, the machine crashing, and if you're not lucky some awful data-corruption problem.  But that's OK, because the ZFS code is all perfect, and never has any problems at all, of course.

From jacob.ritorto at gmail.com  Tue Jan  6 03:04:37 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Mon, 5 Jan 2015 12:04:37 -0500
Subject: [TUHS] Illumos )
In-Reply-To: <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
Message-ID: <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>

On Mon, Jan 5, 2015 at 7:02 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

> On 31 Dec 2014, at 22:42, Larry McVoy <lm at mcvoy.com> wrote:
>
> > My view is Linux is pragmatic about stuff, Solaris was dogmatic about it.
> > Yeah, the latter leads to better thought out stuff but the former tends
> > to be useful sooner.
>
> I think that this is exactly right.


I'm mostly agreeing with the gist of this, although I'd shy away from
taking it as an absolute.  I think the motivation for the dogmatic
behaviour stems from not wanting to utterly immerse in the "just hack it"
mindset.  They were from the cathedral days and, from experience of the
previous iterations of it, participated in the contemporary bazaar mindset
with caution and reservation.  One example is the penchant for (arguably
over-) applying higher level design to a problem instead of just doing
something myopic and 'good enough' to get through a minimum viable product
scenario.  It's a gradient, not a slippery slope and finding the sweet spot
within it is, of course, an exercise in pragmatism.


> [...] Solaris was making a lot of decisions which smelt like ones that an
> academic who didn't need to actually care about use in the real world might
> make, while Linux almost never did that (it had/has other problems,
> specifically long-term interface stability).


Even in SmartOS (Illumos-derived and vociferously "not-Solaris-anymore"),
which amplifies both the pragmatism and the 10000' view design tenets, I
still run into that. An a low-hanging example, while the rest of the
world's happily wheelbarrowing everything into /usr/local and one has to
"follow the rules" and use /opt, it's smacks of an unnecessary kick in the
eye that, unix dissenters could argue, just breaks shit for spite.  I
understood it culturally -- for SVR4-steeped folks, it was a parseable
style pattern / smell -- when you saw a machine configured around
/usr/local, you braced yourself for an unbridled shitshow.  We all kind of
stepped back and grew some pragmatism around that, though -- Joyent, after
much griping from me and my co-workers, came out with sngl containers to
stop this hubris so we could use Chef recipes more easily, albiet rather
late in the game (2012-ish).  Now you can more readily build stuff as a
toddler builds with his blocks.  The brilliant bit is that with SmartOS,
you now academic design, stability, speed and real world usability.

 There's certainly a platform for debate, perhaps in another thread, around
the merits of understanding and engineering everything -vs.- building with
blocks.



>
> The case that made me finally realise that Solaris Had Lost was ZFS, and
> specifically ZFS consistency check.

There is (was in ~2010) *no way to check a zpool outside the kernel*, so if
> you had a zpool which you thought might be damaged you were supposed to
> check it by importing it.


  I'm afraid there's bias confirmation and a zeal for driving nails into
coffins happening here.  Bear in mind that unix didn't even have fsck for a
decade after its release (it appeared after v7 released), while conversely,
zfs had the manual scrub command and other manual zfs recovery tools
(which, much like fsck and icheck, et al, admittedly required expert
knowledge to wield successfully) before it released.  Yes, the default is
that the system will panic or pass over a zfs it can't mount, but that's by
design and when I was in that situation myself, even as a zfs noob, I
managed to figure out how to recover without damaging my pool.  Would you
care to compare this experience to some of the battles we've all personally
waged with fsck?  In the unix tradition, zfs is a designed and deliberate
iteration (innovation) on the filesystem concept, not a "pragmatic,"
good-enough, minimum viable product hip-shot, and the obvious fact that it
isn't what we're used to doesn't make it bad.  While there are certainly
plenty of Solaris coffin nails, this ain't one.

  Here's my favourite Solaris coffin nail: Oracle's last five years of
lawnmowing, almost zero innovative milestones and clueless customer base
and community erosion and desecration.  I do now agree that Solaris is
finally and irredeemably dead.  Their lack of understanding and stewardship
has tragically transitioned it from the being the definitive unix system
to, in essence, a proprietary firmware for expensive iron.  But in the same
breath I'd also assert that Illumos and its derivatives have taken all the
good from it, continue to drive the fork forward in a wonderful variety of
ways, and are the repo- and distros-of-record for this flavour of unix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150105/e2836386/attachment.html>

From cowan at mercury.ccil.org  Tue Jan  6 10:40:54 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 5 Jan 2015 19:40:54 -0500
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <20150105070613.GB10940@server.rulingia.com>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
Message-ID: <20150106004054.GD16715@mercury.ccil.org>

Peter Jeremy scripsit:

> But you pay for the size of $TERMCAP in every process you run.

A single termcap line doesn't cost that much, less than a KB in most cases.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
May the hair on your toes never fall out!  --Thorin Oakenshield (to Bilbo)


From wkt at tuhs.org  Tue Jan  6 11:55:36 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 Jan 2015 12:55:36 +1100
Subject: [TUHS] State of networking in the early '90s
In-Reply-To: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
 <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl>
Message-ID: <20150106015536.GA27434@www.oztivo.net>

On Mon, Jan 05, 2015 at 10:59:26AM +0100, Jacob Goense wrote:
> Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills'
> fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax
> machines.

Reading this e-mail caused me to read up on the fuzzball, which then lead me
to this overview of the state of networking in the early '90s:

http://museum.media.org/eti/

	In 1990 and 1991, I made three trips around the world to write a
	technical travelogue. The result was the book "Exploring the
	Internet", originally published by Prentice-Hall. Perhaps because
	they felt the Internet trend had passed, or more likely because
	of the less-than-mainstream appeal, they allowed the book to go
	out of print. I decided to republish the book on the Internet in
	the hope that perhaps it retains some minor historical interest.

So far I've got through about 6 chapters and it's a good read. I've made it
into an epub if anybody wants a copy.

Cheers, Warren


From crossd at gmail.com  Tue Jan  6 12:23:58 2015
From: crossd at gmail.com (Dan Cross)
Date: Mon, 5 Jan 2015 21:23:58 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
Message-ID: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>

Bob Swartz, founder of Mark Williams Co, has allowed the sources for
COHERENT to be published under a three-clause BSD license.  Steve Ness is
hosting them.  They are available here:

    http://nesssoftware.com/home/mwc/source.php

For reference, for folks who don't know what COHERENT is, it started as a
clone of 7th Edition, but grew more modern features over time.  Dennis
Ritchie's recollections of his interaction with it:
https://groups.google.com/forum/#!msg/alt.folklore.computers/_ZaYeY46eb4/5B41Uym6d4QJ

And of course the requisite Wikipedia link:
http://en.wikipedia.org/wiki/Coherent_(operating_system)

        - Dan C.

PS: I hold a soft spot for COHERENT in my heart.  I became interested in
Unix in high school, but this was before Linux was really a thing and
access to other systems was still hard to come by.  I spotted an ad for
COHERENT in the back of one of the PC-oriented publications at the time,
"Computer Shopper" or some such, and realized that it was *almost* within
my reach financially and that I could install it on the computer I already
owned.  Over the next month or so, I scraped up enough money to buy a copy,
did so, and put it on my PC.  It was quirky compared to actual Unix
distributions, but it was enough to give one a flavor for things.  The
manual, in particular, did not follow the traditional Unix format, but
rather was an alphabetical "lexicon" of commands, system calls and
functions and was (I've always thought) particularly well done.  Links to
the COHERENT lexicon and various other documents:
http://www.nesssoftware.com/home/mwc/.

I graduated onto other systems rather quickly, but COHERENT served as my
introduction to Unix and Unix-like systems.

PPS: Bob Swartz is the father of the late Aaron Swartz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150105/883d3003/attachment.html>

From lm at mcvoy.com  Tue Jan  6 12:40:59 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 5 Jan 2015 18:40:59 -0800
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
References: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
Message-ID: <20150106024059.GD25082@mcvoy.com>

This one line hit me hard:

> PPS: Bob Swartz is the father of the late Aaron Swartz.

Small world.  The fact that he is still doing good things after losing his
son, wow.

I'm a guy who would probably have gone postal if I lost my son.  My heart
and admiration goes out to Bob.

On a fun note, I remember Coherent, it was fun.


From lm at mcvoy.com  Tue Jan  6 12:49:46 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 5 Jan 2015 18:49:46 -0800
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150106024059.GD25082@mcvoy.com>
References: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
 <20150106024059.GD25082@mcvoy.com>
Message-ID: <20150106024946.GE25082@mcvoy.com>

And as a troff fan, I love their docs.  My team hates that I love troff
but I do.  It's a pretty decent markup language and it lends itself to
being version controlled.  As the BitKeeper guy I like version control.

On Mon, Jan 05, 2015 at 06:40:59PM -0800, Larry McVoy wrote:
> This one line hit me hard:
> 
> > PPS: Bob Swartz is the father of the late Aaron Swartz.
> 
> Small world.  The fact that he is still doing good things after losing his
> son, wow.
> 
> I'm a guy who would probably have gone postal if I lost my son.  My heart
> and admiration goes out to Bob.
> 
> On a fun note, I remember Coherent, it was fun.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From imp at bsdimp.com  Tue Jan  6 13:01:04 2015
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 5 Jan 2015 20:01:04 -0700
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150106024946.GE25082@mcvoy.com>
References: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
 <20150106024059.GD25082@mcvoy.com> <20150106024946.GE25082@mcvoy.com>
Message-ID: <13F6FD2B-7520-4EF7-A210-D03AEC6B11D2@bsdimp.com>

I wonder if this will run on my old DEC Rainbow 100B…  There was a binary version
of COHERENT for the RAINBOW, iirc, that I’ve been hoping to get my hands on
for more years than most of my co-workers have been alive… But I’m pretty sure that
was version 2….  Hmmm, some googling suggests it was Venix/86R, which sadly
hasn’t turned up in years :(

Warner

> On Jan 5, 2015, at 7:49 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> And as a troff fan, I love their docs.  My team hates that I love troff
> but I do.  It's a pretty decent markup language and it lends itself to
> being version controlled.  As the BitKeeper guy I like version control.
> 
> On Mon, Jan 05, 2015 at 06:40:59PM -0800, Larry McVoy wrote:
>> This one line hit me hard:
>> 
>>> PPS: Bob Swartz is the father of the late Aaron Swartz.
>> 
>> Small world.  The fact that he is still doing good things after losing his
>> son, wow.
>> 
>> I'm a guy who would probably have gone postal if I lost my son.  My heart
>> and admiration goes out to Bob.
>> 
>> On a fun note, I remember Coherent, it was fun.
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> --
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150105/4a172d2b/attachment.sig>

From akosela at andykosela.com  Tue Jan  6 14:54:21 2015
From: akosela at andykosela.com (Andy Kosela)
Date: Mon, 5 Jan 2015 22:54:21 -0600
Subject: [TUHS] Illumos )
In-Reply-To: <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
Message-ID: <CALMnNGiLb2T+b=+Hvt82AgYP+9rj441MztYiBKMVxLzoPJ9iqA@mail.gmail.com>

On Mon, Jan 5, 2015 at 11:04 AM, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:
> Here's my favourite Solaris coffin nail: Oracle's last five years of
> lawnmowing, almost zero innovative milestones and clueless customer base and
> community erosion and desecration.  I do now agree that Solaris is finally
> and irredeemably dead.  Their lack of understanding and stewardship has
> tragically transitioned it from the being the definitive unix system to, in
> essence, a proprietary firmware for expensive iron.  But in the same breath
> I'd also assert that Illumos and its derivatives have taken all the good
> from it, continue to drive the fork forward in a wonderful variety of ways,
> and are the repo- and distros-of-record for this flavour of unix.

This is your way of putting history together, but I think that
objective view on the matter potray this a little bit differently.  I
personally know a lot of Fortune 500 shops still using Oracle Solaris
and happily migrating from Solaris 10 to Solaris 11, instead of
embracing Illumos and myriad of its incarnations.  You know why?

There could be only one answer -- all of those shops depend heavily on
other technologies provided by Oracle like databases and middleware,
and by sticking to one support vendor they actually save a lot.  There
is even more -- I see an increasing trend in adopting Oracle Linux in
enterprise in place of Red Hat Enterprise Linux also because of the
integration with Oracle databases and other Oracle technologies.

It is a shame that Oracle closed Solaris source, but to be honest
their integration of hardware and software is still unmatched if you
ask me.  If you take a look at their hardware and software plans they
have pretty solid plans going into 2019 for new new CPU's and Solaris
versions[1].  Their T4 and T5 chips are pretty sweet and perform
really well as compared to x86; they still also put a lot of
improvements into ZFS[2], so to say that Oracle Solaris is dead is a
gravely exaggeration.  In contrast Joyent is still just a small
start-up.  And start-up's come and go as we have seen recently with
the history of Joyent spin-off TextDrive run by Dean Allen.  I don't
see Oracle going anywhere in the next 25 years or so.

just my .02
--Andy

[1] http://www.oracle.com/us/products/servers-storage/servers/sparc/oracle-sparc/sparc-roadmap-slide-2076743.pdf
[2] https://blogs.oracle.com/darren/en_GB/entry/new_zfs_encryption_features_in


From fair-tuhs at netbsd.org  Tue Jan  6 17:02:27 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Mon, 05 Jan 2015 23:02:27 -0800
Subject: [TUHS] State of networking in the early '90s
In-Reply-To: <20150106015536.GA27434@www.oztivo.net>
References: <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl>
Message-ID: <22750.1420527747@cesium.clock.org>

> Date: Tue, 6 Jan 2015 12:55:36 +1100
> From: Warren Toomey <wkt at tuhs.org>
> 
> On Mon, Jan 05, 2015 at 10:59:26AM +0100, Jacob Goense wrote:
> > Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills'
> > fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax
> > machines.
> 
> Reading this e-mail caused me to read up on the fuzzball, which then lead me
> to this overview of the state of networking in the early '90s:

31 years ago almost to the day, I stayed up until 01:30 PST to write a
description of all of the networks I knew of in response to a query on the
HUMAN-NETS mailing list; it appears under the subject "The Plethora of
Networks" in HUMAN-NETS digest V7 #1 which can be found:

http://www.cs.rutgers.edu/~cwm/NetStuff/Human-Nets/Volume7.html

A number of others also chimed in, and the resulting discussion inspired (and
was source material for) John S. Quarterman's book "The Matrix" (1989):

http://www.amazon.com/The-Matrix-Computer-Conferencing-Worldwide/dp/1555580335

It's a bit of a budgie-killer, but a fine snapshot of what was at that time.

	Erik <fair at netbsd.org>


From angus at fairhaven.za.net  Tue Jan  6 17:37:56 2015
From: angus at fairhaven.za.net (Angus Robinson)
Date: Tue, 6 Jan 2015 09:37:56 +0200
Subject: [TUHS] State of networking in the early '90s
In-Reply-To: <20150106015536.GA27434@www.oztivo.net>
References: <alpine.GSO.2.03.1501040328400.627@gewt.net>
 <534d2eef8d0fb84d3880c067d9e1517d@xs4all.nl>
 <20150106015536.GA27434@www.oztivo.net>
Message-ID: <CAE49LGk0FYO8PO99MRLEGUnMkYO5fKYdi_ym2f24pppTHiLQsQ@mail.gmail.com>

Hi Warren

It seems like it would be an interesting read. Would you mind sending me a
copy of the epub?

On Tue, Jan 6, 2015 at 3:55 AM, Warren Toomey <wkt at tuhs.org> wrote:

> On Mon, Jan 05, 2015 at 10:59:26AM +0100, Jacob Goense wrote:
> > Early 80s INTELPOST ran on small 11s running RT-11/RSX-11 with Mills'
> > fuzzball bolted on top. These were hooked up to DACOM or Rapicom fax
> > machines.
>
> Reading this e-mail caused me to read up on the fuzzball, which then lead
> me
> to this overview of the state of networking in the early '90s:
>
> http://museum.media.org/eti/
>
>         In 1990 and 1991, I made three trips around the world to write a
>         technical travelogue. The result was the book "Exploring the
>         Internet", originally published by Prentice-Hall. Perhaps because
>         they felt the Internet trend had passed, or more likely because
>         of the less-than-mainstream appeal, they allowed the book to go
>         out of print. I decided to republish the book on the Internet in
>         the hope that perhaps it retains some minor historical interest.
>
> So far I've got through about 6 chapters and it's a good read. I've made it
> into an epub if anybody wants a copy.
>
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/be531c5f/attachment.html>

From wkt at tuhs.org  Tue Jan  6 18:07:54 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 Jan 2015 19:07:54 +1100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
References: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
Message-ID: <20150106080754.GA16120@www.oztivo.net>

On Mon, Jan 05, 2015 at 09:23:58PM -0500, Dan Cross wrote:
>    Bob Swartz, founder of Mark Williams Co, has allowed the sources for
>    COHERENT to be published under a three-clause BSD license.  Steve Ness
>    is hosting them.  They are available here:
>       http://nesssoftware.com/home/mwc/source.php

The Unix Archive has some Coherent files at:
	http://www.tuhs.org/Archive/Other/Coherent/

I'll mirror Steve's files along with the copyright notice and place them
in a sub-folder of the above URL.

Cheers all,
	Warren


From khm at sciops.net  Tue Jan  6 21:10:05 2015
From: khm at sciops.net (Kurt H Maier)
Date: Tue, 06 Jan 2015 11:10:05 +0000
Subject: [TUHS] Illumos )
In-Reply-To: <CALMnNGiLb2T+b=+Hvt82AgYP+9rj441MztYiBKMVxLzoPJ9iqA@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CALMnNGiLb2T+b=+Hvt82AgYP+9rj441MztYiBKMVxLzoPJ9iqA@mail.gmail.com>
Message-ID: <20150106111005.Horde.tR5qOnLIK14Fxim9iVGlRQ3@ssl.eumx.net>

Quoting Andy Kosela <akosela at andykosela.com>:

> There could be only one answer --

Vendor lock-in is not going to save Oracle Solaris, in exactly
the same way DB2 did not save AIX.

khm



From arnold at skeeve.com  Tue Jan  6 22:22:56 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 06 Jan 2015 05:22:56 -0700
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <20150106004054.GD16715@mercury.ccil.org>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
 <20150106004054.GD16715@mercury.ccil.org>
Message-ID: <201501061222.t06CMvTO027313@freefriends.org>

> Peter Jeremy scripsit:
> > But you pay for the size of $TERMCAP in every process you run.

John Cowan <cowan at mercury.ccil.org> wrote:
> A single termcap line doesn't cost that much, less than a KB in most cases.

In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
have 32KB to start with.  (The discussion a few weeks ago about cutting
yacc down to size comes to mind...)

On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
even be paged out, and BSD on the vax didn't have copy-on-write.

ISTR that the /etc/termcap file had a comment saying something like
"you should move the entries needed at your site to the top of this file."
Or am I imagining it? :-)

In short - today, sure, no problem - back then, carrying around a large
environment made more of a difference.

Thanks,

Arnold


From doug at cs.dartmouth.edu  Tue Jan  6 23:41:37 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 06 Jan 2015 08:41:37 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
Message-ID: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>

A very nice addition to the archives. Thank you.

I well remember our disbelief that Mark Williams wrote all its own
code, unlike other vendors who had professed the same. As Dennis
described, we had fun putting together  black-box tests that
recognized  undocumented quirks (or bugs) in our code. We were
duly impressed when the results came back negative.

Doug


From rp at servium.ch  Wed Jan  7 00:25:30 2015
From: rp at servium.ch (Rico Pajarola)
Date: Tue, 6 Jan 2015 09:25:30 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
Message-ID: <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>

do you still have those black-box tests somewhere?

On Tue, Jan 6, 2015 at 8:41 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> A very nice addition to the archives. Thank you.
>
> I well remember our disbelief that Mark Williams wrote all its own
> code, unlike other vendors who had professed the same. As Dennis
> described, we had fun putting together  black-box tests that
> recognized  undocumented quirks (or bugs) in our code. We were
> duly impressed when the results came back negative.
>
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/ff9b9fc9/attachment.html>

From tfb at tfeb.org  Wed Jan  7 01:37:36 2015
From: tfb at tfeb.org (Tim Bradshaw)
Date: Tue, 6 Jan 2015 15:37:36 +0000
Subject: [TUHS] Illumos )
In-Reply-To: <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
Message-ID: <389F2E19-7E08-4294-914E-49EE2641B118@tfeb.org>

On 5 Jan 2015, at 17:04, Jacob Ritorto <jacob.ritorto at gmail.com> wrote:

>  I'm afraid there's bias confirmation and a zeal for driving nails into coffins happening here.  Bear in mind that unix didn't even have fsck for a decade after its release (it appeared after v7 released), while conversely, zfs had the manual scrub command and other manual zfs recovery tools (which, much like fsck and icheck, et al, admittedly required expert knowledge to wield successfully) before it released. 

I own a vintage car, by which I don't mean the spurious things people now call 'vintage' but a car registered in 1930 or before.  It's a lovely thing to drive.  But it has no seatbelts, the fuel tank is over your knees and immediately behind the top of the engine (I try not to think about what that means in an accident) and rod brakes which you adjust with wingnuts.  I would not be happy with these features in a new car.

> Yes, the default is that the system will panic or pass over a zfs it can't mount, but that's by design and when I was in that situation myself, even as a zfs noob, I managed to figure out how to recover without damaging my pool.  Would you care to compare this experience to some of the battles we've all personally waged with fsck?  

Again: the 'fsck on old systems' comparison is simply not relevant, sorry: we have learnt a lot of stuff since then.  One thing we should have learnt is that you want code to run with the minimum possible privilege, because running things with too much privilege has led to appalling disasters which I'm sure I don't need to mention.  That means, for instance, that you should run nothing in the kernel that does not have to be there.  One thing which clearly does not have to be there is consistency checkers and debuggers for filesystems, of whatever kind. There is absolutely nothing in the design of ZFS which prevents that being done.

> In the unix tradition, zfs is a designed and deliberate iteration (innovation) on the filesystem concept, not a "pragmatic," good-enough, minimum viable product hip-shot, and the obvious fact that it isn't what we're used to doesn't make it bad.  While there are certainly plenty of Solaris coffin nails, this ain't one.

I'm extremely happy that ZFS is not a traditional filesystem, because the traditional volume-manager / filesystem model sucks, to put it mildly: I have spent enough of my life dealing with it that I just want it to be over. I just want ZFS to be properly engineered.  Instead, what will (has, probably) happen is a ZFS clone will appear for Linux, which will be properly engineered.  Such is the fate of Solaris: pride does, indeed, come before a fall.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/def16a4a/attachment.html>

From mah at mhorton.net  Wed Jan  7 02:02:54 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Tue, 06 Jan 2015 08:02:54 -0800
Subject: [TUHS] termcap vs terminfo
In-Reply-To: <201501061222.t06CMvTO027313@freefriends.org>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
 <20150106004054.GD16715@mercury.ccil.org>
 <201501061222.t06CMvTO027313@freefriends.org>
Message-ID: <54AC072E.7030605@mhorton.net>

On 01/06/2015 04:22 AM, arnold at skeeve.com wrote:
>> Peter Jeremy scripsit:
>>> But you pay for the size of $TERMCAP in every process you run.
> John Cowan <cowan at mercury.ccil.org> wrote:
>> A single termcap line doesn't cost that much, less than a KB in most cases.
> In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> have 32KB to start with.  (The discussion a few weeks ago about cutting
> yacc down to size comes to mind...)
>
> On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
> even be paged out, and BSD on the vax didn't have copy-on-write.
>
> ISTR that the /etc/termcap file had a comment saying something like
> "you should move the entries needed at your site to the top of this file."
> Or am I imagining it? :-)
>
> In short - today, sure, no problem - back then, carrying around a large
> environment made more of a difference.
>
> Thanks,
>
> Arnold
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
Even with TERMCAP in the environment, there's still that quadratic 
algorithm every time vi starts up.



From imp at bsdimp.com  Wed Jan  7 02:32:06 2015
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 6 Jan 2015 09:32:06 -0700
Subject: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)
In-Reply-To: <201501061222.t06CMvTO027313@freefriends.org>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
 <20150106004054.GD16715@mercury.ccil.org>
 <201501061222.t06CMvTO027313@freefriends.org>
Message-ID: <7D77811B-8E40-4369-AB4E-513F07DDD0DB@bsdimp.com>


> On Jan 6, 2015, at 5:22 AM, arnold at skeeve.com wrote:
> 
>> Peter Jeremy scripsit:
>>> But you pay for the size of $TERMCAP in every process you run.
> 
> John Cowan <cowan at mercury.ccil.org> wrote:
>> A single termcap line doesn't cost that much, less than a KB in most cases.
> 
> In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> have 32KB to start with.  (The discussion a few weeks ago about cutting
> yacc down to size comes to mind...)
> 
> On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
> even be paged out, and BSD on the vax didn't have copy-on-write.
> 
> ISTR that the /etc/termcap file had a comment saying something like
> "you should move the entries needed at your site to the top of this file."
> Or am I imagining it? :-)

No, you aren’t. And iirc, we moved the HP terminal entries to the
top of ours since we got a VAX 11/750, but a bunch of HP terminals
instead of DEC ones for reasons that likely involved graft and fraud
in the procurement office :)

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/bd1cae2f/attachment.sig>

From rp at servium.ch  Wed Jan  7 02:48:55 2015
From: rp at servium.ch (Rico Pajarola)
Date: Tue, 6 Jan 2015 11:48:55 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
Message-ID: <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>

adding the list back

On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com> wrote:

> This is a cool development. Does this code build into a working version of
> Coherent or is this mainly useful to study? Either way, it should be
> interesting to look at the code for a clone specifically aimed at low-end
> hardware.
>
> Mike
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/86c500b7/attachment.html>

From bqt at update.uu.se  Wed Jan  7 02:51:06 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 06 Jan 2015 17:51:06 +0100
Subject: [TUHS] termcap vs terminfo
In-Reply-To: <mailman.143.1420561935.3354.tuhs@minnie.tuhs.org>
References: <mailman.143.1420561935.3354.tuhs@minnie.tuhs.org>
Message-ID: <54AC127A.5050508@update.uu.se>

On 2015-01-06 17:32, Mary Ann Horton<mah at mhorton.net> wrote:
>
> On 01/06/2015 04:22 AM,arnold at skeeve.com  wrote:
>>> >>Peter Jeremy scripsit:
>>>> >>>But you pay for the size of $TERMCAP in every process you run.
>> >John Cowan<cowan at mercury.ccil.org>  wrote:
>>> >>A single termcap line doesn't cost that much, less than a KB in most cases.
>> >In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
>> >have 32KB to start with.  (The discussion a few weeks ago about cutting
>> >yacc down to size comes to mind...)
>> >
>> >On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might
>> >even be paged out, and BSD on the vax didn't have copy-on-write.
>> >
>> >ISTR that the /etc/termcap file had a comment saying something like
>> >"you should move the entries needed at your site to the top of this file."
>> >Or am I imagining it?:-)
>> >
>> >In short - today, sure, no problem - back then, carrying around a large
>> >environment made more of a difference.
>> >
>> >Thanks,
>> >
>> >Arnold
> Even with TERMCAP in the environment, there's still that quadratic
> algorithm every time vi starts up.

I must be stupid or something. What quadratic algorithm?
vi gets the "correct" terminal database entry directly from the 
environment. Admittedly, getting any variable out of the environment 
means a linear search of the environment, but that's about it.

What am I missing? And once you have that, any operation still means 
either searching through the terminal definition for the right function, 
which in itself is also linear, unless you hash that up in your program. 
But I fail to see where the quadratic behavior comes in.

	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 crossd at gmail.com  Wed Jan  7 02:56:42 2015
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Jan 2015 11:56:42 -0500
Subject: [TUHS] termcap vs terminfo
In-Reply-To: <54AC127A.5050508@update.uu.se>
References: <mailman.143.1420561935.3354.tuhs@minnie.tuhs.org>
 <54AC127A.5050508@update.uu.se>
Message-ID: <CAEoi9W7Ke_AV8PjQ=i0kLK3PFUuXQBsFnR3a4A2hjqNTr88tJw@mail.gmail.com>

On Tue, Jan 6, 2015 at 11:51 AM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2015-01-06 17:32, Mary Ann Horton<mah at mhorton.net> wrote:
>
>> Even with TERMCAP in the environment, there's still that quadratic
>> algorithm every time vi starts up.
>>
>
> I must be stupid or something. What quadratic algorithm?
> vi gets the "correct" terminal database entry directly from the
> environment. Admittedly, getting any variable out of the environment means
> a linear search of the environment, but that's about it.
>
> What am I missing? And once you have that, any operation still means
> either searching through the terminal definition for the right function,
> which in itself is also linear, unless you hash that up in your program.
> But I fail to see where the quadratic behavior comes in.


I believe that Mary Ann is referring to repeatedly looking up (presumably
different) elements in the entry.  Assuming that e.g. `vi` looks up O(n)
elements, where $n$ is the number of elements, doing a linear scan for
each, you'd end up with quadratic behavior.

Hashing, or storing in some kind of balanced-tree like structure or
something, would of course help but would also necessitate doing a copy and
would entail some additional memory inefficiency.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/113d08c2/attachment.html>

From crossd at gmail.com  Wed Jan  7 03:04:52 2015
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Jan 2015 12:04:52 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
Message-ID: <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>

On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola <rp at servium.ch> wrote:

> adding the list back
>
> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
> wrote:
>
>> This is a cool development. Does this code build into a working version
>> of Coherent or is this mainly useful to study? Either way, it should be
>> interesting to look at the code for a clone specifically aimed at low-end
>> hardware.
>>
> Unknown (to me, anyway).  Steve said he had intended to organize and
catalog the code at some point, but that he hasn't gotten around to it (and
not to hold one's breath).  I gathered that the tar ball he provided is a
snapshot of (a subset of?) the MWC development disks at the time he was
asked to create the archive.  To that end, I suspect that if one were
sufficiently motivated one *could* use it to build a distribution of
COHERENT, but I suspect you'd have to know quite a bit about their internal
development practices and release processes to do so successfully;
knowledge that may very well have been lost over time.  Perhaps some
motivated person will be able to reverse engineer it, though I suspect it's
more useful as a case study than as working code.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/a70691a5/attachment.html>

From arnold at skeeve.com  Wed Jan  7 03:12:55 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 06 Jan 2015 10:12:55 -0700
Subject: [TUHS] termcap vs terminfo
In-Reply-To: <54AC072E.7030605@mhorton.net>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
 <20150106004054.GD16715@mercury.ccil.org>
 <201501061222.t06CMvTO027313@freefriends.org>
 <54AC072E.7030605@mhorton.net>
Message-ID: <201501061712.t06HCtei003805@freefriends.org>

Mary Ann Horton <mah at mhorton.net> wrote:

> Even with TERMCAP in the environment, there's still that quadratic 
> algorithm every time vi starts up.

Please remind me which one you're talking about? If TERMCAP is
in the environment there's no need to hit /etc/termcap at all.

Or are you talking about something else?

Thanks,

Arnold


From bqt at update.uu.se  Wed Jan  7 03:33:44 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 06 Jan 2015 18:33:44 +0100
Subject: [TUHS] termcap vs terminfo
In-Reply-To: <CAEoi9W7Ke_AV8PjQ=i0kLK3PFUuXQBsFnR3a4A2hjqNTr88tJw@mail.gmail.com>
References: <mailman.143.1420561935.3354.tuhs@minnie.tuhs.org>
 <54AC127A.5050508@update.uu.se>
 <CAEoi9W7Ke_AV8PjQ=i0kLK3PFUuXQBsFnR3a4A2hjqNTr88tJw@mail.gmail.com>
Message-ID: <54AC1C78.6090007@update.uu.se>

On 2015-01-06 17:56, Dan Cross wrote:
> On Tue, Jan 6, 2015 at 11:51 AM, Johnny Billquist <bqt at update.uu.se
> <mailto:bqt at update.uu.se>> wrote:
>
>     On 2015-01-06 17:32, Mary Ann Horton<mah at mhorton.net
>     <mailto:mah at mhorton.net>> wrote:
>
>         Even with TERMCAP in the environment, there's still that quadratic
>         algorithm every time vi starts up.
>
>
>     I must be stupid or something. What quadratic algorithm?
>     vi gets the "correct" terminal database entry directly from the
>     environment. Admittedly, getting any variable out of the environment
>     means a linear search of the environment, but that's about it.
>
>     What am I missing? And once you have that, any operation still means
>     either searching through the terminal definition for the right
>     function, which in itself is also linear, unless you hash that up in
>     your program. But I fail to see where the quadratic behavior comes in.
>
>
> I believe that Mary Ann is referring to repeatedly looking up
> (presumably different) elements in the entry.  Assuming that e.g. `vi`
> looks up O(n) elements, where $n$ is the number of elements, doing a
> linear scan for each, you'd end up with quadratic behavior.

Assuming that you'd look up all the elements of the termcap entry at 
startup, and did each one from scratch, yes.

> Hashing, or storing in some kind of balanced-tree like structure or
> something, would of course help but would also necessitate doing a copy
> and would entail some additional memory inefficiency.

Hashing would indeed cause some extra memory, but not necessarily any 
copying.
But that would beg the question, why is vi doing a repeated scan of the 
terminal entry at startup, if not to find all the capabilities and store 
this somewhere? And if doing a look for all of them, why not scan the 
string from start to finish and store the information as it is found? At 
which point we move from quadratic to linear time.

But now we're getting into the innards of vi, which I never looked at 
anyway, and I guess is less relevant in this thread anyway.

The short of it (from what I got out of it) is that the move from 
termcap to terminfo was mostly motivated by attribute name changing away 
from fixed 2 character names.

A secondary motivation would be performance, but I don't really buy that 
one. Since we only moved to terminfo on systems with plenty of memory, 
performance of termcap could easily be on par anyway.

Thanks for the insights.

	Johnny



From crossd at gmail.com  Wed Jan  7 03:53:27 2015
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Jan 2015 12:53:27 -0500
Subject: [TUHS] termcap vs terminfo
In-Reply-To: <54AC1C78.6090007@update.uu.se>
References: <mailman.143.1420561935.3354.tuhs@minnie.tuhs.org>
 <54AC127A.5050508@update.uu.se>
 <CAEoi9W7Ke_AV8PjQ=i0kLK3PFUuXQBsFnR3a4A2hjqNTr88tJw@mail.gmail.com>
 <54AC1C78.6090007@update.uu.se>
Message-ID: <CAEoi9W5sGmqxjQornM8izVbwSdQ-rD9UcPS8SZPFeT6FcMxYog@mail.gmail.com>

On Tue, Jan 6, 2015 at 12:33 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> On 2015-01-06 17:56, Dan Cross wrote:
>>
>> I believe that Mary Ann is referring to repeatedly looking up
>> (presumably different) elements in the entry.  Assuming that e.g. `vi`
>> looks up O(n) elements, where $n$ is the number of elements, doing a
>> linear scan for each, you'd end up with quadratic behavior.
>>
>
> Assuming that you'd look up all the elements of the termcap entry at
> startup, and did each one from scratch, yes.


Yes.  Isn't that exactly what Mary Ann said was happening?  :-)

 Hashing, or storing in some kind of balanced-tree like structure or
>> something, would of course help but would also necessitate doing a copy
>> and would entail some additional memory inefficiency.
>>
>
> Hashing would indeed cause some extra memory, but not necessarily any
> copying.
>

I fail to see how you can avoid copying the data out of the environment
vector (unless you intend to either (a) turn the env var into a hash table,
or (b) store pointers to the datum in the env var, but you'd need to encode
their length somehow.  I don't think environment variables can contain
embedded NULs, can they?).

But that would beg the question, why is vi doing a repeated scan of the
> terminal entry at startup, if not to find all the capabilities and store
> this somewhere? And if doing a look for all of them, why not scan the
> string from start to finish and store the information as it is found? At
> which point we move from quadratic to linear time.
>

I don't think she said it did things intelligently, just that that's how it
did things.  :-)

But now we're getting into the innards of vi, which I never looked at
> anyway, and I guess is less relevant in this thread anyway.
>
> The short of it (from what I got out of it) is that the move from termcap
> to terminfo was mostly motivated by attribute name changing away from fixed
> 2 character names.
>
> A secondary motivation would be performance, but I don't really buy that
> one. Since we only moved to terminfo on systems with plenty of memory,
> performance of termcap could easily be on par anyway.
>

I tend to agree with you and I'll go one further: it seems that frequently
we tend to identify a problem and then go to 11 with the "solution."  I can
buy that termcap performance was an issue; I don't know that going directly
to hashed terminfo files was the optimal solution.  A dbm file of termcap
data and a hash table in whatever library parsed termcap would go a long
way towards fixing the performance issues.  Did termcap have to be
discarded just to add longer names?  I kind of tend to doubt it, but I
wasn't there and don't know what the design criteria were, so my
very-much-after-the-fact second guessing is just that.

Thanks for the insights.
>
>         Johnny
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/bd279a0f/attachment.html>

From imp at bsdimp.com  Wed Jan  7 04:02:51 2015
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 6 Jan 2015 11:02:51 -0700
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150106080754.GA16120@www.oztivo.net>
References: <CAEoi9W7c+-4kJcwatWi75gjLVK_yaccBMdNZCukz_uie9mMO+w@mail.gmail.com>
 <20150106080754.GA16120@www.oztivo.net>
Message-ID: <BCA69A97-23ED-47C5-9E08-CCA460522A98@bsdimp.com>


> On Jan 6, 2015, at 1:07 AM, Warren Toomey <wkt at tuhs.org> wrote:
> 
> On Mon, Jan 05, 2015 at 09:23:58PM -0500, Dan Cross wrote:
>>   Bob Swartz, founder of Mark Williams Co, has allowed the sources for
>>   COHERENT to be published under a three-clause BSD license.  Steve Ness
>>   is hosting them.  They are available here:
>>      http://nesssoftware.com/home/mwc/source.php
> 
> The Unix Archive has some Coherent files at:
> 	http://www.tuhs.org/Archive/Other/Coherent/
> 
> I'll mirror Steve's files along with the copyright notice and place them
> in a sub-folder of the above URL.

Cool! Looking at Steve’s files, though, it looks like they could use some curating
since they are rather jumbled up. It’s great all the stuff that’s there is there, but
it makes it a bit hard to browse with tarballs inside of tarballs and multiple copies
of what looks like the same thing (but with differences).

Also, the mirrors mentioned in the Other/Coherent read me appear to be gone.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/55872e71/attachment.sig>

From imp at bsdimp.com  Wed Jan  7 04:09:58 2015
From: imp at bsdimp.com (Warner Losh)
Date: Tue, 6 Jan 2015 11:09:58 -0700
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
Message-ID: <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com>


> On Jan 6, 2015, at 10:04 AM, Dan Cross <crossd at gmail.com> wrote:
> 
> On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola <rp at servium.ch> wrote:
> adding the list back
> 
> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com> wrote:
> This is a cool development. Does this code build into a working version of Coherent or is this mainly useful to study? Either way, it should be interesting to look at the code for a clone specifically aimed at low-end hardware.
> 
> Unknown (to me, anyway).  Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath).  I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive.  To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time.  Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code.

Looking at the tarballs and the tarballs inside, this is a mess. It looks like it is all there, but there’s multiple copies of things that are almost identical, RCS files that are mostly enough, but not completely enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using a more modern compiler likely will result in “difficulties”. There’s some docs laying around, but I haven’t read through them all. The collection needs curating TLC...

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/ce9bda2a/attachment.sig>

From random832 at fastmail.us  Wed Jan  7 04:41:14 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Tue, 06 Jan 2015 13:41:14 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
Message-ID: <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>

On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote:
> adding the list back
> 
> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
> wrote:
> 
> > This is a cool development. Does this code build into a working version of
> > Coherent or is this mainly useful to study? Either way, it should be
> > interesting to look at the code for a clone specifically aimed at low-end
> > hardware.

In the "distrib" directory there are four files exactly 1440 kb in size
- maybe someone could try loading those into a VM/Emulator?


From milov at cs.uwlax.edu  Wed Jan  7 05:38:28 2015
From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=)
Date: Tue, 6 Jan 2015 13:38:28 -0600
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
Message-ID: <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>


On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote:

> On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote:
>> adding the list back
>> 
>> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
>> wrote:
>> 
>>> This is a cool development. Does this code build into a working version of
>>> Coherent or is this mainly useful to study? Either way, it should be
>>> interesting to look at the code for a clone specifically aimed at low-end
>>> hardware.
> 
> In the "distrib" directory there are four files exactly 1440 kb in size
> - maybe someone could try loading those into a VM/Emulator?

I had exactly that thought after I downloaded the tar ball this morning. Any suggestions for a VM config that would facilitate this would be welcome. Otherwise I’m going to stumble through virtual box and see what happens.

 - Milo




From dugo at xs4all.nl  Wed Jan  7 05:50:23 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Tue, 06 Jan 2015 20:50:23 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
 <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
Message-ID: <edcc1cca105482cbbe8569c2d30a335a@xs4all.nl>

On 2015-01-06 20:38, Milo Velimirović wrote:
> On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote:
> 
>> On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote:
>>> adding the list back
>>> 
>>> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
>>> wrote:
>>> 
>>>> This is a cool development. Does this code build into a working 
>>>> version of
>>>> Coherent or is this mainly useful to study? Either way, it should be
>>>> interesting to look at the code for a clone specifically aimed at 
>>>> low-end
>>>> hardware.
>> 
>> In the "distrib" directory there are four files exactly 1440 kb in 
>> size
>> - maybe someone could try loading those into a VM/Emulator?
> 
> I had exactly that thought after I downloaded the tar ball this
> morning. Any suggestions for a VM config that would facilitate this
> would be welcome. Otherwise I’m going to stumble through virtual box
> and see what happens.

A quick try with bochs bails out on me, but at least reveals the 
version:

     COHERENT Tertiary boot Version 1.2.7
     If installing COHERENT, please type "begin".
     ? begin
     Loading COHERENT.
     -
     Loading COHERENT data.
[-screen clears-]
     *** COHERENT Version 4.2.10 - 386 Mode.  5712KB free memory. ***
     Color.  NDP=387.  2528 buffers.  2521 buckets.  64 clists.
     256KB kalloc pool.  0 KB phys pool.
     Cyrix OEM CPU Detected
     Copyright 1982, 1994 Mark Williams Company
     fd0: <Door Open>
     PANIC : fsminit: no rootdev(4,15)
     Call backtrace:  -> ffc28142 -> ffc19129 -> ffc002b6

If you want to run COHERENT in a VM this is mandatory reading.

http://thebeezspeaks.blogspot.com/2012/02/my-life-with-coherent-part-1.html
http://thebeezspeaks.blogspot.nl/2012/05/my-life-with-coherent-part-2.html

/Jacob


From crossd at gmail.com  Wed Jan  7 05:52:33 2015
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Jan 2015 14:52:33 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
 <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
Message-ID: <CAEoi9W6jy129hkK1-1p+CUvwPQox+K_VsYea5gfnVdJCk+Uy2Q@mail.gmail.com>

On Tue, Jan 6, 2015 at 2:38 PM, Milo Velimirović <milov at cs.uwlax.edu> wrote:

> On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote:
> > In the "distrib" directory there are four files exactly 1440 kb in size
> > - maybe someone could try loading those into a VM/Emulator?
>
> I had exactly that thought after I downloaded the tar ball this morning.
> Any suggestions for a VM config that would facilitate this would be
> welcome. Otherwise I’m going to stumble through virtual box and see what
> happens.
>

Those look an awful lot like the distribution disks for COHERENT 4.2.10.
There's a writeup of how to get that installed and running under qemu here:
http://thebeezspeaks.blogspot.in/2012/05/my-life-with-coherent-part-2.html

However, there have been some reports of stability issues with the emulated
disk under qemu; VirtualBox seems to be the most consistently reliable (and
fast!) alternative, but you have to run it under a 32-bit host OS.  I ended
up installing a 32-bit Linux under VMWare to run virtual box to run
COHERENT (yes, it's awful).  I haven't tried qemu lately to see if the
stability problems have been addressed, though.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/85533037/attachment.html>

From milov at cs.uwlax.edu  Wed Jan  7 05:57:43 2015
From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=)
Date: Tue, 6 Jan 2015 13:57:43 -0600
Subject: [TUHS] pdp11 UNIX memory allocation. Was: termcap vs terminfo (was:
	I swear! I rtfm'ed)
In-Reply-To: <201501061222.t06CMvTO027313@freefriends.org>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
 <20150106004054.GD16715@mercury.ccil.org>
 <201501061222.t06CMvTO027313@freefriends.org>
Message-ID: <DBC71EB6-B41B-4257-A580-254C613D508E@cs.uwlax.edu>

Bringing a conversation back online.
On Jan 6, 2015, at 6:22 AM, arnold at skeeve.com wrote:

>> Peter Jeremy scripsit:
>>> But you pay for the size of $TERMCAP in every process you run.
> 
> John Cowan <cowan at mercury.ccil.org> wrote:
>> A single termcap line doesn't cost that much, less than a KB in most cases.
> 
> In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> have 32KB to start with.  (The discussion a few weeks ago about cutting
> yacc down to size comes to mind…)

(Or even earlier than ’81.) How did pdp11 UNIXes handle per process memory? It’s suggested above that there was a 50-50 split of the 64KB address space between instructions and data. My own recollection is that you got any combination of instruction and data space that was <64KB. This would also be subject to limits of pdp11 memory management unit.

Anyone have a definitive answer or pointer to appropriate man page or source code?


Thanks,
Milo



From clemc at ccc.com  Wed Jan  7 06:01:37 2015
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jan 2015 15:01:37 -0500
Subject: [TUHS] pdp11 UNIX memory allocation. Was: termcap vs terminfo
 (was: I swear! I rtfm'ed)
In-Reply-To: <DBC71EB6-B41B-4257-A580-254C613D508E@cs.uwlax.edu>
References: <B32459EF-55AE-4F6F-B2BC-1B80128F38F2@bsdimp.com>
 <3578.1420226008@cesium.clock.org>
 <20150105070613.GB10940@server.rulingia.com>
 <20150106004054.GD16715@mercury.ccil.org>
 <201501061222.t06CMvTO027313@freefriends.org>
 <DBC71EB6-B41B-4257-A580-254C613D508E@cs.uwlax.edu>
Message-ID: <CAC20D2Mck9X3XMw-9=RJA69wr6=yTf6Kyr3Gr9cx+F5Ajv+5vw@mail.gmail.com>

Depends the processor.   For the 11/45 class processors, you had a 17th
address bit, which was the I/D choice.  For the 11/40 class you shared the
instructions and data space.  So you had to use overlays and thunks at lot
sooner.

On Tue, Jan 6, 2015 at 2:57 PM, Milo Velimirović <milov at cs.uwlax.edu> wrote:

> Bringing a conversation back online.
> On Jan 6, 2015, at 6:22 AM, arnold at skeeve.com wrote:
>
> >> Peter Jeremy scripsit:
> >>> But you pay for the size of $TERMCAP in every process you run.
> >
> > John Cowan <cowan at mercury.ccil.org> wrote:
> >> A single termcap line doesn't cost that much, less than a KB in most
> cases.
> >
> > In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
> > have 32KB to start with.  (The discussion a few weeks ago about cutting
> > yacc down to size comes to mind…)
>
> (Or even earlier than ’81.) How did pdp11 UNIXes handle per process
> memory? It’s suggested above that there was a 50-50 split of the 64KB
> address space between instructions and data. My own recollection is that
> you got any combination of instruction and data space that was <64KB. This
> would also be subject to limits of pdp11 memory management unit.
>
> Anyone have a definitive answer or pointer to appropriate man page or
> source code?
>
>
> Thanks,
> Milo
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/82cc6713/attachment.html>

From bqt at update.uu.se  Wed Jan  7 06:20:36 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 06 Jan 2015 21:20:36 +0100
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
Message-ID: <54AC4394.3050302@update.uu.se>

On 2015-01-06 20:57, Milo Velimirovi?<milov at cs.uwlax.edu> wrote:
> Bringing a conversation back online.
> On Jan 6, 2015, at 6:22 AM,arnold at skeeve.com  wrote:
>
>>> >>Peter Jeremy scripsit:
>>>> >>>But you pay for the size of $TERMCAP in every process you run.
>> >
>> >John Cowan<cowan at mercury.ccil.org>  wrote:
>>> >>A single termcap line doesn't cost that much, less than a KB in most cases.
>> >
>> >In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only
>> >have 32KB to start with.  (The discussion a few weeks ago about cutting
>> >yacc down to size comes to mind?)
> (Or even earlier than ?81.) How did pdp11 UNIXes handle per process memory? It?s suggested above that there was a 50-50 split of the 64KB address space between instructions and data. My own recollection is that you got any combination of instruction and data space that was <64KB. This would also be subject to limits of pdp11 memory management unit.
>
> Anyone have a definitive answer or pointer to appropriate man page or source code?

You are conflating two things. :-)
A standard PDP-11 have 64Kb of virtual memory space. This can be divided 
any way you want between data and code.

Later model PDP-11 processors had a hardware feature called split I/D 
space. This meant that you could have one 64Kb virtual memory space for 
instructions, and one 64Kb virtual memory space for data.

(This also means that the text you quoted was incorrect, as it stated 
that you had 32Kb, which is incorrect. It was/is 32 Kword.)

	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 random832 at fastmail.us  Wed Jan  7 06:33:53 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Tue, 06 Jan 2015 15:33:53 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <54AC4394.3050302@update.uu.se>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
Message-ID: <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>

On Tue, Jan 6, 2015, at 15:20, Johnny Billquist wrote:
> Later model PDP-11 processors had a hardware feature called split I/D 
> space. This meant that you could have one 64Kb virtual memory space for 
> instructions, and one 64Kb virtual memory space for data.

Was it possible to read/write to the instruction space, or execute the
data space? From what I've seen, the calling convention for PDP-11 Unix
system calls read their arguments from directly after the trap
instruction (which would mean that the C wrappers for the system calls
would have to write their arguments there, even if assembly programs
could have them hardcoded.)


From mah at mhorton.net  Wed Jan  7 07:32:48 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Tue, 06 Jan 2015 13:32:48 -0800
Subject: [TUHS] termcap vs terminfo
Message-ID: <20150106133248.16223dcz4qtnm35s@webmail.mhorton.net>

Quoting Dan Cross <crossd at gmail.com>:

> On Tue, Jan 6, 2015 at 12:33 PM, Johnny Billquist <bqt at update.uu.se> wrote:
>
>> On 2015-01-06 17:56, Dan Cross wrote:
>>>
>>> I believe that Mary Ann is referring to repeatedly looking up
>>> (presumably different) elements in the entry.  Assuming that e.g. `vi`
>>> looks up O(n) elements, where $n$ is the number of elements, doing a
>>> linear scan for each, you'd end up with quadratic behavior.
>>>
>>
>> Assuming that you'd look up all the elements of the termcap entry at
>> startup, and did each one from scratch, yes.
>
>
> Yes.  Isn't that exactly what Mary Ann said was happening?  :-)

Yes

> But that would beg the question, why is vi doing a repeated scan of the
>> terminal entry at startup, if not to find all the capabilities and store
>> this somewhere? And if doing a look for all of them, why not scan the
>> string from start to finish and store the information as it is found? At
>> which point we move from quadratic to linear time.
>>
>
> I don't think she said it did things intelligently, just that that's how it
> did things.  :-)
>
> But now we're getting into the innards of vi, which I never looked at
> anyway, and I guess is less relevant in this thread anyway.

vi does indeed look up all the various capabilities it will need,
once, when it starts up.  It uses the documented interface, which
is tgetent followed by tgetstr/tgetnum/tgetflag for each capability.
tgetent did a linear search.

>> The short of it (from what I got out of it) is that the move from termcap
>> to terminfo was mostly motivated by attribute name changing away from fixed
>> 2 character names.
>>
>> A secondary motivation would be performance, but I don't really buy that
>> one. Since we only moved to terminfo on systems with plenty of memory,
>> performance of termcap could easily be on par anyway.
>>
>
> I tend to agree with you and I'll go one further: it seems that frequently
> we tend to identify a problem and then go to 11 with the "solution."  I can
> buy that termcap performance was an issue; I don't know that going directly
> to hashed terminfo files was the optimal solution.  A dbm file of termcap
> data and a hash table in whatever library parsed termcap would go a long
> way towards fixing the performance issues.  Did termcap have to be
> discarded just to add longer names?  I kind of tend to doubt it, but I
> wasn't there and don't know what the design criteria were, so my
> very-much-after-the-fact second guessing is just that.

It's been 30+ years, so the memory is a little fuzzy.  But as I recall,
I did measure the performance and that's how I discovered that the
quadratic algorithm was causing a big performance hit on the hardware
available at the time (I think I was on a VAX 11/750, this would have
been about 1982.)

I was making several improvements at the same time.  The biggest one
was rewriting curses to improve the screen update optimization, so it
would use insert/delete line/character on terminals supporting it.
Cleaning up the mess termcap had become (the format had become horrible
to update, and I was spending a lot of time making updates with all
the new terminals coming out) and improving startup time (curses also
had to read in a lot of attributes) were part of an overall cleanup.
IIRC, there may also have been some restrictions on parameters to string
capabilities that needed to be generalized.

Hashing could have been done differently, using DBM or some other method.
In fact, I'd used DBM to hash /etc/aliases in delivermail years earlier
(I have an amusing story about the worlds slowest email I'll tell some
other time) but at the time, it seemed best to break with termcap
and go with a cleaner format.



From ron at ronnatalie.com  Wed Jan  7 07:57:14 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 6 Jan 2015 16:57:14 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
Message-ID: <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>


> On Jan 6, 2015, at 3:33 PM, random832 at fastmail.us wrote:
> 
> Was it possible to read/write to the instruction space, or execute the
> data space? 

In split I/D mode (411) magic number.    It is imposible to execute in D space or use regular data access instructions to access i-space.   The addresses are in completely different spaces (i.e, 0 in data is mapped to different memory than 0 in instruction space).  Some access at the kernel level can be done with MFPI and MPFD instructions.

In write protected, non-split more (410 magic), you could read the I space and you could jump in to D space.   You were prohibited to write the i space.

In non protected mode (407 magic) everything was fair game.



From clemc at ccc.com  Wed Jan  7 07:58:30 2015
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jan 2015 16:58:30 -0500
Subject: [TUHS] Illumos )
In-Reply-To: <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
Message-ID: <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>

On Mon, Jan 5, 2015 at 12:04 PM, Jacob Ritorto <jacob.ritorto at gmail.com>
wrote:

> Bear in mind that unix didn't even have fsck for a decade after its
> release (it appeared after v7 released),


​That is actually not wholly true - although in practice you are probably
right.   The late Ted Kowalski starting writing fsck as an undergrad at
Michigan in about 1976 and then finished it up as a grad student at CMU in
1977 with a summer of work in between at BTL [if I have the dates right --
Armando I think you OYOC at the same time as Ted - is that about right].


BTW:  fsck was the program Ted introduced me to C, as I was BLISS hacker
before that. Anyway, all of that was done on 6th edition not 7th.   Fsck
was first released as part of Unix TS inside the labs and migrated
independently of any base distribution - although it was included as part
of BSD.   Ted has been Bill Joy's roommate at Michigan and I never knew how
UCB got it, but I'm guessing it was that connection because it was already
at UCB by the time I arrived.  I never knew for sure, but I think from a
legal standpoint it was assumed a CMU program, so BTL could not make claims
on it - since you right it was not part of V7 either.

Also, for those of you that never saw Unix before fsck or before the work
that Goble did at Purdue to get the write ordering down, you have no idea
what it was like to put a file system back together.   The sync;sync;sync
stuff was because of the lack write ordering; but even with that, small
file system corruptions where common.  fsck was a huge improvement.

Also in an earlier thread people we asking about small address space. One
of the issues Ted had to deal with early in the life of fsck was that the
size of a file system on something like the  RP06 was too large for the
data structures (just think the RP06 had a formatted capacity of less than
200 Mbytes and we partitioned them into smaller file systems).  So, some of
you will remember. that when fsck started up, it asked for a temp file
[which could be tricky if you were trying to fix the root file system].
In fact, one of the things I worked on was the code that allowed us the
deal with the temp file so we could swap those large structures in and out
memory and still work on and 11/40 without I/D space. If you look at the
early fsck code on Warren's site, I suspect you can find it - crude as it
may be -- it worked pretty well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/51eddbf0/attachment.html>

From clemc at ccc.com  Wed Jan  7 08:00:20 2015
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jan 2015 17:00:20 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
Message-ID: <CAC20D2M3s76LGqj77kH8bhmyUZ4E9b79iza45Q-O9m+CnJrwcQ@mail.gmail.com>

Right - that's how the kernel set up the page tables for the user processes.

On Tue, Jan 6, 2015 at 4:57 PM, Ronald Natalie <ron at ronnatalie.com> wrote:

>
> > On Jan 6, 2015, at 3:33 PM, random832 at fastmail.us wrote:
> >
> > Was it possible to read/write to the instruction space, or execute the
> > data space?
>
> In split I/D mode (411) magic number.    It is imposible to execute in D
> space or use regular data access instructions to access i-space.   The
> addresses are in completely different spaces (i.e, 0 in data is mapped to
> different memory than 0 in instruction space).  Some access at the kernel
> level can be done with MFPI and MPFD instructions.
>
> In write protected, non-split more (410 magic), you could read the I space
> and you could jump in to D space.   You were prohibited to write the i
> space.
>
> In non protected mode (407 magic) everything was fair game.
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/2c5538dc/attachment.html>

From ron at ronnatalie.com  Wed Jan  7 08:02:49 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 6 Jan 2015 17:02:49 -0500
Subject: [TUHS] pre-FSCK days
In-Reply-To: <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
Message-ID: <1CA66E3E-8596-460B-BF47-5D23A3E3211B@ronnatalie.com>

Yep I remember those days.    In order to get signed on to work in the UNIX computer center I had to demonstrate I knew the structure of the V6 filesystem and what icheck and dcheck reported, what the common errors were, and how to fix them.

Two things changed.   First FSCK was wriiten, but even to make that useful, some fixes were done to the ordering of operations in the kernel so that the file system wouldn’t be left in a degenerate state after crashes.    Before these changes were made inode link counts less than the number of directory links and dups in free were common.   After the changes to the FS, you’d get missing blocks and a few 0-0 inodes (or ones where the links count was higher than the links).    These while wasteful were not going to cause problems.



From ron at ronnatalie.com  Wed Jan  7 08:04:30 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 6 Jan 2015 17:04:30 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <CAC20D2M3s76LGqj77kH8bhmyUZ4E9b79iza45Q-O9m+CnJrwcQ@mail.gmail.com>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
 <CAC20D2M3s76LGqj77kH8bhmyUZ4E9b79iza45Q-O9m+CnJrwcQ@mail.gmail.com>
Message-ID: <B92F4B00-FDA8-4652-B602-8F06D1796195@ronnatalie.com>

And then of course there was the famous ISVTX bit (also known as the sticky or t bit).




From bqt at update.uu.se  Wed Jan  7 08:20:04 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Tue, 06 Jan 2015 23:20:04 +0100
Subject: [TUHS] pdp11 UNIX memory allocation
In-Reply-To: <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
References: <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
Message-ID: <54AC5F94.3080401@update.uu.se>

On 2015-01-06 22:59, random832 at fastmail.us wrote:
> On Tue, Jan 6, 2015, at 15:20, Johnny Billquist wrote:
>> >Later model PDP-11 processors had a hardware feature called split I/D
>> >space. This meant that you could have one 64Kb virtual memory space for
>> >instructions, and one 64Kb virtual memory space for data.
> Was it possible to read/write to the instruction space, or execute the
> data space? From what I've seen, the calling convention for PDP-11 Unix
> system calls read their arguments from directly after the trap
> instruction (which would mean that the C wrappers for the system calls
> would have to write their arguments there, even if assembly programs
> could have them hardcoded.)

Nope. A process cannot read or write to instruction space, nor can it 
execute from data space.
It's inherent in the MMU. All references related to the PC will be done 
from I-space, while everything else will be done through D-space.

So the MMU have two sets of page registers. One set maps I-space, and 
another maps D-space. Of course, you can have them overlap, in which 
case you get the traditional appearance of older models.

The versions of Unix I am aware of push arguments on the stack. But of 
course, the kernel can remap memory, and so can of course read the 
instruction space. But the user program itself would not be able to 
write anything after the trap instruction.

	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 random832 at fastmail.us  Wed Jan  7 08:36:31 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Tue, 06 Jan 2015 17:36:31 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <1420583703.863814.210431037.61D6C6EC@webmail.messagingengine.com>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <CAC20D2PP1hGyYsep1yNtj9KO55a-V02+QHS+S7bX-4joJy222g@mail.gmail.com>
 <1420583703.863814.210431037.61D6C6EC@webmail.messagingengine.com>
Message-ID: <1420583791.864424.210436089.64BFA544@webmail.messagingengine.com>

Apparently the message I was replying to was off-list, but it seems like
a waste to have typed all this out (including answering my own question)
and have it not go to the list.

On Tue, Jan 6, 2015, at 17:35, random832 at fastmail.us wrote:
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/factor.s
> wrchar:
> 	mov     r0,ch
> 	mov     $1,r0
> 	sys     write; ch; 1
> 	rts     r5
> 
> Though it looks like the C wrappers use the "indirect" system call which
> reads a "fake" trap instruction from the data segment. Looking at the
> implementation of that, my question is answered:
> 
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/trap.c
> 		if (callp == sysent) { /* indirect */
> 			a = (int *)fuiword((caddr_t)(a));
> 			pc++;
> 			i = fuword((caddr_t)a);
> 			a++;
> 			if ((i & ~077) != SYS)
> 				i = 077;        /* illegal */
> 			callp = &sysent[i&077];
> 			fetch = fuword;
> 		} else {
> 			pc += callp->sy_narg - callp->sy_nrarg;
> 			fetch = fuiword;
> 		}
> 
> http://minnie.tuhs.org/TUHS/Archive/PDP-11/Trees/V7/usr/man/man2/indir.2
> The main purpose of indir is to allow a program to
> store arguments in system calls and execute them
> out of line in the data segment.
> This preserves the purity of the text segment.
> 
> Note also the difference between V2 and V5 libc - clearly support for
> split I/D machines was added some time in this interval.
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/lib/write.s
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s4/write.s


From ron at ronnatalie.com  Wed Jan  7 08:36:46 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 6 Jan 2015 17:36:46 -0500
Subject: [TUHS] pdp11 UNIX memory allocation
In-Reply-To: <54AC5F94.3080401@update.uu.se>
References: <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
 <54AC5F94.3080401@update.uu.se>
Message-ID: <50E11A72-348F-4391-B444-33DD1B4ED1CC@ronnatalie.com>

Another quaint bit of history was when we made the jump to actually running the kernel in split-I/D mode.    My good friend Joe Pistritto wrote the JHU boot loader for that.   The 512-byte boot loader that was the standard UNIX one was used to load Joe’s split I/D booter.   It had a better support of the UNIX file system, but the question was how do you get from a non-split I/D program into the split I/D program.    Joe’s solution was rather clever.   He put an instruction that stored the processor status word with the new kernel mode at the top of the boot loader’s address space.    As he did the store the PC rolled over and now it was running at the new mode at location zero.

Years later I found that others had solved the problem by just setting up the kernel registers and executing a trap which switched the modes.    I always thought Joe’s solution was more elegant.   The kernel started the same way any other UNIX program would start.



From jnc at mercury.lcs.mit.edu  Wed Jan  7 08:45:44 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  6 Jan 2015 17:45:44 -0500 (EST)
Subject: [TUHS] pdp11 UNIX memory allocation.
Message-ID: <20150106224544.393BC18C091@mercury.lcs.mit.edu>

    > From: Clem Cole <clemc at ccc.com>

    > Depends the processor. For the 11/45 class processors, you had a 17th
    > address bit, which was the I/D choice. For the 11/40 class you shared
    > the instructions and data space.

To be exact, the 23, 24, 34, 35/40 and 60 all had a single shared space.
(I have no idea why DEC didn't put it in the 60 - probably helped kill that

otherwise intersting machine, with its UCS, early...). The 44, 45/50/55, 70,
73, 83/84, and 93/94 had split.


    > From: random832 at fastmail.us

    > the calling convention for PDP-11 Unix system calls read their
    > arguments from directly after the trap instruction (which would mean
    > that the C wrappers for the system calls would have to write their
    > arguments there, even if assembly programs could have them hardcoded.)

Here's the code for a typical 'wrapper' (this is V6, not sure if V7 changed
the trap stuff):

  _lseek:
	jsr	r5,csv
	mov	4(r5),r0
	mov	6(r5),0f
	mov	8(r5),0f+2
	mov	10.(r5),0f+4
	sys	indir; 9f
	bec	1f
	jmp	cerror
  1:
	jmp	cret

  .data
  9:
	sys	lseek; 0:..; ..; ..

Note the switch to data space for storing the arguments (at the 0: label
hidden in the line of data), and the 'indirect' system call.


    > From: Ronald Natalie <ron at ronnatalie.com>

    > Some access at the kernel level can be done with MFPI and MPFD
    > instructions.

Unless you hacked your hardware, in which case it was possible from user mode
too... :-)

I remember how freaked out we were when we tried to use MFPI to read
instruction space, and it didn't work, whereupon we consulted the 11/45
prints, only to discover that DEC had deliberately made it not work!


    > From: Ronald Natalie <ron at ronnatalie.com>

    > After the changes to the FS, you'd get missing blocks and a few 0-0
    > inodes (or ones where the links count was higher than the links). These
    > while wasteful were not going to cause problems.

It might be worth pointing out that due to the way pipes work, if a system
crashed with pipes open, even (especially!) with the disk perfectly sync'd,
you'll be left with 0-0 inodes. Although as you point out, those were merely
crud, not potential sourdes of file-rot.

	Noel


From clemc at ccc.com  Wed Jan  7 08:55:45 2015
From: clemc at ccc.com (Clem Cole)
Date: Tue, 6 Jan 2015 17:55:45 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <20150106224544.393BC18C091@mercury.lcs.mit.edu>
References: <20150106224544.393BC18C091@mercury.lcs.mit.edu>
Message-ID: <CAC20D2MaeiVZK7v4JuMkpz+8ZWZO_Hs3CCAoBWxQr7MzwQurhQ@mail.gmail.com>

On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I have no idea why DEC didn't put it in the 60 - probably helped kill that
> otherwise intersting machine, with its UCS, early...
>

​"Halt and confuse ucode" had a lot to do with it IMO.

FYI: The 60 set the record of going from production to "traditional
products" faster than​ anything else in DEC's history.     As I understand
it, the 11/60 was expected to a business system and run RSTS.  Why the WCS
was put in, I never understood, other than I expect the price of static RAM
had finally dropped and DEC was buying it in huge quantities for the
Vaxen.  The argument was that they could update the ucode cheaply in the
field (which to my knowledge the never did).   But I asked that question
many years ago to one of the HW manager, who explained to me that it was
felt separate I/D was not needed for the targeted market and would have
somehow increased cost.   I don't understand why it would have cost any
more but I guess it was late.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150106/dbeb090b/attachment.html>

From bqt at update.uu.se  Wed Jan  7 09:14:00 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 07 Jan 2015 00:14:00 +0100
Subject: [TUHS] pdp11 UNIX memory allocation
In-Reply-To: <50E11A72-348F-4391-B444-33DD1B4ED1CC@ronnatalie.com>
References: <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
 <54AC5F94.3080401@update.uu.se>
 <50E11A72-348F-4391-B444-33DD1B4ED1CC@ronnatalie.com>
Message-ID: <54AC6C38.8070904@update.uu.se>

On 2015-01-06 23:36, Ronald Natalie wrote:
> Another quaint bit of history was when we made the jump to actually running the kernel in split-I/D mode.    My good friend Joe Pistritto wrote the JHU boot loader for that.   The 512-byte boot loader that was the standard UNIX one was used to load Joe’s split I/D booter.   It had a better support of the UNIX file system, but the question was how do you get from a non-split I/D program into the split I/D program.    Joe’s solution was rather clever.   He put an instruction that stored the processor status word with the new kernel mode at the top of the boot loader’s address space.    As he did the store the PC rolled over and now it was running at the new mode at location zero.

??? Are you sure you remember that right?
The change from non split I/D to split I/D is not in the processor 
status word. Also, the last address of memory, before you enable the 
MMU, is actually the PSW. You can't have code there.

> Years later I found that others had solved the problem by just setting up the kernel registers and executing a trap which switched the modes.    I always thought Joe’s solution was more elegant.   The kernel started the same way any other UNIX program would start.

I'm probably missing a whole bunch of detail here, as I'm not fully 
following what was done.

Also, I fail to even spot the problem. Enabling split I/D space is just 
a bit in the MMU, but even after, you can have the same memory pages in 
both page tables, in essence making it a noop. Of course, being able to 
have data outside your code means you can have so much more code, in 
addition to more data, that you'd just would want to keep them split.
But that means just setting up the two page tables appropriately, load 
the memory as needed, and then enable the MMU and the split I/D, and 
you're done.

	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 bqt at update.uu.se  Wed Jan  7 09:34:06 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 07 Jan 2015 00:34:06 +0100
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <mailman.151.1420584979.3354.tuhs@minnie.tuhs.org>
References: <mailman.151.1420584979.3354.tuhs@minnie.tuhs.org>
Message-ID: <54AC70EE.4060301@update.uu.se>

On 2015-01-06 23:56, Clem Cole<clemc at ccc.com> wrote:
>
> On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa<jnc at mercury.lcs.mit.edu>
> wrote:
>
>> >I have no idea why DEC didn't put it in the 60 - probably helped kill that
>> >otherwise intersting machine, with its UCS, early...
>> >
> ?"Halt and confuse ucode" had a lot to do with it IMO.
>
> FYI: The 60 set the record of going from production to "traditional
> products" faster than? anything else in DEC's history.     As I understand
> it, the 11/60 was expected to a business system and run RSTS.  Why the WCS
> was put in, I never understood, other than I expect the price of static RAM
> had finally dropped and DEC was buying it in huge quantities for the
> Vaxen.  The argument was that they could update the ucode cheaply in the
> field (which to my knowledge the never did).   But I asked that question
> many years ago to one of the HW manager, who explained to me that it was
> felt separate I/D was not needed for the targeted market and would have
> somehow increased cost.   I don't understand why it would have cost any
> more but I guess it was late.

No, field upgrade of microcode can not have been it. The WCS for the 
11/60 was an option. Very few machines actually had it. It was for 
writing your own extra microcode as addition to the architecture.
The basic microcode for the machine was in ROM, just like on all the 
other PDP-11s. And DEC sold a compiler and other programs required to 
develop microcode for the 11/60. Not that I know of anyone who had them. 
I've "owned" four PDP-11/60 systems in my life. I still have a set of 
boards for the 11/60 CPU, but nothing else left around.

The 11/60 was, by the way, not the only PDP-11 with WCS. The 11/03 (if I 
remember right) also had such an option. Obviously the microcode was not 
compatible between the two machines, so you couldn't move it over from 
one to the other.

Also, reportedly, someone at DEC implemented a PDP-8 on the 11/60, 
making it the fastest PDP-8 ever manufactured. I probably have some 
notes about it somewhere, but I'd have to do some serious searching if I 
were to dig that up.

But yes, the 11/60 went from product to "traditional" extremely fast.

Split I/D space was one omission from the machine, but even more serious 
was the decision to only do 18-bit addressing on it. That killed it very 
fast.

Someone else mentioned the MFPI/MFPD instructions as a way of getting 
around the I/D restrictions. As far as I know (can tell), they are 
possible to use to read/write instruction space on a machine. I would 
assume that any OS would set both current and previous mode to user when 
executing in user space.
The documentation certainly claims they will work. I didn't think of 
those previously, but they would allow you to read/write to instruction 
space even when you have split I/D space enabled.

	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 scj at yaccman.com  Wed Jan  7 09:52:27 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Tue, 6 Jan 2015 15:52:27 -0800
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <54AC70EE.4060301@update.uu.se>
References: <mailman.151.1420584979.3354.tuhs@minnie.tuhs.org>
 <54AC70EE.4060301@update.uu.se>
Message-ID: <d67f4ebdc4c39b2be03b841cf9f96876.squirrel@webmail.yaccman.com>


>> ...Why the WCS was put in, I never understood, other than I expect
>> the price of static RAM had finally dropped and DEC was buying it
>> in huge quantities for the Vaxen...

The Interdata 8/32, Bell Labs' first 32-bit Unix port target, had writable
microcode.  It added a rather modest amount to the cost of the system as I
remember (about $8K).  Unfortunately, it was pretty useless.  The
instruction format, like many machines at the time, had opcodes and then
some of the instruction bits were use to get the operands -- register,
memory, offsets from registers, etc.  The operand handling was implemented
in hardware, and any added instructions could not use get to this operand
hardware.  So any new instructions that were added were pretty crippled.

Moreover, the implementation in microcode was flawed.  If you tried to
load a word through a pointer that had a -1 in it (a common error in
earlier Unices where -1 was an error return from the OS), you actually got
two faults--a memory bounds error and an alignment check.  Unfortunately,
these faults came at slightly different times--the alignment check
executed 2 or 3 micro instructions and then the bounds check arrived,
reset the microcode and lost all the status information.  Not only was the
fault unrecoverable but the only way to clear it was to power cycle the
processor!

A bunch of us went to talk to the manufacturer and said, in effect, "We
like your machine but we won't buy any more until this fault recovery
problem is fixed".  It was like talking to a bunch of cinder blocks --
they just didn't get it.  Shortly afterwards the VAX arrived and the rest
was history...



From dave at horsfall.org  Wed Jan  7 11:46:52 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Jan 2015 12:46:52 +1100 (EST)
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
Message-ID: <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>

On Tue, 6 Jan 2015, Ronald Natalie wrote:

> In non protected mode (407 magic) everything was fair game.

Which reminds me, I wonder how many people know that "407" was the 40's 
instruction that, if the a.out header was present, would neatly skip over 
it...

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From dave at horsfall.org  Wed Jan  7 11:53:46 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Jan 2015 12:53:46 +1100 (EST)
Subject: [TUHS] Illumos )
In-Reply-To: <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>

On Tue, 6 Jan 2015, Clem Cole wrote:

> Also, for those of you that never saw Unix before fsck or before the 
> work that Goble did at Purdue to get the write ordering down, you have 
> no idea what it was like to put a file system back together.

Somewhere, deep in Minnie's bowels, is the article I wrote, explaining 
exactly how to use icheck/ncheck/dcheck/clri etc.  I'm told it's saved the 
bacon of quite a few people (assuming it was savable at all).

> The sync;sync;sync stuff was because of the lack write ordering; but 
> even with that, small file system corruptions where common.

It was drilled into us that the correct usage was:

# sync
# sync
# sync

This gives the disk buffers time to actually flush (the writes were merely 
scheduled, and were asynchronous).

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From ron at ronnatalie.com  Wed Jan  7 12:00:02 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Tue, 6 Jan 2015 21:00:02 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
 <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>
Message-ID: <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com>

Yep, the only time this was ever trully useful was so you could put an a.out directly into the boot block I think.
During normal operations the a.out header was never actually loaded into the user memory.

> On Jan 6, 2015, at 8:46 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> On Tue, 6 Jan 2015, Ronald Natalie wrote:
> 
>> In non protected mode (407 magic) everything was fair game.
> 
> Which reminds me, I wonder how many people know that "407" was the 40's 
> instruction that, if the a.out header was present, would neatly skip over 
> it...



From jnc at mercury.lcs.mit.edu  Wed Jan  7 12:18:42 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Tue,  6 Jan 2015 21:18:42 -0500 (EST)
Subject: [TUHS] pdp11 UNIX memory allocation.
Message-ID: <20150107021842.2642418C09B@mercury.lcs.mit.edu>

    > From: Ronald Natalie <ron at ronnatalie.com>

    > Yep, the only time this was ever trully useful was so you could put an
    > a.out directly into the boot block I think.

Well, sort of. If you had non position-independent code, it would blow out
(it would be off by 020). Also, some bootstraps (e.g. the RL, IIRC) were so
close to 512. bytes long that the extra 020 was a problem. And it was so easy
to strip off:

   dd if=a.out of=fooboot bs=1 skip=16

I'm not sure that anything actually used the fact that 407 was 'br .+020', by
the V6 era; I think it was just left over from older Unixes (where it was not
in fact stripped on loading). Not just on executables running under Unix; the
boot-loader also stripped it, so it wasn't even necessary to strip the a.out
header off /unix.

	Noel


From cowan at mercury.ccil.org  Wed Jan  7 12:39:19 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 6 Jan 2015 21:39:19 -0500
Subject: [TUHS] pdp11 UNIX memory allocation
In-Reply-To: <54AC5F94.3080401@update.uu.se>
References: <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
 <54AC5F94.3080401@update.uu.se>
Message-ID: <20150107023919.GB16334@mercury.ccil.org>

Johnny Billquist scripsit:

> The versions of Unix I am aware of push arguments on the stack. 

Yes.  It was typical for HLLs not to use JSR Rn instructions (which you
need if you are going to pull arguments out of the instruction stream)
but rather JSR PC instructions.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Long-short-short, long-short-short / Dactyls in dimeter,
Verse form with choriambs / (Masculine rhyme):
One sentence (two stanzas) / Hexasyllabically
Challenges poets who / Don't have the time.     --robison who's at texas dot net


From bqt at update.uu.se  Wed Jan  7 12:59:56 2015
From: bqt at update.uu.se (Johnny Billquist)
Date: Wed, 07 Jan 2015 03:59:56 +0100
Subject: [TUHS] pdp11 UNIX memory allocation
In-Reply-To: <20150107023919.GB16334@mercury.ccil.org>
References: <mailman.149.1420581544.3354.tuhs@minnie.tuhs.org>
 <54AC5F94.3080401@update.uu.se> <20150107023919.GB16334@mercury.ccil.org>
Message-ID: <54ACA12C.5090806@update.uu.se>

On 2015-01-07 03:39, John Cowan wrote:
> Johnny Billquist scripsit:
>
>> The versions of Unix I am aware of push arguments on the stack.
>
> Yes.  It was typical for HLLs not to use JSR Rn instructions (which you
> need if you are going to pull arguments out of the instruction stream)
> but rather JSR PC instructions.

True. However, in this particular case, we were talking about system 
calls. But the versions of the code I was aware of were equally much 
pushing stuff on the stack for that case.

	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 dave at horsfall.org  Wed Jan  7 16:29:45 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Jan 2015 17:29:45 +1100 (EST)
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
 <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>
 <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com>
Message-ID: <alpine.BSF.2.11.1501071722340.58880@aneurin.horsfall.org>

On Tue, 6 Jan 2015, Ronald Natalie wrote:

> Yep, the only time this [the 407 magic number] was ever trully useful 
> was so you could put an a.out directly into the boot block I think.

But why would you include an a.out header in a boot block?  When you only 
had 512 bytes, every one of 'em counted, and I, oops, I mean others, had 
to resort to vile stuff such as self-modifying code...

> During normal operations the a.out header was never actually loaded into 
> the user memory.

I heard a story that on sufficiently-early Unices, the header was indeed 
loaded, hence the "407".

Any grey-beards here like to comment?

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From wkt at tuhs.org  Wed Jan  7 16:39:35 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 Jan 2015 17:39:35 +1100
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <alpine.BSF.2.11.1501071722340.58880@aneurin.horsfall.org>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
 <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>
 <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com>
 <alpine.BSF.2.11.1501071722340.58880@aneurin.horsfall.org>
Message-ID: <20150107063935.GA27943@www.oztivo.net>

On Wed, Jan 07, 2015 at 05:29:45PM +1100, Dave Horsfall wrote:
> I heard a story that on sufficiently-early Unices, the header was indeed 
> loaded, hence the "407".
> Any grey-beards here like to comment?

My beard isn't grey (yet), but here's the link to the 1st Edition code
which does exec(2):

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s

and here is the relevant code:

	mov	$14,u.count
	mov	$u.off,u.fofp
	clr	u.off / set offset in file to be read to zero
	jsr	r0,readi / read in first six words of user's file, starting 
			 / at $core
	mov	sp,r5 / put users stack address in r5
	sub	$core+40.,r5 / subtract $core +40, from r5 (leaves
			     / number of words less 26 available for
			     / program in user core
	mov	r5,u.count /
	cmp	core,$405 / br .+14 is first instruction if file is
			  / standard a.out format
	bne	1f / branch, if not standard format
	mov	core+2,r5 / put 2nd word of users program in r5; number of
			  / bytes in program text
	sub	$14,r5 / subtract 12
	cmp	r5,u.count /
	bgt	1f / branch if r5 greater than u.count
	mov	r5,u.count
	jsr	r0,readi / read in rest of user's program text
	add	core+10,u.nread / add size of user data area to u.nread
	br	2f
1:
	jsr	r0,readi / read in rest of file

My memory of PDP-11 assembly is too rusty to interpret this. Anybody else?

Cheers, Warren


From brantleycoile at me.com  Wed Jan  7 20:06:29 2015
From: brantleycoile at me.com (Brantley Coile)
Date: Wed, 07 Jan 2015 05:06:29 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <20150107063935.GA27943@www.oztivo.net>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
 <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>
 <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com>
 <alpine.BSF.2.11.1501071722340.58880@aneurin.horsfall.org>
 <20150107063935.GA27943@www.oztivo.net>
Message-ID: <A691340F-C0DF-49DF-A0AA-CEDACC637CBC@me.com>

It indeed executes the magic number.  The comment at the end of sysexec says it executes the code at $core, which has the twelve word header still in it.  Notice that the magic number is two less than the later formats; 0405 instead of 0407.  This most likely means that the header was still in the address space in later versions even after another two words were added to the header.

Brantley 



Sent from my iPad

> On Jan 7, 2015, at 1:39 AM, Warren Toomey <wkt at tuhs.org> wrote:
> 
>> On Wed, Jan 07, 2015 at 05:29:45PM +1100, Dave Horsfall wrote:
>> I heard a story that on sufficiently-early Unices, the header was indeed 
>> loaded, hence the "407".
>> Any grey-beards here like to comment?
> 
> My beard isn't grey (yet), but here's the link to the 1st Edition code
> which does exec(2):
> 
> http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s
> 
> and here is the relevant code:
> 
>    mov    $14,u.count
>    mov    $u.off,u.fofp
>    clr    u.off / set offset in file to be read to zero
>    jsr    r0,readi / read in first six words of user's file, starting 
>             / at $core
>    mov    sp,r5 / put users stack address in r5
>    sub    $core+40.,r5 / subtract $core +40, from r5 (leaves
>                 / number of words less 26 available for
>                 / program in user core
>    mov    r5,u.count /
>    cmp    core,$405 / br .+14 is first instruction if file is
>              / standard a.out format
>    bne    1f / branch, if not standard format
>    mov    core+2,r5 / put 2nd word of users program in r5; number of
>              / bytes in program text
>    sub    $14,r5 / subtract 12
>    cmp    r5,u.count /
>    bgt    1f / branch if r5 greater than u.count
>    mov    r5,u.count
>    jsr    r0,readi / read in rest of user's program text
>    add    core+10,u.nread / add size of user data area to u.nread
>    br    2f
> 1:
>    jsr    r0,readi / read in rest of file
> 
> My memory of PDP-11 assembly is too rusty to interpret this. Anybody else?
> 
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/7c83f212/attachment.html>

From jacob.ritorto at gmail.com  Wed Jan  7 23:29:11 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 7 Jan 2015 08:29:11 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <alpine.BSF.2.11.1501071722340.58880@aneurin.horsfall.org>
References: <mailman.147.1420574271.3354.tuhs@minnie.tuhs.org>
 <54AC4394.3050302@update.uu.se>
 <1420576433.410248.210385277.513EF8EC@webmail.messagingengine.com>
 <5E62DDAA-0055-46FB-8077-92DB856DEEE0@ronnatalie.com>
 <alpine.BSF.2.11.1501071244560.58880@aneurin.horsfall.org>
 <2509FDBD-67C4-4552-BB58-01281049DCB6@ronnatalie.com>
 <alpine.BSF.2.11.1501071722340.58880@aneurin.horsfall.org>
Message-ID: <CAHYQbfDEy1_BJGT9h6fYwUpgou4gAmiPRb112F1PYwvE28qRjQ@mail.gmail.com>

>
> But why would you include an a.out header in a boot block?  When you only
> had 512 bytes, every one of 'em counted, and I, oops, I mean others, had
> to resort to vile stuff such as self-modifying code...
>
>
Ooh, can we see annotated examples?  This is the really delicious stuff!


>
> I heard a story that on sufficiently-early Unices, the header was indeed
> loaded, hence the "407".
> Any grey-beards here like to comment?
>

+1 for hearing that and wanting to see annotated examples of it as well!

On Wed, Jan 7, 2015 at 1:29 AM, Dave Horsfall <dave at horsfall.org> wrote:

> On Tue, 6 Jan 2015, Ronald Natalie wrote:
>
> > Yep, the only time this [the 407 magic number] was ever trully useful
> > was so you could put an a.out directly into the boot block I think.
>
> But why would you include an a.out header in a boot block?  When you only
> had 512 bytes, every one of 'em counted, and I, oops, I mean others, had
> to resort to vile stuff such as self-modifying code...
>
> > During normal operations the a.out header was never actually loaded into
> > the user memory.
>
> I heard a story that on sufficiently-early Unices, the header was indeed
> loaded, hence the "407".
>
> Any grey-beards here like to comment?
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/295c1465/attachment.html>

From clemc at ccc.com  Thu Jan  8 02:14:48 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Jan 2015 11:14:48 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <54AC70EE.4060301@update.uu.se>
References: <mailman.151.1420584979.3354.tuhs@minnie.tuhs.org>
 <54AC70EE.4060301@update.uu.se>
Message-ID: <CAC20D2PRdyZCb6edmHbX1cTeuEcGZdjTo_TMzFzYVAv9UMegXQ@mail.gmail.com>

On Tue, Jan 6, 2015 at 6:34 PM, Johnny Billquist <bqt at update.uu.se> wrote:

> The basic microcode for the machine was in ROM, just like on all the other
> PDP-11s. And DEC sold a compiler and other programs required to develop
> microcode for the 11/60. Not that I know of anyone who had them. I've
> "owned" four PDP-11/60 systems in my life. I still have a set of boards for
> the 11/60 CPU, but nothing else left around.


I did not realized it was an option.  ​IIRC we had it on the Teklabs 11/60,
but we could not run the tools easily so we ended up never messing with it.
  We had talked about adding the CMU csav/cret instructs from the 11/40e
but we got the 11/70 and that sucked up my time and I never got back to try
it.

It was not a redux of the 11/34 BTW.  Jeff Mitchell did the 11/34 and was
off working on the 750 when the 60 was done.  I believe Al Pat was somehow
involved with 60, but I've forgotten.

As for the "halt and confuse uCode" stuff.  The 60 was notorious for
getting "stuck" when running UNIX.    I've now forgotten many of the
details, IIRC it had to with context switch, register save and I think I
remember it was something to do with multiple interrupts.   Since Glaser
and I did the original 11/60 port, I think we knew most of the USENIX UNIX
sites that run it on them since we swapped notes if not code.  All of us
used to complain about random hangs where the uCode take a jump and the
system would halt.    The only solution when that happened was the pull the
circuit breaker power on the back of the machine because the front panel
switched were lost.   I personally spend many hours with the DEC guys
trying to figure what is was, we could never repeat it.   Years later, when
I got to know some of the uCode engineers that had worked on the 11s and
the Vaxen, I found out it was agreed at DEC engineer there was a uCode bug,
but so few UNIX customer were out there (and the system had gone to
"traditional products") management dropped as not being worth finding and
fixing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/eb826931/attachment.html>

From clemc at ccc.com  Thu Jan  8 02:17:58 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Jan 2015 11:17:58 -0500
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <20150107021842.2642418C09B@mercury.lcs.mit.edu>
References: <20150107021842.2642418C09B@mercury.lcs.mit.edu>
Message-ID: <CAC20D2N3LVF9G5+N-SjLxJVeyqM=EBCZ9DWH4cUhMy9t8zPsDA@mail.gmail.com>

On Tue, Jan 6, 2015 at 9:18 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I'm not sure that anything actually used the fact that 407 was 'br .+020',
> by
> the V6 era; I think it was just left over from older Unixes (where it was
> not
> in fact stripped on loading). Not just on executables running under Unix;
> the
> boot-loader also stripped it, so it wasn't even necessary to strip the
> a.out
> header off /unix.
>

​If you look at the first edition code that Warren has, that seems to
support it.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/6356e917/attachment.html>

From clemc at ccc.com  Thu Jan  8 02:26:24 2015
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Jan 2015 11:26:24 -0500
Subject: [TUHS] Illumos )
In-Reply-To: <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
 <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>
Message-ID: <CAC20D2Oc5SKecCwOaNh-JugE7k_a=KrvoE2RC2hywhqObTQPKA@mail.gmail.com>

On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Somewhere, deep in Minnie's bowels, is the article I wrote, explaining
> exactly how to use icheck/ncheck/dcheck/clri etc.
>

​Shows I am old - it would fun to read that again.  I never saw the
article, I learned from doing it (wrong probably) a few times ;-)
Then Ted gives us fsck  . . .

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/35139e59/attachment.html>

From dave at horsfall.org  Thu Jan  8 03:27:33 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 8 Jan 2015 04:27:33 +1100 (EST)
Subject: [TUHS] pdp11 UNIX memory allocation.
In-Reply-To: <CAC20D2PRdyZCb6edmHbX1cTeuEcGZdjTo_TMzFzYVAv9UMegXQ@mail.gmail.com>
References: <mailman.151.1420584979.3354.tuhs@minnie.tuhs.org>
 <54AC70EE.4060301@update.uu.se>
 <CAC20D2PRdyZCb6edmHbX1cTeuEcGZdjTo_TMzFzYVAv9UMegXQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.11.1501080410400.58880@aneurin.horsfall.org>

On Wed, 7 Jan 2015, Clem Cole wrote:

> I did not realized it [WCS] was an option.  ​IIRC we had it on the 
> Teklabs 11/60, but we could not run the tools easily so we ended up 
> never messing with it.

Our 11/60 certainly had it; I remember scouring the manual, trying to make 
sense of it, but after five years studying at UNSW and eight years working 
there (almost got long service leave!) I got itchy feet.  Besides, 
although the CSU was a great place to work, I didn't like the plans to 
merge it with the Chancellery (the bureaucratic centre), lest I come to 
work one morning and find myself working on a COBOL program...

The provenance of the beast was that apparently a deal with some big 
publishing house fell through (Limited News, perhaps?) and DEC was stuck 
with a warehouse full of them; it seems the WCS was to be used for the 
typesetting or something, I dunno; they could always have yanked the WCS?

[...]

> The only solution when that happened was the pull the circuit breaker 
> power on the back of the machine because the front panel switched were 
> lost.

Don't all 11s have the same key?  I used to carry one on my key-ring.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)

From scj at yaccman.com  Thu Jan  8 04:32:57 2015
From: scj at yaccman.com (scj at yaccman.com)
Date: Wed, 7 Jan 2015 10:32:57 -0800
Subject: [TUHS] Illumos )
In-Reply-To: <CAC20D2Oc5SKecCwOaNh-JugE7k_a=KrvoE2RC2hywhqObTQPKA@mail.gmail.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
 <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>
 <CAC20D2Oc5SKecCwOaNh-JugE7k_a=KrvoE2RC2hywhqObTQPKA@mail.gmail.com>
Message-ID: <c9c1c85fcb3f806e1ceef97e2febcf1c.squirrel@webmail.yaccman.com>

My memories are somewhat fuzzy on this issue, but I vividly remember the
file corruptions.  The earliest Unix systems had a file format that
limited the size of a file to a size that proved to be too small.  So Ken
put in a "large file" format as well.  All files started out as small, but
as they grew they had to be rejiggered to become large files.  If the
system crashed while this rejiggering was going on, the file was toast.

The saving grace was that most of us were using model 33 or 37 teletypes,
so we had our edit history on paper.  When the system crashed, I picked up
a highlighter I kept next to the terminal, reeled in the paper that had
piled up behind the terminal, and highlighted the lines that would need to
be entered again.

One memorable day, I was working at home and the system crashed right
before lunch.  It was several hours before I could get back to the
terminal, and I discovered to my horror that our cat had mistaken the pile
of paper behind the terminal for her litter box.  Yes, I really did pick
up a highlighter and followed the usual plan, but I had to get another
color since the yellow didn't show up very well...

A later revision of the file system eliminated the small/large file
distinction, and disc corruptions became a rare event...

> On Tue, Jan 6, 2015 at 8:53 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>> Somewhere, deep in Minnie's bowels, is the article I wrote, explaining
>> exactly how to use icheck/ncheck/dcheck/clri etc.
>>
>
> âShows I am old - it would fun to read that again.  I never saw the
> article, I learned from doing it (wrong probably) a few times ;-)
> Then Ted gives us fsck  . . .
>
> Clem
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>




From andrzejpopielewicz at gmail.com  Thu Jan  8 05:36:58 2015
From: andrzejpopielewicz at gmail.com (Andrzej Popielewicz)
Date: Wed, 7 Jan 2015 20:36:58 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
Message-ID: <20150107193658.GA72@amu.edu.pl>

* Rico Pajarola <rp at servium.ch> [2015-01-06 11:48:55]:

> adding the list back
> 
> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com> wrote:
> 
> > This is a cool development. Does this code build into a working version of
> > Coherent or is this mainly useful to study? Either way, it should be
> > interesting to look at the code for a clone specifically aimed at low-end
> > hardware.
> >
> > Mike
> >

> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

Hi
This archive contains full sources for 4.2.10 and 4.2.12 .
And You can build working version of the system.
It contains also full installation media (4 floppy images).
So usually You will install the system and You can rebuild the system
using the sources.
It contains also sources of Coherent 3.x.
Andrzej


From andrzejpopielewicz at gmail.com  Thu Jan  8 05:40:25 2015
From: andrzejpopielewicz at gmail.com (Andrzej Popielewicz)
Date: Wed, 7 Jan 2015 20:40:25 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
Message-ID: <20150107194025.GB72@amu.edu.pl>

* Dan Cross <crossd at gmail.com> [2015-01-06 12:04:52]:

> On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola <rp at servium.ch> wrote:
> 
> > adding the list back
> >
> > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
> > wrote:
> >
> >> This is a cool development. Does this code build into a working version
> >> of Coherent or is this mainly useful to study? Either way, it should be
> >> interesting to look at the code for a clone specifically aimed at low-end
> >> hardware.
> >>
> > Unknown (to me, anyway).  Steve said he had intended to organize and
> catalog the code at some point, but that he hasn't gotten around to it (and
> not to hold one's breath).  I gathered that the tar ball he provided is a
> snapshot of (a subset of?) the MWC development disks at the time he was
> asked to create the archive.  To that end, I suspect that if one were
> sufficiently motivated one *could* use it to build a distribution of
> COHERENT, but I suspect you'd have to know quite a bit about their internal
> development practices and release processes to do so successfully;
> knowledge that may very well have been lost over time.  Perhaps some
> motivated person will be able to reverse engineer it, though I suspect it's
> more useful as a case study than as working code.
> 
>         - Dan C.

> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
Hi Dan,
What to You mean by building distribution. The archive contains original distribution 
of Coherent 4.2.10. Or You mean one could build quite new distribution ?
I mean, which would work on modern hardware ?
Andrzej 


From andrzejpopielewicz at gmail.com  Thu Jan  8 05:47:57 2015
From: andrzejpopielewicz at gmail.com (Andrzej Popielewicz)
Date: Wed, 7 Jan 2015 20:47:57 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
 <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com>
Message-ID: <20150107194757.GA95@amu.edu.pl>

* Warner Losh <imp at bsdimp.com> [2015-01-06 11:09:58]:

> 
> > On Jan 6, 2015, at 10:04 AM, Dan Cross <crossd at gmail.com> wrote:
> > 
> > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola <rp at servium.ch> wrote:
> > adding the list back
> > 
> > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com> wrote:
> > This is a cool development. Does this code build into a working version of Coherent or is this mainly useful to study? Either way, it should be interesting to look at the code for a clone specifically aimed at low-end hardware.
> > 
> > Unknown (to me, anyway).  Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath).  I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive.  To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time.  Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code.
> 
> Looking at the tarballs and the tarballs inside, this is a mess. It looks like it is all there, but there???s multiple copies of things that are almost identical, RCS files that are mostly enough, but not completely enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using a more modern compiler likely will result in ???difficulties???. There???s some docs laying around, but I haven???t read through them all. The collection needs curating TLC...
> 
> Warner
> 



> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
Hi,
They have used also gcc-2.5.6 , which is in TUHS archives , I believe.
I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. Almost 95% of kernel sources
compiles well with these newer compilers.
Andrzej



From jacob.ritorto at gmail.com  Thu Jan  8 04:59:18 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 7 Jan 2015 13:59:18 -0500
Subject: [TUHS] Misread on my part,
 or is there really a notable gcc port? Was: (Re: COHERENT sources
 released under 3-clause BSD license.)
Message-ID: <CAHYQbfB_qn67n+cFVq0jV3LeQp79Rw2Yq2EbONL2pW7XGmBe+g@mail.gmail.com>

Andrzej wrote:
>
> I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x.
>

Ported them to what?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/17b33981/attachment.html>

From mjkerpan at kerpan.com  Thu Jan  8 05:02:22 2015
From: mjkerpan at kerpan.com (Michael Kerpan)
Date: Wed, 7 Jan 2015 14:02:22 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150107194757.GA95@amu.edu.pl>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
 <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com>
 <20150107194757.GA95@amu.edu.pl>
Message-ID: <CAHfSdrUXSYnw9f_EcaZaeUFaPBcQrfaNKzT=+me6=cACHr7H4g@mail.gmail.com>

My main interest is actually in pre-386 code. I'd love to see how a
Unix-like system could be made to work on an 8086 or a 286. Did any of that
code survive to the 4.2 era or were things 32-bit only by that point?

Mike
On Jan 7, 2015 1:46 PM, "Andrzej Popielewicz" <andrzejpopielewicz at gmail.com>
wrote:

> * Warner Losh <imp at bsdimp.com> [2015-01-06 11:09:58]:
>
> >
> > > On Jan 6, 2015, at 10:04 AM, Dan Cross <crossd at gmail.com> wrote:
> > >
> > > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola <rp at servium.ch> wrote:
> > > adding the list back
> > >
> > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
> wrote:
> > > This is a cool development. Does this code build into a working
> version of Coherent or is this mainly useful to study? Either way, it
> should be interesting to look at the code for a clone specifically aimed at
> low-end hardware.
> > >
> > > Unknown (to me, anyway).  Steve said he had intended to organize and
> catalog the code at some point, but that he hasn't gotten around to it (and
> not to hold one's breath).  I gathered that the tar ball he provided is a
> snapshot of (a subset of?) the MWC development disks at the time he was
> asked to create the archive.  To that end, I suspect that if one were
> sufficiently motivated one *could* use it to build a distribution of
> COHERENT, but I suspect you'd have to know quite a bit about their internal
> development practices and release processes to do so successfully;
> knowledge that may very well have been lost over time.  Perhaps some
> motivated person will be able to reverse engineer it, though I suspect it's
> more useful as a case study than as working code.
> >
> > Looking at the tarballs and the tarballs inside, this is a mess. It
> looks like it is all there, but there???s multiple copies of things that
> are almost identical, RCS files that are mostly enough, but not completely
> enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using
> a more modern compiler likely will result in ???difficulties???. There???s
> some docs laying around, but I haven???t read through them all. The
> collection needs curating TLC...
> >
> > Warner
> >
>
>
>
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> Hi,
> They have used also gcc-2.5.6 , which is in TUHS archives , I believe.
> I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. Almost 95% of kernel
> sources
> compiles well with these newer compilers.
> Andrzej
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/1570083c/attachment.html>

From root at amu.edu.pl  Thu Jan  8 06:17:50 2015
From: root at amu.edu.pl (Andrzej Popielewicz)
Date: Wed, 7 Jan 2015 21:17:50 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <edcc1cca105482cbbe8569c2d30a335a@xs4all.nl>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
 <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
 <edcc1cca105482cbbe8569c2d30a335a@xs4all.nl>
Message-ID: <20150107201750.GA149@amu.edu.pl>

* Jacob Goense <dugo at xs4all.nl> [2015-01-06 20:50:23]:

> On 2015-01-06 20:38, Milo Velimirović wrote:
> >On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote:
> >
> >>On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote:
> >>>adding the list back
> >>>
> >>>On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
> >>>wrote:
> >>>
> >>>>This is a cool development. Does this code build into a working
> >>>>version of
> >>>>Coherent or is this mainly useful to study? Either way, it should be
> >>>>interesting to look at the code for a clone specifically aimed at
> >>>>low-end
> >>>>hardware.
> >>
> >>In the "distrib" directory there are four files exactly 1440 kb in size
> >>- maybe someone could try loading those into a VM/Emulator?
> >
> >I had exactly that thought after I downloaded the tar ball this
> >morning. Any suggestions for a VM config that would facilitate this
> >would be welcome. Otherwise I???m going to stumble through virtual box
> >and see what happens.
> 
> A quick try with bochs bails out on me, but at least reveals the version:
> 
>     COHERENT Tertiary boot Version 1.2.7
>     If installing COHERENT, please type "begin".
>     ? begin
>     Loading COHERENT.
>     -
>     Loading COHERENT data.
> [-screen clears-]
>     *** COHERENT Version 4.2.10 - 386 Mode.  5712KB free memory. ***
>     Color.  NDP=387.  2528 buffers.  2521 buckets.  64 clists.
>     256KB kalloc pool.  0 KB phys pool.
>     Cyrix OEM CPU Detected
>     Copyright 1982, 1994 Mark Williams Company
>     fd0: <Door Open>
>     PANIC : fsminit: no rootdev(4,15)
>     Call backtrace:  -> ffc28142 -> ffc19129 -> ffc002b6
> 
> If you want to run COHERENT in a VM this is mandatory reading.
> 
> http://thebeezspeaks.blogspot.com/2012/02/my-life-with-coherent-part-1.html
> http://thebeezspeaks.blogspot.nl/2012/05/my-life-with-coherent-part-2.html
> 
> /Jacob
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

You have to inform the emulator that You are booting from floppy.
The message no rootdev(4,15) means no floppy there (4 major 15 minor number).
Installator awaits media on the floppy.
But I had tested only virtual box.
Andrzej


From root at amu.edu.pl  Thu Jan  8 06:03:51 2015
From: root at amu.edu.pl (Andrzej Popielewicz)
Date: Wed, 7 Jan 2015 21:03:51 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
Message-ID: <20150107200351.GA126@amu.edu.pl>

* Rico Pajarola <rp at servium.ch> [2015-01-06 11:48:55]:

> adding the list back
> 
> On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com> wrote:
> 
> > This is a cool development. Does this code build into a working version of
> > Coherent or is this mainly useful to study? Either way, it should be
> > interesting to look at the code for a clone specifically aimed at low-end
> > hardware.
> >
> > Mike
> >

> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
Hi
Yes. You can build 4.2.10 or 4.2.14 kernel from sources.
Usually You will install using full distribution media for 4.2.10 and then
rebuild using the full sources, distribution media are of course 
in the archive.

Andrzej


From imp at bsdimp.com  Thu Jan  8 07:19:04 2015
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 7 Jan 2015 14:19:04 -0700
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <CAHfSdrUXSYnw9f_EcaZaeUFaPBcQrfaNKzT=+me6=cACHr7H4g@mail.gmail.com>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
 <63B244BE-7BB0-4E7F-A589-8CD4B9FF42AF@bsdimp.com>
 <20150107194757.GA95@amu.edu.pl>
 <CAHfSdrUXSYnw9f_EcaZaeUFaPBcQrfaNKzT=+me6=cACHr7H4g@mail.gmail.com>
Message-ID: <501A725C-A616-42A8-A017-12B9B5417E14@bsdimp.com>

There’s a PS2 kernel directory in one of the files. This is a 3.x based kernel and runs on 286. There are some vestiges of 8086, but I don’t know how well it will work. It looked fairly incomplete to me…

Warner

> On Jan 7, 2015, at 12:02 PM, Michael Kerpan <mjkerpan at kerpan.com> wrote:
> 
> My main interest is actually in pre-386 code. I'd love to see how a Unix-like system could be made to work on an 8086 or a 286. Did any of that code survive to the 4.2 era or were things 32-bit only by that point?
> 
> Mike
> 
> On Jan 7, 2015 1:46 PM, "Andrzej Popielewicz" <andrzejpopielewicz at gmail.com> wrote:
> * Warner Losh <imp at bsdimp.com> [2015-01-06 11:09:58]:
> 
> >
> > > On Jan 6, 2015, at 10:04 AM, Dan Cross <crossd at gmail.com> wrote:
> > >
> > > On Tue, Jan 6, 2015 at 11:48 AM, Rico Pajarola <rp at servium.ch> wrote:
> > > adding the list back
> > >
> > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com> wrote:
> > > This is a cool development. Does this code build into a working version of Coherent or is this mainly useful to study? Either way, it should be interesting to look at the code for a clone specifically aimed at low-end hardware.
> > >
> > > Unknown (to me, anyway).  Steve said he had intended to organize and catalog the code at some point, but that he hasn't gotten around to it (and not to hold one's breath).  I gathered that the tar ball he provided is a snapshot of (a subset of?) the MWC development disks at the time he was asked to create the archive.  To that end, I suspect that if one were sufficiently motivated one *could* use it to build a distribution of COHERENT, but I suspect you'd have to know quite a bit about their internal development practices and release processes to do so successfully; knowledge that may very well have been lost over time.  Perhaps some motivated person will be able to reverse engineer it, though I suspect it's more useful as a case study than as working code.
> >
> > Looking at the tarballs and the tarballs inside, this is a mess. It looks like it is all there, but there???s multiple copies of things that are almost identical, RCS files that are mostly enough, but not completely enough, etc. Plus they were using gcc 2.5.1 for compiling things, so using a more modern compiler likely will result in ???difficulties???. There???s some docs laying around, but I haven???t read through them all. The collection needs curating TLC...
> >
> > Warner
> >
> 
> 
> 
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> Hi,
> They have used also gcc-2.5.6 , which is in TUHS archives , I believe.
> I have ported gcc-2.8.1,2.95.3,3.2.3 and 4.2.x. Almost 95% of kernel sources
> compiles well with these newer compilers.
> Andrzej
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/244b6f7b/attachment.sig>

From dugo at xs4all.nl  Thu Jan  8 08:19:18 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Wed, 07 Jan 2015 23:19:18 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150107201750.GA149@amu.edu.pl>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
 <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
 <edcc1cca105482cbbe8569c2d30a335a@xs4all.nl>
 <20150107201750.GA149@amu.edu.pl>
Message-ID: <5cccba3c85f63674843f21371a147639@xs4all.nl>

On 2015-01-07 21:17, Andrzej Popielewicz wrote:
> * Jacob Goense <dugo at xs4all.nl> [2015-01-06 20:50:23]:
>> A quick try with bochs bails out on me, but at least reveals the 
>> version:
>> 
>>     COHERENT Tertiary boot Version 1.2.7
>>     If installing COHERENT, please type "begin".
>>     ? begin
>>     Loading COHERENT.
>>     -
>>     Loading COHERENT data.
>> [-screen clears-]
>>     *** COHERENT Version 4.2.10 - 386 Mode.  5712KB free memory. ***
>>     Color.  NDP=387.  2528 buffers.  2521 buckets.  64 clists.
>>     256KB kalloc pool.  0 KB phys pool.
>>     Cyrix OEM CPU Detected
>>     Copyright 1982, 1994 Mark Williams Company
>>     fd0: <Door Open>
>>     PANIC : fsminit: no rootdev(4,15)
>>     Call backtrace:  -> ffc28142 -> ffc19129 -> ffc002b6
> 
> You have to inform the emulator that You are booting from floppy.
> The message no rootdev(4,15) means no floppy there (4 major 15 minor 
> number).
> Installator awaits media on the floppy.
> But I had tested only virtual box.

That's exactly what I thought I did in the bochs config.

     floppya: 1_44=d1, status=inserted
     boot: floppy

The bochs floppy drive and the Coherent #1 disk never wanted to dance.
The last time I tried before was with bochs-2.4.2 and with bochs-2.6.7
I still get the dreaded <Door Open> message.

If you know the magic incantation to get it past that in bochs, please
let me know.

Meanwhile it installs and seems to run like a charm in qemu-2.2.0.

/Jacob


From crossd at gmail.com  Thu Jan  8 13:22:33 2015
From: crossd at gmail.com (Dan Cross)
Date: Wed, 7 Jan 2015 22:22:33 -0500
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150107194025.GB72@amu.edu.pl>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <CAEoi9W4DxADcQst87WOEVecY-V+GGievnL7Vp-Jbf1GFJoz4kA@mail.gmail.com>
 <20150107194025.GB72@amu.edu.pl>
Message-ID: <CAEoi9W6k12BjbrExSVLZvzAPVV5HFszsPaGn4mMpgAHbdpJe=w@mail.gmail.com>

On Wed, Jan 7, 2015 at 2:40 PM, Andrzej Popielewicz <
andrzejpopielewicz at gmail.com> wrote:
> > > On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com
> wrote:
> > > This is a cool development. Does this code build into a working
version
> > > of Coherent or is this mainly useful to study? Either way, it should
be
> > > interesting to look at the code for a clone specifically aimed at
low-end
> > > hardware.
> >
> > Unknown (to me, anyway).  Steve said he had intended to organize and
> > catalog the code at some point, but that he hasn't gotten around to it
(and
> > not to hold one's breath).  I gathered that the tar ball he provided is
a
> > snapshot of (a subset of?) the MWC development disks at the time he was
> > asked to create the archive.  To that end, I suspect that if one were
> > sufficiently motivated one *could* use it to build a distribution of
> > COHERENT, but I suspect you'd have to know quite a bit about their
internal
> > development practices and release processes to do so successfully;
> > knowledge that may very well have been lost over time.  Perhaps some
> > motivated person will be able to reverse engineer it, though I suspect
it's
> > more useful as a case study than as working code.
>
> Hi Dan,
> What to You mean by building distribution. The archive contains original
distribution
> of Coherent 4.2.10. Or You mean one could build quite new distribution ?
> I mean, which would work on modern hardware ?

To a first order approximation, I meant regenerating the installation media
from source.

You would certainly know more than I would about it; if you say it can be
done, I believe you.  :-)  I don't know how to go about it, though (I
assume it involves typing more than one command, but I could well be wrong).

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150107/0e26d142/attachment.html>

From mparson at bl.org  Fri Jan  9 09:11:17 2015
From: mparson at bl.org (Michael Parson)
Date: Thu, 8 Jan 2015 17:11:17 -0600 (CST)
Subject: [TUHS] VAX faxing?
In-Reply-To: <alpine.BSF.2.11.1501051530130.58880@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1501050446570.58880@aneurin.horsfall.org>
 <19446.1420413351@cesium.clock.org>
 <alpine.BSF.2.11.1501051530130.58880@aneurin.horsfall.org>
Message-ID: <alpine.NEB.2.11.1501081710250.20490@neener.bl.org>

On Mon, 5 Jan 2015, Dave Horsfall wrote:
> On Sun, 4 Jan 2015, Erik E. Fair wrote:
>
>> It amazes and annoys me to this day how many PDFs purported to be
>> "electronic documents" are merely pictures of paper. Not only am I
>> missing my 2000's-era personal jetpack, I'm still waiting for my fully
>> paperless office.
>
> Right after we get the paperless toilet...

You don't know how to use the 3 clam shells?

-- 
Michael Parson
Austin, TX
KF5LGQ


From cubexyz at gmail.com  Fri Jan  9 14:59:21 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Thu, 8 Jan 2015 23:59:21 -0500
Subject: [TUHS] single user mode in v5 & v6
Message-ID: <CADxT5N6DpT35NDNa=0ez2+9thHaJyYk4+FKOshGMFJFy9E7jwg@mail.gmail.com>

Ok, I've finally managed to get Unix v5 and v6 to go into single user
mode while running under simh.

I boot up unix as normal, that is to say in multi-user mode.
Then a ctrl-e and

dep system sr 173030 (simh command)

then c to continue execution of the operating system and finally "kill -1 1".

This gets me from multi user mode to single user mode. I can also go
back to multi user mode with:

ctrl-e and dep system sr 000000

then once again c to continue execution of the operating system and "kill -1 1".

Now I'm in muti user mode, and I can telnet in as another user so it
seems to be working but then if I do a "ps -alx" I get:

TTY F S UID   PID PRI ADDR  SZ  WCHAN COMMAND
?:  3 S   0     0-100 1227   2   5676 ????
?:  1 W   0     1  40 1324   6   5740 -
8:  1 W   0    51  40 2456  19   5766 -
?:  1 W   0    55  10 1377   6  42066 -
?:  1 W   0     5  90 1734   5   5440 /etc/update
?:  1 W   0    32  10 2001   6  42126 -
?:  1 W   0    33  10 2054   6  42166 -
?:  1 W   0    34  10 2127   6  42226 -
?:  1 W   0    35  10 2202   6  42266 -
?:  1 W   0    36  10 2255   6  42326 -
?:  1 W   0    37  10 2330   6  42366 -
?:  1 W   0    38  10 2403   6  42426 -
8:  1 R   0    59 104 1472  17        ps alx

The ps command doesn't show the /etc/init process explicitly, although
I'm pretty sure it is running. I'm not sure if unix of the v6 or v5
era was designed to go from multi user to single user mode and then
back again. Would it be safer to just go to single user and then shut
it down?

Mark


From jnc at mercury.lcs.mit.edu  Fri Jan  9 16:18:48 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  9 Jan 2015 01:18:48 -0500 (EST)
Subject: [TUHS] single user mode in v5 & v6
Message-ID: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>

    > From: Mark Longridge <cubexyz at gmail.com>

    > I've finally managed to get Unix v5 and v6 to go into single user mode
    > while running under simh.
    > ...
    > dep system sr 173030 (simh command)

Just out of curiousity, why don't you set the SR before you boot the machine?
That way it'll come up single user, and you can icheck/dcheck before you go
to multi-user mode. I prefer doing it that way, there's as little as possible
going on, in case the disk is slightly 'confused', so less chance any bit-rot
will spread...

    > Now I'm in muti user mode .. but then if I do a "ps -alx" I get:
    >
    > TTY F S UID   PID PRI ADDR  SZ  WCHAN COMMAND
    > ?:  3 S   0     0-100 1227   2   5676 ????
    > ?:  1 W   0     1  40 1324   6   5740 -

    > The ps command doesn't show the /etc/init process explicitly, although
    > I'm pretty sure it is running.

No, it's there: the second line (PID 1). For some reason, the code for
/etc/init (in V6 at least, I don't know anything about V5) bashes the command
line so it just has '-' in it, so it looks just like a shell.

I fixed my copy so it says "/etc/init", or something like that. The machine
my source is on is powered down at the moment; if you want, I can upload the
'fixed' code tomorrow.

    > I'm not sure if unix of the v6 or v5 era was designed to go from multi
    > user to single user mode and then back again.

I seem to recall there's some issue, something like in some cases there's an
extra shell left running attached to the console, but I don't recall the
details (too lazy to look for the note I made about the bug; I can look it up
if you really want to know).

    > Would it be safer to just go to single user and then shut it down?

I don't usually bother; I just log out all the shells except the one on the
console, so the machine is basically idle; then do a 'sync', and shortly
after than completes, I just halt the machine.

	Noel


From jrvalverde at cnb.csic.es  Fri Jan  9 19:23:21 2015
From: jrvalverde at cnb.csic.es (Jose R. Valverde)
Date: Fri, 9 Jan 2015 10:23:21 +0100
Subject: [TUHS] Illumos )
In-Reply-To: <389F2E19-7E08-4294-914E-49EE2641B118@tfeb.org>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org>
 <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <389F2E19-7E08-4294-914E-49EE2641B118@tfeb.org>
Message-ID: <20150109102321.1987ec37@cnb.csic.es>

On all of this discussion I mostly miss the word of old age and experience. 
Probably because the downing of the Bazaar came to crystallize the old
wisdom.

Let me explain: it is true that a cathedral is very well engineered. But it
is no less true that after any long experiece, it is but a glorified version 
of the humble bazaar shop.

When you start building and designing a cathedral you do it considering the
materials, tools and knowledge that you have at hand at the time. But times,
they are a'changin. And sooner or later the cathedral will not be fit for
your needs and you will need to build another. The life cycle may be longer,
or not, but it is still the same. You must throw away the design and start
a-new from scratch sooner or later.

To continue the analogy. I was often puzzled by ancient megalythic monuments.
I recently visited a multi-dolmen site. They transpire an evolution from the 
cave in a mountain to huge stones making up an artificial mountain and cave,
to smaller megalyths, to pyrammids, to probably smaller stone temples,
possibly to the brick and mortar ziggurats of the early bronze age... with
the obvious return to stone in the Classic to Neoclassic period and back to
brick and mortar today... 

At any rate, caves probably became inconvenient in the Neolythic when hunters
became farmers in the plains and they had to "reinvent" them. The Bronze Age
allowed reducing the size of the megalyths. The Iron Age allowed making regular
stones... and so on.

In the end, you start with Unix and one day you need to add unforeseen technology
such as VM, so you redesign and rebuild it. Then you need plug-and-play, so you
redesign and rebuild it. Then you want support for zillions of devices and need
to separate/modularize the kernel from device drivers, and redesign and rebuild
it to a micro-kernel-like system, and then you want to have zillions of hackers
or developers, and you need to redesign/rebuild it, and then you want isolation
and redesign it to have jails/VMs/whatever, and so on.

So, pray, what is the difference? For anything we build, we will have to re-design
and rebuild it sooner or later, because it no longer satisfies our needs or 
because new, better, more modern tools and needs come into existence. The life
cycle may be millenia, centuries, decades, years, months or weeks, but you
can never foresee all future needs, you will always have to re-design and 
re-build. You will always be "building", be it complex cathedrals of chaotic
bazaars. In the end they are both the same.

It is not the Cathedral versus the Bazaar. It is all about building for your
needs.

In the Classic times of the Roman monuments, every household also had its own
lair, shrine, for the family "good ancestors" which remained as gods (lares). 
You need both, the Cathedral and the Bazaar at all  times. A good mason, a good 
architect or a good IT professional understands of "building", and should not 
need to care whether his assignment is a temple or a shrine.

IMMHO

				j
-- 
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es


From jrvalverde at cnb.csic.es  Fri Jan  9 19:50:05 2015
From: jrvalverde at cnb.csic.es (Jose R. Valverde)
Date: Fri, 9 Jan 2015 10:50:05 +0100
Subject: [TUHS] COHERENT sources released under 3-clause BSD license.
In-Reply-To: <20150107201750.GA149@amu.edu.pl>
References: <201501061341.t06Dfbsh025288@coolidge.cs.dartmouth.edu>
 <CACwAiQ=AA35tMY0Jh1pOxbBxCW_9R2+naFgMuPg1rpfRRucYnw@mail.gmail.com>
 <CAHfSdrUT3VWQnezocJmM02v3-Syx4N7i+8mjwbggYW4ejwvc7A@mail.gmail.com>
 <CACwAiQkePc2ueFNMMMj=gxxRd7uk-MmYg9VKxE18Xc0RLPZhLA@mail.gmail.com>
 <1420569674.381164.210321493.7C9C5223@webmail.messagingengine.com>
 <2BE827F7-5498-4D7A-90B9-1228BBBEB950@cs.uwlax.edu>
 <edcc1cca105482cbbe8569c2d30a335a@xs4all.nl>
 <20150107201750.GA149@amu.edu.pl>
Message-ID: <20150109105005.36b72d1b@cnb.csic.es>

What Andrzej fails to mention is that for quite a long time, Coherent has been
maintained alive by a reduced groups of enthusiasts gathered around him and
comp.os.coherent and that a binary distribution was also available thanks to
a great extent to his devoted work (he was one of the few who had permission 
to).

I have mentioned on occasion that I remember the code being left loose under
a permissive license sometime around the end of the '90s, and I got a copy 
then, but -sadly- didn't keep the original message with the license (I was 
switching jobs or house or both or traveling or something).

Anyway, the available binary distro can be run on Qemu reasonably well. I think
I was the first to succeed running it on 2008 on Qemu 0.9.1.

In any case, I would like to publicly thank Adrzej for all the work he has been
doing all these years to keep Coherent alive.

				j



On Wed, 7 Jan 2015 21:17:50 +0100
Andrzej Popielewicz <root at amu.edu.pl> wrote:
> * Jacob Goense <dugo at xs4all.nl> [2015-01-06 20:50:23]:
> 
> > On 2015-01-06 20:38, Milo Velimirović wrote:
> > >On Jan 6, 2015, at 12:41 PM, random832 at fastmail.us wrote:
> > >
> > >>On Tue, Jan 6, 2015, at 11:48, Rico Pajarola wrote:
> > >>>adding the list back
> > >>>
> > >>>On Tue, Jan 6, 2015 at 10:42 AM, Michael Kerpan <mjkerpan at kerpan.com>
> > >>>wrote:
> > >>>
> > >>>>This is a cool development. Does this code build into a working
> > >>>>version of
> > >>>>Coherent or is this mainly useful to study? Either way, it should be
> > >>>>interesting to look at the code for a clone specifically aimed at
> > >>>>low-end
> > >>>>hardware.
> > >>
> > >>In the "distrib" directory there are four files exactly 1440 kb in size
> > >>- maybe someone could try loading those into a VM/Emulator?
> > >
> > >I had exactly that thought after I downloaded the tar ball this
> > >morning. Any suggestions for a VM config that would facilitate this
> > >would be welcome. Otherwise I???m going to stumble through virtual box
> > >and see what happens.
> > 
> > A quick try with bochs bails out on me, but at least reveals the version:
> > 
> >     COHERENT Tertiary boot Version 1.2.7
> >     If installing COHERENT, please type "begin".
> >     ? begin
> >     Loading COHERENT.
> >     -
> >     Loading COHERENT data.
> > [-screen clears-]
> >     *** COHERENT Version 4.2.10 - 386 Mode.  5712KB free memory. ***
> >     Color.  NDP=387.  2528 buffers.  2521 buckets.  64 clists.
> >     256KB kalloc pool.  0 KB phys pool.
> >     Cyrix OEM CPU Detected
> >     Copyright 1982, 1994 Mark Williams Company
> >     fd0: <Door Open>
> >     PANIC : fsminit: no rootdev(4,15)
> >     Call backtrace:  -> ffc28142 -> ffc19129 -> ffc002b6
> > 
> > If you want to run COHERENT in a VM this is mandatory reading.
> > 
> > http://thebeezspeaks.blogspot.com/2012/02/my-life-with-coherent-part-1.html
> > http://thebeezspeaks.blogspot.nl/2012/05/my-life-with-coherent-part-2.html
> > 
> > /Jacob
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> You have to inform the emulator that You are booting from floppy.
> The message no rootdev(4,15) means no floppy there (4 major 15 minor number).
> Installator awaits media on the floppy.
> But I had tested only virtual box.
> Andrzej
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


-- 
		Scientific Computing Service
	Solving all your computer needs for Scientific
			Research.

		http://bioportal.cnb.csic.es


From ron at ronnatalie.com  Sat Jan 10 00:23:00 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 9 Jan 2015 09:23:00 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
Message-ID: <ED116F20-2907-4F14-AB55-77CD8B46A784@ronnatalie.com>

If I recall, our V6 system would go from singe user to multiuser when you logged out of the single user shell (our init checked the switch register to determine whether to bring up single or multiuser).    I believe our system shutdown if you kill -1-1 (HUP to init).   V7 would revert to single user at that point.


I think the init 
> On Jan 9, 2015, at 1:18 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
>> From: Mark Longridge <cubexyz at gmail.com>
> 
>> I've finally managed to get Unix v5 and v6 to go into single user mode
>> while running under simh.
>> ...
>> dep system sr 173030 (simh command)
> 
> Just out of curiousity, why don't you set the SR before you boot the machine?
> That way it'll come up single user, and you can icheck/dcheck before you go
> to multi-user mode. I prefer doing it that way, there's as little as possible
> going on, in case the disk is slightly 'confused', so less chance any bit-rot
> will spread...
> 
>> Now I'm in muti user mode .. but then if I do a "ps -alx" I get:
>> 
>> TTY F S UID   PID PRI ADDR  SZ  WCHAN COMMAND
>> ?:  3 S   0     0-100 1227   2   5676 ????
>> ?:  1 W   0     1  40 1324   6   5740 -
> 
>> The ps command doesn't show the /etc/init process explicitly, although
>> I'm pretty sure it is running.
> 
> No, it's there: the second line (PID 1). For some reason, the code for
> /etc/init (in V6 at least, I don't know anything about V5) bashes the command
> line so it just has '-' in it, so it looks just like a shell.
> 
> I fixed my copy so it says "/etc/init", or something like that. The machine
> my source is on is powered down at the moment; if you want, I can upload the
> 'fixed' code tomorrow.
> 
>> I'm not sure if unix of the v6 or v5 era was designed to go from multi
>> user to single user mode and then back again.
> 
> I seem to recall there's some issue, something like in some cases there's an
> extra shell left running attached to the console, but I don't recall the
> details (too lazy to look for the note I made about the bug; I can look it up
> if you really want to know).
> 
>> Would it be safer to just go to single user and then shut it down?
> 
> I don't usually bother; I just log out all the shells except the one on the
> console, so the machine is basically idle; then do a 'sync', and shortly
> after than completes, I just halt the machine.
> 
> 	Noel
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From clemc at ccc.com  Sat Jan 10 00:36:10 2015
From: clemc at ccc.com (Clem Cole)
Date: Fri, 9 Jan 2015 09:36:10 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
Message-ID: <CAC20D2NZL5LanOFEFiNa+a4Mb9GAhpwk9jGgVheh4QE90dKnWg@mail.gmail.com>

On Fri, Jan 9, 2015 at 1:18 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> Just out of curiousity, why don't you set the SR before you boot the
> machine?
> That way it'll come up single user, and you can icheck/dcheck before you go
> to multi-user mode. I prefer doing it that way, there's as little as
> possible
> going on, in case the disk is slightly 'confused', so less chance any
> bit-rot
> will spread...
>

​Right and it's probably worth digging up the v6 version of fsck.  I had it
on tape but I worry that it might be 800 bpi which I have lost the ability
to read.  I need to find a working TS08.

Also remember for early UNIX, ps "knew" about some kernel data structures
and had to compiled with the same sources that your kernel used if you want
all the command field in particular to look reasonable.

I've forgotten when that got fixed, my memory is that V7 still had vestiges
of that issue i.e. it was not until post 4.1BSD that got ps got more
independant.   That said, until V8 and /proc that user mode utilities like
that got really cleaned up.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150109/4bd6c022/attachment.html>

From clemc at ccc.com  Sat Jan 10 00:36:51 2015
From: clemc at ccc.com (Clem Cole)
Date: Fri, 9 Jan 2015 09:36:51 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <ED116F20-2907-4F14-AB55-77CD8B46A784@ronnatalie.com>
References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
 <ED116F20-2907-4F14-AB55-77CD8B46A784@ronnatalie.com>
Message-ID: <CAC20D2N0vjQepbh_ZgEC6iWRVF+-MSPD8xGXQc7MPW1kxWuebQ@mail.gmail.com>

On Fri, Jan 9, 2015 at 9:23 AM, Ronald Natalie <ron at ronnatalie.com> wrote:

> If I recall, our V6 system would go from singe user to multiuser when you
> logged out of the single user shell (our init checked the switch register
> to determine whether to bring up single or multiuser).


That is the behavior I remember, also.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150109/cc60ee14/attachment.html>

From ron at ronnatalie.com  Sat Jan 10 00:44:19 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 9 Jan 2015 09:44:19 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <CAC20D2NZL5LanOFEFiNa+a4Mb9GAhpwk9jGgVheh4QE90dKnWg@mail.gmail.com>
References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
 <CAC20D2NZL5LanOFEFiNa+a4Mb9GAhpwk9jGgVheh4QE90dKnWg@mail.gmail.com>
Message-ID: <E070ADE7-C23B-4641-A2BD-4E0FF7567C82@ronnatalie.com>

If I recall, PS read /dev/kmem to get the proc structure which was a table of all the active processes.
The user structure of the currently running process is the only one that is guaranteed to be in memory (the others could be paged out)
and at least on our system was always located at 0140000.    Any processes that were swapped you could read the user structure
so things that were stored there were often unavailable (particularly the command name).   Yeah, so ps had intimate knowledge of the
layout of the kernel user and proc structures.

We moved a short version of the command name into the proc structure for reason.   We added a new TTY special character ^T
(borrowed that from the KA-10 guys) to do a brief listing of the processes controlled by the current terminal from within the kernel. (Mike Muuss did this while he was playing with scheduler hacking).

> 
> 
> Also remember for early UNIX, ps "knew" about some kernel data structures and had to compiled with the same sources that your kernel used if you want all the command field in particular to look reasonable.
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150109/4fccbb2b/attachment.html>

From clemc at ccc.com  Sat Jan 10 02:52:42 2015
From: clemc at ccc.com (Clem cole)
Date: Fri, 9 Jan 2015 11:52:42 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <E070ADE7-C23B-4641-A2BD-4E0FF7567C82@ronnatalie.com>
References: <20150109061848.94B1918C0CC@mercury.lcs.mit.edu>
 <CAC20D2NZL5LanOFEFiNa+a4Mb9GAhpwk9jGgVheh4QE90dKnWg@mail.gmail.com>
 <E070ADE7-C23B-4641-A2BD-4E0FF7567C82@ronnatalie.com>
Message-ID: <DA7CBC18-635C-48E4-B2AE-46655E4CDDBC@ccc.com>

Right.  We did some similar stuff at CMU.  One other hack we had was science compiled ps with the kernel IIRC we had a table of sleep addresses so that ps could print the actual thing you were waiting for not just an address.  I think that was a Dan Klein hack. 


Yeah the ^T hack was implemented a number of times.  Masscomp is the only product kernel that I knew supported it.  I did miss it for a long time 

Clem

Sent from my iPhone

> On Jan 9, 2015, at 9:44 AM, Ronald Natalie <ron at ronnatalie.com> wrote:
> 
> If I recall, PS read /dev/kmem to get the proc structure which was a table of all the active processes.
> The user structure of the currently running process is the only one that is guaranteed to be in memory (the others could be paged out)
> and at least on our system was always located at 0140000.    Any processes that were swapped you could read the user structure
> so things that were stored there were often unavailable (particularly the command name).   Yeah, so ps had intimate knowledge of the
> layout of the kernel user and proc structures.
> 
> We moved a short version of the command name into the proc structure for reason.   We added a new TTY special character ^T
> (borrowed that from the KA-10 guys) to do a brief listing of the processes controlled by the current terminal from within the kernel. (Mike Muuss did this while he was playing with scheduler hacking).
> 
>> 
>> 
>> Also remember for early UNIX, ps "knew" about some kernel data structures and had to compiled with the same sources that your kernel used if you want all the command field in particular to look reasonable.
>> 
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150109/d67079f7/attachment.html>

From jnc at mercury.lcs.mit.edu  Sat Jan 10 04:06:07 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  9 Jan 2015 13:06:07 -0500 (EST)
Subject: [TUHS] single user mode in v5 & v6
Message-ID: <20150109180607.E198918C0CE@mercury.lcs.mit.edu>

    > From: Noel Chiappa

    > For some reason, the code for /etc/init .. bashes the command line so
    > it just has '-' in it, so it looks just like a shell.

BTW, that may be accidental, not a deliberate choice - e.g. someone copied
another line of code which exec'd a shell, and didn't change the second arg.

    > I fixed my copy so it says "/etc/init", or something like that. ... I
    > can upload the 'fixed' code tomorrow.

The change is pretty minor: in this piece of code:

	case reboot:
		termall();
		execl(init, minus, 0);
		reset();

just change the execl() line to say:

		execl(init, init, 0);


    >> I'm not sure if unix of the v6 or v5 era was designed to go from multi
    >> user to single user mode and then back again.

    > I seem to recall there's some issue, something like in some cases
    > there's an extra shell left running attached to the console

So the bug is that in going from single-user to multi-user, by using "kill -1
1" in single-user with the switch register set for multi-user, it doesn't
kill the running single-user shell on the console. The workaround to that bug
which I use is to set the CSWR and then ^D the running shell.

In general, the code in init.c isn't quite as clean/clear as would be optimal
(which is part of why I haven't tried to fix the above bug), but _in general_
it does support going back and forth.


    > From: Ronald Natalie

    > our init checked the switch register to determine whether to bring up
    > single or multiuser

I think that's standard from Bell, actually.

    > I believe our system shutdown if you kill -1-1 (HUP to init).

The 'stock' behaviour is that when that happens, it checks the switch
register, and there are three options (the code is a little hard to follow,
but I'm pretty sure this is right):

- if it's set for single-user, it shuts down all the other children, and
brings up a console shell; when done, it does the next
- if it's set for 'reboot', it just shuts down all children, and restarts
the init process (presumably so one can switch to a new version of the init
without restarting the whole machine);
- if it's not set for either, it re-reads /etc/ttys, and for any lines which
have switched state in that file, it starts/kills the process listening to
that line (this allows one to add/drop lines dynamically).


    > From: Clem Cole

    > it's probably worth digging up the v6 version of fsck.

That's on that MIT V6 tape, too. Speaking of which, time to write the code to
grok the tape...

	Noel


From jnc at mercury.lcs.mit.edu  Sat Jan 10 04:38:45 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri,  9 Jan 2015 13:38:45 -0500 (EST)
Subject: [TUHS] single user mode in v5 & v6
Message-ID: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu>

    > From: Clem Cole

    > ps "knew" about some kernel data structures and had to compiled with
    > the same sources that your kernel used if you want all the command
    > field in particular to look reasonable.

Not just the command field!

The real problem was that all the parameters (e.g. NPROC) were not stored in
the kernel anywhere, so if you wanted to have one copy of the 'ps' binary
which would work on two different machines (but which were running the same
version of the kernel)... rotsa ruck.

I have hacked my V6 to include lines like:

  int     ninode  NINODE;
  int     nfile   NFILE;
  int     nproc   NPROC;

etc so 'ps' can just read those variables to find the table sizes in the
running kernel. (Obviously if you modify a table format, then you're SOL.)


    > From: Ronald Natalie

    > The user structure of the currently running process is the only one
    > that is guaranteed to be in memory ... Any processes that were swapped
    > you could read the user structure so things that were stored there were
    > often unavailable (particularly the command name). 

Well, 'ps' (even the V6 stock version) was actually prepared to poke around
on the swap device to look at the images of swapped-out processes. And the
command name didn't come from the U area (it wasn't saved there in stock V6),
'ps' actually had to look on the top of the user stack (which is why it
wasn't guaranteed to be accurate - the user process could smash that).


    > From: Clem cole

    > IIRC we had a table of sleep addresses so that ps could print the
    > actual thing you were waiting for not just an address. 

I've hacked my copy of 'ps' to grovel around in the system's symbol table,
and print 'wchan' symbolically. E.g. here's some of the output of 'ps' on
my system:

 TTY  F  S UID   PID  PPID PRI NIC CPU TIM ADDR  SZ  TXT   WCHAN       COMMAND
 ?:   SL S   0     0     0-100   0  -1 127 1676   16    runout         <swapper>
 ?:    L W   0     1     0  40   0   0 127 1774   43  0 proc+26        /etc/init
 ?:    L W   0    11     1  90   0   0 127 2405   37    tout           /etc/update
 8:    L W   0    12     1  10   0   0 127 2772   72  2 kl11           -
 a:    L W   0    13     1  40   0   0 127 3122   72  2 proc+102       -
 a:    L R   0    22    13 100   0  10   0 3422  138  3                ps axl
 b:    L W   0    14     1  10   0   0 127 2120   41  1 dz11+40        - 4

It's pretty easy to interpret this to see what each process is waiting for.

	Noel


From dave at horsfall.org  Sat Jan 10 04:59:08 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 10 Jan 2015 05:59:08 +1100 (EST)
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <20150109180607.E198918C0CE@mercury.lcs.mit.edu>
References: <20150109180607.E198918C0CE@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.11.1501100555340.91430@aneurin.horsfall.org>

On Fri, 9 Jan 2015, Noel Chiappa wrote:

>     > For some reason, the code for /etc/init .. bashes the command line 
>     > so it just has '-' in it, so it looks just like a shell.
> 
> BTW, that may be accidental, not a deliberate choice - e.g. someone 
> copied another line of code which exec'd a shell, and didn't change the 
> second arg.

I have a vague recollection of patching "ps" so that process 0 showed as 
"unix" or something, as otherwise it was just random rubbish.

>     > our init checked the switch register to determine whether to bring 
>     > up single or multiuser
> 
> I think that's standard from Bell, actually.

Yes.

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From clemc at ccc.com  Sat Jan 10 06:54:36 2015
From: clemc at ccc.com (Clem Cole)
Date: Fri, 9 Jan 2015 15:54:36 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu>
References: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu>
Message-ID: <CAC20D2PR_9zg92n4E3qFDdvesc8rcpiaCcUAO4Ecn=7nUv1Okg@mail.gmail.com>

On Fri, Jan 9, 2015 at 1:38 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
> Not just the command field!
>
​right...
​


>
> The real problem was that all the parameters (e.g. NPROC) were not stored
> in
> the kernel anywhere, so if you wanted to have one copy of the 'ps' binary
> which would work on two different machines (but which were running the same
> version of the kernel)... rotsa ruck.
>
​Yup, I remember that ...​





>
>
>
> I've hacked my copy of 'ps' to grovel around in the system's symbol table,
> and print 'wchan' symbolically.

​right - that look pretty much what it looked like on our systems.  Great
minds run on the same channel.

Clem​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150109/bb9c8767/attachment.html>

From ron at ronnatalie.com  Sat Jan 10 06:57:33 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 9 Jan 2015 15:57:33 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <CAC20D2PR_9zg92n4E3qFDdvesc8rcpiaCcUAO4Ecn=7nUv1Okg@mail.gmail.com>
References: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu>
 <CAC20D2PR_9zg92n4E3qFDdvesc8rcpiaCcUAO4Ecn=7nUv1Okg@mail.gmail.com>
Message-ID: <E55DB434-1792-4C4E-A72F-608F4EA27825@ronnatalie.com>

The symbol table was commonly used, but that was not so good if you didn't boot from /unix.



From clemc at ccc.com  Sat Jan 10 07:18:23 2015
From: clemc at ccc.com (Clem Cole)
Date: Fri, 9 Jan 2015 16:18:23 -0500
Subject: [TUHS] single user mode in v5 & v6
In-Reply-To: <E55DB434-1792-4C4E-A72F-608F4EA27825@ronnatalie.com>
References: <20150109183845.05AEB18C0CE@mercury.lcs.mit.edu>
 <CAC20D2PR_9zg92n4E3qFDdvesc8rcpiaCcUAO4Ecn=7nUv1Okg@mail.gmail.com>
 <E55DB434-1792-4C4E-A72F-608F4EA27825@ronnatalie.com>
Message-ID: <CAC20D2NfGdiJzaS+c0V+co6HUKhgoLxRDxF586bF9Cc42LxjpQ@mail.gmail.com>

On Fri, Jan 9, 2015 at 3:57 PM, Ronald Natalie <ron at ronnatalie.com> wrote:

> The symbol table was commonly used, but that was not so good if you didn't
> boot from /unix.
>
> IIRC that we stuffed the pathname that we booted with somewhere, so that
ps could find it.   All of this is very hazy now, too many different UNIX
systems and different hacks over the years ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150109/bca03ce0/attachment.html>

From cubexyz at gmail.com  Sat Jan 10 12:20:22 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Fri, 9 Jan 2015 21:20:22 -0500
Subject: [TUHS] Early Unix file system checks
Message-ID: <CADxT5N5KH-kOzpFWxc7_c6Yxuo3BCnuXrHHqPWPtL0+NN8XSEQ@mail.gmail.com>

> Noel Chiappa:
> Just out of curiousity, why don't you set the SR before you boot the machine?
> That way it'll come up single user, and you can icheck/dcheck before you go
> to multi-user mode. I prefer doing it that way, there's as little as possible
> going on, in case the disk is slightly 'confused', so less chance any bit-rot
> will spread...

I actually do file system checks on v5 as it's the early unix I use the most:

check -l /dev/rk0
check -u /dev/rk0

same for rk1, rk2.

The v5 manual entry for check references the 'restor' command,
although the man page for that is missing.

Your idea of starting up in single user mode is a good one although
I'm not sure if it's necessary to check the file system on each boot
up. I've been running this disk image of v5 for about two years and no
blow-ups as yet. I also keep various snapshots of v5, v6 and v7 disk
images for safety reasons.

And there are text files of all the source code changes I've made, so
if disaster strikes I can redo it all.

Mark


From cubexyz at gmail.com  Sat Jan 10 13:01:30 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Fri, 9 Jan 2015 22:01:30 -0500
Subject: [TUHS] Fixed Unix v5 bug!
Message-ID: <CADxT5N6AwWNjyAxmZ4Dp0PrUn3pLRsuVv5mJb+8acFmzQkUosQ@mail.gmail.com>

> Noel Chiappa
> The change is pretty minor: in this piece of code:
>
>        case reboot:
>              termall();
>              execl(init, minus, 0);
>              reset();
>
> just change the execl() line to say:
>
>                execl(init, init, 0);

I patched init in v5 and now ps shows /etc/init as expected, even
after going from multi to single to multi mode.

Looks like init.c was the same in v5 and v6.


From david at kdbarto.org  Sun Jan 11 08:15:39 2015
From: david at kdbarto.org (David Barto)
Date: Sat, 10 Jan 2015 14:15:39 -0800
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
Message-ID: <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>

<much discussion about quadratic search removed>

All I remember (and still support to this day) is that I’ve got a TERMCAP=‘string’ in my login scripts to set termcap to the specific terminal I’m logging in with.

Long ago this made things much faster. Today I think that it is just a holdover that I’m not changing due to inertia, rather than any real need for it.

	David
— 
	David Barto
	david at kdbarto.org



From lyndon at orthanc.ca  Sun Jan 11 08:43:53 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 10 Jan 2015 14:43:53 -0800
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
Message-ID: <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>

On Jan 10, 2015, at 2:15 PM, David Barto <david at kdbarto.org> wrote:

> All I remember (and still support to this day) is that I’ve got a TERMCAP=‘string’ in my login scripts to set termcap to the specific terminal I’m logging in with.
> 
> Long ago this made things much faster. Today I think that it is just a holdover that I’m not changing due to inertia, rather than any real need for it.

There is still a need for this.

Most modern curses capability entries for 'xterm' and friends use the memory buffer windowing capability (a term I made up) such that when you - say - run less to display a file, it switches to a dedicated region in the terminal memory buffer while printing its output, then restores the buffer to back where you were to begin with when you exit the pager.

This drives me insane!  When I 'man foo' and find the relevant bits in the document, when I quit out of the pager I want those bits to stay on the screen so I can refer to them, dammit!  There are two shortcuts to this, both involving custom termcap/terminfo entries.

In the termcap case, you can define a $TERMCAP capability that describes an 'xterm' without the memory buffer hopping.  In the terminfo case, you tic(1) your custom 'xterm' definition into $HOME/.terminfo/...

These days - naturally - everyone knows the universe exists inside an ANSI terminal window, so who gives a fsck about term{cap.info}?  Well, I do, for this very reason.  A pox on everyone who has not 'setenv TERM aaa-48-s' !!!

--lyndon

P.S.  Terminfo entry attached for your enjoyment. (It's a text/plain. I have no idea what the hell Apple's Mail.app will do with it.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: xterm.terminfo
Type: application/octet-stream
Size: 1339 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/582ebbd1/attachment.obj>
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/582ebbd1/attachment.sig>

From lyndon at orthanc.ca  Sun Jan 11 08:51:00 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 10 Jan 2015 14:51:00 -0800
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
Message-ID: <EB8BB8D6-E9A6-4907-8A1B-77E117471A0E@orthanc.ca>


On Jan 10, 2015, at 2:43 PM, Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> Most modern curses capability entries for 'xterm' and friends use the memory buffer windowing capability (a term I made up)

Umm ... I meant 'just made up' as in "I can't think of a better name this second."  I'm pretty sure somebody else invented memory buffers and sliding pointers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/b0b8aa7b/attachment.sig>

From chneukirchen at gmail.com  Sun Jan 11 09:02:50 2015
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Sun, 11 Jan 2015 00:02:50 +0100
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca> (Lyndon
 Nerenberg's message of "Sat, 10 Jan 2015 14:43:53 -0800")
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
Message-ID: <87iogegrxh.fsf@gmail.com>

Lyndon Nerenberg <lyndon at orthanc.ca> writes:

> On Jan 10, 2015, at 2:15 PM, David Barto <david at kdbarto.org> wrote:
>
>> All I remember (and still support to this day) is that I’ve got a
>> TERMCAP=‘string’ in my login scripts to set termcap to the specific
>> terminal I’m logging in with.
>> 
>> Long ago this made things much faster. Today I think that it is just
>> a holdover that I’m not changing due to inertia, rather than any
>> real need for it.
>
> There is still a need for this.
>
> Most modern curses capability entries for 'xterm' and friends use the
> memory buffer windowing capability (a term I made up) such that when
> you - say - run less to display a file, it switches to a dedicated
> region in the terminal memory buffer while printing its output, then
> restores the buffer to back where you were to begin with when you exit
> the pager.
>
> This drives me insane!  When I 'man foo' and find the relevant bits in
> the document, when I quit out of the pager I want those bits to stay
> on the screen so I can refer to them, dammit!  There are two shortcuts
> to this, both involving custom termcap/terminfo entries.

Or just use: xterm -xrm '*titeInhibit: true'
Just for less: export LESS="-X"
Just for vim: set t_ti= t_te=

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org


From lyndon at orthanc.ca  Sun Jan 11 09:04:28 2015
From: lyndon at orthanc.ca (Lyndon Nerenberg)
Date: Sat, 10 Jan 2015 15:04:28 -0800
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <87iogegrxh.fsf@gmail.com>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca> <87iogegrxh.fsf@gmail.com>
Message-ID: <E15113DD-72B3-4C19-9E53-DA906B107EF4@orthanc.ca>


On Jan 10, 2015, at 3:02 PM, Christian Neukirchen <chneukirchen at gmail.com> wrote:

> Or just use: xterm -xrm '*titeInhibit: true'
> Just for less: export LESS="-X"
> Just for vim: set t_ti= t_te=

Please provide the list of workarounds for all other curses consumers used worldwide and forever.

Wouldn't it be nice if I could just do this in one place?  Oh, wait ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150110/525f7f9a/attachment.sig>

From dave at horsfall.org  Sun Jan 11 12:06:08 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 11 Jan 2015 13:06:08 +1100 (EST)
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
Message-ID: <alpine.BSF.2.11.1501111302010.97981@aneurin.horsfall.org>

On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:

> This drives me insane!  When I 'man foo' and find the relevant bits in 
> the document, when I quit out of the pager I want those bits to stay on 
> the screen so I can refer to them, dammit!  There are two shortcuts to 
> this, both involving custom termcap/terminfo entries.

I'm glad I'm not the only one annoyed by this "feature".

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From doug at cs.dartmouth.edu  Sun Jan 11 15:20:58 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 11 Jan 2015 00:20:58 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
Message-ID: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>

> when you - say - run less to display a file, it switches to a dedicated
> region in the terminal memory buffer while printing its output, then
> restores the buffer to back where you were to begin with when you exit
> the pager

Sorry for veering away from Unix history, but this pushed one of the hottest
of my buttons. Less is the epitome of modern Unix decadence. Besides the
maddening behavior described above, why, when all screens have a scroll bar,
should a pager do its own scrolling? But for a quantitative measure of
decadence, try less --help | wc. It takes excess to a level not dreamed of
in Pike's classic critique, "cat -v considered harmful".

Doug


From dds at aueb.gr  Sun Jan 11 19:16:21 2015
From: dds at aueb.gr (Diomidis Spinellis)
Date: Sun, 11 Jan 2015 11:16:21 +0200
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <alpine.BSF.2.11.1501111302010.97981@aneurin.horsfall.org>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
 <alpine.BSF.2.11.1501111302010.97981@aneurin.horsfall.org>
Message-ID: <54B23F65.2090104@aueb.gr>

On 11/01/2015 04:06, Dave Horsfall wrote:
> On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:
>
>> This drives me insane!  When I 'man foo' and find the relevant bits in
>> the document, when I quit out of the pager I want those bits to stay on
>> the screen so I can refer to them, dammit!  There are two shortcuts to
>> this, both involving custom termcap/terminfo entries.
>
> I'm glad I'm not the only one annoyed by this "feature".

I agree it's maddening!  This is what I have on my .bashrc file to avoid 
this behavior.

# Don't restore screen, quit at EOF, more-like prompt, pass color 
control chars
export LESS=-XEmR

This problem, and the desire to use the vi key bindings instead of the 
Emacs ones for command-line editing, are the reason I invested effort to 
place my login configuration under Git control, and replicate it on the 
tens of hosts I find myself logged in over a working day.  Now a simple 
"git clone" restores sanity to my working environment.


From chneukirchen at gmail.com  Mon Jan 12 02:48:44 2015
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Sun, 11 Jan 2015 17:48:44 +0100
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <E15113DD-72B3-4C19-9E53-DA906B107EF4@orthanc.ca> (Lyndon
 Nerenberg's message of "Sat, 10 Jan 2015 15:04:28 -0800")
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
 <87iogegrxh.fsf@gmail.com>
 <E15113DD-72B3-4C19-9E53-DA906B107EF4@orthanc.ca>
Message-ID: <8761cdgt5f.fsf@gmail.com>

Lyndon Nerenberg <lyndon at orthanc.ca> writes:

> On Jan 10, 2015, at 3:02 PM, Christian Neukirchen <chneukirchen at gmail.com> wrote:
>
>> Or just use: xterm -xrm '*titeInhibit: true'
>> Just for less: export LESS="-X"
>> Just for vim: set t_ti= t_te=
>
> Please provide the list of workarounds for all other curses consumers
> used worldwide and forever.
>
> Wouldn't it be nice if I could just do this in one place?  Oh, wait ...

I did: xterm -xrm '*titeInhibit: true'

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org


From jacob.ritorto at gmail.com  Mon Jan 12 03:08:44 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Sun, 11 Jan 2015 12:08:44 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
Message-ID: <CAHYQbfB-NdQx16WiLKFM6DfmM5GRO3UGHmYFMtHxQ55vQ1V9Qg@mail.gmail.com>

>
> Less is the epitome of modern Unix decadence.


agree


> Besides the
> maddening behavior described above, why, when all screens have a scroll
> bar,
> should a pager do its own scrolling?


in lieu of X scrollbars, there's also terminal multiplexers like tmux or
screen.  Also, there's the case of working directly on a character cell
terminal or console (rare these days, I admit, but I still do it frequently
enough to occasionally get caught without a scrollback buffer and lose
important stuff).  Hence my use of tmux et al..

So, yeah, agree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150111/9e46e5e8/attachment.html>

From brantleycoile at me.com  Mon Jan 12 05:40:19 2015
From: brantleycoile at me.com (Brantley Coile)
Date: Sun, 11 Jan 2015 14:40:19 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
Message-ID: <CEFA1C02-9254-4291-B257-0F8D4B995973@me.com>


On Jan 11, 2015, at 12:20 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>> when you - say - run less to display a file, it switches to a dedicated
>> region in the terminal memory buffer while printing its output, then
>> restores the buffer to back where you were to begin with when you exit
>> the pager
> 
> Sorry for veering away from Unix history, but this pushed one of the hottest
> of my buttons. Less is the epitome of modern Unix decadence. Besides the
> maddening behavior described above, why, when all screens have a scroll bar,
> should a pager do its own scrolling? But for a quantitative measure of
> decadence, try less --help | wc. It takes excess to a level not dreamed of
> in Pike's classic critique, "cat -v considered harmful".
> 
> Doug

I couldn’t agree with you more, Doug.  That’s why I started my new company, South Suite Software.  I want to re-evolve the software on the server side.

Besides “man less | wc -l”, there is the following.

- A man of gcc produces more lines than was in Dennis’ 7th Edition compiler.

- The number bytes in the C compiler clang's object file on my machine is 37,810,480, yet the compiler I use to build our software, Ken Thompson’s C from Plan 9, is 280,764 bytes.  

- Kernels now measure in the millions of lines.  Even with the various device drivers removed from a recent Linux kernel, almost a million lines remain.

- The recently hacked NTP protocol weights in at over 200,000 lines.

I could go on.

When Coraid’s management decided to change the base operating system from Plan 9 to Solaris, I decided it was time to start a new company dedicated to the re-evolution of the system software used in the back end machine rooms of the Internet.

I say re-evolution, because the existing code base has accretions that a software archeologist could use to study all the problems faced by system software since the 1960’s.  Each solution to a temporal problem has been entombed in all the code going forward.  Paging in from disk is a good example.  The Atlas invented paging to overcome a dearth of local memory by swapping out to a magnetic drum.  Today, when an average instruction executes in 600 picoseconds, it seems untenable to fetch 4096 bytes from a disk in 6,000,000,000 picoseconds.  Most of the code in current Unix-like systems still have code that solves problems like this that we no longer have.

And the consequences of the current code growth has real ramifications on everyone.  The continued improvement in quality of life has always depended on advancements of technology that lowered the cost of production.  Thanks to Moore’s law, system software has had a free lunch for twenty-five years.  Now that free lunch room is closed.  Six years ago Gordon Moore said there was two, maybe three Moore cycles left.  Things have gotten so small that quantum affects are beginning to dominate.  Intel, reportedly, has had problem getting satisfactory 14nm technology yields.  Silicon capital equipment manufacturers have halted development on equipment to produce larger wafers.  Moore’s law will no longer lower the cost of a unit of compute.

In addition, it’s obvious from history that the larger the code is the more buggy it is.  Not only is reliably an issue, but so is security.  Security is compromised by exploiting a class of bugs.  So, if the code is larger, and the number of bugs is more, it follows that the number of security bugs is also greater.  At one of my previous companies I built the PIX Firewall, later sold to Cisco, which was only about 50,000 bytes.  It’s simplicity, at least at the time I was involved with it, made it very secure.

So now I have started South Suite to produce software that, when added to white box hardware, creates easy to deploy, highly efficient, high performance appliances at a significantly lower cost.  We are re-evoloving system software, skipping all the intermediate steps that are encased in all other solutions.  We are doing it in the same culture, the same value system, that was at Bell Labs center 1127 and gave us these wonderful versions of Unix we all enjoy learning from.  We are even using Bell Labs tools from Plan 9 to re-invent the back end server room as if we were back at the labs, starting over.

I share the frustration with modern Unix some have expressed on this list.  And I’m trying to do something about it.  We on this list are lucky enough to know versions of Unix that were simple, clear, general and very, very effective.  The performance they extracted from the modest PDP-11 hardware was amazing.  In whatever way the readers of this list can, we should all bring this kind of values to the programming we do.  Together it can have a huge affect on the quality of life for everyone.

Thanks for being a part of giving birth to that legacy, Doug.  

Thanks everyone for listening to my rant.  

Brantley Coile



From dave at horsfall.org  Mon Jan 12 07:27:08 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 12 Jan 2015 08:27:08 +1100 (EST)
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <CEFA1C02-9254-4291-B257-0F8D4B995973@me.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <CEFA1C02-9254-4291-B257-0F8D4B995973@me.com>
Message-ID: <alpine.BSF.2.11.1501120825090.97981@aneurin.horsfall.org>

On Sun, 11 Jan 2015, Brantley Coile wrote:

> We are re-evoloving system software [...]

I know it was a typo, but I still like it :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)


From brantleycoile at me.com  Mon Jan 12 08:10:12 2015
From: brantleycoile at me.com (Brantley Coile)
Date: Sun, 11 Jan 2015 17:10:12 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <alpine.BSF.2.11.1501120825090.97981@aneurin.horsfall.org>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <CEFA1C02-9254-4291-B257-0F8D4B995973@me.com>
 <alpine.BSF.2.11.1501120825090.97981@aneurin.horsfall.org>
Message-ID: <5BA2B1DE-252B-448D-AFA4-868E85E9EDCE@me.com>

:)

And I guess we evo love it again, too.  :)

Sent from my iPad

> On Jan 11, 2015, at 4:27 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
>> On Sun, 11 Jan 2015, Brantley Coile wrote:
>> 
>> We are re-evoloving system software [...]
> 
> I know it was a typo, but I still like it :-)
> 
> -- 
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From clemc at ccc.com  Tue Jan 13 01:32:47 2015
From: clemc at ccc.com (Clem Cole)
Date: Mon, 12 Jan 2015 10:32:47 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <CEFA1C02-9254-4291-B257-0F8D4B995973@me.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <CEFA1C02-9254-4291-B257-0F8D4B995973@me.com>
Message-ID: <CAC20D2OyRYqAwrRfCykP-kSC8rtLWkZvkx+Jd8-nDagrUf7sMg@mail.gmail.com>

Brantley/Doug - I think you might be amused (or maybe disgusted) when the
3B2 came out.  I pointed out to Dennis that the bootloader was multiple
times of the size of 6th edition kernel and not nearly as easy to
understand.

Indeed, I agree that Pike's railing in "*cat -v considered harmful*" was a
telltale of bad things.  I always thought that many of my siblings at UCB
had lost the spirit of "UNIX Philosophy" of a "single small program doing
one job well" when the Vax "fixed" the address issues of the PDP-11.  It
allowed for sloppiness and programs grew without thought or bound.

Doug, while you describe "less" as the an example of decadence, I think a
better example of same is sendmail.    I have always said that if Eric had
left the SMTPD as a separate program (which is what is was when the TCP/IP
support came to UCB from BBN); sendmail would never have become what it
did.   The primary issue of header rewriting was not something most sites
had issues like UCB did - they just needed an SMTP interface and sendmail
was the SMTPD for 4.3BSD.  So sites picked it up because of that.

Clem

On Sun, Jan 11, 2015 at 2:40 PM, Brantley Coile <brantleycoile at me.com>
wrote:

>
> On Jan 11, 2015, at 12:20 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> >> when you - say - run less to display a file, it switches to a dedicated
> >> region in the terminal memory buffer while printing its output, then
> >> restores the buffer to back where you were to begin with when you exit
> >> the pager
> >
> > Sorry for veering away from Unix history, but this pushed one of the
> hottest
> > of my buttons. Less is the epitome of modern Unix decadence. Besides the
> > maddening behavior described above, why, when all screens have a scroll
> bar,
> > should a pager do its own scrolling? But for a quantitative measure of
> > decadence, try less --help | wc. It takes excess to a level not dreamed
> of
> > in Pike's classic critique, "cat -v considered harmful".
> >
> > Doug
>
> I couldn’t agree with you more, Doug.  That’s why I started my new
> company, South Suite Software.  I want to re-evolve the software on the
> server side.
>
> Besides “man less | wc -l”, there is the following.
>
> - A man of gcc produces more lines than was in Dennis’ 7th Edition
> compiler.
>
> - The number bytes in the C compiler clang's object file on my machine is
> 37,810,480, yet the compiler I use to build our software, Ken Thompson’s C
> from Plan 9, is 280,764 bytes.
>
> - Kernels now measure in the millions of lines.  Even with the various
> device drivers removed from a recent Linux kernel, almost a million lines
> remain.
>
> - The recently hacked NTP protocol weights in at over 200,000 lines.
>
> I could go on.
>
> When Coraid’s management decided to change the base operating system from
> Plan 9 to Solaris, I decided it was time to start a new company dedicated
> to the re-evolution of the system software used in the back end machine
> rooms of the Internet.
>
> I say re-evolution, because the existing code base has accretions that a
> software archeologist could use to study all the problems faced by system
> software since the 1960’s.  Each solution to a temporal problem has been
> entombed in all the code going forward.  Paging in from disk is a good
> example.  The Atlas invented paging to overcome a dearth of local memory by
> swapping out to a magnetic drum.  Today, when an average instruction
> executes in 600 picoseconds, it seems untenable to fetch 4096 bytes from a
> disk in 6,000,000,000 picoseconds.  Most of the code in current Unix-like
> systems still have code that solves problems like this that we no longer
> have.
>
> And the consequences of the current code growth has real ramifications on
> everyone.  The continued improvement in quality of life has always depended
> on advancements of technology that lowered the cost of production.  Thanks
> to Moore’s law, system software has had a free lunch for twenty-five
> years.  Now that free lunch room is closed.  Six years ago Gordon Moore
> said there was two, maybe three Moore cycles left.  Things have gotten so
> small that quantum affects are beginning to dominate.  Intel, reportedly,
> has had problem getting satisfactory 14nm technology yields.  Silicon
> capital equipment manufacturers have halted development on equipment to
> produce larger wafers.  Moore’s law will no longer lower the cost of a unit
> of compute.
>
> In addition, it’s obvious from history that the larger the code is the
> more buggy it is.  Not only is reliably an issue, but so is security.
> Security is compromised by exploiting a class of bugs.  So, if the code is
> larger, and the number of bugs is more, it follows that the number of
> security bugs is also greater.  At one of my previous companies I built the
> PIX Firewall, later sold to Cisco, which was only about 50,000 bytes.  It’s
> simplicity, at least at the time I was involved with it, made it very
> secure.
>
> So now I have started South Suite to produce software that, when added to
> white box hardware, creates easy to deploy, highly efficient, high
> performance appliances at a significantly lower cost.  We are re-evoloving
> system software, skipping all the intermediate steps that are encased in
> all other solutions.  We are doing it in the same culture, the same value
> system, that was at Bell Labs center 1127 and gave us these wonderful
> versions of Unix we all enjoy learning from.  We are even using Bell Labs
> tools from Plan 9 to re-invent the back end server room as if we were back
> at the labs, starting over.
>
> I share the frustration with modern Unix some have expressed on this
> list.  And I’m trying to do something about it.  We on this list are lucky
> enough to know versions of Unix that were simple, clear, general and very,
> very effective.  The performance they extracted from the modest PDP-11
> hardware was amazing.  In whatever way the readers of this list can, we
> should all bring this kind of values to the programming we do.  Together it
> can have a huge affect on the quality of life for everyone.
>
> Thanks for being a part of giving birth to that legacy, Doug.
>
> Thanks everyone for listening to my rant.
>
> Brantley Coile
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/319422f8/attachment.html>

From clemc at ccc.com  Tue Jan 13 01:36:29 2015
From: clemc at ccc.com (Clem Cole)
Date: Mon, 12 Jan 2015 10:36:29 -0500
Subject: [TUHS] Termcap vs terminfo
In-Reply-To: <alpine.BSF.2.11.1501111302010.97981@aneurin.horsfall.org>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
 <alpine.BSF.2.11.1501111302010.97981@aneurin.horsfall.org>
Message-ID: <CAC20D2PetY__5+8xNJnyk=SA6hEBL=m_QcjQR7u94V=B=t8Hwg@mail.gmail.com>

+1

On Sat, Jan 10, 2015 at 9:06 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:
>
> > This drives me insane!  When I 'man foo' and find the relevant bits in
> > the document, when I quit out of the pager I want those bits to stay on
> > the screen so I can refer to them, dammit!  There are two shortcuts to
> > this, both involving custom termcap/terminfo entries.
>
> I'm glad I'm not the only one annoyed by this "feature".
>
> --
> Dave Horsfall DTM (VK2KFU)  "Bliss is a MacBook with a FreeBSD server."
> http://www.horsfall.org/spam.html (and check the home page whilst you're
> there)
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/03579331/attachment.html>

From r.rezaian at earthlink.net  Tue Jan 13 02:51:54 2015
From: r.rezaian at earthlink.net (Russell Rezaian)
Date: Mon, 12 Jan 2015 10:51:54 -0600
Subject: [TUHS] Disable "less" screen swapping was: Re: Termcap vs terminfo
In-Reply-To: <CAC20D2PetY__5+8xNJnyk=SA6hEBL=m_QcjQR7u94V=B=t8Hwg@mail.gmail.com>
References: <1FD28B19-FA50-4581-BB0A-257B5DDE1890@kdbarto.org>
 <30E98281-D4A7-424D-A757-2EF50A0BFC65@kdbarto.org>
 <C4622955-2DEB-4316-A695-3BACD75D2F1E@orthanc.ca>
 <alpine.BSF.2.11.1501111302010.97981@aneurin.horsfall.org>
 <CAC20D2PetY__5+8xNJnyk=SA6hEBL=m_QcjQR7u94V=B=t8Hwg@mail.gmail.com>
Message-ID: <54B3FBAA.1060505@earthlink.net>

On Sat, Jan 10, 2015 at 9:06 PM, Dave Horsfall <dave at horsfall.org 
<mailto:dave at horsfall.org>> wrote:
>
>     On Sat, 10 Jan 2015, Lyndon Nerenberg wrote:
>
>     > This drives me insane!  When I 'man foo' and find the relevant
>     bits in
>     > the document, when I quit out of the pager I want those bits to
>     stay on
>     > the screen so I can refer to them, dammit!  There are two
>     shortcuts to
>     > this, both involving custom termcap/terminfo entries.
>
>     I'm glad I'm not the only one annoyed by this "feature".
>
I am also not happy with this behavior.

There is at least one "fix" I have found for this particular annoyance.

A little background: this behavior uses a pair of termcap entries called 
"ti" and "te" which, on most recent xterm implementations, switch 
between alternate screens.  Many programs on startup switch to the 
alternate screen to keep their displays separate from the normal command 
scroll buffer.

There is an xterm resource "titeInhibit" which, if set to true, will 
disable the remarkably annoying mode switch that is used by less (and 
also any other application that tries to use the screen swap).

Given this started out as a termcap thread, hopefully this will be 
appropriate!

This complete disable of the screen swap may not be what everyone is 
looking for, but it certainly was what I wanted.
--
Russell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/5a2613a0/attachment.html>

From random832 at fastmail.us  Tue Jan 13 05:38:25 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Mon, 12 Jan 2015 14:38:25 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
Message-ID: <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>



On Sun, Jan 11, 2015, at 00:20, Doug McIlroy wrote:
> Sorry for veering away from Unix history, but this pushed one of the
> hottest
> of my buttons. Less is the epitome of modern Unix decadence. Besides the
> maddening behavior described above, why, when all screens have a scroll
> bar,
> should a pager do its own scrolling?

The console screen doesn't, and the one in an emulator can't be
controlled by the pager. The real question is why a pager should be
executed at all in an xterm. Except xterm has no ability to search in
scrollback, and its buffer may not be large enough for some very large
manpages.


From jacob.ritorto at gmail.com  Tue Jan 13 05:44:30 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Mon, 12 Jan 2015 14:44:30 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
Message-ID: <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>

On Mon, Jan 12, 2015 at 2:38 PM, <random832 at fastmail.us> wrote:

>
>
> On Sun, Jan 11, 2015, at 00:20, Doug McIlroy wrote:
> The console screen doesn't, and the one in an emulator can't be
> controlled by the pager. The real question is why a pager should be
> executed at all in an xterm. Except xterm has no ability to search in
> scrollback, and its buffer may not be large enough for some very large
> manpages.


srsly, this is why we have tmux.  or even good old screen, in a pinch.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1

each program small and good at its one own thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/56648ae7/attachment.html>

From cowan at ccil.org  Tue Jan 13 05:52:06 2015
From: cowan at ccil.org (cowan at ccil.org)
Date: Mon, 12 Jan 2015 14:52:06 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
 <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
Message-ID: <26f30fee0aa9ee31687ab7e6ec169975.squirrel@www.ccil.org>

> each program small and good at its one own thing.

I don't think it's sensible to apply this dictum to editors and viewers.
We don't, for example, have separate programs for inserting text, deleting
text, replacing text, scrolling a view up, scrolling a view down, and so
on.  Less is really a sort of ed without the ability to modify its buffer.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Some people open all the Windows; wise wives welcome the spring by moving
the Unix.  --Advertisement for Unix Book Units (U.K.)
(see http://cm.bell-labs.com/cm/cs/who/dmr/unix3image.gif)




From khm at sciops.net  Tue Jan 13 05:53:00 2015
From: khm at sciops.net (Kurt H Maier)
Date: Mon, 12 Jan 2015 19:53:00 +0000
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
 <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
Message-ID: <20150112195300.Horde.m-KX0gVuyTDTW6lnVUnE1Q2@ssl.eumx.net>

Quoting Jacob Ritorto <jacob.ritorto at gmail.com>:

>
> srsly, this is why we have tmux.  or even good old screen, in a pinch.
>
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1
>
> each program small and good at its one own thing.

If the "one thing" is "fix the broken design of another program" it's often
a better idea to just fix the original program.

khm



From random832 at fastmail.us  Tue Jan 13 06:34:21 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Mon, 12 Jan 2015 15:34:21 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
 <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
Message-ID: <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com>

On Mon, Jan 12, 2015, at 14:44, Jacob Ritorto wrote:
> srsly, this is why we have tmux.  or even good old screen, in a pinch.
> 
> http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tmux.1?query=tmux&sec=1
> 
> each program small and good at its one own thing.

In principle, the functions "detachable terminal session", "terminal
session multiplexer", and "terminal with scrollback", and "translator
from a common VT100 superset to whatever the hell the user is using"
could be four separate programs.


From clemc at ccc.com  Tue Jan 13 07:25:07 2015
From: clemc at ccc.com (Clem Cole)
Date: Mon, 12 Jan 2015 16:25:07 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
 <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
 <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com>
Message-ID: <CAC20D2M6Fag5Woz1crqsfgpQ54-eGG2q-5VHRG76N1h=yuC==Q@mail.gmail.com>

On Mon, Jan 12, 2015 at 3:34 PM, <random832 at fastmail.us> wrote:
>
>
> In principle, the functions "detachable terminal session", "terminal
> session multiplexer", and "terminal with scrollback", and "translator
> from a common VT100 superset to whatever the hell the user is using"
> could be four separate programs.



​To quote Rob and Brian from the "cat -v" paper: [
http://harmful.cat-v.org/cat-v/unix_prog_design.pdf]

​

Separate programs are not always better than wider options; which is better
depends on the problem.
Whenever one needs a way to perform a new function, one faces the choice of
whether to add a new option
or write a new program (assuming that none of the programmable tools will
do the job conveniently). The
guiding principle for making the choice should be that each program does
one thing. Options are appropriately
added to a program that already has the right functionality. If there is no
such program, then a new
program is called for. In that case, the usual criteria for program design
should be used: the program should
be as general as possible, its default behavior should match the most
common usage, and it should cooperate
with other programs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150112/fb4d7542/attachment.html>

From wkt at tuhs.org  Wed Jan 14 11:12:03 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 14 Jan 2015 12:12:03 +1100
Subject: [TUHS] SVN of CSRG Releases
Message-ID: <20150114011203.GA632@www.oztivo.net>

Hi all, I came across this last week:

	http://svnweb.freebsd.org/

It's a Subversion VCS of all the CSRG releases. I'm not sure if it
has been mentioned here before.

Cheers, Warren


From lm at mcvoy.com  Wed Jan 14 11:42:56 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 13 Jan 2015 17:42:56 -0800
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114011203.GA632@www.oztivo.net>
References: <20150114011203.GA632@www.oztivo.net>
Message-ID: <20150114014256.GB17893@mcvoy.com>

Aren't the SCCS sources for the real history online?  I know Kirk made
them available on his CD, I have them somewhere.

On Wed, Jan 14, 2015 at 12:12:03PM +1100, Warren Toomey wrote:
> Hi all, I came across this last week:
> 
> 	http://svnweb.freebsd.org/
> 
> It's a Subversion VCS of all the CSRG releases. I'm not sure if it
> has been mentioned here before.
> 
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From wkt at tuhs.org  Wed Jan 14 11:55:57 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 14 Jan 2015 12:55:57 +1100
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114014256.GB17893@mcvoy.com>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
Message-ID: <20150114015556.GA3136@www.oztivo.net>

On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote:
> Aren't the SCCS sources for the real history online?  I know Kirk made
> them available on his CD, I have them somewhere.

In a previous private e-mail I received from Kirk, he said:
	The folks at UC
	Berkeley have always required me to track distributions of the SCCS
	files as they somehow think of them as still sensitive.

which implies that the SCCS files cannot be released publicly. However,
the SVN version is a "derivative" of the SCCS files and, on that basis,
is publicly available. Go figure :)

Cheers, Warren


From grog at lemis.com  Wed Jan 14 12:24:27 2015
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Wed, 14 Jan 2015 13:24:27 +1100
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114015556.GA3136@www.oztivo.net>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net>
Message-ID: <20150114022427.GB24813@eureka.lemis.com>

On Wednesday, 14 January 2015 at 12:55:57 +1100, Warren Toomey wrote:
> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote:
>> Aren't the SCCS sources for the real history online?  I know Kirk made
>> them available on his CD, I have them somewhere.
>
> In a previous private e-mail I received from Kirk, he said:
> 	The folks at UC
> 	Berkeley have always required me to track distributions of the SCCS
> 	files as they somehow think of them as still sensitive.
>
> which implies that the SCCS files cannot be released publicly. However,
> the SVN version is a "derivative" of the SCCS files and, on that basis,
> is publicly available. Go figure :)

Considering that all the SCCS files are on the CDs that Kirk
distributed, that's particularly strange.  My thought was that, with
the exception of Larry, nobody has the SCCS software any more.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150114/dc1210d8/attachment.sig>

From lm at mcvoy.com  Wed Jan 14 12:37:52 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 13 Jan 2015 18:37:52 -0800
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114022427.GB24813@eureka.lemis.com>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
 <20150114015556.GA3136@www.oztivo.net>
 <20150114022427.GB24813@eureka.lemis.com>
Message-ID: <20150114023752.GC17893@mcvoy.com>

On Wed, Jan 14, 2015 at 01:24:27PM +1100, Greg 'groggy' Lehey wrote:
> On Wednesday, 14 January 2015 at 12:55:57 +1100, Warren Toomey wrote:
> > On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote:
> >> Aren't the SCCS sources for the real history online?  I know Kirk made
> >> them available on his CD, I have them somewhere.
> >
> > In a previous private e-mail I received from Kirk, he said:
> > 	The folks at UC
> > 	Berkeley have always required me to track distributions of the SCCS
> > 	files as they somehow think of them as still sensitive.
> >
> > which implies that the SCCS files cannot be released publicly. However,
> > the SVN version is a "derivative" of the SCCS files and, on that basis,
> > is publicly available. Go figure :)
> 
> Considering that all the SCCS files are on the CDs that Kirk
> distributed, that's particularly strange.  My thought was that, with
> the exception of Larry, nobody has the SCCS software any more.

GNU has an SCCS clone.  A so-so one but James and his crew fixes bugs.
And I suspect that BitSCCS is out there on the intertubes somewhere.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From cowan at mercury.ccil.org  Wed Jan 14 14:41:11 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 13 Jan 2015 23:41:11 -0500
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114023752.GC17893@mcvoy.com>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
 <20150114015556.GA3136@www.oztivo.net>
 <20150114022427.GB24813@eureka.lemis.com>
 <20150114023752.GC17893@mcvoy.com>
Message-ID: <20150114044111.GF26762@mercury.ccil.org>

Larry McVoy scripsit:

> GNU has an SCCS clone.  A so-so one but James and his crew fixes bugs.

OpenIndiana has a derivative of the SVR4 version, and so does the
Heirloom Toolkit.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.


From sdaoden at yandex.com  Wed Jan 14 21:24:11 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Wed, 14 Jan 2015 12:24:11 +0100
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114023752.GC17893@mcvoy.com>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
 <20150114015556.GA3136@www.oztivo.net>
 <20150114022427.GB24813@eureka.lemis.com>
 <20150114023752.GC17893@mcvoy.com>
Message-ID: <20150114112411.sD3MlJkTf6mgWh37@yandex.com>

Larry McVoy <lm at mcvoy.com> wrote:
 |On Wed, Jan 14, 2015 at 01:24:27PM +1100, Greg 'groggy' Lehey wrote:
 |> On Wednesday, 14 January 2015 at 12:55:57 +1100, Warren Toomey wrote:
 |>> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote:
 |>>> Aren't the SCCS sources for the real history online?  I know Kirk made
 |>>> them available on his CD, I have them somewhere.
 |>>
 |>> In a previous private e-mail I received from Kirk, he said:
 |>>  The folks at UC
 |>>  Berkeley have always required me to track distributions of the SCCS
 |>>  files as they somehow think of them as still sensitive.
 |>>
 |>> which implies that the SCCS files cannot be released publicly. However,
 |>> the SVN version is a "derivative" of the SCCS files and, on that basis,
 |>> is publicly available. Go figure :)
 |> 
 |> Considering that all the SCCS files are on the CDs that Kirk
 |> distributed, that's particularly strange.  My thought was that, with
 |> the exception of Larry, nobody has the SCCS software any more.
 |
 |GNU has an SCCS clone.  A so-so one but James and his crew fixes bugs.
 |And I suspect that BitSCCS is out there on the intertubes somewhere.

Jörg Schilling also has a(n extended) SCCS, now located at [1].

  [1] http://sourceforge.net/projects/schilytools/

I have cloned the (FreeBSD based) git(1) repo mentioned elsewhere
in this thread, but it is no good -- a better version with much
(, much) better meta data is at [2], but it is much larger, of
course.

  [2] https://github.com/jonathangray/csrg

--steffen


From dds at aueb.gr  Wed Jan 14 21:45:26 2015
From: dds at aueb.gr (Diomidis Spinellis)
Date: Wed, 14 Jan 2015 13:45:26 +0200
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <20150114015556.GA3136@www.oztivo.net>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com> <20150114015556.GA3136@www.oztivo.net>
Message-ID: <54B656D6.8080907@aueb.gr>

On 14/01/2015 03:55, Warren Toomey wrote:
> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote:
>> Aren't the SCCS sources for the real history online?  I know Kirk made
>> them available on his CD, I have them somewhere.
>
> In a previous private e-mail I received from Kirk, he said:
> 	The folks at UC
> 	Berkeley have always required me to track distributions of the SCCS
> 	files as they somehow think of them as still sensitive.
>
> which implies that the SCCS files cannot be released publicly. However,
> the SVN version is a "derivative" of the SCCS files and, on that basis,
> is publicly available. Go figure :)

Here's another data point: when I asked Kirk regarding the public 
availability of the SCCS repo he pointed me to 
http://svnweb.freebsd.org/csrg/.

At https://github.com/dspinellis/unix-history-repo you can find a single 
1GB repository that integrates many of the snapshots and version control 
repositories available through TUHS and other sources (including the 
CSRG data).  Its commit history starts on Jun 20th 1972 with the First 
Research Edition and ends with FreeBSD 10 in 2015.  Git blame works 
across all the history's commits.



From jacob.ritorto at gmail.com  Thu Jan 15 03:38:05 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 14 Jan 2015 12:38:05 -0500
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <54B656D6.8080907@aueb.gr>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
 <20150114015556.GA3136@www.oztivo.net> <54B656D6.8080907@aueb.gr>
Message-ID: <CAHYQbfD+P88YdNbuEPFsYU_Eq+cLHDqjy_THJO8mXwbj52rpeQ@mail.gmail.com>

Not to over-state the importance of this particular version control system,
but having this code on github is game-changing; thanks, guys.

On Wed, Jan 14, 2015 at 6:45 AM, Diomidis Spinellis <dds at aueb.gr> wrote:

> On 14/01/2015 03:55, Warren Toomey wrote:
>
>> On Tue, Jan 13, 2015 at 05:42:56PM -0800, Larry McVoy wrote:
>>
>>> Aren't the SCCS sources for the real history online?  I know Kirk made
>>> them available on his CD, I have them somewhere.
>>>
>>
>> In a previous private e-mail I received from Kirk, he said:
>>         The folks at UC
>>         Berkeley have always required me to track distributions of the
>> SCCS
>>         files as they somehow think of them as still sensitive.
>>
>> which implies that the SCCS files cannot be released publicly. However,
>> the SVN version is a "derivative" of the SCCS files and, on that basis,
>> is publicly available. Go figure :)
>>
>
> Here's another data point: when I asked Kirk regarding the public
> availability of the SCCS repo he pointed me to http://svnweb.freebsd.org/
> csrg/.
>
> At https://github.com/dspinellis/unix-history-repo you can find a single
> 1GB repository that integrates many of the snapshots and version control
> repositories available through TUHS and other sources (including the CSRG
> data).  Its commit history starts on Jun 20th 1972 with the First Research
> Edition and ends with FreeBSD 10 in 2015.  Git blame works across all the
> history's commits.
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150114/cdd005be/attachment.html>

From cowan at ccil.org  Thu Jan 15 03:52:30 2015
From: cowan at ccil.org (cowan at ccil.org)
Date: Wed, 14 Jan 2015 12:52:30 -0500
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <CAHYQbfD+P88YdNbuEPFsYU_Eq+cLHDqjy_THJO8mXwbj52rpeQ@mail.gmail.com>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
 <20150114015556.GA3136@www.oztivo.net> <54B656D6.8080907@aueb.gr>
 <CAHYQbfD+P88YdNbuEPFsYU_Eq+cLHDqjy_THJO8mXwbj52rpeQ@mail.gmail.com>
Message-ID: <d4bd8780f229b8d010841c7d2208ddad.squirrel@www.ccil.org>

Jacob Ritorto scripsit:

> Not to over-state the importance of this particular version control
> system, but having this code on github is game-changing; thanks, guys.

When Github collapses because it can't make money, and there's nowhere
to move all 20 million repositories, *that* will be game-changing.
~~ grumble ~~

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann
man auch in grossen Dingen nicht vertrauen.  --Albert Einstein on honesty




From jacob.ritorto at gmail.com  Thu Jan 15 04:34:09 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 14 Jan 2015 13:34:09 -0500
Subject: [TUHS] SVN of CSRG Releases
In-Reply-To: <d4bd8780f229b8d010841c7d2208ddad.squirrel@www.ccil.org>
References: <20150114011203.GA632@www.oztivo.net>
 <20150114014256.GB17893@mcvoy.com>
 <20150114015556.GA3136@www.oztivo.net> <54B656D6.8080907@aueb.gr>
 <CAHYQbfD+P88YdNbuEPFsYU_Eq+cLHDqjy_THJO8mXwbj52rpeQ@mail.gmail.com>
 <d4bd8780f229b8d010841c7d2208ddad.squirrel@www.ccil.org>
Message-ID: <CAHYQbfDacKZOS11aG2xz4H8fZzi0Rdj8f-erxgR4x1-+-_EO-g@mail.gmail.com>

haha, totally +1, but it's soooo easy to broadcast code, garner
contribution and collaborate this way that it's almost worth the risk.

On Wed, Jan 14, 2015 at 12:52 PM, <cowan at ccil.org> wrote:

> Jacob Ritorto scripsit:
>
> > Not to over-state the importance of this particular version control
> > system, but having this code on github is game-changing; thanks, guys.
>
> When Github collapses because it can't make money, and there's nowhere
> to move all 20 million repositories, *that* will be game-changing.
> ~~ grumble ~~
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Wer es in kleinen Dingen mit der Wahrheit nicht ernst nimmt, dem kann
> man auch in grossen Dingen nicht vertrauen.  --Albert Einstein on honesty
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150114/66f1e6ee/attachment.html>

From jacob.ritorto at gmail.com  Thu Jan 15 14:32:57 2015
From: jacob.ritorto at gmail.com (Jacob Ritorto)
Date: Wed, 14 Jan 2015 23:32:57 -0500
Subject: [TUHS] Less -- was Termcap vs terminfo
In-Reply-To: <CAC20D2M6Fag5Woz1crqsfgpQ54-eGG2q-5VHRG76N1h=yuC==Q@mail.gmail.com>
References: <201501110520.t0B5KwvP018801@coolidge.cs.dartmouth.edu>
 <1421091505.3373070.212956033.39DC72E0@webmail.messagingengine.com>
 <CAHYQbfDySuXHyYpsf=BZROia7VsiZDUUdAb-z5UoSQkEg-KyCA@mail.gmail.com>
 <1421094861.3387032.212981065.1F9F4427@webmail.messagingengine.com>
 <CAC20D2M6Fag5Woz1crqsfgpQ54-eGG2q-5VHRG76N1h=yuC==Q@mail.gmail.com>
Message-ID: <CAHYQbfCjsGQPpiQAK_ME0gDqo9YywQ+7DBoSwFEKr9cTruw9Ow@mail.gmail.com>

Just noticed that Garrett is doing things to less.  Maybe talk to him?
http://garrett.damore.org/2014/09/modernizing-less.html
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20150114/f08e42cf/attachment.html>

From tih at hamartun.priv.no  Fri Jan 16 18:40:11 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Fri, 16 Jan 2015 09:40:11 +0100
Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos ))
In-Reply-To: <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org> (Dave
 Horsfall's message of "Wed, 7 Jan 2015 12:53:46 +1100")
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
 <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>
Message-ID: <m2lhl3w238.fsf_-_@athene.hamartun.priv.no>

Dave Horsfall <dave at horsfall.org> writes:

> It was drilled into us that the correct usage was:
>
> # sync
> # sync
> # sync
>
> This gives the disk buffers time to actually flush (the writes were merely 
> scheduled, and were asynchronous).

There is another reason why multiple syncs before halting the system
were needed.  There was no fancy I/O order juggling, so everything was
written in the same chronological order as it was scheduled.  If you
look at 6th edition source code, you'll find that a call to sync would
invoke the internal routine update(), which does three things in order:

1: schedule writes of superblocks, and wait for them to complete
2: update in-memory inode time stamps wherever needed
3: schedule writes of inodes and data blocks that are now dirty

What this means is that the second sync, by waiting for its own
superblock writes, will wait until all the inode and file data flushes
scheduled by the first one have completed.

What I haven't been able to figure out from a few minutes studying the
code, is whether the third sync is really needed, or just a "belt and
suspenders" thing.  I've heard it claimed that the flushing of inodes
and/or file data going on while the second sync is waiting for its
already scheduled superblock writes to complete will cause the third one
to be needed.  That would mean either that flushing dirty file blocks
could cause inode updates, or that flushing inodes could cause
superblock updates.  Anyone know the internals well enough to say?

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"


From jnc at mercury.lcs.mit.edu  Fri Jan 16 22:33:01 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 16 Jan 2015 07:33:01 -0500 (EST)
Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos ))
Message-ID: <20150116123301.A4A9218C099@mercury.lcs.mit.edu>

    > From: Tom Ivar Helbekkmo

    > There was no fancy I/O order juggling, so everything was written in the
    > same chronological order as it was scheduled.
    > ...
    > What this means is that the second sync, by waiting for its own
    > superblock writes, will wait until all the inode and file data flushes
    > scheduled by the first one have completed.

Ah, I'm not sure this is correct. Not all disk drivers handled requests in a
'first-come, first-served' order (i.e. where a request for block X, which was
scheduled before a request for block Y, actually happened before the
operation on block Y). It all depends on the particular driver; some drivers
(e.g. the RP driver) re-organized the waiting request queue to optimize head
motion, using a so-called 'elevator algorithm'.

(PS: For a good time, do "dd if=/dev/[large_partition] of=/dev/null" on a
running system with such a disk, and a lot of users on - the system will
apparently come to a screeching halt while the 'up' pass on the disk
completes... I found this out the hard way, needless to say! :-)

Since the root block is block 1 in the partition, one might think that even
with an elevator algorithm, this would tend to guarantee that doing it would
more or less guarantee that all other pending operations would have completed
(since it could only happen at the end of 'down' pass); _but_ the elevator
algorithm is in terms of actual physical block numbers, so blocks in another
lower partition might still remain to be written.

But now that I think about it a bit, if such blocks existed, that partition's
super-block would also need to be written, so when that one completed, the
disk queue would be empty.

But the point remains - because there's no guarantee of _overall_ disk
operation ordering in V6, scheduling a disk request and waiting for it to
complete does not guarantee that all previously-requested disk operations
will have completed before it does.


I really think the whole triple-sync thing is mythology. Look through the V6
documentation and although IIRC there are instructions on how to shut the
system down, it's not mentioned. We certainly never used it at MIT (and I
still don't), and I've never seen a problem with disk corruption _when the
system was deliberately shut down_.

	Noel


From random832 at fastmail.us  Fri Jan 16 23:39:06 2015
From: random832 at fastmail.us (random832 at fastmail.us)
Date: Fri, 16 Jan 2015 08:39:06 -0500
Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos ))
In-Reply-To: <m2lhl3w238.fsf_-_@athene.hamartun.priv.no>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
 <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>
 <m2lhl3w238.fsf_-_@athene.hamartun.priv.no>
Message-ID: <1421415546.919096.214748125.23E789CE@webmail.messagingengine.com>

On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo wrote:
> What this means is that the second sync, by waiting for its own
> superblock writes, will wait until all the inode and file data flushes
> scheduled by the first one have completed.

Everything I've read indicates that nothing in the sync call actually
waits on anything, and that it's actually just the time taken to type
the second and third command on a 110 baud terminal gives the first one
time to finish executing.


From brantleycoile at me.com  Sat Jan 17 00:14:53 2015
From: brantleycoile at me.com (Brantley Coile)
Date: Fri, 16 Jan 2015 09:14:53 -0500
Subject: [TUHS] sync; sync; sync; halt (was: Re: Illumos ))
In-Reply-To: <1421415546.919096.214748125.23E789CE@webmail.messagingengine.com>
References: <20141231062219.GA21046@mcvoy.com>
 <1420018115.54a3c1c32faaa@www.paradise.net.nz>
 <20141231131335.GA26926@mercury.ccil.org> <54A4357F.9040703@aueb.gr>
 <CAC20D2POf41Psp6gWdsX9a5PvYsMag-YBQLbawtbFaXpo0wG-A@mail.gmail.com>
 <20141231203617.GB3922@mcvoy.com>
 <CAHYQbfAJC32YuzDHQfBQ4Jbk5uDOsUxGbg3qDv0ZdA_j2eNb_Q@mail.gmail.com>
 <20141231224249.GA5833@mcvoy.com>
 <EA114F48-926C-4729-A900-E28D645AC57D@tfeb.org>
 <CAHYQbfA6NEk6Nsj+r7-4rP+_UHsgN+NUZTS9jZp2Byx0oQy_8A@mail.gmail.com>
 <CAC20D2PdYXD22Fqz=Eb5J4tMYsGwvx7ecV7ffTsTwqwekHk8Zw@mail.gmail.com>
 <alpine.BSF.2.11.1501071248120.58880@aneurin.horsfall.org>
 <m2lhl3w238.fsf_-_@athene.hamartun.priv.no>
 <1421415546.919096.214748125.23E789CE@webmail.messagingengine.com>
Message-ID: <4C37916E-48D1-4B6C-9337-581CBC0E948A@me.com>

Sixth Edition and 7th Edition are different.  Looking at the code, 6th Edition waits on the updates, but 7th Edition delays the writes(bdwrite()) and then calls bflush() when all finished.  The three sync’s were indeed to give the disk driver time to do all the IO sitting on the queue.  The HP driver used disksort() so those blocks wouldn’t necessarily be written in the order they were touched.

We used to use one sync and just watch the disk’s activity light.

Brantley
South Suite Software

On Jan 16, 2015, at 8:39 AM, random832 at fastmail.us wrote:

> On Fri, Jan 16, 2015, at 03:40, Tom Ivar Helbekkmo wrote:
>> What this means is that the second sync, by waiting for its own
>> superblock writes, will wait until all the inode and file data flushes
>> scheduled by the first one have completed.
> 
> Everything I've read indicates that nothing in the sync call actually
> waits on anything, and that it's actually just the time taken to type
> the second and third command on a 110 baud terminal gives the first one
> time to finish executing.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From tih at hamartun.priv.no  Sun Jan 18 07:20:15 2015
From: tih at hamartun.priv.no (Tom Ivar Helbekkmo)
Date: Sat, 17 Jan 2015 22:20:15 +0100
Subject: [TUHS] sync; sync; sync; halt
In-Reply-To: <20150116123301.A4A9218C099@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Fri, 16 Jan 2015 07:33:01 -0500 (EST)")
References: <20150116123301.A4A9218C099@mercury.lcs.mit.edu>
Message-ID: <m2ppadumsw.fsf@athene.hamartun.priv.no>

Noel Chiappa <jnc at mercury.lcs.mit.edu> writes:

> It all depends on the particular driver; some drivers (e.g. the RP
> driver) re-organized the waiting request queue to optimize head
> motion, using a so-called 'elevator algorithm'.

Ah, yes, now that you point it out, I see the sorting in the RP driver.

> I really think the whole triple-sync thing is mythology.

It looks that way, yes.  The fact that it does a synchronous write of
the superblocks at the start of the sync seems to imply that two
successive calls should ensure a proper flushing of everything, and may
even have been written like that with that effect in mind, but once disk
drivers started optimizing I/O ordering, the effect was lost - which
might just be why the synchronous superblock write was gone in V7.

-tih
-- 
Popularity is the hallmark of mediocrity.  --Niles Crane, "Frasier"


