From jnc at mercury.lcs.mit.edu  Thu Nov  1 01:39:37 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 31 Oct 2018 11:39:37 -0400 (EDT)
Subject: [TUHS] Archaic yacc C grammar
Message-ID: <20181031153937.767D318C0BF@mercury.lcs.mit.edu>

    > From: Steve Johnson

    > references that were checked using the pointer type of the structure
    > pointer. My code was a nightmare, and some of the old Unix code was at
    > least a bad dream.

I had a 'fun' experience with this when I went to do the pipe splice() system
call (after the discussion here). I elected to do it in V6, which I i) had
running, and ii) know like the back of my hand.

Alas! V6 uses 'int *' everywhere for pointers to structures. It also, in the
pipe code, uses constructs like '(p+1)' to provide wait channels. When I wrote
the new code, I naturally declared my pointers as 'struct inode *ip', or
whatever. However, when I went to do 'sleep(ip+1)', the wrong thing happened!
And since V6 C didn't have coercions, I couldn't win that way. IIRC, I finally
resorted to declaring an 'int *xip', and doing an 'xip = ip' before finally
doing my 'sleep(xip+1)'. Gack!

	  Noel


From paul.winalski at gmail.com  Thu Nov  1 01:47:20 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 31 Oct 2018 11:47:20 -0400
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <20181031043810.GA10775@minnie.tuhs.org>
References: <20181031043810.GA10775@minnie.tuhs.org>
Message-ID: <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>

On 10/31/18, Warren Toomey <wkt at tuhs.org> wrote:
>
>   The POSIX file API is a great example, but not of a deep
>   interface. Rather, it’s a great example of how code with a very
>   complicated interface may look deceptively simple when reduced to C-style
>   function signatures.

For me one of the most important software design principles is that
the simple and most common use cases should be the simplest for the
user to code.  It's OK if complicated things are complicated to code,
but simple things should be kept simple.

I've always thought that the UNIX file primitives very elegantly
adhere to this principle.  Reading a file in UNIX is a simple
open()/read().../close() sequence.  Contrast that with VMS's $QIO or
IBM OS access methods, where the full complexity is not only exposed
in the interface, it must be considered, set up, and controlled by the
user for even the simplest operations.  Multibuffered, asynchronous,
interrupt-driven I/O is more complicated (if not downright clumsy) in
UNIX than in VMS or OS/VS, but that's OK, IMO--it shifts the
complexity burden to those doing complex things.

-Paul W.


From clemc at ccc.com  Thu Nov  1 03:22:08 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 31 Oct 2018 13:22:08 -0400
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
Message-ID: <CAC20D2OF9HLBH_8XmJ52v+BPvsFfEzrcvOy_ZEoQUmPR8sp51Q@mail.gmail.com>

On Wed, Oct 31, 2018 at 12:51 PM Paul Winalski <paul.winalski at gmail.com>
wrote:

> For me one of the most important software design principles is that the
> simple and most common use cases should be the simplest for theuser to
> code.

It's OK if complicated things are complicated to code, but simple things
> should be kept simple.
>
+1 Amen.

>
> I've always thought that the UNIX file primitives very elegantly adhere
> to this principle.  Reading a file in UNIX is a simple open()/read().../close()
> sequence.  Contrast that with VMS's $QIO or IBM OS access methods, where
> the full complexity is not only exposed in the interface, it must be
> considered, set up, and controlled by the
> user for even the simplest operations.

As my friend Tom Texiera once so wisely observered, "*it was not so bad
that QIO had over a 1000 options, it was that each of them had to be test
for on each I/O.*"
I also remember having an argument with Culter about QIO vs UNIX I/O (he
was defending QIO at the time as it was 'better' - as being more
complete).   But I pointed out, that it was interesting that after stream
I/O was added to VMS, most DEC customers (and the internal language
libraries team) had switched to using stream (UNIX style I/O) for most
operations because it was simplier and just as fast.   It was one of the
few times, I saw Dave stop arguing as he really did not have a response.



> Multibuffered, asynchronous, interrupt-driven I/O is more complicated (if
> not downright clumsy) in UNIX than in VMS or OS/VS, but that's OK,
> IMO--it shifts the
> complexity burden to those doing complex things.
>
Exactly, those programs that need to do it, can when they need to.   That
said, because of our VMS experience, we added ASTs (which I tink are
simplier than UNIX signals) and a QIO like call to RTU because the
Real-Time customers coming from VMS needed (wanted) it.  Truth is async
I/O  was really useful for some special cases that we had customers that
really need use it.   But for the most part the simple UNIX 5 I/O calls
were good enough (athough I would still rather AST's).

BTW:  when we added threads we discovered that a lot of the need/use for
async I/O also went away and frankly much of the complexity (clumsiness) of
the async I/O code was not longer needed, as the threading to care of it
and certain was smaller and simplier.

Also, I'll agree it was a tad clumsy, but the old double-dd (ddd) program
(you can find it in the UUNET archives), uses two processes that
communicate via a pipe to do the same trick with a traditional (6th
edition) UNIX I/O system to do some of the same things.  Basically the two
processes, take turns between reading and writing.   Thus the asynchronous
is purely left in the kernel.  The user code is actually very simple.
 There is a pipe that passes a token back and forth as to when the next
read/write can start.  For old UNIX systems lacking async I/O, ddd(8)  was
only way I knew you get a tape drive such as QIC/4 or 8 mm, much less a 1/2
streamer to keep up.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181031/48be9ef5/attachment.html>

From stewart at serissa.com  Thu Nov  1 05:33:37 2018
From: stewart at serissa.com (Lawrence Stewart)
Date: Wed, 31 Oct 2018 15:33:37 -0400
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CAC20D2OF9HLBH_8XmJ52v+BPvsFfEzrcvOy_ZEoQUmPR8sp51Q@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <CAC20D2OF9HLBH_8XmJ52v+BPvsFfEzrcvOy_ZEoQUmPR8sp51Q@mail.gmail.com>
Message-ID: <710E5C36-BCDA-4E9F-A54C-D794497DEBA9@serissa.com>

My version of this:

With JCL, it is as easy to read 1000 tapes as it is to read one tape.

For JCL, substitute the all-singing API of your choice.

On the other hand you can spend a very long time writing code that actually responds correctly to all the failure cases in, say, a TCP stream connection.

-L



From g.branden.robinson at gmail.com  Thu Nov  1 06:57:40 2018
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Wed, 31 Oct 2018 16:57:40 -0400
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
Message-ID: <20181031205738.vb2yba55cdrh5vdt@crack.deadbeast.net>

At 2018-10-31T11:47:20-0400, Paul Winalski wrote:
> On 10/31/18, Warren Toomey <wkt at tuhs.org> wrote:
> >
> >   The POSIX file API is a great example, but not of a deep
> >   interface. Rather, it’s a great example of how code with a very
> >   complicated interface may look deceptively simple when reduced to C-style
> >   function signatures.

Indeed.  It is my hope that in the coming years software engineers will
decline to describe an interface as "simple" until they've seen how much
logic is required to formally verify it.
> 
> For me one of the most important software design principles is that
> the simple and most common use cases should be the simplest for the
> user to code.

Yes.  OpenSSL is an infamous example of design failure in this respect.

However, the term "software design principle" is a bit vague.  More
specifically you're identifying a maxim of good programming interface
design.

What's good for a library API is not necessarily what's good for a
system call interface.  System calls are not really library functions,
and that is why they have had a different section in the manual from day
one.

open/reda/write/(l)seek/close did not primarily constitute, as I think
they were originally conceived, and API; they were there to expose
_primitives_ of the operating system.

The lateness in coming of the C standard I/O library may have been
something of a problem here; an I/O library is exactly where you want to
press your design principle to the maximum.  (On the other hand,
sometimes the design space needs to be explored, and you don't know what
the common cases are going to be because you don't have enough data
points yet.  In that case you expose the primitive operations and study
what bubbles up when programmers apply the DRY principle--they are
future standard library calls in disguise.)

But I suspect another problem, even had stdio.h been around in 1972,
would have been the obsessive false economy of "programming close to the
metal".  Because the C language did that, and because the system call
interface was there and easy to grab a hold of, tons of application
programmers thought they should follow suit, violating Knuth's principle
about optimization with fervor.

> I've always thought that the UNIX file primitives very elegantly
> adhere to this principle.  Reading a file in UNIX is a simple
> open()/read().../close() sequence.  Contrast that with VMS's $QIO or
> IBM OS access methods, where the full complexity is not only exposed
> in the interface, it must be considered, set up, and controlled by the
> user for even the simplest operations.  Multibuffered, asynchronous,
> interrupt-driven I/O is more complicated (if not downright clumsy) in
> UNIX than in VMS or OS/VS, but that's OK, IMO--it shifts the
> complexity burden to those doing complex things.

I haven't programmed on VMS or OS/VS, but again this sounds like a
scenario where a standard I/O library should have existed but didn't (or
was inadequate to the demands placed on it--as stdio itself arguably
still is, with a static global errno variable and an original design
that ignored reentrancy entirely, such that we have to consult manuals
to determine which calls are safe for multi-threaded apps or use in a
signal handler).

Context has to be managed somewhere.  open()/read()/.../close() only
look simple because a lot of context has been pushed down into the
kernel--the list of flags supported by open() has steadily grown over
the years.

The POSIX openat() system call family is a superior design, though still
saddled with a lot of context.  I admit, it is probably more annoying to
use for application programmers who want to use it directly.  That's
because they're trying to solve their problems at the wrong level.  It
irritates them that they have to keep track of their own contexts (in
this case, a file descriptor).  A well-designed library is able to do
this for them, but they want to be close to the metal.  And too many of
them will not do the job adequately themselves, so they demand that the
kernel handle it itself.  Now the system call interface is even less a
set of primitives, and even more something that's "easy to code to" for
sloppy programmers.

That is one way kernel interfaces, memory requirements, and
task-switching times bloat.  How close to the metal does one feel then?

-- 
Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181031/f3e8b4bb/attachment.sig>

From steffen at sdaoden.eu  Thu Nov  1 07:10:35 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 31 Oct 2018 22:10:35 +0100
Subject: [TUHS] First ARPAnet transmission
In-Reply-To: <7w7ei0gkap.fsf@junk.nocrew.org>
References: <alpine.BSF.2.21.9999.1810291159340.58929@aneurin.horsfall.org>
 <20181029021023.GA27974@eureka.lemis.com>
 <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se>
 <CAC20D2N=HEks=2SK4rfHAU09KGAaCThNijeY6WVSH2OZYbh63Q@mail.gmail.com>
 <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com>
 <alpine.BSF.2.21.9999.1810300805170.58929@aneurin.horsfall.org>
 <20181030010931.731C8156E410@mail.bitblocks.com>
 <7w7ei0gkap.fsf@junk.nocrew.org>
Message-ID: <20181031211035.6M26u%steffen@sdaoden.eu>

Lars Brinkhoff wrote in <7w7ei0gkap.fsf at junk.nocrew.org>:
 |Bakul Shah wrote:
 |> Dave Horsfall wrote:
 |>> Abolish DST, I say; it was introduced as a temporary measure during \
 |>> one of 
 |>> the World Wars to increase production or something.
 |> Agree it should be abolished. 
 |
 |Being done in EU.
 --End of <7w7ei0gkap.fsf at junk.nocrew.org>

Jaaa, but with alarming language, and i wonder how many of all
those who voted had simply been trapped by that.
I commented in the according field, that children should not go to
school in the dark, and that i have seen a real night sky only two
times in my life, because of the overexposure through human light
pollution, and the rest i have forgotten.

But whatever, it does not matter of course.  For one i hope that
LED street lights will save a lot of prescious power, and they do
reduce the amount of light that is, how do you say that in
english, streamed upwards.  Of course children must be broken, and
need to learn to find their way through the darkness, to school.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From dave at horsfall.org  Thu Nov  1 07:31:25 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 1 Nov 2018 08:31:25 +1100 (EST)
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>

On Wed, 31 Oct 2018, Paul Winalski wrote:

> I've always thought that the UNIX file primitives very elegantly adhere 
> to this principle. [...]

Until Berkeley introduced sockets, which has the worst API that I've ever 
seen in Unix-land...

Last place I worked, they had a library that simplified it; the 
application said "I am a server on port NNN" and the client said "I want 
to talk to port NNN on 1.2.3.4" etc.

I wish I'd "borrowed" that code when I left.

-- Dave


From pdagog at gmail.com  Thu Nov  1 17:42:31 2018
From: pdagog at gmail.com (Pierre DAVID)
Date: Thu, 1 Nov 2018 08:42:31 +0100
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
Message-ID: <20181101074231.GA4844@vagabond>

On Thu, Nov 01, 2018 at 08:31:25AM +1100, Dave Horsfall wrote:
>On Wed, 31 Oct 2018, Paul Winalski wrote:
>
>>I've always thought that the UNIX file primitives very elegantly 
>>adhere to this principle. [...]
>
>Until Berkeley introduced sockets, which has the worst API that I've 
>ever seen in Unix-land...
>

Do you *really* think that IPC System V primitives are better than 
sockets?

Pierre


From dave at horsfall.org  Thu Nov  1 20:20:46 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 1 Nov 2018 21:20:46 +1100 (EST)
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <20181101074231.GA4844@vagabond>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
Message-ID: <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>

On Thu, 1 Nov 2018, Pierre DAVID wrote:

> Do you *really* think that IPC System V primitives are better than 
> sockets?

Nope; they're even worse, which I didn't think was possible.  The one 
saving grace (IMHO) of SysV was the TTY driver and its cleaner interface.

I did see a proposal a while back (can't remember where/when) to use 
something like open("/dev/net/host/port", ...) to establish a network 
connection (or a server with appropriate flags), in much the same way that 
device files are created dynamically.

With Unix, everything looks like a file, but as I said, the sockets API 
broke that convention, forcing users to work at a much lower level than 
necessary.

I suppose that around now someone will say that Plan 9 fixed all that :-)

-- Dave


From lars at nocrew.org  Thu Nov  1 22:31:53 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 01 Nov 2018 12:31:53 +0000
Subject: [TUHS] Revisions of "C Reference Manual"
Message-ID: <7w1s859dxi.fsf@junk.nocrew.org>

Hello,

Which revisions of the "C Reference Manuals" are known to be out there?


I found this:
https://www.bell-labs.com/usr/dmr/www/cman.pdf

Which seems to match the one from V6:
https://github.com/dspinellis/unix-history-repo/tree/Research-V6-Snapshot-Development/usr/doc/c

"C is also available on the HIS 6070 computer at Murray Hill and and on
the IBM System/370 at Holmdel [3]."


But then there's this:
https://www.princeton.edu/ssp/joseph-henry-project/unix-and-c/bell_labs_1369_001.pdf

"C is also available on the HIS 6070 computer ar Hurray Hill, using a
compiler written bu A. Snyder and currently maintained by S. C. Johnson.
A compiler for the IBM System/360/370 series is under construction."

Due to the description of the IBM compiler, it seems to predate the V6
revision.

Both above revisions use the =+ etc operators.


Finally, this version edited by Snyder:

https://github.com/PDP-10/its/blob/master/doc/c/c.refman

"In addition to the UNIX C compiler, there exist C compilers for the HIS
6000 and the IBM System/370 [2]."

This version documents both += and =+ operators.


From clemc at ccc.com  Thu Nov  1 22:57:39 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Nov 2018 08:57:39 -0400
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
Message-ID: <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>

On Thu, Nov 1, 2018 at 7:48 AM Dave Horsfall <dave at horsfall.org> wrote:

> I did see a proposal a while back (can't remember where/when) to use
> something like open("/dev/net/host/port", ...) to establish a network
> connection (or a server with appropriate flags), in much the same way that
> device files are created dynamically.
>

Dave - that's how the original UNIX ChaosNet code worked and the original
BBN TCP (before sockets).  Apollo used the same scheme with Aegis/Domain
(probably because Larry Allen implemented both UNIX Chaos and Aegis IIRC).

P9 took a different path still (pun intended).

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181101/38f4b998/attachment.html>

From lars at nocrew.org  Thu Nov  1 23:29:20 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 01 Nov 2018 13:29:20 +0000
Subject: [TUHS] Revisions of "C Reference Manual"
In-Reply-To: <7w1s859dxi.fsf@junk.nocrew.org> (Lars Brinkhoff's message of
 "Thu, 01 Nov 2018 12:31:53 +0000")
References: <7w1s859dxi.fsf@junk.nocrew.org>
Message-ID: <7wwopx7wpb.fsf@junk.nocrew.org>

> But then there's this:
> https://www.princeton.edu/ssp/joseph-henry-project/unix-and-c/bell_labs_1369_001.pdf
>
> "C is also available on the HIS 6070 computer at Murray Hill, using a
> compiler written by A. Snyder and currently maintained by S. C. Johnson.
> A compiler for the IBM System/360/370 series is under construction."
>
> Due to the description of the IBM compiler, it seems to predate the V6
> revision.

Here's a revision from 1974:
https://9p.io/cm/cs/who/dmr/cman74.pdf

"The language is also available on the HIS 6000 and IBM S/370."

Does this imply the Princeton copy is from before 1974?


Also Appendix A from the K&R book has the text from the C Reference
Manual.


From clemc at ccc.com  Thu Nov  1 23:50:58 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Nov 2018 09:50:58 -0400
Subject: [TUHS] Revisions of "C Reference Manual"
In-Reply-To: <7w1s859dxi.fsf@junk.nocrew.org>
References: <7w1s859dxi.fsf@junk.nocrew.org>
Message-ID: <CAC20D2PW8PgWm=UJ+AV+snh+qBWsxqywU+JySkMqfJNeBNty+g@mail.gmail.com>

4th and 5th Editions refer to a reference manual.   Check out the 4th
Edition man pages:
https://www.tuhs.org//Archive/Distributions/Research/Dennis_v4/

running cc.1 thru nroff reveals:

SEE ALSO

       `C reference manual'

The .th macro dates the man page as 03/15/72

I know I learned C by reading the UNIX source code and having some sort of
a reference manual with the 5th edition; but I can not find a document in
my archives.  I'll keep looking but I syspect that was lost.

Clem
ᐧ

On Thu, Nov 1, 2018 at 9:20 AM Lars Brinkhoff <lars at nocrew.org> wrote:

> Hello,
>
> Which revisions of the "C Reference Manuals" are known to be out there?
>
>
> I found this:
> https://www.bell-labs.com/usr/dmr/www/cman.pdf
>
> Which seems to match the one from V6:
>
> https://github.com/dspinellis/unix-history-repo/tree/Research-V6-Snapshot-Development/usr/doc/c
>
> "C is also available on the HIS 6070 computer at Murray Hill and and on
> the IBM System/370 at Holmdel [3]."
>
>
> But then there's this:
>
> https://www.princeton.edu/ssp/joseph-henry-project/unix-and-c/bell_labs_1369_001.pdf
>
> "C is also available on the HIS 6070 computer ar Hurray Hill, using a
> compiler written bu A. Snyder and currently maintained by S. C. Johnson.
> A compiler for the IBM System/360/370 series is under construction."
>
> Due to the description of the IBM compiler, it seems to predate the V6
> revision.
>
> Both above revisions use the =+ etc operators.
>
>
> Finally, this version edited by Snyder:
>
> https://github.com/PDP-10/its/blob/master/doc/c/c.refman
>
> "In addition to the UNIX C compiler, there exist C compilers for the HIS
> 6000 and the IBM System/370 [2]."
>
> This version documents both += and =+ operators.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181101/40919afc/attachment.html>

From rminnich at gmail.com  Fri Nov  2 00:19:50 2018
From: rminnich at gmail.com (ron minnich)
Date: Thu, 1 Nov 2018 07:19:50 -0700
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
Message-ID: <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>

On Thu, Nov 1, 2018 at 7:05 AM Clem Cole <clemc at ccc.com> wrote:

>
> P9 took a different path still (pun intended).

as in: http://doc.cat-v.org/plan_9/4th_edition/papers/net/

It shows that you can use the pathname model for networks, And it
shows one way to get it right. There are others.

Here's a simple example of what get it right means:
there are *no* commands on Plan 9 that end in 6. No ping6, for
example. Plan 9 did not fall over sideways, as Unix did, when
infiiniband introduced 20 octet addresses, which are
the ip6 address and "more".

Just look at how many sockaddr_* there are Linux nowadays, including
those odd ones that have a name starting with a null byte. In Plan 9
there are 1, since a sockaddr in plan 9 is ... a string.

That's not to say plan 9 got it perfect. it's just to say that one can
use the Unix model of pathnames, open/read/write/close, for networks
and IPC in general (even pipes).

It's just a shame nobody's caught on yet ;-)

And, to repeat, a bunch of us in the 80s tried to implement the idea
of /dev/net/host/port (mind was in AmigaDOS), and it fails badly for
all kinds of reasons.
simple one:
what's the implications of
mv /dev/net/harv/20 /dev/net/prep/35

what happens? If only somebody could only find Rob's talk which delves
into this in such nice detail ...

In my view, what went wrong with Unix networking 40 years ago is that
it broke from the Unix model, i.e. that resources are accessed via
path names, and went with binary descriptors as paths. But what can
you do? Synthetics were yet to be created.

ron


From clemc at ccc.com  Fri Nov  2 00:41:53 2018
From: clemc at ccc.com (Clem Cole)
Date: Thu, 1 Nov 2018 10:41:53 -0400
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
 <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>
Message-ID: <CAC20D2N_AnLUYeSDAs+G3QLZbOxja-hExA_FdAuMasUb8ndesw@mail.gmail.com>

On Thu, Nov 1, 2018 at 10:20 AM ron minnich <rminnich at gmail.com> wrote:

> In my view, what went wrong with Unix networking 40 years ago is that it
> broke from the Unix model, i.e. that resources are accessed via path
> names, and went with binary descriptors as paths.
>
Agreed.

And I think somthing else where P9 differed from UNIX was dealing with OOB
(control) information (*i.e.* ioctl(2) was a terrible misstake).   Dennis
and Ken created ioctl(2) with v7 as a generalization of stty/gtty from the
TTY handler.  At the time, it seemed like a reasonable way to handle those
'small things that need to be tweeked - like baud rate or canonicalization;
but ioctl(2) quickly got abused as the universal end-around, and those
things caused also sorts of issues (also being a binary interface only made
it worse, although on the PDP-11 it made sense for size reasons).
 Creating a seperate interface from the 'file' to orchestrate/control the
I/O and controlling that as a set of strings not binaries, seems like a more
sane idea.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181101/53d28fc1/attachment.html>

From jnc at mercury.lcs.mit.edu  Fri Nov  2 01:39:12 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Thu,  1 Nov 2018 11:39:12 -0400 (EDT)
Subject: [TUHS] Unix APIs: elegant or not?
Message-ID: <20181101153912.4583118C0CA@mercury.lcs.mit.edu>

    > From: Clem Cole

    > (probably because Larry Allen implemented both UNIX Chaos and Aegis IIRC).

Maybe there are two Larry Allen's - the one who did networking stuff at
MIT-LCS was Larry W. Allen, and I'm pretty sure he didn't do Unix CHAOS code
(he was part of our group at LCS, and we only did TCP/IP stuff; someone over
in EE had a Unix with CHAOS code at the time, so it pre-dated his time with
us).

	Noel



From imp at bsdimp.com  Fri Nov  2 02:43:54 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 1 Nov 2018 10:43:54 -0600
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CAC20D2N_AnLUYeSDAs+G3QLZbOxja-hExA_FdAuMasUb8ndesw@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
 <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>
 <CAC20D2N_AnLUYeSDAs+G3QLZbOxja-hExA_FdAuMasUb8ndesw@mail.gmail.com>
Message-ID: <CANCZdfr9bEuL3c7ZKd3-6cj18VRcP9+jjeXLRXfgQTixzmhG6Q@mail.gmail.com>

On Thu, Nov 1, 2018 at 9:38 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Thu, Nov 1, 2018 at 10:20 AM ron minnich <rminnich at gmail.com> wrote:
>
>> In my view, what went wrong with Unix networking 40 years ago is that it
>> broke from the Unix model, i.e. that resources are accessed via path
>> names, and went with binary descriptors as paths.
>>
> Agreed.
>
> And I think somthing else where P9 differed from UNIX was dealing with OOB
> (control) information (*i.e.* ioctl(2) was a terrible misstake).   Dennis
> and Ken created ioctl(2) with v7 as a generalization of stty/gtty from the
> TTY handler.  At the time, it seemed like a reasonable way to handle those
> 'small things that need to be tweeked - like baud rate or canonicalization;
> but ioctl(2) quickly got abused as the universal end-around, and those
> things caused also sorts of issues (also being a binary interface only
> made it worse, although on the PDP-11 it made sense for size reasons).
>  Creating a seperate interface from the 'file' to orchestrate/control the
> I/O and controlling that as a set of strings not binaries, seems like a
> more sane idea.
>

There's another school of thought too that says the kernel has no business
parsing strings with all the security implications of doing so...

Warner


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

From rminnich at gmail.com  Fri Nov  2 02:48:38 2018
From: rminnich at gmail.com (ron minnich)
Date: Thu, 1 Nov 2018 09:48:38 -0700
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CANCZdfr9bEuL3c7ZKd3-6cj18VRcP9+jjeXLRXfgQTixzmhG6Q@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
 <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>
 <CAC20D2N_AnLUYeSDAs+G3QLZbOxja-hExA_FdAuMasUb8ndesw@mail.gmail.com>
 <CANCZdfr9bEuL3c7ZKd3-6cj18VRcP9+jjeXLRXfgQTixzmhG6Q@mail.gmail.com>
Message-ID: <CAP6exY+ZxHC3H=jUt0G1kGPJQdMUid40Lt4aDkf80tevC9K1dg@mail.gmail.com>

On Thu, Nov 1, 2018 at 9:44 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> There's another school of thought too that says the kernel has no business
> parsing strings with all the security implications of doing so...
>
>
yeah, it's an interesting question. But Unix is based on parsing strings.
The kernel already parses lots of strings for paths, for all kinds of
reasons, so adding another element in the kernel that uses paths seems
acceptable.

The bigger problem for Plan 9 that started to bite was i8n. All the Plan 9
messages are English, oops. All the control messages are english. And so
on.

And, further, that network architecture I referenced is much less efficient
than the BSD model -- 5 system calls per accept! so that was starting to
hit us here on the Akaros project, since we imported the entire Plan 9
network stack into akaros, along with the drivers. Linux left us in the
dust on network connections/second. We were going to change it had Akaros
continued.

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

From imp at bsdimp.com  Fri Nov  2 02:56:44 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 1 Nov 2018 10:56:44 -0600
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CAP6exY+ZxHC3H=jUt0G1kGPJQdMUid40Lt4aDkf80tevC9K1dg@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
 <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>
 <CAC20D2N_AnLUYeSDAs+G3QLZbOxja-hExA_FdAuMasUb8ndesw@mail.gmail.com>
 <CANCZdfr9bEuL3c7ZKd3-6cj18VRcP9+jjeXLRXfgQTixzmhG6Q@mail.gmail.com>
 <CAP6exY+ZxHC3H=jUt0G1kGPJQdMUid40Lt4aDkf80tevC9K1dg@mail.gmail.com>
Message-ID: <CANCZdfqSv7U+fOyoX2YeD7UZpr8Pi6sWJm_jCFr=xjRhE808qw@mail.gmail.com>

On Thu, Nov 1, 2018 at 10:48 AM ron minnich <rminnich at gmail.com> wrote:

>
>
> On Thu, Nov 1, 2018 at 9:44 AM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> There's another school of thought too that says the kernel has no
>> business parsing strings with all the security implications of doing so...
>>
>>
> yeah, it's an interesting question. But Unix is based on parsing strings.
> The kernel already parses lots of strings for paths, for all kinds of
> reasons, so adding another element in the kernel that uses paths seems
> acceptable.
>

Well, if the nose of a camel comes in under the tent, the rest of the camel
is sure to follow... Parsing a string path is rock simple, but are there
two arguments or three for this command, and what happens if they are too
long, or negative when you expect and fd, or or or. The CVE-archive is
littered with people who thought parsing in the kernel was simple and
easy...


> The bigger problem for Plan 9 that started to bite was i8n. All the Plan 9
> messages are English, oops. All the control messages are english. And so
> on.
>
> And, further, that network architecture I referenced is much less
> efficient than the BSD model -- 5 system calls per accept! so that was
> starting to hit us here on the Akaros project, since we imported the entire
> Plan 9 network stack into akaros, along with the drivers. Linux left us in
> the dust on network connections/second. We were going to change it had
> Akaros continued.
>

That's the other reason to not do stings in the kernel: parsing is takes
time.

I'll grant there's a balance here: A single int fd is nice so you don't
have to pass a pointer to the device call function and provides a level of
abstraction that blocks many bad data attacks. But even with this interface
there's been issues with improper range checks for some interfaces.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181101/9d431283/attachment.html>

From aap at papnet.eu  Fri Nov  2 03:21:23 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Thu, 1 Nov 2018 18:21:23 +0100
Subject: [TUHS] Reconstructed and newly set UNIX Manual
In-Reply-To: <20181026194636.GA11870@indra.papnet.eu>
References: <20181026194636.GA11870@indra.papnet.eu>
Message-ID: <20181101172123.GA29612@indra.papnet.eu>

And the V1 manual is done as well. Almost to the day 47 years
after it was first printed.

I'll just link everything again for simplicity:
https://github.com/aap/unixman
http://squoze.net/UNIX/v1man/ http://squoze.net/UNIX/v1man.tgz
http://squoze.net/UNIX/v2man/ http://squoze.net/UNIX/v2man.tgz
http://squoze.net/UNIX/v3man/ http://squoze.net/UNIX/v3man.tgz
http://squoze.net/UNIX/v4man/ http://squoze.net/UNIX/v4man.tgz
http://squoze.net/UNIX/v5man/ http://squoze.net/UNIX/v5man.tgz
http://squoze.net/UNIX/v6man/ http://squoze.net/UNIX/v6man.tgz

I fixed some issues with the tty 37 -> html filter (it now turns
half-line feeds into full line feeds. together with some CSS this looks
acceptable). Some typos in V2 were also fixed.
The nroff output now prints the header once, otherwise no pagination.
I will leave pagination for when I can convert nroff output to pdf.
This means all nroff output has changed from the previous version.

This has been quite an exhausting task, but fortunately it has also
been quite educational. I now feel like some sort of UNIX scholar.

I would really appreciate it if people could proof read some of this.


aap


From bakul at bitblocks.com  Fri Nov  2 15:24:27 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 01 Nov 2018 22:24:27 -0700
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: Your message of "Thu, 01 Nov 2018 09:48:38 -0700."
 <CAP6exY+ZxHC3H=jUt0G1kGPJQdMUid40Lt4aDkf80tevC9K1dg@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <CAC20D2M=q2zJHBq+730BR0yMJHqGoyUPcEUzYBoOMd+=zBEZsA@mail.gmail.com>
 <CAP6exYKfkS9J8Mgv0zP_E8xw5Tfg4Eii7iwd1LSbYG+DmgZXsQ@mail.gmail.com>
 <CAC20D2N_AnLUYeSDAs+G3QLZbOxja-hExA_FdAuMasUb8ndesw@mail.gmail.com>
 <CANCZdfr9bEuL3c7ZKd3-6cj18VRcP9+jjeXLRXfgQTixzmhG6Q@mail.gmail.com>
 <CAP6exY+ZxHC3H=jUt0G1kGPJQdMUid40Lt4aDkf80tevC9K1dg@mail.gmail.com>
Message-ID: <20181102052434.93EC6156E40C@mail.bitblocks.com>

On Thu, 01 Nov 2018 09:48:38 -0700 ron minnich <rminnich at gmail.com> wrote:
>
> On Thu, Nov 1, 2018 at 9:44 AM Warner Losh <imp at bsdimp.com> wrote:
> >
> > There's another school of thought too that says the kernel has no business
> > parsing strings with all the security implications of doing so...

Which is more a function of C. A proper string type might've
helped. I would argue it is *easier* to debug string based
stuff than all those ioctls using magic numbers replaced with
#defines.

> And, further, that network architecture I referenced is much less efficient
> than the BSD model -- 5 system calls per accept! so that was starting to
> hit us here on the Akaros project, since we imported the entire Plan 9
> network stack into akaros, along with the drivers. Linux left us in the
> dust on network connections/second. We were going to change it had Akaros
> continued.

What sort of changes were you contemplating?

I view(ed) 9p more as a prototype.


From scj at yaccman.com  Sun Nov  4 07:50:49 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 03 Nov 2018 14:50:49 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <7w5zxjg88e.fsf@junk.nocrew.org>
Message-ID: <5af2ef1c292fc7cedddf2389a438e8c9ae86cd64@webmail.yaccman.com>


One thing that was supported on PCC for many years was the ability to
generate GE/Honeywell 6-bit character constants, using the back quote
(`) character.  I remember trying it in the late 80's on a shipping
Sun machine and seeing that it was still present in the grammar, and,
as nearly as I could remember, still produced the correct answer.

Steve

----- Original Message -----
From: "Lars Brinkhoff" <lars at nocrew.org>
To:"Warner Losh" <imp at bsdimp.com>
Cc:"Steve Johnson" <scj at yaccman.com>, "The Eunuchs Hysterical Society"
<tuhs at tuhs.org>
Sent:Tue, 30 Oct 2018 08:16:17 +0000
Subject:Re: [TUHS] Archaic yacc C grammar

 Warner Losh wrote:
 > Steve Johnson wrote:
 > We actually had a pretty good system for making changes like
 > that. First, we would change the compiler to accept both the old
and
 > the new. Then we would produce a warning that on a particular date
 > the old would no longer work. Then we made the old an error and
 > printed a message about how to fix it.
 >
 > How long a transition period did you typically have?

 I heard the V7 compiler still supports old B style initialization
 "int x 42;". So in some cases, a really long time.


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

From scj at yaccman.com  Sun Nov  4 08:14:08 2018
From: scj at yaccman.com (Steve Johnson)
Date: Sat, 03 Nov 2018 15:14:08 -0700
Subject: [TUHS] Archaic yacc C grammar
In-Reply-To: <20181031005800.GA5670@mcvoy.com>
Message-ID: <135f4f9d6aa38aac485afb158ec1decd27922e67@webmail.yaccman.com>



    ----- Original Message -----
    From:"Larry McVoy" <lm at mcvoy.com>

    ...
     I get that it doesn't scale but man, oh man, do I love the
early Unix
    data structures that had one namespace. I kinda wish you hadn't
fixed
    that Steve.

What was the push that made you fix it?

It came from Dennis, so I can't say why he decided to change it.  The
argument for it is that many structures would have similar names and
similar functions, such as "next" and "prev" in linked lists.  
Adding a new linked list action could be done much more easily by
copying the code and changing the declaration, instead of having to
change ab_next into cd_next, and then dealing with the inevitable
typos that would sneak a use of ab_next into code for cd.

Just to clarify, from the beginning I considered C to be Dennis'
language.  I would make suggestions, and sometimes he adopted them
(I'm responsible for ^ as the exclusive OR, for example).  In one
case, with casts, we were porting Unix to the 32-bit Interdata and
desparately needed a cast operator, but couldn't find a syntax that we
liked that was general enough to handle casts to, for example,
structure pointers or function pointers.  Matters were approaching a
crisis, and one evening I played with the yacc grammar and worked out
the strengths and weaknesses of the top three candidates.  I
suggested the one that I felt was best, and that was what was adopted.
  The simple rule was that you formed a cast by taking a declaration
of what you wanted the result to be, remove the variable being
declared, and enclose the rest in parens.  I had implemented it and
saw that it worked (because the port was based on PCC, there wasn't
nearly the pressure to change the PDP-11 compiler).   The fact that
we could explain the syntax in one sentence led us to feel like it
would be reasonable.   The problem, of course, is that we didn't put
anything back where the variable had been, so when you encounter a
nontrivial cast you have to enumerate all the possible places a
variable might be and determine which one is syntactically correst
while your brain turns to mush... 

Steve


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

From cmhanson at eschatologist.net  Sun Nov  4 20:49:00 2018
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sun, 4 Nov 2018 02:49:00 -0800
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <20181031043810.GA10775@minnie.tuhs.org>
References: <20181031043810.GA10775@minnie.tuhs.org>
Message-ID: <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>

If anyone ever asks me about the elegance of UNIX, there’s one word, or really term, that springs to mind: EINTR.

The fact that man pages on modern systems still describe calls as returning -1 with errno set to EINTR baffles me.

  -- Chris



From cmhanson at eschatologist.net  Sun Nov  4 20:53:23 2018
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sun, 4 Nov 2018 02:53:23 -0800
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
Message-ID: <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>

On Nov 1, 2018, at 3:20 AM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> With Unix, everything looks like a file, but as I said, the sockets API broke that convention, forcing users to work at a much lower level than necessary.

This was broken from the start though, and always really meant everything looks like a file *descriptor*, not a path in the filesystem.

There are tons of non-file descriptor namespaces on UNIX platforms. At least some later systems have tried to create a hierarchical “object” abstraction of which file descriptors are just one subtype.

  -- Chris



From arnold at skeeve.com  Sun Nov  4 22:28:22 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 04 Nov 2018 05:28:22 -0700
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
Message-ID: <201811041228.wA4CSMIA017639@freefriends.org>

Chris Hanson <cmhanson at eschatologist.net> wrote:

> If anyone ever asks me about the elegance of UNIX, there’s one word, or really term, that springs to mind: EINTR.
>
> The fact that man pages on modern systems still describe calls as returning -1 with errno set to EINTR baffles me.
>
>   -- Chris
>

Can you explain this some more?  This sounds like a claim that UNIX
isn't elegant.  But I'm not following whatever it is you're saying.

Thanks,

Arnold


From imp at bsdimp.com  Sun Nov  4 23:35:47 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 4 Nov 2018 06:35:47 -0700
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
Message-ID: <CANCZdfq7SdnvR+p0iH3viP7Q7Zi4sNhcq+o_QMCX8g9+=F_m0g@mail.gmail.com>

On Sun, Nov 4, 2018, 4:28 AM Chris Hanson <cmhanson at eschatologist.net wrote:

> If anyone ever asks me about the elegance of UNIX, there’s one word, or
> really term, that springs to mind: EINTR.
>
> The fact that man pages on modern systems still describe calls as
> returning -1 with errno set to EINTR baffles me.
>

Why? It's still a thing...

Warner

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

From lars at nocrew.org  Sun Nov  4 23:48:06 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 04 Nov 2018 13:48:06 +0000
Subject: [TUHS] PDP-11/VAX Unix Chaosnet
Message-ID: <7w36sh3qeh.fsf@junk.nocrew.org>

Hello,

According to this: https://lm-3.github.io/amber.html#The-Unix-Implementation
there were Chaosnet for PDP-11 Unix V7, and VAX Berkeley Unix.  Does
anyone have a copy of this?

Thes repository: https://github.com/LM-3/chaos may or may not have
something of that left, but has been hacked for Linux.


From clemc at ccc.com  Mon Nov  5 00:59:45 2018
From: clemc at ccc.com (Clem cole)
Date: Sun, 4 Nov 2018 06:59:45 -0800
Subject: [TUHS] PDP-11/VAX Unix Chaosnet
In-Reply-To: <7w36sh3qeh.fsf@junk.nocrew.org>
References: <7w36sh3qeh.fsf@junk.nocrew.org>
Message-ID: <FDB3AB97-2412-41B1-808E-8E30AA533CE2@ccc.com>

Yes assuming I can read the tape

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Nov 4, 2018, at 5:48 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
> 
> Hello,
> 
> According to this: https://lm-3.github.io/amber.html#The-Unix-Implementation
> there were Chaosnet for PDP-11 Unix V7, and VAX Berkeley Unix.  Does
> anyone have a copy of this?
> 
> Thes repository: https://github.com/LM-3/chaos may or may not have
> something of that left, but has been hacked for Linux.


From rminnich at gmail.com  Mon Nov  5 01:34:03 2018
From: rminnich at gmail.com (ron minnich)
Date: Sun, 4 Nov 2018 07:34:03 -0800
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>
Message-ID: <CAP6exYLvcAeR1Mb3A2GcEo+A5QH0zjG8SUR22pHWf4etDtvtoA@mail.gmail.com>

On Sun, Nov 4, 2018 at 4:00 AM Chris Hanson <cmhanson at eschatologist.net> wrote:

> This was broken from the start though, and always really meant everything looks like a file *descriptor*, not a path in the filesystem.

OK, I only got into this game in 1976, and a lot had happened in Unix by then,
and maybe you saw some earlier stuff. But certainly in 1976, as
compared to the other 4 PDP-11 operating systems I was using,
the fact that resources had names visible to every program was very
important  to us. On the competitor systems the naming would be built
into individual programs,
e.g. PIP or (non-PDP11) the MPE fcopy program, one of the few programs
on that system where you could name, e.g., the tape drive on your
terminal.

Being able to use a path name for resources was a very big deal for us
at the time. And we didn't say file descriptors, we said names.

Hence, I rate your comment as "interesting if true" but I see no
evidence to support it.

ron


From imp at bsdimp.com  Mon Nov  5 03:06:36 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 4 Nov 2018 10:06:36 -0700
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CAP6exYLvcAeR1Mb3A2GcEo+A5QH0zjG8SUR22pHWf4etDtvtoA@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>
 <CAP6exYLvcAeR1Mb3A2GcEo+A5QH0zjG8SUR22pHWf4etDtvtoA@mail.gmail.com>
Message-ID: <CANCZdfr9XOf49KaG8DhmjrJQZXaae7pBow8rnomohfXF6MXt1A@mail.gmail.com>

On Sun, Nov 4, 2018 at 9:31 AM ron minnich <rminnich at gmail.com> wrote:

> On Sun, Nov 4, 2018 at 4:00 AM Chris Hanson <cmhanson at eschatologist.net>
> wrote:
>
> > This was broken from the start though, and always really meant
> everything looks like a file *descriptor*, not a path in the filesystem.
>
> OK, I only got into this game in 1976, and a lot had happened in Unix by
> then,
> and maybe you saw some earlier stuff. But certainly in 1976, as
> compared to the other 4 PDP-11 operating systems I was using,
> the fact that resources had names visible to every program was very
> important  to us. On the competitor systems the naming would be built
> into individual programs,
> e.g. PIP or (non-PDP11) the MPE fcopy program, one of the few programs
> on that system where you could name, e.g., the tape drive on your
> terminal.
>
> Being able to use a path name for resources was a very big deal for us
> at the time. And we didn't say file descriptors, we said names.
>
> Hence, I rate your comment as "interesting if true" but I see no
> evidence to support it.
>

It depends on what you did...

Tapes were always special. You could access them via a named interface, but
it was tricky. Tapes are stateful creatures, and some programs wanted
stateful, others wanted stateless. So you got different devices to do
different behavior. Easy to oops and use the rmt0 instead of the nrmt0
device. So while it was a file, it was a file that had odd state you didn't
have disks.

Serial ports were worse. There you had no way to control the serial port
except with fancy extra programs. There was no /dev/ttyd0.9600.8N1 devnode
to open. If you wanted 9600 baud, you had to either hack the driver to do
that on open, or you had to hack your programs to know they were talking to
a special thing and needed special code to cope (raw vs cooked was another
one). so, sure, it was file based, but not entirely file based as you had
to escape to either hacky system calls (v6 and earlier) or later
generalized ioctls (v7 and later).

Every other snowflake device had it's own config program that you had to
run (or ioctls your data collection programs had to do). Setting up the
sampling rates for the A2D, or the signal strength for an IRIG generator or
whatever.

So sure, you could address these devices by a file name, but you couldn't
"cp config /dev/irig" or "cat /dev/ttyd0.2400.7O2" to get data flowing on
the devices, so their addresses in the filesystem namespace were of limited
value since some files were more special than others.

I'm not sure plan-9 solved this by having a second device side-channel
either in its attempt to try a different approach to side-channel
communications than ioctl(2).

Network sockets are a logical conclusion to this state of affairs, btw. All
the plethera of new system calls for them could have been done as ioctls,
though the generic processing stuff for ioctls would have gotten in the way
of some of the socket API. It's another twist on the baud rate problem: I
need to communicate metadata about how to do things to the driver... And in
this case, a lot of the 'how to do things' is negotiated via a different
side channel (routed, ARP, etc) and so you no longer had a raw physical
network device to open, but a logical, cooked one that you interacted at
the top of the stack to and all those other details were abstracted out /
taken care of in other ways. It's unfortunate that you can't just open
"/dev/net/sri-nic.arpa" and have it do the right thing, but files kinda
want to be stateless and there's a lot of state about what you want to do
with that open command...

And while mounting allowed one to get files from a disk, it wasn't so good
at doing things dynamically (as the original system were quite static) and
required a number of ad-hoc hacks to make work right. block vs character
devices showed early on a crack in the uniformity.

So while I love the ideal, I also see how the practical side of things
forced us down the path we're down, ugly warts and all. I'd love to see
someone start with V7ish level of kernel, but add the modern things like
devfs (so one could pass 'state' strings to drivers on 'open' and have them
accept/reject them to get around some of these issues), as well as provide
all objects in a namespace that's sane and mostly enumerable. For that
you'd need new abstractions (like saying that all drivers don't interact
via cdev-nodes like today, but instead present a filesystem-like interface
so you'd open /dev/tty/d0/9600n1/hw-flow and the tty driver would get a
message for its d0 instance of 9600n1/hw-flow, though this would break
dirent(2)). In this world, you could have most of the crazy encoded into a
path for network operations as well... though I have doubts you could do it
in as a performant manner as sockets).

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181104/0789bdfc/attachment.html>

From bakul at bitblocks.com  Mon Nov  5 04:52:25 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 4 Nov 2018 10:52:25 -0800
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>
Message-ID: <3694A06C-26E9-4325-92AB-7A937B8D82B9@bitblocks.com>



> On Nov 4, 2018, at 2:53 AM, Chris Hanson <cmhanson at eschatologist.net> wrote:
> 
>> On Nov 1, 2018, at 3:20 AM, Dave Horsfall <dave at horsfall.org> wrote:
>> 
>> With Unix, everything looks like a file, but as I said, the sockets API broke that convention, forcing users to work at a much lower level than necessary.
> 
> This was broken from the start though, and always really meant everything looks like a file *descriptor*, not a path in the filesystem.

A “file” descriptor is very much like a capability, a handle.
This is separate from hierarchical naming intended for humans.
They are both needed. An ability to name something doesn’t
give you an automatic right to access it. And you don’t always
need to name something. For instance creating a pipe. The
third feature was capturing IO operations to a rather diverse set
of devices and files in a relatively simple interface. The fourth
feature that first attracted me first to Unix was its simple scheme
of major, minor device numbers. The “elegance” of Unix was that
you could get a lot done using a few abstractions. They were not
perfect but were good enough for the most part.




From dave at horsfall.org  Mon Nov  5 05:47:24 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Nov 2018 06:47:24 +1100 (EST)
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
Message-ID: <alpine.BSF.2.21.9999.1811050645000.78183@aneurin.horsfall.org>

On Sun, 4 Nov 2018, Chris Hanson wrote:

> The fact that man pages on modern systems still describe calls as 
> returning -1 with errno set to EINTR baffles me.

Err, how else would you do it?  You do understand the purpose of EINTR, 
don't you?

-- Dave


From rminnich at gmail.com  Mon Nov  5 06:00:51 2018
From: rminnich at gmail.com (ron minnich)
Date: Sun, 4 Nov 2018 12:00:51 -0800
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <CANCZdfr9XOf49KaG8DhmjrJQZXaae7pBow8rnomohfXF6MXt1A@mail.gmail.com>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <CABH=_VQ2U3UvtNSDtmMpfd2Ap9JT4Zbag0qYcN2yYwyYU5_TuQ@mail.gmail.com>
 <alpine.BSF.2.21.9999.1811010827590.78183@aneurin.horsfall.org>
 <20181101074231.GA4844@vagabond>
 <alpine.BSF.2.21.9999.1811012104130.78183@aneurin.horsfall.org>
 <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net>
 <CAP6exYLvcAeR1Mb3A2GcEo+A5QH0zjG8SUR22pHWf4etDtvtoA@mail.gmail.com>
 <CANCZdfr9XOf49KaG8DhmjrJQZXaae7pBow8rnomohfXF6MXt1A@mail.gmail.com>
Message-ID: <CAP6exYJ-3aaZaKsCK=yNfUpy+nEVBzmPfTFVCcapnrA2NW_sAw@mail.gmail.com>

On Sun, Nov 4, 2018 at 9:06 AM Warner Losh <imp at bsdimp.com> wrote:
> Every other snowflake device had it's own config program that you had to run (or ioctls your data collection programs had to do). Setting up the sampling rates for the A2D, or the signal strength for an IRIG generator or whatever.


I'm not saying that having a name for everything solved the world's
problems. I'm saying that in Unix, as of the mid 1970s, things could
be named, including devices. And if you weren't using the other
systems available at the time, it's almost impossible to appreciate
just how important that was. I also used contemporary systems such as
OS/MVS, where even in the mid 70s we were accessing data sets by using
a disk and block #.

Although there is an analogy: do you prefer to name your personal
machine 2130706433 or localhost?

ron


From gtaylor at tnetconsulting.net  Mon Nov  5 06:51:08 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 4 Nov 2018 13:51:08 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
Message-ID: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>

Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central 
directory on Unix?

I'm contemplating playing with them for historical reasons.

As such, I'm wondering what the current evolution is for a pure Unix 
environment.  Read:  No Active Directory.  Is there a current central 
directory service for Unix (or Linux)?  If so, what is it?

I'm guessing it's LDAP combined with Kerberos, but I'm not sure.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181104/e3d11a87/attachment.bin>

From dave at horsfall.org  Mon Nov  5 06:52:03 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Nov 2018 07:52:03 +1100 (EST)
Subject: [TUHS] Unix half a billion seconds old in 1985
Message-ID: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>

UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20 
1985 GMT (measuring since the time(2) epoch).
		-- Andy Tannenbaum

Hmmm...  According to my rough calculations, it hit a billion (US) seconds 
around 2000.

-- Dave


From cmhanson at eschatologist.net  Mon Nov  5 07:34:10 2018
From: cmhanson at eschatologist.net (Chris Hanson)
Date: Sun, 4 Nov 2018 13:34:10 -0800
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <201811041228.wA4CSMIA017639@freefriends.org>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
 <201811041228.wA4CSMIA017639@freefriends.org>
Message-ID: <C84DDCBC-7699-4078-8E92-521589FADB2C@eschatologist.net>

On Nov 4, 2018, at 4:28 AM, arnold at skeeve.com wrote:
> 
> Chris Hanson <cmhanson at eschatologist.net> wrote:
> 
>> If anyone ever asks me about the elegance of UNIX, there’s one word, or really term, that springs to mind: EINTR.
>> 
>> The fact that man pages on modern systems still describe calls as returning -1 with errno set to EINTR baffles me.
> 
> Can you explain this some more?  This sounds like a claim that UNIX
> isn't elegant.  But I'm not following whatever it is you're saying.

Every piece of code that wants to call, say, read(2) needs to handle not only real errors but also needs to special-case EINTR and retry the read. Thus you should virtually never use read(2), only ever something like this:

    ssize_t safe_read(int fd, void *buf, size_t buf_size)
    {
        ssize_t rc;
        do {
            rc = read(fd, buf, buf_size);
        } while ((rc == -1) && (errno == EINTR));
        return rc;
    }

And do this for every classic system call, since virtually no client code should ever have to care about EINTR. It was early an implementation expediency that became API and that everyone now has to just deal with because you can’t expect the system call interface you use to do this for you.

This is the sort of wart that should’ve been fixed by System V and/or BSD 4 at latest.

  — Chris




From ben at cogs.com  Mon Nov  5 07:46:12 2018
From: ben at cogs.com (Ben Greenfield)
Date: Sun, 4 Nov 2018 16:46:12 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
Message-ID: <2C8E05E9-E710-4482-BEBA-792D85C4A20F@cogs.com>


I had the great pleasure of learning on an NIS/NetInfo/Active Directory. I’m not sure what the windows service was called but we would edit all our clients to point to a sun solaris 6-8 NIS server.

Sun bought some LDAP company with planet in the name and I never in months of trying could get their LDAP script to set-up the LDAP environment.

Over time we added Open Directory which is what OS X used after NetInfo. I still use directory services and have used OS X Server’s Directory Server as a kerberized LDAP server or Linux and server user’s accounts. This required get the Linux servers to bind using SASL to my kerbierized server.

That has been my experience and with the changes coming to OS X server I’m now moving towards OpenBSD but plan on bringing the OS X and it’s Directory Server with me as long as it lasts:)

Let me know if you have specific questions,

Ben


> On Nov 4, 2018, at 3:51 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central directory on Unix?
> 
> I'm contemplating playing with them for historical reasons.
> 
> As such, I'm wondering what the current evolution is for a pure Unix environment.  Read:  No Active Directory.  Is there a current central directory service for Unix (or Linux)?  If so, what is it?
> 
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



From jnc at mercury.lcs.mit.edu  Mon Nov  5 08:37:46 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  4 Nov 2018 17:37:46 -0500 (EST)
Subject: [TUHS] Unix APIs: elegant or not?
Message-ID: <20181104223746.4B8D018C0B6@mercury.lcs.mit.edu>

    > From: Chris Hanson

    > you should virtually never use read(2), only ever something like this:
    > ...
    > And do this for every classic system call, since virtually no client
    > code should ever have to care about EINTR.

"Virtually". Maybe there are places that want to know if their read call was
interrupted; if you don't make this version available to them, how can they
tell? Leaving the user as much choice as possible is the only way to go, IMO;
why force them to do it the way _you_ think is best?

And it makes the OS simpler; any time you can move functionality out of the
OS, to the user, that's a Good Thing, IMO. There's nothing stopping people
from using the EINTR-hiding wrapper. (Does the Standard I/O library do this,
does anyone know?)

	Noel

PS: Only system calls that can block can return EINTR; there are quite a few
that don't, not sure what the counts are in modern Unix.


From imp at bsdimp.com  Mon Nov  5 08:44:37 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 4 Nov 2018 15:44:37 -0700
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
Message-ID: <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>

On Sun, Nov 4, 2018 at 2:35 PM Dave Horsfall <dave at horsfall.org> wrote:

> UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20
> 1985 GMT (measuring since the time(2) epoch).
>                 -- Andy Tannenbaum
>
> Hmmm...  According to my rough calculations, it hit a billion (US) seconds
> around 2000.
>

It's over a billion and a half today:
% date +%s
1541371441

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181104/786fa838/attachment.html>

From tytso at mit.edu  Mon Nov  5 08:29:03 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sun, 4 Nov 2018 17:29:03 -0500
Subject: [TUHS] Unix APIs: elegant or not?
Message-ID: <20181104222903.GA24498@thunk.org>

On Sun, 4 Nov 2018, Chris Hanson wrote:
> Every piece of code that wants to call, say, read(2) needs to handle
> not only real errors but also needs to special-case EINTR and retry
> the read. Thus you should virtually never use read(2), only ever
> something like this:
> ...
> And do this for every classic system call, since virtually no client
> code should ever have to care about EINTR. It was early an
> implementation expediency that became API and that everyone now has
> to just deal with because you can’t expect the system call interface
> you use to do this for you.
>
>This is the sort of wart that should’ve been fixed by System V and/or BSD 4 at latest.

But it *was* fixed in BSD, and it's in POSIX as the SA_RESTART flag to
sigaction (which gives you BSD signal semantics).

POSIX supports both the original V7 and BSD signal semantics, because
by then there were programs which expected system calls to be
interrupted by signals (and to be fair, there are times when that's
the more convenient way of handling an interrupt, as opposed to using
setjump/longjump to break out of a restartable system call).

					- Ted

P.S.  The original implementation of ERESTARTSYS / ERESTARTNOHAND /
ERESTARTNOINTR errno handling in Linux's system call return path was
my fault.  :-)


From krewat at kilonet.net  Mon Nov  5 08:45:38 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Sun, 4 Nov 2018 17:45:38 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
Message-ID: <0342052a-e3a0-2881-2710-a4d1cb18d5e1@kilonet.net>

On 11/4/2018 3:51 PM, Grant Taylor via TUHS wrote:
> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a 
> central directory on Unix?
>

I've used all three (NIS and YP are the same thing).

I think it all depends on what you're centered on. If your user 
credentials are all in Active Directory, you use LDAP. If you already 
have LDAP, you use LDAP. If you've been using NIS for the past 20 years 
(like I have in my office), you stick with NIS+. NIS+? Same thing. NIS+ 
is a little limited, as I'm not sure what supports that anymore. I don't 
think even Solaris 11.x does.

As to which is better, I really can't say. LDAP/AD has it's points. When 
NIS+ first came out, I gladly moved to it, as it has a compatibility 
mode that allows it to answer NIS queries. So the transition from NIS to 
NIS+ went smoothly. But that was an almost 100% Sun shop where I did that.

if I were to start up a new environment today, and it was PURELY Unix, 
I'd probably use NIS. But then, I have a slew of scripts that I use to 
administer NIS (and NIS+) that use SCCS for change tracking, and also 
can populate DNS zones for the hosts map. To administer LDAP, you either 
use a GUI, or script things with ldapmodify, etc. Which is ghastly, IMO.

art k.



From grawity at gmail.com  Mon Nov  5 08:58:53 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Mon, 5 Nov 2018 00:58:53 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
Message-ID: <CAPWNY8UPFuK2B=gBVE4JwQVrpDvDu10_ngtCFoNVHjeZAnG0yA@mail.gmail.com>

On Sun, Nov 4, 2018 at 11:34 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> directory on Unix?
>
> I'm contemplating playing with them for historical reasons.
>
> As such, I'm wondering what the current evolution is for a pure Unix
> environment.  Read:  No Active Directory.  Is there a current central
> directory service for Unix (or Linux)?  If so, what is it?
>
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
>

As far as I know, LDAP is very much in use in the Linux world – via nslcd
or SSSD as clients; OpenLDAP (blech) or 389-ds as "build from scratch"
servers. There's also FreeIPA which tries to be an integrated solution.
(But even if you seek a pure Linux/Unix environment, I suspect AD is what
keeps LDAP from being replaced – because as long as there are clients for
AD, there will be clients for pure LDAP as well.)

Kerberos exists too, but somewhat less common – FreeIPA includes it by
default, but many people just piggyback on LDAP bind as password-based
authentication and use SSH keys for passwordless (because apparently
protocols other than SSH and HTTPS don't exist anymore). The MIT Kerberos 5
suite is still actively maintained and receives new features, such as
S-PAKE), whereas Heimdal appears to be on life support.

(Speaking of zombies, Linux glibc still comes with Hesiod support built
in...)

Many people's idea of a central directory nowadays appears to be "deploy an
/etc/passwd via Salt or Ansible".

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/46bd8f7d/attachment.html>

From grog at lemis.com  Mon Nov  5 09:35:05 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 5 Nov 2018 10:35:05 +1100
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
Message-ID: <20181104233505.GA70281@eureka.lemis.com>

On Monday,  5 November 2018 at  7:52:03 +1100, Dave Horsfall wrote:
> UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20
> 1985 GMT (measuring since the time(2) epoch).
> 		-- Andy Tannenbaum
>
> Hmmm...  According to my rough calculations, it hit a billion (US) seconds
> around 2000.

Yes, on 9 September 2001 (two days before *the* 11 September), and on
14 July last year it hit 1500000000 seconds:

  $ TZ=UTC date -r 1000000000
  Sun  9 Sep 2001 01:46:40 UTC
  $ TZ=UTC date -r 1500000000
  Fri 14 Jul 2017 02:40:00 UTC

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/c1d4f068/attachment.sig>

From robert at timetraveller.org  Mon Nov  5 09:39:04 2018
From: robert at timetraveller.org (Robert Brockway)
Date: Mon, 5 Nov 2018 09:39:04 +1000 (AEST)
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
Message-ID: <alpine.DEB.2.20.1811050919370.13752@mira.opentrend.net>

On Mon, 5 Nov 2018, Dave Horsfall wrote:

> UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20
> 1985 GMT (measuring since the time(2) epoch).
> 		-- Andy Tannenbaum
>
> Hmmm...  According to my rough calculations, it hit a billion (US) seconds
> around 2000.

There were billion second parties around the world at the time.  Two days 
later all hell broke loose...

$ date -d @1000000000 -u
Sun Sep  9 01:46:40 UTC 2001

A few of my friends had a lunch to celebrate 1.5 billion seconds since the 
epoch in 2017 too.  Alas, I couldn't make it to lunch.  1.5 billion 
seconds was actually reached during the lunch thanks to our TZ:

$date -d @1500000000
Fri Jul 14 12:40:00 AEST 2017

Rob


From imp at bsdimp.com  Mon Nov  5 09:49:01 2018
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 4 Nov 2018 16:49:01 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8UPFuK2B=gBVE4JwQVrpDvDu10_ngtCFoNVHjeZAnG0yA@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAPWNY8UPFuK2B=gBVE4JwQVrpDvDu10_ngtCFoNVHjeZAnG0yA@mail.gmail.com>
Message-ID: <CANCZdfq7BxVroACC0Lm49-KRqUYJZK9RCGGkMsfqiBh0REiAvA@mail.gmail.com>

On Sun, Nov 4, 2018 at 4:44 PM Mantas Mikulėnas <grawity at gmail.com> wrote:

> Kerberos exists too, but somewhat less common – FreeIPA includes it by
> default, but many people just piggyback on LDAP bind as password-based
> authentication and use SSH keys for passwordless (because apparently
> protocols other than SSH and HTTPS don't exist anymore). The MIT Kerberos 5
> suite is still actively maintained and receives new features, such as
> S-PAKE), whereas Heimdal appears to be on life support.
>

FreeBSD has Heimdal. We switched over a long time ago when MIT Kerberos 5
at MIT looked like it was going to die. Now the roles have somewhat
reversed.

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

From akosela at andykosela.com  Mon Nov  5 10:29:40 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Sun, 4 Nov 2018 18:29:40 -0600
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
 <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>
Message-ID: <CALMnNGizsbh9PJcK+qdaGrRZexfFnyJWO+VYfUQD+nW5mb=VOA@mail.gmail.com>

On Sunday, November 4, 2018, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Sun, Nov 4, 2018 at 2:35 PM Dave Horsfall <dave at horsfall.org> wrote:
>
>> UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20
>> 1985 GMT (measuring since the time(2) epoch).
>>                 -- Andy Tannenbaum
>>
>> Hmmm...  According to my rough calculations, it hit a billion (US)
>> seconds
>> around 2000.
>>
>
> It's over a billion and a half today:
> % date +%s
> 1541371441
>
>
The interesting number happened also specifically on Feb 13, 2009 23:31:30
(UTC)

1234567890

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181104/362aa039/attachment.html>

From bakul at bitblocks.com  Mon Nov  5 10:42:52 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 04 Nov 2018 16:42:52 -0800
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: Your message of "Sun, 04 Nov 2018 15:44:37 -0700."
 <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
 <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>
Message-ID: <20181105004259.A0840156E40C@mail.bitblocks.com>

On Sun, 04 Nov 2018 15:44:37 -0700 Warner Losh <imp at bsdimp.com> wrote:
>
> On Sun, Nov 4, 2018 at 2:35 PM Dave Horsfall <dave at horsfall.org> wrote:
>
> > UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20
> > 1985 GMT (measuring since the time(2) epoch).
> >                 -- Andy Tannenbaum
> >
> > Hmmm...  According to my rough calculations, it hit a billion (US) seconds
> > around 2000.
> >
>
> It's over a billion and a half today:
> % date +%s
> 1541371441

Strictly speaking Unix wasn't born on Thu Jan 1 UTC 1970, right?
dmr says this in "The Evolution of the Unix Time-Sharing Sytem":

  Although it was not until well into 1970 that Brian
  Kernighan suggested the name `Unix,' in a somewhat
  treacherous pun on `Multics,' the operating system we know
  today was born.

I wonder if how many unix programmers were born on Thu Jan 1
UTC 1970.  Linus comes close.


From ken at google.com  Mon Nov  5 13:16:35 2018
From: ken at google.com (Ken Thompson)
Date: Sun, 4 Nov 2018 19:16:35 -0800
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <20181105004259.A0840156E40C@mail.bitblocks.com>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
 <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>
 <20181105004259.A0840156E40C@mail.bitblocks.com>
Message-ID: <CAG=a+rjbK-GAGrh5uA4SjLRVgJ258582UAxjgSDkM_3BmKumAg@mail.gmail.com>

unix time was originally measured in
ticks (60th of a second). alas, 2^32
only allows between 2 and 3 years.

so, we ran for 2 years and ended
up facing big problem in the 3rd.
our solution was to read all files
and all backup tapes and subtract
one year from all dates and move
the epoch up a year. we didnt mind
since dectapes (our backup tapes)
had to be rewritten to keep the bits
from rotting.

we did it again the next year and
when disaster was facing us on
the 4th year, we went to seconds.

it shows how much we bet on the
longevity of unix.


On Sun, Nov 4, 2018 at 4:42 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> On Sun, 04 Nov 2018 15:44:37 -0700 Warner Losh <imp at bsdimp.com> wrote:
>>
>> On Sun, Nov 4, 2018 at 2:35 PM Dave Horsfall <dave at horsfall.org> wrote:
>>
>> > UNIX was half a billion (500000000) seconds old on Tue Nov  5 00:53:20
>> > 1985 GMT (measuring since the time(2) epoch).
>> >                 -- Andy Tannenbaum
>> >
>> > Hmmm...  According to my rough calculations, it hit a billion (US) seconds
>> > around 2000.
>> >
>>
>> It's over a billion and a half today:
>> % date +%s
>> 1541371441
>
> Strictly speaking Unix wasn't born on Thu Jan 1 UTC 1970, right?
> dmr says this in "The Evolution of the Unix Time-Sharing Sytem":
>
>   Although it was not until well into 1970 that Brian
>   Kernighan suggested the name `Unix,' in a somewhat
>   treacherous pun on `Multics,' the operating system we know
>   today was born.
>
> I wonder if how many unix programmers were born on Thu Jan 1
> UTC 1970.  Linus comes close.


From robert at timetraveller.org  Mon Nov  5 13:16:54 2018
From: robert at timetraveller.org (Robert Brockway)
Date: Mon, 5 Nov 2018 13:16:54 +1000 (AEST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
Message-ID: <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote:

> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central 
> directory on Unix?

I used NIS a lot in the 90s and early 2000s.  I think it continues to be 
underrated.  The main gripe people had was lack of security but if all of 
the hosts were in the same security domain anyway it wouldn't matter. 
Integrated very well with NFS on Solaris & Linux for me back in the day.

NIS+ is awful.  Let us not speak of it again.

I did a lot of LDAP around 2007-2010.  I got quite good at writing 
filters as we were using for a lot more than juse user auth.

Most installations I'm seeing today auth to AD, which is of course now 
supported.

> I'm contemplating playing with them for historical reasons.
>
> As such, I'm wondering what the current evolution is for a pure Unix 
> environment.  Read:  No Active Directory.  Is there a current central 
> directory service for Unix (or Linux)?  If so, what is it?

In my experience LDAP is preferred in a pure *nix environment these days. 
I've never played much with Kerberos.

There is another option that is largely ignored...

Increasingly *nix systems are managed through orchestration tools like 
Puppet or Ansible.  One option is to build the user account details from 
an AD or LDAP backend on the orchestration server and write it out 
locally on the *nix boxes.  The *nix boxes just auth locally but still 
gain the benefit of dynamically managed users.  There are advantages and 
disavantages of this outside the scope of this list.

Cheers,

Rob


From lm at mcvoy.com  Mon Nov  5 13:49:40 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 4 Nov 2018 19:49:40 -0800
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
Message-ID: <20181105034940.GE2660@mcvoy.com>

I'm really tired (been crabbing all day and got 2 crabs, 7 pots, 5 hour soak,
got 2, sucked).

And I know very little about LDAP.

But I did do a sort of vnode/file system switch answer to this problem,
we called it lamed, I'll try and find you some docs in the morning.

We built a server that could take requests in any form and spit back
the answer.  My goal was to have a 200mhz MIPS server serve up this info
for the entire state of California, perform well, and work across reboots.
We pretty much did it.

On Sun, Nov 04, 2018 at 01:51:08PM -0700, Grant Taylor via TUHS wrote:
> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> directory on Unix?
> 
> I'm contemplating playing with them for historical reasons.
> 
> As such, I'm wondering what the current evolution is for a pure Unix
> environment.  Read:  No Active Directory.  Is there a current central
> directory service for Unix (or Linux)?  If so, what is it?
> 
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



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


From dave at horsfall.org  Mon Nov  5 13:54:19 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Nov 2018 14:54:19 +1100 (EST)
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.1811051446100.78183@aneurin.horsfall.org>

OK, given it's so easy to plug in an arbitrary value (I'd forgotten about
the "-r" flag on date(1)), I'll drop this item; I was just amused that it 
was Andy Tannenbaum who pointed it out.

Oh, and I know that it's not really Unix's birthday, OK?  Sheesh...

-- Dave


From dave at horsfall.org  Mon Nov  5 14:04:52 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 5 Nov 2018 15:04:52 +1100 (EST)
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <20181104223746.4B8D018C0B6@mercury.lcs.mit.edu>
References: <20181104223746.4B8D018C0B6@mercury.lcs.mit.edu>
Message-ID: <alpine.BSF.2.21.9999.1811051459040.78183@aneurin.horsfall.org>

On Sun, 4 Nov 2018, Noel Chiappa wrote:

> "Virtually". Maybe there are places that want to know if their read call 
> was interrupted; if you don't make this version available to them, how 
> can they tell? Leaving the user as much choice as possible is the only 
> way to go, IMO; why force them to do it the way _you_ think is best?

I certainly don't want the kernel making that decision for me; I might 
want to abandon the entire read() if I was signalled.  I did write some 
code that did that, but I've long since forgotten the details.

> And it makes the OS simpler; any time you can move functionality out of 
> the OS, to the user, that's a Good Thing, IMO. There's nothing stopping 
> people from using the EINTR-hiding wrapper. (Does the Standard I/O 
> library do this, does anyone know?)

Agreed; the kernel should make as few decisions as possible, and I've used 
variations on that wrapper, depending on the signal etc.

> PS: Only system calls that can block can return EINTR; there are quite a 
> few that don't, not sure what the counts are in modern Unix.

Almost invariably serial lines, and I used to do a lot of that code.

-- Dave


From wkt at tuhs.org  Mon Nov  5 14:22:45 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 Nov 2018 14:22:45 +1000
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <CAG=a+rjbK-GAGrh5uA4SjLRVgJ258582UAxjgSDkM_3BmKumAg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
 <CANCZdfpJD9PVYYqmAPY=kHNhzGYTCaoGTTgoK8pHeSyXq=rYaw@mail.gmail.com>
 <20181105004259.A0840156E40C@mail.bitblocks.com>
 <CAG=a+rjbK-GAGrh5uA4SjLRVgJ258582UAxjgSDkM_3BmKumAg@mail.gmail.com>
Message-ID: <20181105042245.GA9156@minnie.tuhs.org>

On Sun, Nov 04, 2018 at 07:16:35PM -0800, Ken Thompson via TUHS wrote:
> so, we ran for 2 years and ended
> up facing big problem in the 3rd.
> our solution was to read all files
> and all backup tapes and subtract
> one year from all dates and move
> the epoch up a year. we didnt mind
> since dectapes (our backup tapes)
> had to be rewritten to keep the bits
> from rotting.
> 
> we did it again the next year and
> when disaster was facing us on
> the 4th year, we went to seconds.

This bit me when Dennis sent me an electronic copy of a DECtape from 
this timeframe. It took us quite a while to decide how to interpret
the timestamps. See:
https://www.tuhs.org/Archive/Distributions/Research/1972_stuff/Readme
right down the bottom.

Cheers, Warren


From gtaylor at tnetconsulting.net  Mon Nov  5 16:08:58 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 4 Nov 2018 23:08:58 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
Message-ID: <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>

On 11/04/2018 08:16 PM, Robert Brockway wrote:
> I used NIS a lot in the 90s and early 2000s.  I think it continues to be 
> underrated.  The main gripe people had was lack of security but if all 
> of the hosts were in the same security domain anyway it wouldn't matter.

I'd like to hear more about the security issues.

Did NIS(+) ever encrypt it's communications?  (I'm not counting things 
like IPsec transport.)

I'm fairly certain that it was possible to enumerate the directory or 
otherwise scrape most (if not all) of it's contents.

> Integrated very well with NFS on Solaris & Linux for me back in the day.

*nod*

I was pleasantly surprised at how well Samba+Winbind integrated with 
things.  Groups and IDs from AD just showed up identical to local 
groups.  We didn't even need to worry about NetGroups.

> NIS+ is awful.  Let us not speak of it again.

Okay.

Can I ask that you enlighten this grasshopper without saying it's name? 
():-)

> I did a lot of LDAP around 2007-2010.  I got quite good at writing 
> filters as we were using for a lot more than juse user auth.

Ya.  The LDAP filters are why I tried to avoid just using LDAP against 
AD.  That and the fact that the Unix passwords were actually a separate 
field that could have different values from what the Windows systems used.

> Most installations I'm seeing today auth to AD, which is of course now 
> supported.

I'm curious what "supported" actually means.  I think there is 
preconfigured LDAP against AD templates, and things like Samba+Winbind. 
But all seem to be less native / seamless than NIS.

> In my experience LDAP is preferred in a pure *nix environment these 
> days. I've never played much with Kerberos.

Does that mean that the authentication is also done across LDAP?  I hope 
that it's encrypted LDAP.

> There is another option that is largely ignored...
> 
> Increasingly *nix systems are managed through orchestration tools like 
> Puppet or Ansible.  One option is to build the user account details from 
> an AD or LDAP backend on the orchestration server and write it out 
> locally on the *nix boxes.  The *nix boxes just auth locally but still 
> gain the benefit of dynamically managed users.  There are advantages and 
> disavantages of this outside the scope of this list.

IMHO that is still local accounts and not centrally manged.  It's just 
automated deployment.  Sort of like the difference of creating a file in 
a directory with the GID bit set vs creating the file and then changing 
the group after the fact.  Similar end result, but totally different 
execution method.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181104/cbb966b7/attachment.bin>

From gtaylor at tnetconsulting.net  Mon Nov  5 16:12:05 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sun, 4 Nov 2018 23:12:05 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <20181105034940.GE2660@mcvoy.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com>
Message-ID: <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net>

On 11/04/2018 08:49 PM, Larry McVoy wrote:
> I'm really tired (been crabbing all day and got 2 crabs, 7 pots, 5 hour 
> soak, got 2, sucked).

I'm sorry the day wasn't as productive as you had hoped.  Here's hoping 
that you at least got to spend some quality time with good friends.  In 
between all the hard work.  ;-)

> And I know very little about LDAP.

I know very little.  But it's enough to know that I think learning more 
and / or dealing with it is going to be annoying.

> But I did do a sort of vnode/file system switch answer to this problem, 
> we called it lamed, I'll try and find you some docs in the morning.
> 
> We built a server that could take requests in any form and spit back 
> the answer.  My goal was to have a 200mhz MIPS server serve up this info 
> for the entire state of California, perform well, and work across reboots. 
> We pretty much did it.

That sounds very intriguing.  I'd be interested to hear more about it.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181104/cff049fa/attachment.bin>

From lars at nocrew.org  Mon Nov  5 17:19:09 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 05 Nov 2018 07:19:09 +0000
Subject: [TUHS] PDP-11/VAX Unix Chaosnet
In-Reply-To: <FDB3AB97-2412-41B1-808E-8E30AA533CE2@ccc.com> (Clem cole's
 message of "Sun, 4 Nov 2018 06:59:45 -0800")
References: <7w36sh3qeh.fsf@junk.nocrew.org>
 <FDB3AB97-2412-41B1-808E-8E30AA533CE2@ccc.com>
Message-ID: <7wa7mo2dqq.fsf@junk.nocrew.org>

Let's hope it's OK!

I found some files for 4.1BSD and 4.3BSD.  I suppose I'll have to add a
simulation of the Unibus CH11 Chaosnet interface to SIMH.


> Yes assuming I can read the tape
>
>
>> On Nov 4, 2018, at 5:48 AM, Lars Brinkhoff <lars at nocrew.org> wrote:
>> 
>> Hello,
>> 
>> According to this: https://lm-3.github.io/amber.html#The-Unix-Implementation
>> there were Chaosnet for PDP-11 Unix V7, and VAX Berkeley Unix.  Does
>> anyone have a copy of this?


From grawity at gmail.com  Mon Nov  5 17:24:24 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Mon, 5 Nov 2018 09:24:24 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
Message-ID: <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>

On Mon, Nov 5, 2018 at 9:19 AM Grant Taylor via TUHS
<tuhs at minnie.tuhs.org> wrote:
>
> On 11/04/2018 08:16 PM, Robert Brockway wrote:
> > I used NIS a lot in the 90s and early 2000s.  I think it continues to be
> > underrated.  The main gripe people had was lack of security but if all
> > of the hosts were in the same security domain anyway it wouldn't matter.
>
> I'd like to hear more about the security issues.
>
> Did NIS(+) ever encrypt it's communications?  (I'm not counting things
> like IPsec transport.)
>
> I'm fairly certain that it was possible to enumerate the directory or
> otherwise scrape most (if not all) of it's contents.

There was `ypcat passwd`, wasn't there?

> > I did a lot of LDAP around 2007-2010.  I got quite good at writing
> > filters as we were using for a lot more than juse user auth.
>
> Ya.  The LDAP filters are why I tried to avoid just using LDAP against
> AD.  That and the fact that the Unix passwords were actually a separate
> field that could have different values from what the Windows systems used.

I would say that expecting to just pull password hashes from the
directory service – using it as nothing more than networked
/etc/shadow – is a bad approach to begin with. Let the client handle
authentication via Kerberos (or via whatever else is apropriate for
AD).

> > Most installations I'm seeing today auth to AD, which is of course now
> > supported.
>
> I'm curious what "supported" actually means.  I think there is
> preconfigured LDAP against AD templates, and things like Samba+Winbind.
> But all seem to be less native / seamless than NIS.


Could you elaborate on that?


> > In my experience LDAP is preferred in a pure *nix environment these
> > days. I've never played much with Kerberos.
>
> Does that mean that the authentication is also done across LDAP?  I hope
> that it's encrypted LDAP.


Standard TLS.

-- 
Mantas Mikulėnas


From grawity at gmail.com  Mon Nov  5 17:33:34 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Mon, 5 Nov 2018 09:33:34 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
Message-ID: <CAPWNY8WfVU=_Qfm6F1CXU-J2NC20Yw+n4TBeeK1gi0nvdYv-6w@mail.gmail.com>

On Mon, Nov 5, 2018 at 9:24 AM Mantas Mikulėnas <grawity at gmail.com> wrote:
> > > In my experience LDAP is preferred in a pure *nix environment these
> > > days. I've never played much with Kerberos.
> >
> > Does that mean that the authentication is also done across LDAP?  I hope
> > that it's encrypted LDAP.

I replied to the second sentence, but missed the first one. Yes, many
places use LDAP for authentication.

Although strictly speaking LDAP is not an *authentication* protocol,
but it *is* a read/write protocol: the way you make updates to the
directory isn't by rebuilding it from a textfile, but by
authenticating and sending updates via LDAP itself. Naturally this
supports TLS for encrypting the channel.

Normally it isn't just the sysadmin who can do so, but every user can
also authenticate as themselves (i.e. "bind" to their own entry in
LDAP terms). Maybe they can't edit anything at all, maybe they can
edit only their own finger information, but they're usually able to
authenticate nevertheless.

And so many installations just turn this backwards and declare "If you
can successfully bind to the LDAP database, you must be a valid user".

-- 
Mantas Mikulėnas


From jnc at mercury.lcs.mit.edu  Mon Nov  5 20:08:11 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon,  5 Nov 2018 05:08:11 -0500 (EST)
Subject: [TUHS] PDP-11/VAX Unix Chaosnet
Message-ID: <20181105100811.B438E18C0CB@mercury.lcs.mit.edu>

    > From: Lars Brinkhoff

    > Let's hope it's OK!

Indeed! It will be fun to see that code.

    > I suppose I'll have to add a simulation of the Unibus CH11 Chaosnet
    > interface to SIMH.

Why? Once 10M Ethernet hardware was available, people switched pretty rapidly
to using that, instead of the CHAOS hardware. (It was available off the shelf,
and the analog hardware was better designed.) That's part of the reason ARP is
multi-protocol.

Some hard-to-run cables (e.g. under the street from Tech Sq to main campus)
stayed CHAOS hardware because it was easier to just keep using what was there,
but most new machines got Ethernet cards.

    Noel


From lars at nocrew.org  Mon Nov  5 21:11:42 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 05 Nov 2018 11:11:42 +0000
Subject: [TUHS] PDP-11/VAX Unix Chaosnet
In-Reply-To: <20181105100811.B438E18C0CB@mercury.lcs.mit.edu> (Noel Chiappa's
 message of "Mon, 5 Nov 2018 05:08:11 -0500 (EST)")
References: <20181105100811.B438E18C0CB@mercury.lcs.mit.edu>
Message-ID: <7wtvkv22z5.fsf@junk.nocrew.org>

Noel Chiappa wrote:
>> I suppose I'll have to add a simulation of the Unibus CH11 Chaosnet
>> interface to SIMH.
>
> Why? Once 10M Ethernet hardware was available, people switched pretty
> rapidly to using that, instead of the CHAOS hardware.

Because the 4.1BSD Chaosnet I have found only supports CH11.  And also,
it would be useful for running MINITS and ITS on SIMH.


From mutiny.mutiny at india.com  Tue Nov  6 00:11:04 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Mon, 5 Nov 2018 14:11:04 +0000 (UTC)
Subject: [TUHS] Unix APIs: elegant or not?
In-Reply-To: <C84DDCBC-7699-4078-8E92-521589FADB2C@eschatologist.net>
References: <20181031043810.GA10775@minnie.tuhs.org>
 <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net>
 <201811041228.wA4CSMIA017639@freefriends.org>,
 <C84DDCBC-7699-4078-8E92-521589FADB2C@eschatologist.net>
Message-ID: <2008946716.58169.1541427064505.JavaMail.tomcat@india-live-be01>



At 4 Nov 2018 22:07:46 +0000 (+00:00) from Chris Hanson <cmhanson at eschatologist.net>:
> And do this for every classic system call, since virtually no client code should ever have to care about EINTR. It was early an implementation expediency that became API and that everyone now has to just deal with because you can’t expect the system call interface you use to do this for you.
> 
> This is the sort of wart that should’ve been fixed by System V and/or BSD 4 at latest.
> 
you are right!


From lm at mcvoy.com  Tue Nov  6 01:44:04 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 5 Nov 2018 07:44:04 -0800
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <20181105034940.GE2660@mcvoy.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com>
Message-ID: <20181105154404.GA19335@mcvoy.com>

OK, found some slides:

http://mcvoy.com/lm/papers/lamed.pdf

If your browser can't read the pdf (firefox failed for me), wget it or
whatever and try a command line pdf viewer (mupdf worked for me).

Happy to fill in the details if you have questions.

On Sun, Nov 04, 2018 at 07:49:40PM -0800, Larry McVoy wrote:
> I'm really tired (been crabbing all day and got 2 crabs, 7 pots, 5 hour soak,
> got 2, sucked).
> 
> And I know very little about LDAP.
> 
> But I did do a sort of vnode/file system switch answer to this problem,
> we called it lamed, I'll try and find you some docs in the morning.
> 
> We built a server that could take requests in any form and spit back
> the answer.  My goal was to have a 200mhz MIPS server serve up this info
> for the entire state of California, perform well, and work across reboots.
> We pretty much did it.
> 
> On Sun, Nov 04, 2018 at 01:51:08PM -0700, Grant Taylor via TUHS wrote:
> > Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> > directory on Unix?
> > 
> > I'm contemplating playing with them for historical reasons.
> > 
> > As such, I'm wondering what the current evolution is for a pure Unix
> > environment.  Read:  No Active Directory.  Is there a current central
> > directory service for Unix (or Linux)?  If so, what is it?
> > 
> > I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
> > 
> > 
> > 
> > -- 
> > Grant. . . .
> > unix || die
> > 
> 
> 
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

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


From krewat at kilonet.net  Tue Nov  6 02:12:19 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 5 Nov 2018 11:12:19 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
Message-ID: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>

On 11/5/2018 2:24 AM, Mantas Mikulėnas wrote:
>> I'd like to hear more about the security issues.
>>
>> Did NIS(+) ever encrypt it's communications?  (I'm not counting things
>> like IPsec transport.)
>>
>> I'm fairly certain that it was possible to enumerate the directory or
>> otherwise scrape most (if not all) of it's contents.
> There was `ypcat passwd`, wasn't there?
>

It was possible, unless you used a network filter on the server, to just 
ypbind to the server, and then you could ypcat all the maps. Not to 
mention that without specifying a server, it was a broadcast. So any YP 
server on the subnet would answer.

NIS+ was encrypted over the network, and needed a public key mechanism 
to authenticate clients. One of which was the server itself. With it's 
hierarchical architecture, it had a lot of flexibility.

I really never understood why people didn't like NIS+. It took an extra 
step or two to do certain things, but once scripted it was a fairly 
secure way of handling authentication and directory services. I added 
new maps to it to do custom .cshrc/.profile scripts using subsections in 
/usr/local/profile, and a few other customizations. Add it's 
compatibility mode for NIS/YP, and you could use it to serve not only 
Sun clients.

Operationally, it really was just NIS/YP but with a lot of whiz-bang 
features. In a deployment of a few hundred mechanical and electrical 
engineers, with about 50 actual workstations and servers I never had a 
problem with it. Permissions and other features were actually quite useful.

However, I must say, I kept the NIS/YP way of using flat files to 
regenerate the NIS+ maps each time they were edited. So I guess I 
cheated a little.

art k.

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

From arnold at skeeve.com  Tue Nov  6 04:38:50 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 05 Nov 2018 11:38:50 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <20181105154404.GA19335@mcvoy.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com>
Message-ID: <201811051838.wA5Icosk029361@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> OK, found some slides:
>
> http://mcvoy.com/lm/papers/lamed.pdf

That was quite interesting!! Very impressive.  Did the reference
port ever get contributed to Linux?  It looks like a nice architecture.

Arnold


From lm at mcvoy.com  Tue Nov  6 05:04:24 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 5 Nov 2018 11:04:24 -0800
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <201811051838.wA5Icosk029361@freefriends.org>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com>
 <20181105154404.GA19335@mcvoy.com>
 <201811051838.wA5Icosk029361@freefriends.org>
Message-ID: <20181105190424.GE19335@mcvoy.com>

On Mon, Nov 05, 2018 at 11:38:50AM -0700, arnold at skeeve.com wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > OK, found some slides:
> >
> > http://mcvoy.com/lm/papers/lamed.pdf
> 
> That was quite interesting!! Very impressive.  Did the reference
> port ever get contributed to Linux?  It looks like a nice architecture.

Yeah, it was sort of overkill for the problem space, but it seemed
like the right answer.  Very much inspired by the vnode/vfs interface
I learned in SunOS.

The caches worked across reboots.  I left not long after we completed 1.0,
Bob Mende (RIP) and some other folks took the mmap based dbm (I called
mdbm) and put locks in each page so you could have multiple writers.
That code made its way to yahoo and just got used for everything, they
made it C++ (not a fan of that but whatever) and evolved it farther than
I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
They open sourced their stuff.

I'm not sure if SGI ever open sourced it, be a shame if they didn't.
Though the need for a YP server that scales to the entire world is
not so clear to me.  But you could do it.


From gtaylor at tnetconsulting.net  Tue Nov  6 05:27:29 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 12:27:29 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
Message-ID: <71883234-7c08-0365-1395-d07fb3363c93@spamtrap.tnetconsulting.net>

On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> There was `ypcat passwd`, wasn't there?

I suppose.  I don't have any first hand experience with NIS(+).  So I'm 
trying to learn vicariously through others before I dive into any end of 
pool that is my lab network.

> I would say that expecting to just pull password hashes from the directory 
> service – using it as nothing more than networked /etc/shadow – is 
> a bad approach to begin with. Let the client handle authentication via 
> Kerberos (or via whatever else is apropriate for AD).

I think I naively thought there was some level of detail(s) sent between 
the client and the server such that the server would only return the 
pertinent information of the user being ypcated.  Thus (hopefully) 
preventing seeing other people's shadow information.

> Could you elaborate on that?

I thought that I'd seen equipment that /only/ used LDAP but had 
templates for the query to sidle up to AD's LDAP and things just worked. 
  I.e. you filled in enough details so that the template could construct 
the proper LDAP query.

This obviously is not joined to an AD domain and is really just an LDAP 
client.  (No Kerberos.)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/1eeb9543/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 05:32:26 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 12:32:26 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>
Message-ID: <cf4ed0fd-e2d1-4b5d-0514-5500efb6f3f5@spamtrap.tnetconsulting.net>

On 11/05/2018 09:12 AM, Arthur Krewat wrote:
> It was possible, unless you used a network filter on the server, to just 
> ypbind to the server, and then you could ypcat all the maps. Not to 
> mention that without specifying a server, it was a broadcast. So any YP 
> server on the subnet would answer.

Duly noted.  Thank you for the explanation.

> NIS+ was encrypted over the network, and needed a public key mechanism 
> to authenticate clients. One of which was the server itself. With it's 
> hierarchical architecture, it had a lot of flexibility.

The encryption would thwart snooping.  But it doesn't sound like that 
would prevent a properly authenticated client from ypcating too much 
information.

> I really never understood why people didn't like NIS+. It took an extra 
> step or two to do certain things, but once scripted it was a fairly 
> secure way of handling authentication and directory services.

I've heard a lot of people say they don't like something when they had 
something else that did what they needed / wanted (at the time) that 
required less work.  Occam's Razor / Parsimony....

> I added new maps to it to do custom .cshrc/.profile scripts using 
> subsections in /usr/local/profile, and a few other customizations. Add 
> it's compatibility mode for NIS/YP, and you could use it to serve not 
> only Sun clients.

Nice.

> Operationally, it really was just NIS/YP but with a lot of whiz-bang 
> features. In a deployment of a few hundred mechanical and electrical 
> engineers, with about 50 actual workstations and servers I never had a 
> problem with it. Permissions and other features were actually quite useful.

ACK

> However, I must say, I kept the NIS/YP way of using flat files to 
> regenerate the NIS+ maps each time they were edited. So I guess I 
> cheated a little.

Work smarter, not harder.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/10f7b6ce/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 05:36:30 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 12:36:30 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
Message-ID: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>

On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> Let the client handle authentication via Kerberos

I don't know enough about Kerberos (yet) to know if it would be possible 
for a login process to communicate with the KDC and get a TGT as part of 
logging in, without already being logged in.

My ignorance is leaving me with a priming problem that seems like a 
catch 22.  You can't login without shadow information or TGT.  But 
traditional (simpler) kinit is run after being logged in.  So ... how do 
you detangle that?  The only thing that I can come up with is that the 
login process does the kinit functionality on the users behalf.

I can see how NIS(+) sans-shadow could still be useful.  I can also see 
how LDAP could be a close approximation / replacement for NIS(+) in this 
case.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/cefeef3f/attachment.bin>

From dave at horsfall.org  Tue Nov  6 05:58:30 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 6 Nov 2018 06:58:30 +1100 (EST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com>
 <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.1811060645430.78183@aneurin.horsfall.org>

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote:

[...]

>> And I know very little about LDAP.
>
> I know very little.  But it's enough to know that I think learning more 
> and / or dealing with it is going to be annoying.

I've used OpenLDAP in a previous job for many years, for all sorts of 
things, and it worked well.  I had it integrated with Sendmail and even 
Kerberos, but I've forgotten the details now.

There is a damned good book on LDAP in general (I can't remember the 
title, but it's a thick hard-cover) so read it, cover to cover.  Then 
download the OpenLDAP source (or used a trusted binary) and read the 
documentation, esp. the quick start guide and the admin guide.

Then read them again :-)

The most important thing about learning LDAP is forgetting everything you 
ever knew about relational databases; LDAP is a *directory*, not a 
database, and the idiots at work were constantly referring to records, not 
*entries*, which drove me crazy (I have a Unify RDBMS background too).

And if/when you start using OpenLDAP, always keep it up to date; there is 
an active mailing list, but the first thing they'll ask is "What version 
are you running?".  Sure, there's been some lemon releases, but in general 
it worked fine for us; the company's balls depended upon it.

-- Dave


From dave at horsfall.org  Tue Nov  6 06:10:33 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 6 Nov 2018 07:10:33 +1100 (EST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.1811060659260.78183@aneurin.horsfall.org>

On Sun, 4 Nov 2018, Grant Taylor via TUHS wrote:

> I'd like to hear more about the security issues.

When I was working for Lionel Singer (a Sun reseller) we used to refer to 
YP as Yellow Plague.  It was riddled with security holes, but alas I can 
no longer remember them.

-- Dave


From a.phillip.garcia at gmail.com  Tue Nov  6 06:48:34 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Mon, 5 Nov 2018 15:48:34 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
Message-ID: <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>

On Sun, Nov 4, 2018, 4:34 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org
wrote:

> Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
> directory on Unix?
>
> I'm contemplating playing with them for historical reasons.
>
> As such, I'm wondering what the current evolution is for a pure Unix
> environment.  Read:  No Active Directory.  Is there a current central
> directory service for Unix (or Linux)?  If so, what is it?
>
> I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
>

Yes, that's exactly what Active Directory does and does well, so why shun
it? I'd be interested in knowing where a pure unix environment exists,
beyond my imagination and dreams that is. Linux is pretty much a first
class citizen in a Windows world today. Samba4 can act as a domain
controller, but I don't know how practical that solution is, how well it
scales, or what kind of support exists. It uses the same standard protocols
as AD.

I do dread the day that Microsoft introduces "Group Policy for Linux", if
they haven't already. Also, I like Powershell and was stoked when they
introduced it to Linux, but I've personally been resisting its use to
manage Linux servers, perhaps for no good reason.

Yesterday I read that MS is starting to develop SysInternals-like tools for
Linux. They own GitHub. Like it or not, they're not going away. They're
going to continue diluting the waters between Windows and Linux more and
more. Resistance is futile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/cc65fbf7/attachment.html>

From noel.hunt at gmail.com  Tue Nov  6 07:21:37 2018
From: noel.hunt at gmail.com (Noel Hunt)
Date: Tue, 6 Nov 2018 08:21:37 +1100
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <20181105190424.GE19335@mcvoy.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com>
 <201811051838.wA5Icosk029361@freefriends.org>
 <20181105190424.GE19335@mcvoy.com>
Message-ID: <CAGfO01yWuKUjO24fNFKWqcvV-Svvf8QYqk_msfhg7oGtVhBQrA@mail.gmail.com>

The mention of a YP server that scales to the entire world
reminds me of my time at Lehman Bros. (yes, evil incarnate)
in Tokyo, 1995-96. They were using moira which I believe was
from Project Athena, to push out YP maps to all their sites
around the world. I have a feeling there were ex-MIT people
at Lehman in New York.

On Tue, Nov 6, 2018 at 7:09 AM Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 05, 2018 at 11:38:50AM -0700, arnold at skeeve.com wrote:
> > Larry McVoy <lm at mcvoy.com> wrote:
> >
> > > OK, found some slides:
> > >
> > > http://mcvoy.com/lm/papers/lamed.pdf
> >
> > That was quite interesting!! Very impressive.  Did the reference
> > port ever get contributed to Linux?  It looks like a nice architecture.
>
> Yeah, it was sort of overkill for the problem space, but it seemed
> like the right answer.  Very much inspired by the vnode/vfs interface
> I learned in SunOS.
>
> The caches worked across reboots.  I left not long after we completed 1.0,
> Bob Mende (RIP) and some other folks took the mmap based dbm (I called
> mdbm) and put locks in each page so you could have multiple writers.
> That code made its way to yahoo and just got used for everything, they
> made it C++ (not a fan of that but whatever) and evolved it farther than
> I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
> They open sourced their stuff.
>
> I'm not sure if SGI ever open sourced it, be a shame if they didn't.
> Though the need for a YP server that scales to the entire world is
> not so clear to me.  But you could do it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/5a096c09/attachment.html>

From grawity at gmail.com  Tue Nov  6 07:36:25 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Mon, 5 Nov 2018 23:36:25 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
Message-ID: <CAPWNY8WkNt778OqPKt74C+5g6OurHMxKA+R69joY4OW-8oE8YQ@mail.gmail.com>

On Mon, Nov 5, 2018 at 11:00 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> > Let the client handle authentication via Kerberos
>
> I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
>

Sure, that's how the process of obtaining a TGT works in the first place.
You send an AS-REQ packet with proof of password knowledge, you get an
AS-REP with the TGT ticket back.

My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
>

Not sure what part of the 'login' process you're referring to.

 * Credential verification? That's part of obtaining a TGT. You don't need
a ticket to obtain the TGT – instead you submit proof that you know the
password.

 * Retrieval of directory information (uid, gid, homedir)? The login
process either uses its own "machine" credentials to do so, or just
retrieves the information anonymously, depending on sysadmin's preference.
(Or in the case of AD it's already stapled to the TGT to speed everything
up.)


> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>

Yes, that's exactly what happens. However, probably not for all of the same
reasons as you imagine.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/a3c65819/attachment.html>

From ben at cogs.com  Tue Nov  6 07:43:59 2018
From: ben at cogs.com (Ben Greenfield)
Date: Mon, 5 Nov 2018 16:43:59 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
Message-ID: <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>



> On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> Let the client handle authentication via Kerberos
> 
> I don't know enough about Kerberos (yet) to know if it would be possible for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.
> 
> My ignorance is leaving me with a priming problem that seems like a catch 22.  You can't login without shadow information or TGT.  But traditional (simpler) kinit is run after being logged in.  So ... how do you detangle that?  The only thing that I can come up with is that the login process does the kinit functionality on the users behalf.

I found that I had to do all of this using SASL. 


I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.

I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.


Thanks,

Ben

> 
> I can see how NIS(+) sans-shadow could still be useful.  I can also see how LDAP could be a close approximation / replacement for NIS(+) in this case.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



From crossd at gmail.com  Tue Nov  6 08:34:24 2018
From: crossd at gmail.com (Dan Cross)
Date: Mon, 5 Nov 2018 17:34:24 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
Message-ID: <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>

On Mon, Nov 5, 2018 at 4:00 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> > Let the client handle authentication via Kerberos
>
> I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
>
> My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>

You can use a modified `login` that will validate you against a KDC.

The way it works is to set up a host key for the host you're logging into;
that is then used to authenticate the *host* to the KDC, which then allows
it to validate a user against the KDC and issue the user a TGT at the same
time. This works well for e.g. console and X logins.

Modifications have been made to e.g. SSH so that one can authenticate an
SSH session via GSSAPI, which usually wraps Kerberos. If I recall, GSSAPI
might be one of the lasting legacies of the DCE, though I may be
misremembering history.

I can see how NIS(+) sans-shadow could still be useful.  I can also see
> how LDAP could be a close approximation / replacement for NIS(+) in this
> case.
>

Security, in general, usually seeks to address five questions:

1. Authentication - Is some entity who it claims to be?
2. Authorization - Is some entity allowed to perform some action?
3. Privacy - Can a third party snoop on a private conversation between two
entities?
4. Integrity - Can a third party alter communications between two entities
in an undetectable way?
5. Non-repudiation - Can it be definitively shown that some entity was a
party to some communication?

Kerberos is a authentication protocol.

LDAP, YP (retroactively named NIS after a lawsuit involving, I believe,
British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all
examples of directory services. To a first-order approximation, one might
think of a directory service as providing an oracle allowing one to
discover what entities exist in some domain.

Authentication protocols and directory services solve different problems.
Though in true Micro$oft-of-old fashion, AD sort of merged both.

Kerberos solves the authentication problem, but does not provide a
directory service nor does it solve the authorization problem (though some
"kerberized" services could use a library to consult a user-provided file
of ACLs mapping principals to privileges). On Unix, "authorization data"
includes things like your UID and the set of groups you belong to (or more
precisely, your process's UIDs and GIDs/groups). Kerberos provided support
for privacy via encryption libraries, and it provided support for integrity
via hashing/checksumming/signature libraries. "Kerberized" versions of
network services such as telnet, FTP, rsh/rlogin/rcp etc all provided
support for authentication via the baseline Kerberos protocol as well as
privacy and integrity via connection-level encryption and checksumming.
Kerberos provided a replay cache, but otherwise provided only limited
support for non-repudiation via mutual authentication through the KDC (that
is, clients authenticated to servers, but servers also authenticated to
clients). So while a KDC might tell you whether the principal connecting to
your SSH service is really "cross at GAJENDRA.NET", it won't tell you your
UID, what shell you use, the path to your home directory, what groups you
are a member of, or what finger should say for your real name.

In its pure form, SSH provides support for limited authentication (via
public key cryptography and the wide distribution of public keys) and
limited authorization (via the `authorized_keys` file), privacy and
integrity.

LDAP might provide you some mechanism to look up a user record that
provides those details; it may also provide some kind of hashed password
that a system can use to validate a password, but it won't do much better
than that. I suppose you could put an authorized SSH public key into an
LDAP directory in the same way you would put a hashed password.

NIS was based on Sun RPC; as was mentioned earlier, anyone on a network
could bind to an NIS server and query it to get e.g., hashed password file
entries that they could run crack against. Nothing was encrypted. There was
a system for a user to update his/her information in the NIS database
(e.g., this was how you changed your password or set your shell or updated
your office phone number...), but the "authentication" was just checking
your password; again nothing was encrypted, so a malicious third party on
your network could in theory mount a man-in-the-middle attack against you
and inject his/her own data into the transaction and take over your account.

NIS+ improved on this, but wasn't universally supported across systems and
we lost some useful NIS functionality: back in the NIS days, you could
supplement the contents of /etc/passwd with the NIS passwd maps, but keep
local overrides (e.g., for anyone not in the `@staff` netgroup, set shell
to `/sbin/nologin` on servers); perhaps there was a way to do this with
NIS+ but it felt very much like a binary thing: you were either all in on
NIS+ or not at all. Mixing and matching just wasn't as easy as it had been.
Also, the symmetric crypto was, I think, DES based and as that fell apart I
don't recall it getting much better. So unless you were all Sun based (and
many of us had heterogenous systems to worry about; my shops supported Suns
running SunOS 4 and Solaris 2, SGIs running Irix, HP-UX machines, Alphas
running OSF/1 then DEC Unix then Tru64, DECstations running Ultrix,
RS/6000's running AIX, RTs running AOS, a few NeXTs, PCs running Linux *BSD
and PCs running Windows and Macs. Oh, and VMS on VAXen and Alphas. Yay.
Elsewhere on campus we had a mainframe running VM/ESA, a couple of Crays,
some AS/400s; we also had a few plan9 machines. We even had a PDP-10
running TOPS-10 at some point. Good ol' YP cut across the widest swath of
these so that's what we ran the longest, but it was a more innocent time,
network access was more tightly controlled and it wasn't quite as dangerous
to run something like ypserv.

I thought for a while that LDAP would be the light and the way, but it was
really a lot more general than what I cared about just for Unix system
administration. Setting it up wasn't as easy as NIS, or even NIS+ for that
matter.

Netinfo came from NeXT and survived into Macos for a little while. It was
kind of neat but again the all-singing, all-dancing solution to the world.
No one else really used it.

Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed the
need for a directory service on DNS, which is already a distributed
directory service. You embedded relevant data into DNS TXT records, so
imagine doing a DNS query to look up a user's /etc/passwd entry: after all,
DNS already scaled and was well-proven Internet-wide. I don't know that
anyone ever really supported it, though.

So yeah. Kerberos is plenty fine for authentication for small to medium
sites (up to mid tens of thousands of users, I'd guess), but won't help you
distribute your authorization data. You need a directory service or some
other mechanism for that. Directory services will help you with that, but
usually don't do a great job at authentication, though they may provide the
means to distributed the data that other systems can use for that. Of the
directory services out there these days, LDAP seems to have "won".

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

From krewat at kilonet.net  Tue Nov  6 08:43:53 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Mon, 5 Nov 2018 17:43:53 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <cf4ed0fd-e2d1-4b5d-0514-5500efb6f3f5@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>
 <cf4ed0fd-e2d1-4b5d-0514-5500efb6f3f5@spamtrap.tnetconsulting.net>
Message-ID: <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net>

On 11/5/2018 2:32 PM, Grant Taylor via TUHS wrote:
>
>> NIS+ was encrypted over the network, and needed a public key 
>> mechanism to authenticate clients. One of which was the server 
>> itself. With it's hierarchical architecture, it had a lot of 
>> flexibility.
>
> The encryption would thwart snooping.  But it doesn't sound like that 
> would prevent a properly authenticated client from ypcating too much 
> information.
Unless someone already replied and I didn't read it yet:

NIS/YP is different than NIS+. NIS/YP is the old protocol. You could 
basically bind to any server with the correct domain name, and look at 
all the maps including passwd with it's encrypted passwords.

NIS+ is the hierarchical, encrypted, clients-need-keys, protocol.

Almost two entirely different things. And "almost" is more like 
99.99999999999999999% different :)

ak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/48af10c2/attachment.html>

From gtaylor at tnetconsulting.net  Tue Nov  6 08:53:12 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 15:53:12 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <alpine.BSF.2.21.9999.1811060645430.78183@aneurin.horsfall.org>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com>
 <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.21.9999.1811060645430.78183@aneurin.horsfall.org>
Message-ID: <121753c0-ad8b-428f-498b-002749baf132@spamtrap.tnetconsulting.net>

On 11/05/2018 12:58 PM, Dave Horsfall wrote:
> I've used OpenLDAP in a previous job for many years, for all sorts of 
> things, and it worked well.  I had it integrated with Sendmail and even 
> Kerberos, but I've forgotten the details now.

ACK

My biggest problem with OpenLDAP, or any LDAP, is (other than my 
ignorance) the fact that all of them (save for AD) started with an empty 
schema.  So I was functionally needing to create a schema that was 
hopefully compatible with the things I needed /while/ learning LDAP ~> 
$LDAPimplementation.  I always felt it was a relatively steep learning 
curve.  And I was never sufficiently motivated.

Conversely, AD, has a very well established LDAP schema and many things 
know how to work with it.

> There is a damned good book on LDAP in general (I can't remember the 
> title, but it's a thick hard-cover)

Do you by chance know any more details?  I'll dig and see if I can find it.

> so read it, cover to cover.  Then download the OpenLDAP source (or used 
> a trusted binary) and read the documentation, esp. the quick start guide 
> and the admin guide.

ACK

> Then read them again :-)

~chuckle~

> The most important thing about learning LDAP is forgetting everything 
> you ever knew about relational databases; LDAP is a *directory*, not a 
> database, and the idiots at work were constantly referring to records, 
> not *entries*, which drove me crazy (I have a Unify RDBMS background too).

I think I understand that.  Or at least what (little) I know doesn't 
doesn't seem to have any objection to that.  I know that I would not 
want to use LDAP as a general purpose relational database.

> And if/when you start using OpenLDAP, always keep it up to date; there 
> is an active mailing list, but the first thing they'll ask is "What 
> version are you running?".  Sure, there's been some lemon releases, but 
> in general it worked fine for us; the company's balls depended upon it.

Thank you for the ProTip.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/27ce9326/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 09:07:49 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 16:07:49 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
Message-ID: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>

On 11/05/2018 01:48 PM, A. P. Garcia wrote:
> Yes, that's exactly what Active Directory does and does well, so why 
> shun it? I'd be interested in knowing where a pure unix environment 
> exists, beyond my imagination and dreams that is.

Ah.  Let me describe it this way:

LAN with a mixture of Windows and Linux /workstations/ that doesn't 
include a Windows /server/ to provide the AD resources (DNS, LDAP, 
Kerberos, etc.)

I guess it could be said that Samba4 acting as an AD DC might be the 
proper choice here.  But that sounds like some hassle without the 
typical Windows GUI tools for administering AD.  -  I've also never done 
that, so the unknown quantity is a bit deterrent.

I can also see having multiple Linux machines in a network without any 
other OS.  Possibly a cluster of Raspberry Pi Zeros on a Cluster Hat. 
}:-)  Use the underlying Pi as the gateway and infrastructure device, 
including the directory.

The point being, there are environments with multiple Linux (Unix) 
machines that don't have ready access to AD.  Thus my asking about the 
Unix (Linux) native method.

> Linux is pretty much a first class citizen in a Windows world 
> today. Samba4 can act as a domain controller, but I don't know how 
> practical that solution is, how well it scales, or what kind of support 
> exists. It uses the same standard protocols as AD.

I feel like standing up AD, be it on Windows Server or Linux with 
Samba4, is applying a Windows centric solution to Linux (Unix) systems. 
I think this is acceptable if there is already Windows ~> AD in the mix. 
  But that's not always the case.

I also loath the idea that Unix (Linux) doesn't have a stand alone 
central directory server solution.  Or if LDAP + Kerveros is said 
solution, so be it.  -  That's sort of what I'm trying to figure out.

> I do dread the day that Microsoft introduces "Group Policy for Linux", 
> if they haven't already.

I'm fairly certain that group policy objects do exist for Linux AD 
clients.  I think they are just simpler and can do far fewer things.  I 
think they also effectively map to the standard things that we could 
already do in Linux.  It's just behind a Microsoft MMC snap-in to edit GPOs.

> Also, I like Powershell and was stoked when they introduced it to Linux, 
> but I've personally been resisting its use to manage Linux servers, 
> perhaps for no good reason.

I know a couple of people that have messed with PowerShell on Linux. 
One of whom actually prefers PowerShell to Bash (et al) for scripting. 
He stated that things are stored in data structures in PowerShell, and 
as such were easier to manipulate and work with, compared to 
unstructured data in STDIN / STDOUT.

He also stated that PowerShell was functionally just another shell for 
doing things on Linux.  In some ways, quite similar to moving between 
/bin/sh, /bin/bash, /bin/zsh, etc.  Obviously interacting with the shell 
is different.  But you're still calling Linux commands to do core 
things.  The glue is just different.

> Yesterday I read that MS is starting to develop SysInternals-like tools 
> for Linux. They own GitHub. Like it or not, they're not going away. 
> They're going to continue diluting the waters between Windows and Linux 
> more and more. Resistance is futile.

I was more meaning environments that don't include Windows Server, not 
meaning to shun Windows.

Translation:  What is the current Unix (Linux) method to provide central 
user directory / authentication for about a dozen Unix (Linux / Solaris 
/ *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't 
own a license for any version of Windows Server that supports AD.  Nor 
do I feel compelled to buy one.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/2ccc44c3/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 09:12:43 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 16:12:43 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WkNt778OqPKt74C+5g6OurHMxKA+R69joY4OW-8oE8YQ@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAPWNY8WkNt778OqPKt74C+5g6OurHMxKA+R69joY4OW-8oE8YQ@mail.gmail.com>
Message-ID: <b8d9ba6f-bacb-a31b-9515-54e956dd9a0a@spamtrap.tnetconsulting.net>

On 11/05/2018 02:36 PM, Mantas Mikulėnas wrote:
> Sure, that's how the process of obtaining a TGT works in the first 
> place. You send an AS-REQ packet with proof of password knowledge, you 
> get an AS-REP with the TGT ticket back.

Thank you for confirming that such is possible.

> Not sure what part of the 'login' process you're referring to.

Vaguely ... /bin/login or the login prompt from SSH (which I /think/ is 
independent of /bin/login.)

>   * Credential verification? That's part of obtaining a TGT. You don't 
> need a ticket to obtain the TGT – instead you submit proof that you know 
> the password.
> 
>   * Retrieval of directory information (uid, gid, homedir)? The login 
> process either uses its own "machine" credentials to do so, or just 
> retrieves the information anonymously, depending on sysadmin's 
> preference. (Or in the case of AD it's already stapled to the TGT to 
> speed everything up.)

Thank you for explaining.

> Yes, that's exactly what happens. However, probably not for all of the 
> same reasons as you imagine.

ACK



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/dd6bd6b9/attachment.bin>

From dave at horsfall.org  Tue Nov  6 11:28:47 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 6 Nov 2018 12:28:47 +1100 (EST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <121753c0-ad8b-428f-498b-002749baf132@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com>
 <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.21.9999.1811060645430.78183@aneurin.horsfall.org>
 <121753c0-ad8b-428f-498b-002749baf132@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.1811061217210.78183@aneurin.horsfall.org>

[Getting a bit off-topic now...]

On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:

>> There is a damned good book on LDAP in general (I can't remember the 
>> title, but it's a thick hard-cover)
>
> Do you by chance know any more details?  I'll dig and see if I can find 
> it.

This looks like it (I recognise the authors) but I would've had the first 
edition, and my ex-supervisor is no longer at work:

     https://www.amazon.com/Understanding-Deploying-LDAP-Directory-Services/dp/0672323168/ref=zg_bs_69960_25?_encoding=UTF8&psc=1&refRID=ZWNJQSFWS5ARJEG469XN

You may have to strip off tracking codes...

I see there's also an O'Reilly book, but it's an admin guide so presumably 
basic knowledge of LDAP is required.

[...]

> I think I understand that.  Or at least what (little) I know doesn't 
> doesn't seem to have any objection to that.  I know that I would not 
> want to use LDAP as a general purpose relational database.

It most certainly is not; it's optimised for searching (with complex 
patterns) and reading, not for writing.

-- Dave


From crossd at gmail.com  Tue Nov  6 11:41:38 2018
From: crossd at gmail.com (Dan Cross)
Date: Mon, 5 Nov 2018 20:41:38 -0500
Subject: [TUHS] Directory services in early Unix networks?
Message-ID: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>

Spurred by the recent discussion of NIS, NIS+, LDAP et al, I'm curious what
the landscape was like for distributing administrative information in early
Unix networks.

Specifically I'm thinking about things like the Newcastle Connection, etc.

I imagine that PDP-11's connected to the ARPAnet running Unix would (e.g.,
RFC 681 style) would have adapted the HOSTS.TXT format somehow. What about
CHAOS? Newcastle? Datakit?

What was the introduction of DNS into the mix like? I can imagine that that
changed all sorts of assumptions about failure modes and the like.

NIS and playing around with Hesiod are probably the earliest such things I
ever saw, but I know there must have been prior art.

Supposedly field 5 from /etc/passwd is the GECOS username for remote job
entry (or printing)? How did that work?

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

From crossd at gmail.com  Tue Nov  6 11:46:18 2018
From: crossd at gmail.com (Dan Cross)
Date: Mon, 5 Nov 2018 20:46:18 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
Message-ID: <CAEoi9W6d5KCExxGHdOoCyae154r4u_NvMYj40w0OCNXF7kRQxw@mail.gmail.com>

On Mon, Nov 5, 2018 at 7:33 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> [snip]
> Translation:  What is the current Unix (Linux) method to provide central
> user directory / authentication for about a dozen Unix (Linux / Solaris
> / *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't
> own a license for any version of Windows Server that supports AD.  Nor
> do I feel compelled to buy one.
>

On small networks, I eventually jettisoned YP/LDAP et al in favor of flat
text files in a directory tree on an NFS server. All clients mounted that
and every $n$ minutes cron ran a script that sync'ed important files on
each host. We were already using Kerberized NFS everywhere; this eliminated
the directory service as another point of failure. Since passwords were in
the Kerberos master, I didn't care about the contents of /etc/passwd,
though I used make and cpp to generate "ACL" files that drove a script that
generated /etc/passwd on each host so that e.g., normal users couldn't log
into the NFS server; not because I cared about them logging in but rather
because I didn't want them running real programs there and slowing it down.

Root was probably the only account with an actual password in
/etc/{shadow,master.passwd} but that was explicitly chosen with enough
entropy that if someone got the hash and ran crack or john the ripper or
whatever against it they were only going to succeed in generating lots of
heat.

If I only got a dozen or so systems, that's what I'd do again. Setting up
an LDAP schema probably isn't worth the complexity; NIS would be the only
other realistic option and it's just not secure enough in this day and age.
Setting up a KDC and an NFS server is much easier.

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

From robert at timetraveller.org  Tue Nov  6 13:03:47 2018
From: robert at timetraveller.org (Robert Brockway)
Date: Tue, 6 Nov 2018 13:03:47 +1000 (AEST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
Message-ID: <alpine.DEB.2.20.1811061122360.13752@mira.opentrend.net>

On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:

> I also loath the idea that Unix (Linux) doesn't have a stand alone central 
> directory server solution.  Or if LDAP + Kerveros is said solution, so be it. 
> -  That's sort of what I'm trying to figure out.

LDAP with or without Kerberos certainly counts as a standalone directory 
server solution for *nix.

> Translation:  What is the current Unix (Linux) method to provide central user 
> directory / authentication for about a dozen Unix (Linux / Solaris / *BSD / 
> AIX) systems /without/ a Windows Server in the mix.  I don't own a license 
> for any version of Windows Server that supports AD.  Nor do I feel compelled 
> to buy one.

I've seen plenty of businesses with Linux servers and OSX desktops.  These 
business often manage user auth on Linux with LDAP.  Various solutions 
were used to manage the OSX boxes but they were quite separate to Linux.

One caveat with LDAP.  When I last did this a few years ago many Linux 
systems were set up in such a manner that a failure of LDAP makes the 
systems largely unusable. AFAIK this is still a problem.

A sysadmin logging in had to wait out a series of timeouts while trying to 
open nsswitch.conf or the PAM config to disable LDAP so the underlying 
problems could be addressed.

One fix for this that I mentioned earlier is to manage the Linux systems 
using orchestration tools like Ansible.  Have them generate local passwd, 
shadow & group files from data stored in LDAP.  This prevent the timeout 
problems I mentioned earlier and also means that switching to a new 
authentication backend (eg, OpenLDAP to AD) is a lot easier since it is 
abstracted away.

Cheers,

Rob


From gtaylor at tnetconsulting.net  Tue Nov  6 14:58:58 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 21:58:58 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
Message-ID: <4505fa46-380b-2a2d-2e9b-e114369fbc5d@spamtrap.tnetconsulting.net>

On 11/05/2018 02:43 PM, Ben Greenfield via TUHS wrote:
> I found that I had to do all of this using SASL.

At first read I was thinking "SASL?  Really?".  Then I remembered that 
Simple Authentication and Security Layer is really just an abstraction 
layer.  An abstraction layer that very easily could have (but I don't 
know one way or the other) a back end to Kerberos.

> I remember it as SASL would handle the kerberization during boot up 
> getting tickets for each LDAP entry that you wanted mapped to a service 
> on that client.

Hum.

> I could be wrong but I think SASL seems to be way connect services on 
> Linux with LDAP that are served kerberized.

I've always viewed SASL as a way for applications to outsource the 
authentication / security so that the program code didn't need to worry 
about it.  It also allowed SASL to manage supporting all the different 
back end security methods.

I also think much the same about PAM.  -  In fact, I don't think I could 
properly differentiate between PAM and SASL.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/a1f5c5d7/attachment.bin>

From davida at pobox.com  Tue Nov  6 15:03:00 2018
From: davida at pobox.com (David Arnold)
Date: Tue, 6 Nov 2018 16:03:00 +1100
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <alpine.DEB.2.20.1811061122360.13752@mira.opentrend.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811061122360.13752@mira.opentrend.net>
Message-ID: <35C37347-E1DF-4FDF-BD5E-2EA92A46A0E2@pobox.com>

One place I worked recently used FreeIPA.  It's a Redhat-sponsored attempt to integrate a bunch of other free/open source projects and put them under a single web UI.

It’s largely compatible, functionally, with Active Directory, and I think can be set up to support cross-realm authentication with an AD installation as well.  It *doesn’t* (or at least in the setup I used) replace AD, and doesn’t seem to use any Samba components.

It does however include the DHCP and (Dynamic)DNS integration that’s part of AD.

It seemed pretty fragile in practice, although the overall level of systems expertise in this place was fairly low, and a lot of its problems could well have been issues with the underlying virtual machine or storage infrastructure.

I too still use NIS at home.  It works with my Linux boxes, but also the Sun, DEC, SGI and NeXT stuff as well.  I like the idea of a central directory, but X.500 always seemed like overkill and the “Lightweight” bit of LDAP doesn’t quite throw enough away for me …



d


> On 6 Nov 2018, at 14:03, Robert Brockway <robert at timetraveller.org> wrote:
> 
> On Mon, 5 Nov 2018, Grant Taylor via TUHS wrote:
> 
>> I also loath the idea that Unix (Linux) doesn't have a stand alone central directory server solution.  Or if LDAP + Kerveros is said solution, so be it. -  That's sort of what I'm trying to figure out.
> 
> LDAP with or without Kerberos certainly counts as a standalone directory server solution for *nix.
> 
>> Translation:  What is the current Unix (Linux) method to provide central user directory / authentication for about a dozen Unix (Linux / Solaris / *BSD / AIX) systems /without/ a Windows Server in the mix.  I don't own a license for any version of Windows Server that supports AD.  Nor do I feel compelled to buy one.
> 
> I've seen plenty of businesses with Linux servers and OSX desktops.  These business often manage user auth on Linux with LDAP.  Various solutions were used to manage the OSX boxes but they were quite separate to Linux.
> 
> One caveat with LDAP.  When I last did this a few years ago many Linux systems were set up in such a manner that a failure of LDAP makes the systems largely unusable. AFAIK this is still a problem.
> 
> A sysadmin logging in had to wait out a series of timeouts while trying to open nsswitch.conf or the PAM config to disable LDAP so the underlying problems could be addressed.
> 
> One fix for this that I mentioned earlier is to manage the Linux systems using orchestration tools like Ansible.  Have them generate local passwd, shadow & group files from data stored in LDAP.  This prevent the timeout problems I mentioned earlier and also means that switching to a new authentication backend (eg, OpenLDAP to AD) is a lot easier since it is abstracted away.
> 
> Cheers,
> 
> Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/90d50f31/attachment.sig>

From gtaylor at tnetconsulting.net  Tue Nov  6 15:24:42 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 22:24:42 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
Message-ID: <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>

On 11/05/2018 03:34 PM, Dan Cross wrote:
> You can use a modified `login` that will validate you against a KDC.

ACK

> The way it works is to set up a host key for the host you're logging 
> into; that is then used to authenticate the *host* to the KDC, which 
> then allows it to validate a user against the KDC and issue the user a 
> TGT at the same time. This works well for e.g. console and X logins.

That makes sense.

> Modifications have been made to e.g. SSH so that one can authenticate an 
> SSH session via GSSAPI, which usually wraps Kerberos. If I recall, 
> GSSAPI might be one of the lasting legacies of the DCE, though I may be 
> misremembering history.

*nod*

Generic Security Service Application Program Interface - The abstraction 
layer that (as far as I know) only had one service behind it.

> Security, in general, usually seeks to address five questions:
> 
> 1. Authentication - Is some entity who it claims to be?
> 2. Authorization - Is some entity allowed to perform some action?
> 3. Privacy - Can a third party snoop on a private conversation between 
> two entities?
> 4. Integrity - Can a third party alter communications between two 
> entities in an undetectable way?
> 5. Non-repudiation - Can it be definitively shown that some entity was a 
> party to some communication?

The 3rd A that I'm used to is "Access Control".  Is the requested action 
allowed given the above information.

> Kerberos is a authentication protocol.
> 
> LDAP, YP (retroactively named NIS after a lawsuit involving, I believe, 
> British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all 
> examples of directory services. To a first-order approximation, one 
> might think of a directory service as providing an oracle allowing one 
> to discover what entities exist in some domain.
> 
> Authentication protocols and directory services solve different 
> problems. Though in true Micro$oft-of-old fashion, AD sort of merged both.

I would argue that a directory including shadow information (like 
NIS(+)) does both too.

> Kerberos solves the authentication problem, but does not provide a 
> directory service nor does it solve the authorization problem (though 
> some "kerberized" services could use a library to consult a 
> user-provided file of ACLs mapping principals to privileges). On Unix, 
> "authorization data" includes things like your UID and the set of groups 
> you belong to (or more precisely, your process's UIDs and GIDs/groups). 
> Kerberos provided support for privacy via encryption libraries, and it 
> provided support for integrity via hashing/checksumming/signature 
> libraries. "Kerberized" versions of network services such as telnet, 
> FTP, rsh/rlogin/rcp etc all provided support for authentication via the 
> baseline Kerberos protocol as well as privacy and integrity via 
> connection-level encryption and checksumming.

I was not aware that Kerberos could provide privacy (encryption) for 
kerberized services.  I (naively) thought that Kerberos was 
authentication that other things could use to make access control decisions.

> Kerberos provided a replay cache, but otherwise provided only limited 
> support for non-repudiation via mutual authentication through the 
> KDC (that is, clients authenticated to servers, but servers also 
> authenticated to clients).

*nod*  I think NT4 domains and AD both had the same type of client to 
server mutual trust.  (At least for NT derived clients with machine 
trust accounts.)

> So while a KDC might tell you whether the principal connecting to your 
> SSH service is really "cross at GAJENDRA.NET <mailto:cross at GAJENDRA.NET>", 
> it won't tell you your UID, what shell you use, the path to your home 
> directory, what groups you are a member of, or what finger should say 
> for your real name.

*nod*nod*nod*

That's why the directory component is so important.  Somewhere to get 
all that other information.

> In its pure form, SSH provides support for limited authentication (via 
> public key cryptography and the wide distribution of public keys) and 
> limited authorization (via the `authorized_keys` file), privacy and 
> integrity.

I think that OpenSSH's certificate support extends that a bit.

> LDAP might provide you some mechanism to look up a user record that 
> provides those details; it may also provide some kind of hashed password 
> that a system can use to validate a password, but it won't do much 
> better than that. I suppose you could put an authorized SSH public key 
> into an LDAP directory in the same way you would put a hashed password.

I've always viewed LDAP as a directory that can have various content in 
it.  It then makes this content relatively easy to access.  What the 
content is is up to the content consumer.  Be it names, email addresses, 
shells, or password hashes.

> NIS was based on Sun RPC; as was mentioned earlier, anyone on a network 
> could bind to an NIS server and query it to get e.g., hashed password 
> file entries that they could run crack against. Nothing was encrypted.

Even if communications with the NIS server was encrypted, I'm not 
hearing anything that prevents an authenticated user from enumerating 
NIS.  Even if it was over encrypted channels.

> There was a system for a user to update his/her information in the NIS 
> database (e.g., this was how you changed your password or set your shell 
> or updated your office phone number...), but the "authentication" was 
> just checking your password; again nothing was encrypted, so a malicious 
> third party on your network could in theory mount a man-in-the-middle 
> attack against you and inject his/her own data into the transaction and 
> take over your account.

ACK

> NIS+ improved on this, but wasn't universally supported across systems 
> and we lost some useful NIS functionality: back in the NIS days, you 
> could supplement the contents of /etc/passwd with the NIS passwd maps, 
> but keep local overrides (e.g., for anyone not in the `@staff` netgroup, 
> set shell to `/sbin/nologin` on servers); perhaps there was a way to do 
> this with NIS+ but it felt very much like a binary thing: you were 
> either all in on NIS+ or not at all. Mixing and matching just wasn't as 
> easy as it had been. Also, the symmetric crypto was, I think, DES based 
> and as that fell apart I don't recall it getting much better. So unless 
> you were all Sun based (and many of us had heterogenous systems to worry 
> about; my shops supported Suns running SunOS 4 and Solaris 2, SGIs 
> running Irix, HP-UX machines, Alphas running OSF/1 then DEC Unix then 
> Tru64, DECstations running Ultrix, RS/6000's running AIX, RTs running 
> AOS, a few NeXTs, PCs running Linux *BSD and PCs running Windows and 
> Macs. Oh, and VMS on VAXen and Alphas. Yay. Elsewhere on campus we had a 
> mainframe running VM/ESA, a couple of Crays, some AS/400s; we also had a 
> few plan9 machines. We even had a PDP-10 running TOPS-10 at some point. 
> Good ol' YP cut across the widest swath of these so that's what we ran 
> the longest, but it was a more innocent time, network access was more 
> tightly controlled and it wasn't quite as dangerous to run something 
> like ypserv.

*nod*

> I thought for a while that LDAP would be the light and the way, but it 
> was really a lot more general than what I cared about just for Unix 
> system administration. Setting it up wasn't as easy as NIS, or even NIS+ 
> for that matter.

That's what I've gathered from a number of sources.  Which is why I've 
heard people avoid LDAP directly.  Or at least use something like 
Samba+Winbind or SSSD as an abstraction layer into LDAP+Kerberos.

> Netinfo came from NeXT and survived into Macos for a little while. It 
> was kind of neat but again the all-singing, all-dancing solution to the 
> world. No one else really used it.

Typical.

> Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed 
> the need for a directory service on DNS, which is already a distributed 
> directory service. You embedded relevant data into DNS TXT records, so 
> imagine doing a DNS query to look up a user's /etc/passwd entry: after 
> all, DNS already scaled and was well-proven Internet-wide. I don't know 
> that anyone ever really supported it, though.

I know that Red Hat Linux did have support for it.  One of my colleagues 
was a Hesiod maintainer for a while.

> So yeah. Kerberos is plenty fine for authentication for small to medium 
> sites (up to mid tens of thousands of users, I'd guess), but won't help 
> you distribute your authorization data. You need a directory service or 
> some other mechanism for that. Directory services will help you with 
> that, but usually don't do a great job at authentication, though they 
> may provide the means to distributed the data that other systems can use 
> for that. Of the directory services out there these days, LDAP seems to 
> have "won".

(Raw) LDAP and AD seem to be what I see the most of.  I've worked in a 
few shops that evolved their NDS into eDirectory with appropriate 
clients for other platforms.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/05a4fe0b/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 15:25:55 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 22:25:55 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>
 <cf4ed0fd-e2d1-4b5d-0514-5500efb6f3f5@spamtrap.tnetconsulting.net>
 <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net>
Message-ID: <f23fd60e-a26a-00a9-f31b-d88db9eecd9f@spamtrap.tnetconsulting.net>

On 11/05/2018 03:43 PM, Arthur Krewat wrote:
> NIS/YP is different than NIS+. NIS/YP is the old protocol. You could 
> basically bind to any server with the correct domain name, and look at 
> all the maps including passwd with it's encrypted passwords.
> 
> NIS+ is the hierarchical, encrypted, clients-need-keys, protocol.

ACK

> Almost two entirely different things. And "almost" is more like 
> 99.99999999999999999% different :)

I'm sorry, are you talking about NIS vs NIS+ or IPv4 vs IPv6?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/ae1e0418/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 15:32:53 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 22:32:53 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAEoi9W6d5KCExxGHdOoCyae154r4u_NvMYj40w0OCNXF7kRQxw@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
 <CAEoi9W6d5KCExxGHdOoCyae154r4u_NvMYj40w0OCNXF7kRQxw@mail.gmail.com>
Message-ID: <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net>

On 11/05/2018 06:46 PM, Dan Cross wrote:
> NIS would be the only other realistic option and it's just not secure 
> enough in this day and age.

What do you think about NIS (sans shadow) for directory and Kerberos for 
authentication?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/eb43cef1/attachment.bin>

From gtaylor at tnetconsulting.net  Tue Nov  6 15:34:48 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Mon, 5 Nov 2018 22:34:48 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <alpine.DEB.2.20.1811061122360.13752@mira.opentrend.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811061122360.13752@mira.opentrend.net>
Message-ID: <5d0536fb-5191-b5e3-bee0-764118db9fa9@spamtrap.tnetconsulting.net>

On 11/05/2018 08:03 PM, Robert Brockway wrote:
> One caveat with LDAP.  When I last did this a few years ago many Linux 
> systems were set up in such a manner that a failure of LDAP makes the 
> systems largely unusable. AFAIK this is still a problem.
> 
> A sysadmin logging in had to wait out a series of timeouts while trying 
> to open nsswitch.conf or the PAM config to disable LDAP so the 
> underlying problems could be addressed.

I've experienced such pain.  It's not fun.

I think SSSD is coming in to vogue as an abstraction layer between the 
system and LDAP+Kerberos for this very reason.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181105/0eb2a787/attachment.bin>

From grawity at gmail.com  Tue Nov  6 16:53:58 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Tue, 6 Nov 2018 08:53:58 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
Message-ID: <CAPWNY8WH09se3ZiJOsYYNBJGzgR7wgdA0tScKq3DFxRnEjCWBg@mail.gmail.com>

On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs at minnie.tuhs.org>
wrote:

>
>
> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
> wrote:
> >
> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> >> Let the client handle authentication via Kerberos
> >
> > I don't know enough about Kerberos (yet) to know if it would be possible
> for a login process to communicate with the KDC and get a TGT as part of
> logging in, without already being logged in.
> >
> > My ignorance is leaving me with a priming problem that seems like a
> catch 22.  You can't login without shadow information or TGT.  But
> traditional (simpler) kinit is run after being logged in.  So ... how do
> you detangle that?  The only thing that I can come up with is that the
> login process does the kinit functionality on the users behalf.
>
> I found that I had to do all of this using SASL.
>
>
> I remember it as SASL would handle the kerberization during boot up
> getting tickets for each LDAP entry that you wanted mapped to a service on
> that client.
>

Sorry but I cannot parse that sentence at all...


> I could be wrong but I think SASL seems to be way connect services on
> Linux with LDAP that are served kerberized.
>

SASL is involved somewhat, in that it does help with implementing Kerberos
– services and clients can call libsasl instead of talking Kerberos
directly, abstract away the complexity – but that's all it is, an
abstraction layer. (A quite useful one, though.)

But it's not the only method, strictly speaking (e.g. SSH and HTTP use
GSSAPI, and various older software use Kerberos directly). And as far as I
could understand the previous paragraph – it doesn't have anything specific
about "kerberization during boot up".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/70fd030c/attachment.html>

From grawity at gmail.com  Tue Nov  6 17:07:31 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Tue, 6 Nov 2018 09:07:31 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
Message-ID: <CAPWNY8UG9T32hme5bvtcmrFd3YYdXzNnPJK4J56zhBxBr=-MUA@mail.gmail.com>

On Tue, Nov 6, 2018 at 8:40 AM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 11/05/2018 03:34 PM, Dan Cross wrote:
> > You can use a modified `login` that will validate you against a KDC.
>
> ACK
>

These days the modification generally consists of pam_krb5 added to the
system's PAM configuration.


> > Modifications have been made to e.g. SSH so that one can authenticate an
> > SSH session via GSSAPI, which usually wraps Kerberos. If I recall,
> > GSSAPI might be one of the lasting legacies of the DCE, though I may be
> > misremembering history.
>
> *nod*
>

And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one can
authenticate a session via SASL, which usually wraps GSSAPI, which usually
wraps Kerberos.

> Kerberos solves the authentication problem, but does not provide a
> > directory service nor does it solve the authorization problem (though
> > some "kerberized" services could use a library to consult a
> > user-provided file of ACLs mapping principals to privileges). On Unix,
> > "authorization data" includes things like your UID and the set of groups
> > you belong to (or more precisely, your process's UIDs and GIDs/groups).
> > Kerberos provided support for privacy via encryption libraries, and it
> > provided support for integrity via hashing/checksumming/signature
> > libraries. "Kerberized" versions of network services such as telnet,
> > FTP, rsh/rlogin/rcp etc all provided support for authentication via the
> > baseline Kerberos protocol as well as privacy and integrity via
> > connection-level encryption and checksumming.
>
> I was not aware that Kerberos could provide privacy (encryption) for
> kerberized services.  I (naively) thought that Kerberos was
> authentication that other things could use to make access control
> decisions.
>

You're right, it's primarily an authentication protocol. But due to the way
it works, it *also* negotiates a 'session key' between the user and the
service, which then may be used for transport encryption (sealing). It's
not commonly used as far as I know – most new protocols already have their
own security layers such as TLS or SSH.

Actually LDAP is the only still-widespread protocol that comes to mind
whose implementations frequently make use of Kerberos-based encryption (via
GSSAPI). This is especially common in Active Directory environments, where
the DCs might not have a valid TLS certificate.

(I seem to recall kerberized Telnet didn't survive because it was limited
to DES/3DES for an odd reason. Didn't quite understand why that was the
case, though.)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/bdd11757/attachment.html>

From ben at cogs.com  Tue Nov  6 22:54:31 2018
From: ben at cogs.com (Ben Greenfield)
Date: Tue, 6 Nov 2018 07:54:31 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
Message-ID: <BD6882ED-8BB9-4E34-8155-B3A5E123D307@cogs.com>



> On Nov 5, 2018, at 5:34 PM, Dan Cross <crossd at gmail.com> wrote:
> 
> Netinfo came from NeXT and survived into Macos for a little while.

We had are Netinfo server lookup passwords from our Solaris system and we used that through Mac OS X Server which I think stopped at version 1.2 or 1.6. They then switched the directory system when Mac OS X client was released  to Open Directory which was an OpenLDAP. The Open Directory was kerberized and all services that were shipped used kerberos.  This could act as Directory Domain server for windows clients.


> It was kind of neat but again the all-singing, all-dancing solution to the world. No one else really used it.



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

From ben at cogs.com  Tue Nov  6 22:59:22 2018
From: ben at cogs.com (Ben Greenfield)
Date: Tue, 6 Nov 2018 07:59:22 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <4505fa46-380b-2a2d-2e9b-e114369fbc5d@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
 <4505fa46-380b-2a2d-2e9b-e114369fbc5d@spamtrap.tnetconsulting.net>
Message-ID: <82EB9899-0D1D-44DB-BB7D-61E12B621551@cogs.com>



> On Nov 5, 2018, at 11:58 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> On 11/05/2018 02:43 PM, Ben Greenfield via TUHS wrote:
>> I found that I had to do all of this using SASL.
> 
> At first read I was thinking "SASL?  Really?".  Then I remembered that Simple Authentication and Security Layer is really just an abstraction layer.  An abstraction layer that very easily could have (but I don't know one way or the other) a back end to Kerberos.
> 
>> I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.
> 
> Hum.
> 
>> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
> 
> I've always viewed SASL as a way for applications to outsource the authentication / security so that the program code didn't need to worry about it.  It also allowed SASL to manage supporting all the different back end security methods.
> 
> I also think much the same about PAM.  -  In fact, I don't think I could properly differentiate between PAM and SASL.

Yes, pam when I was trying to figure out how to put it altogether PAM was always working in the background but I believe it was the SASL configs that pointed to my Open Directory server that centralized our Linux accounts. So as strange as it may seem to some there have be instances were OS X served Linux clients:)



> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 



From ben at cogs.com  Tue Nov  6 23:21:14 2018
From: ben at cogs.com (Ben Greenfield)
Date: Tue, 6 Nov 2018 08:21:14 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WH09se3ZiJOsYYNBJGzgR7wgdA0tScKq3DFxRnEjCWBg@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
 <CAPWNY8WH09se3ZiJOsYYNBJGzgR7wgdA0tScKq3DFxRnEjCWBg@mail.gmail.com>
Message-ID: <A75BA761-85C8-4062-9F49-26870AF51884@cogs.com>



> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:
> 
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
> 
> 
> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
> > 
> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
> >> Let the client handle authentication via Kerberos
> > 
> > I don't know enough about Kerberos (yet) to know if it would be possible for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.
> > 
> > My ignorance is leaving me with a priming problem that seems like a catch 22.  You can't login without shadow information or TGT.  But traditional (simpler) kinit is run after being logged in.  So ... how do you detangle that?  The only thing that I can come up with is that the login process does the kinit functionality on the users behalf.
> 
> I found that I had to do all of this using SASL. 
> 
> 
> I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.
> 
> Sorry but I cannot parse that sentence at all…


I’m sorry it was about 8 years ago and is from memory but. I believe during the startup of the system the SASL config files contained tickets that established a trust relationship between that system and our Open Directory server. My memory is that each ticket was associated a service and the config file for the service  would point to the ticket.

> 
> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
>  
> SASL is involved somewhat, in that it does help with implementing Kerberos – services and clients can call libsasl instead of talking Kerberos directly, abstract away the complexity – but that's all it is, an abstraction layer. (A quite useful one, though.)
> 
> But it's not the only method, strictly speaking (e.g. SSH and HTTP use GSSAPI, and various older software use Kerberos directly). And as far as I could understand the previous paragraph – it doesn't have anything specific about "kerberization during boot up”.


My memory could be wrong but I thought to establish the trust relationship between the kerberized server and the client happened during boot/when the config files were read ticket granting tickets were given and received. 



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

From grawity at gmail.com  Tue Nov  6 23:44:47 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Tue, 6 Nov 2018 15:44:47 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <A75BA761-85C8-4062-9F49-26870AF51884@cogs.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
 <CAPWNY8WH09se3ZiJOsYYNBJGzgR7wgdA0tScKq3DFxRnEjCWBg@mail.gmail.com>
 <A75BA761-85C8-4062-9F49-26870AF51884@cogs.com>
Message-ID: <CAPWNY8WqaFQ1=gD-tLbrgb6hYSz1O7nS_E+ZeSfJ1P9idqLzZA@mail.gmail.com>

On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben at cogs.com> wrote:

>
>
> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:
>
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>
>>
>>
>> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
>> wrote:
>> >
>> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> >> Let the client handle authentication via Kerberos
>> >
>> > I don't know enough about Kerberos (yet) to know if it would be
>> possible for a login process to communicate with the KDC and get a TGT as
>> part of logging in, without already being logged in.
>> >
>> > My ignorance is leaving me with a priming problem that seems like a
>> catch 22.  You can't login without shadow information or TGT.  But
>> traditional (simpler) kinit is run after being logged in.  So ... how do
>> you detangle that?  The only thing that I can come up with is that the
>> login process does the kinit functionality on the users behalf.
>>
>> I found that I had to do all of this using SASL.
>>
>>
>> I remember it as SASL would handle the kerberization during boot up
>> getting tickets for each LDAP entry that you wanted mapped to a service on
>> that client.
>>
>
> Sorry but I cannot parse that sentence at all…
>
>
>
> I’m sorry it was about 8 years ago and is from memory but. I believe
> during the startup of the system the SASL config files contained tickets
> that established a trust relationship between that system and our Open
> Directory server. My memory is that each ticket was associated a service
> and the config file for the service  would point to the ticket.
>
>
>> I could be wrong but I think SASL seems to be way connect services on
>> Linux with LDAP that are served kerberized.
>>
>
> SASL is involved somewhat, in that it does help with implementing Kerberos
> – services and clients can call libsasl instead of talking Kerberos
> directly, abstract away the complexity – but that's all it is, an
> abstraction layer. (A quite useful one, though.)
>
> But it's not the only method, strictly speaking (e.g. SSH and HTTP use
> GSSAPI, and various older software use Kerberos directly). And as far as I
> could understand the previous paragraph – it doesn't have anything specific
> about "kerberization during boot up”.
>
>
> My memory could be wrong but I thought to establish the trust relationship
> between the kerberized server and the client happened during boot/when the
> config files were read ticket granting tickets were given and received.
>

No, kerberized servers don't obtain own tickets – unless they themselves
act as *clients* to another kerberized service.

Trust relationships between the server and KDC (as well as between the
client and KDC) are just based on it knowing the same shared secret as the
KDC does. For clients that's the password, for server's that's usually the
raw key in /etc/krb5.keytab.

As for the trust relationship between client and server – if I remember the
protocol correctly, at this point it becomes asymmetric. When a client
sends its ticket to the server, the server will just decrypt it using its
own key (keytab) without any KDC involvement. On success, it knows that
it's a legitimate ticket because only the KDC could have encrypted it –
whereas the client knows that only the real server will be able to decrypt
it.

The main reason a server might obtain tickets on boot is because it *also*
acts as client to another kerberized service. (For example, a web server
might be a client of a fileserver. An SSH shell server might be a client of
an LDAP directory server.)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/f7dc7f26/attachment.html>

From grawity at gmail.com  Tue Nov  6 23:46:34 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Tue, 6 Nov 2018 15:46:34 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <A75BA761-85C8-4062-9F49-26870AF51884@cogs.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
 <CAPWNY8WH09se3ZiJOsYYNBJGzgR7wgdA0tScKq3DFxRnEjCWBg@mail.gmail.com>
 <A75BA761-85C8-4062-9F49-26870AF51884@cogs.com>
Message-ID: <CAPWNY8XbPtugsE0H-yyeZBYVxw9bHetGsKm7sbtoq-TaEuRdPw@mail.gmail.com>

On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben at cogs.com> wrote:

>
>
> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:
>
> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs at minnie.tuhs.org>
> wrote:
>
>>
>>
>> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
>> wrote:
>> >
>> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> >> Let the client handle authentication via Kerberos
>> >
>> > I don't know enough about Kerberos (yet) to know if it would be
>> possible for a login process to communicate with the KDC and get a TGT as
>> part of logging in, without already being logged in.
>> >
>> > My ignorance is leaving me with a priming problem that seems like a
>> catch 22.  You can't login without shadow information or TGT.  But
>> traditional (simpler) kinit is run after being logged in.  So ... how do
>> you detangle that?  The only thing that I can come up with is that the
>> login process does the kinit functionality on the users behalf.
>>
>> I found that I had to do all of this using SASL.
>>
>>
>> I remember it as SASL would handle the kerberization during boot up
>> getting tickets for each LDAP entry that you wanted mapped to a service on
>> that client.
>>
>
> Sorry but I cannot parse that sentence at all…
>
>
>
> I’m sorry it was about 8 years ago and is from memory but. I believe
> during the startup of the system the SASL config files contained tickets
> that established a trust relationship between that system and our Open
> Directory server. My memory is that each ticket was associated a service
> and the config file for the service  would point to the ticket.
>

Upon rereading this, you're probably thinking of keytabs (which hold static
pre-provisioned keys) rather than tickets (which hold session keys).

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/30939773/attachment.html>

From ben at cogs.com  Wed Nov  7 00:00:09 2018
From: ben at cogs.com (Ben Greenfield)
Date: Tue, 6 Nov 2018 09:00:09 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8WqaFQ1=gD-tLbrgb6hYSz1O7nS_E+ZeSfJ1P9idqLzZA@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <D1834A80-1F31-4F16-9AC2-E6004E3AE4E6@cogs.com>
 <CAPWNY8WH09se3ZiJOsYYNBJGzgR7wgdA0tScKq3DFxRnEjCWBg@mail.gmail.com>
 <A75BA761-85C8-4062-9F49-26870AF51884@cogs.com>
 <CAPWNY8WqaFQ1=gD-tLbrgb6hYSz1O7nS_E+ZeSfJ1P9idqLzZA@mail.gmail.com>
Message-ID: <2B38E200-697F-4A26-9013-26C07B54351B@cogs.com>



> On Nov 6, 2018, at 8:44 AM, Mantas Mikulėnas <grawity at gmail.com> wrote:
> 
> On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield <ben at cogs.com <mailto:ben at cogs.com>> wrote:
> 
> 
>> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas <grawity at gmail.com <mailto:grawity at gmail.com>> wrote:
>> 
>> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
>> 
>> 
>> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS <tuhs at minnie.tuhs.org <mailto:tuhs at minnie.tuhs.org>> wrote:
>> > 
>> > On 11/05/2018 12:24 AM, Mantas Mikulėnas wrote:
>> >> Let the client handle authentication via Kerberos
>> > 
>> > I don't know enough about Kerberos (yet) to know if it would be possible for a login process to communicate with the KDC and get a TGT as part of logging in, without already being logged in.
>> > 
>> > My ignorance is leaving me with a priming problem that seems like a catch 22.  You can't login without shadow information or TGT.  But traditional (simpler) kinit is run after being logged in.  So ... how do you detangle that?  The only thing that I can come up with is that the login process does the kinit functionality on the users behalf.
>> 
>> I found that I had to do all of this using SASL. 
>> 
>> 
>> I remember it as SASL would handle the kerberization during boot up getting tickets for each LDAP entry that you wanted mapped to a service on that client.
>> 
>> Sorry but I cannot parse that sentence at all…
> 
> 
> I’m sorry it was about 8 years ago and is from memory but. I believe during the startup of the system the SASL config files contained tickets that established a trust relationship between that system and our Open Directory server. My memory is that each ticket was associated a service and the config file for the service  would point to the ticket.
> 
>> 
>> I could be wrong but I think SASL seems to be way connect services on Linux with LDAP that are served kerberized.
>>  
>> SASL is involved somewhat, in that it does help with implementing Kerberos – services and clients can call libsasl instead of talking Kerberos directly, abstract away the complexity – but that's all it is, an abstraction layer. (A quite useful one, though.)
>> 
>> But it's not the only method, strictly speaking (e.g. SSH and HTTP use GSSAPI, and various older software use Kerberos directly). And as far as I could understand the previous paragraph – it doesn't have anything specific about "kerberization during boot up”.
> 
> 
> My memory could be wrong but I thought to establish the trust relationship between the kerberized server and the client happened during boot/when the config files were read ticket granting tickets were given and received. 
> 
> No, kerberized servers don't obtain own tickets – unless they themselves act as *clients* to another kerberized service.

Which might be what I’m trying to describe.


> 
> Trust relationships between the server and KDC (as well as between the client and KDC) are just based on it knowing the same shared secret as the KDC does. For clients that's the password, for server's that's usually the raw key in /etc/krb5.keytab.
> 
> As for the trust relationship between client and server – if I remember the protocol correctly, at this point it becomes asymmetric. When a client sends its ticket to the server, the server will just decrypt it using its own key (keytab) without any KDC involvement. On success, it knows that it's a legitimate ticket because only the KDC could have encrypted it – whereas the client knows that only the real server will be able to decrypt it.
> 
> The main reason a server might obtain tickets on boot is because it *also* acts as client to another kerberized service. (For example, a web server might be a client of a fileserver. An SSH shell server might be a client of an LDAP directory server.)
> 
> -- 
> Mantas Mikulėnas

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

From krewat at kilonet.net  Wed Nov  7 02:50:36 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 6 Nov 2018 11:50:36 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <f23fd60e-a26a-00a9-f31b-d88db9eecd9f@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>
 <cf4ed0fd-e2d1-4b5d-0514-5500efb6f3f5@spamtrap.tnetconsulting.net>
 <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net>
 <f23fd60e-a26a-00a9-f31b-d88db9eecd9f@spamtrap.tnetconsulting.net>
Message-ID: <a53582e6-d1ee-d50e-d7d6-387876bc75cb@kilonet.net>



On 11/6/2018 12:25 AM, Grant Taylor via TUHS wrote:
> On 11/05/2018 03:43 PM, Arthur Krewat wrote:
>
>> Almost two entirely different things. And "almost" is more like 
>> 99.99999999999999999% different :)
>
> I'm sorry, are you talking about NIS vs NIS+ or IPv4 vs IPv6?
>
>
>

Not sure if that's humor or not ;)


NIS (YP) vs. NIS+




From aap at papnet.eu  Wed Nov  7 03:09:55 2018
From: aap at papnet.eu (Angelo Papenhoff)
Date: Tue, 6 Nov 2018 18:09:55 +0100
Subject: [TUHS] /crp
Message-ID: <20181106170955.GA4087@indra.papnet.eu>

I was wondering, what was the /crp mount point in early UNIX used for?
And what does "crp" mean? Does it mean what I think it does?
It is only mentioned in V3 it seems:
./v4man/manx/unspk.8:unspk lives in /crp/vs   (v4/manx means pre-v4)
./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc  [ <grammar ]
./v3man/man4/rk.4:/dev/rk3      /crp file system

I suppose scj, doug or ken can help out.

aap


From gtaylor at tnetconsulting.net  Wed Nov  7 03:30:48 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 6 Nov 2018 10:30:48 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAPWNY8UG9T32hme5bvtcmrFd3YYdXzNnPJK4J56zhBxBr=-MUA@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAPWNY8UG9T32hme5bvtcmrFd3YYdXzNnPJK4J56zhBxBr=-MUA@mail.gmail.com>
Message-ID: <4d85ccda-7200-b6e7-8a27-5832e3bdcdba@spamtrap.tnetconsulting.net>

On 11/06/2018 12:07 AM, Mantas Mikulėnas wrote:
> These days the modification generally consists of pam_krb5 added to the 
> system's PAM configuration.

Hum....  I need to do some reading on that.

> And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one 
> can authenticate a session via SASL, which usually wraps GSSAPI, which 
> usually wraps Kerberos.

*nod*

Complicating things is that implementations can choose to bypass SASL 
and do the GSSAPI interaction directly.  Or take things even further and 
do the Kerberos interaction directly.

Yet another reason why all these things are complicated.  So many 
choices that impact other choices in the same problem domain.

> You're right, it's primarily an authentication protocol.

:-)

> But due to the way it works, it *also* negotiates a 'session key' between 
> the user and the service, which then may be used for transport encryption 
> (sealing).

Does that mean that the protocols would need to retain the session key 
and use it for their other non-Kerberos specific protocols?  I.e. the 
rsh daemon would need to use the session key to encrypt / decrypt the 
rsh data, after and independent of the Kerberos authentication process.

> It's not commonly used as far as I know – most new protocols already 
> have their own security layers such as TLS or SSH.

ACK

I worry that other encryption protocols / methods have far surpassed 
Kerberos' encryption capability / strength.

> Actually LDAP is the only still-widespread protocol that comes to mind 
> whose implementations frequently make use of Kerberos-based encryption 
> (via GSSAPI).

O.o‽

This sounds like it would be independent of LDAP over SSL (TCP 636).

Would this Kerberos specified encryption be run over the standard LDAP 
port (TCP 389)?

> This is especially common in Active Directory environments, where the 
> DCs might not have a valid TLS certificate.

O.o‽

I'm going to have to go pick my AD guru's brain after reading that.

> (I seem to recall kerberized Telnet didn't survive because it was 
> limited to DES/3DES for an odd reason. Didn't quite understand why that 
> was the case, though.)

#questionsQuestions



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/34257534/attachment.bin>

From ron at ronnatalie.com  Wed Nov  7 05:22:38 2018
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Tue, 6 Nov 2018 14:22:38 -0500
Subject: [TUHS] /crp
In-Reply-To: <20181106170955.GA4087@indra.papnet.eu>
References: <20181106170955.GA4087@indra.papnet.eu>
Message-ID: <04d501d47606$15044630$3f0cd290$@ronnatalie.com>

The "crp" user name was Chuck Privitera.    Don't know if it was him or they
just had a disk they dumped cr..p on ...


> -----Original Message-----
> From: TUHS <tuhs-bounces at minnie.tuhs.org> On Behalf Of Angelo
> Papenhoff
> Sent: Tuesday, November 6, 2018 12:10 PM
> To: tuhs at minnie.tuhs.org
> Subject: [TUHS] /crp
> 
> I was wondering, what was the /crp mount point in early UNIX used for?
> And what does "crp" mean? Does it mean what I think it does?
> It is only mentioned in V3 it seems:
> ./v4man/manx/unspk.8:unspk lives in /crp/vs   (v4/manx means pre-v4)
> ./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc  [ <grammar ]
> ./v3man/man4/rk.4:/dev/rk3      /crp file system
> 
> I suppose scj, doug or ken can help out.
> 
> aap



From ron at ronnatalie.com  Wed Nov  7 05:25:29 2018
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Tue, 6 Nov 2018 14:25:29 -0500
Subject: [TUHS] /crp
In-Reply-To: <20181106170955.GA4087@indra.papnet.eu>
References: <20181106170955.GA4087@indra.papnet.eu>
Message-ID: <04db01d47606$7b003700$7100a500$@ronnatalie.com>

An early UNIX paper shows the system had four RK05's (4872 512-byte blocks
on UNIX, for some reason only 4800 used on the DEC OSs ... remember we had
to poke ROLLIN to copy the full UNIX partition standalone).
/dev/rk0 - available for user packs.
/dev/rk1 - root
/dev/rk2 - /usr
/dev/rk3 - /crp

I think it was just additional storage of "crap".

> -----Original Message-----
> From: TUHS <tuhs-bounces at minnie.tuhs.org> On Behalf Of Angelo
> Papenhoff
> Sent: Tuesday, November 6, 2018 12:10 PM
> To: tuhs at minnie.tuhs.org
> Subject: [TUHS] /crp
> 
> I was wondering, what was the /crp mount point in early UNIX used for?
> And what does "crp" mean? Does it mean what I think it does?
> It is only mentioned in V3 it seems:
> ./v4man/manx/unspk.8:unspk lives in /crp/vs   (v4/manx means pre-v4)
> ./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc  [ <grammar ]
> ./v3man/man4/rk.4:/dev/rk3      /crp file system
> 
> I suppose scj, doug or ken can help out.
> 
> aap



From gtaylor at tnetconsulting.net  Wed Nov  7 05:43:44 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 6 Nov 2018 12:43:44 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <a53582e6-d1ee-d50e-d7d6-387876bc75cb@kilonet.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net>
 <cf4ed0fd-e2d1-4b5d-0514-5500efb6f3f5@spamtrap.tnetconsulting.net>
 <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net>
 <f23fd60e-a26a-00a9-f31b-d88db9eecd9f@spamtrap.tnetconsulting.net>
 <a53582e6-d1ee-d50e-d7d6-387876bc75cb@kilonet.net>
Message-ID: <19db57c0-f07a-da21-f642-9014cb88ba17@spamtrap.tnetconsulting.net>

On 11/06/2018 09:50 AM, Arthur Krewat wrote:
> Not sure if that's humor or not ;)

Just spinning what I took as your humor about NIS vs NIS+ and 
reassigning it as my humor about IPv4 vs IPv6.  }:-)

> NIS (YP) vs. NIS+

ACK



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/c92dcb48/attachment.bin>

From grawity at gmail.com  Wed Nov  7 05:58:04 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Tue, 6 Nov 2018 21:58:04 +0200
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <4d85ccda-7200-b6e7-8a27-5832e3bdcdba@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAPWNY8UG9T32hme5bvtcmrFd3YYdXzNnPJK4J56zhBxBr=-MUA@mail.gmail.com>
 <4d85ccda-7200-b6e7-8a27-5832e3bdcdba@spamtrap.tnetconsulting.net>
Message-ID: <CAPWNY8WycJjaYXEsJvk3M9czQ6d_S6aRsPpF=fs=-=3hcoxE3g@mail.gmail.com>

On Tue, Nov 6, 2018 at 9:18 PM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 11/06/2018 12:07 AM, Mantas Mikulėnas wrote:
> > These days the modification generally consists of pam_krb5 added to the
> > system's PAM configuration.
>
> Hum....  I need to do some reading on that.
>
> > And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one
> > can authenticate a session via SASL, which usually wraps GSSAPI, which
> > usually wraps Kerberos.
>
> *nod*
>
> Complicating things is that implementations can choose to bypass SASL
> and do the GSSAPI interaction directly.  Or take things even further and
> do the Kerberos interaction directly.
>

Though from what I've seen on their mailing list, MIT Kerberos developers
seem to recommend using GSSAPI at minimum, rather than the raw Kerberos
APIs.


>
> Yet another reason why all these things are complicated.  So many
> choices that impact other choices in the same problem domain.
>
> > You're right, it's primarily an authentication protocol.
>
> :-)
>
> > But due to the way it works, it *also* negotiates a 'session key'
> between
> > the user and the service, which then may be used for transport
> encryption
> > (sealing).
>
> Does that mean that the protocols would need to retain the session key
> and use it for their other non-Kerberos specific protocols?  I.e. the
> rsh daemon would need to use the session key to encrypt / decrypt the
> rsh data, after and independent of the Kerberos authentication process.
>

Well, they can use it, but they don't have to. It's up to the developer in
the end. The earlier kerberized protocols did, because they didn't have any
other encryption layer. Most recent protocols establish encryption in any
case (be it TLS or SSHv2 or something else) so they just don't bother
calling the SASL (or GSSAPI) seal functions.


>
> > It's not commonly used as far as I know – most new protocols already
> > have their own security layers such as TLS or SSH.
>
> ACK
>
> I worry that other encryption protocols / methods have far surpassed
> Kerberos' encryption capability / strength.
>

Kerberos does include modern enctypes (such as aes128/aes256), but from
what *little* I understand about this part, it's still not as good as the
modern protocols. (E.g. complete lack of PFS – the same client or server
always uses the same master key until it's manually rotated...)

On the bright side, the *authentication* of Kerberos is solid as far as
I've heard. (Which, again I know very little about this part, but I do
remember someone saying that it has an actual security proof, as well as
being decently quantum-resistant.)


>
> > Actually LDAP is the only still-widespread protocol that comes to mind
> > whose implementations frequently make use of Kerberos-based encryption
> > (via GSSAPI).
>
> O.o‽
>
> This sounds like it would be independent of LDAP over SSL (TCP 636).
>
> Would this Kerberos specified encryption be run over the standard LDAP
> port (TCP 389)?
>

Usually, yes.

(There is no technical reason why it couldn't run inside TLS, it's just
redundant – OpenLDAP doesn't mind but e.g. Active Directory explicitly
refuses to use both encryption layers at once. If you use TLS, you can
still use GSSAPI auth, but it insists that you turn off the GSSAPI
signing/sealing.)


>
> > This is especially common in Active Directory environments, where the
> > DCs might not have a valid TLS certificate.
>
> O.o‽
>
> I'm going to have to go pick my AD guru's brain after reading that.
>
> > (I seem to recall kerberized Telnet didn't survive because it was
> > limited to DES/3DES for an odd reason. Didn't quite understand why that
> > was the case, though.)
>
> #questionsQuestions
>

(This reminds me that I've noticed at least one of the MIT Kerberos
developers here in TUHS, who would surely know more about this than I've
gathered through barely few years of messing around.)

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/82647b66/attachment.html>

From dave at horsfall.org  Wed Nov  7 07:51:32 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 7 Nov 2018 08:51:32 +1100 (EST)
Subject: [TUHS] /crp
In-Reply-To: <04db01d47606$7b003700$7100a500$@ronnatalie.com>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
Message-ID: <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>

On Tue, 6 Nov 2018, ron at ronnatalie.com wrote:

> An early UNIX paper shows the system had four RK05's (4872 512-byte 
> blocks on UNIX, for some reason only 4800 used on the DEC OSs ... 
> remember we had to poke ROLLIN to copy the full UNIX partition 
> standalone).

Bad blocks?  I think I have an article in AUUGN where I proposed that bad 
blocks be assigned (somehow) to a pseudo-file as inode #0 (or -1?); that 
way, the "dump" utility would not see it, and neither would the FS tools 
(but a disk image would, of course).

> /dev/rk0 - available for user packs.
> /dev/rk1 - root

Odd layout...  I normally saw them the other way around.

-- Dave


From crossd at gmail.com  Wed Nov  7 08:24:02 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Nov 2018 17:24:02 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
Message-ID: <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>

On Tue, Nov 6, 2018 at 1:40 AM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 11/05/2018 03:34 PM, Dan Cross wrote:
> [snip]
> > Security, in general, usually seeks to address five questions:
> >
> > 1. Authentication - Is some entity who it claims to be?
> > 2. Authorization - Is some entity allowed to perform some action?
> > 3. Privacy - Can a third party snoop on a private conversation between
> > two entities?
> > 4. Integrity - Can a third party alter communications between two
> > entities in an undetectable way?
> > 5. Non-repudiation - Can it be definitively shown that some entity was a
> > party to some communication?
>
> The 3rd A that I'm used to is "Access Control".  Is the requested action
> allowed given the above information.
>

Isn't that authorization?

> Kerberos is a authentication protocol.
> >
> > LDAP, YP (retroactively named NIS after a lawsuit involving, I believe,
> > British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all
> > examples of directory services. To a first-order approximation, one
> > might think of a directory service as providing an oracle allowing one
> > to discover what entities exist in some domain.
> >
> > Authentication protocols and directory services solve different
> > problems. Though in true Micro$oft-of-old fashion, AD sort of merged
> both.
>
> I would argue that a directory including shadow information (like
> NIS(+)) does both too.
>

Not really. It provides the data that lets one perform a relatively weak
validation of e.g. a password, but it is not *itself* an authentication
protocol.

> Kerberos solves the authentication problem, but does not provide a
> > directory service nor does it solve the authorization problem (though
> > some "kerberized" services could use a library to consult a
> > user-provided file of ACLs mapping principals to privileges). On Unix,
> > "authorization data" includes things like your UID and the set of groups
> > you belong to (or more precisely, your process's UIDs and GIDs/groups).
> > Kerberos provided support for privacy via encryption libraries, and it
> > provided support for integrity via hashing/checksumming/signature
> > libraries. "Kerberized" versions of network services such as telnet,
> > FTP, rsh/rlogin/rcp etc all provided support for authentication via the
> > baseline Kerberos protocol as well as privacy and integrity via
> > connection-level encryption and checksumming.
>
> I was not aware that Kerberos could provide privacy (encryption) for
> kerberized services.  I (naively) thought that Kerberos was
> authentication that other things could use to make access control
> decisions.
>

Older versions of Kerberos often included modified versions of popular
servers and their clients that had been modified to use the kerberos
protocol for authentication, and also often to encrypt communications. For
example, the version of `telnet` that shipped with MIT kerberos back in the
day had an option that could be used to encrypt the data stream; similarly
with rlogin, et al. I have a dim memory that the version of FTP might
support encryption for the control connection but not data connections (but
I also might be purely imagining that). I'm guessing most of this stuff has
been dropped from more recent distributions because...really...telnet?

[snip]
> > In its pure form, SSH provides support for limited authentication (via
> > public key cryptography and the wide distribution of public keys) and
> > limited authorization (via the `authorized_keys` file), privacy and
> > integrity.
>
> I think that OpenSSH's certificate support extends that a bit.
>

What I meant is that SSH supports a limited sense of checking whether a
given key matches and making a yea or nay decision based on that.

[snip]
> Even if communications with the NIS server was encrypted, I'm not
> hearing anything that prevents an authenticated user from enumerating
> NIS.  Even if it was over encrypted channels.
>

Correct. `ypcat passwd` often gave you a bunch of hashed passwords in field
two of a stream 7th Edition /etc/passwd formatted entries.

I have, again, some vague memory that at some point this was changed so
that root on the localhost could get a shadow-style map, but normal users
couldn't see the password hashes. But I might totally be making that up,
and of course, it wasn't robust security since what went over the wire
wasn't encrypted and breaking root on a host could still get you all the
hashes on the network. Contrast with Kerberos, where breaking root on a
host doesn't compromise much beyond that host (modulo leveraging that to
steal user passwords and the like).

[snip]
> > Hesiod, which seems unique to Athena, was kind of neat; it piggy-backed
> > the need for a directory service on DNS, which is already a distributed
> > directory service. You embedded relevant data into DNS TXT records, so
> > imagine doing a DNS query to look up a user's /etc/passwd entry: after
> > all, DNS already scaled and was well-proven Internet-wide. I don't know
> > that anyone ever really supported it, though.
>
> I know that Red Hat Linux did have support for it.  One of my colleagues
> was a Hesiod maintainer for a while.
>

Ha! That's a hoot.

[snip]

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

From crossd at gmail.com  Wed Nov  7 08:29:50 2018
From: crossd at gmail.com (Dan Cross)
Date: Tue, 6 Nov 2018 17:29:50 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
 <CAEoi9W6d5KCExxGHdOoCyae154r4u_NvMYj40w0OCNXF7kRQxw@mail.gmail.com>
 <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net>
Message-ID: <CAEoi9W6fQw05GvrfWkkT0ABLG=JLvkUJ_hg=sj+TbENsav9enQ@mail.gmail.com>

On Tue, Nov 6, 2018 at 1:42 AM Grant Taylor via TUHS <tuhs at minnie.tuhs.org>
wrote:

> On 11/05/2018 06:46 PM, Dan Cross wrote:
> > NIS would be the only other realistic option and it's just not secure
> > enough in this day and age.
>
> What do you think about NIS (sans shadow) for directory and Kerberos for
> authentication?
>

It wouldn't do it, but I guess it depends on how much you trust your
environment and your users etc. If you're intent on using a network
directory service, I'd bite the bullet and invest in setting up Kerberos
and LDAP. The thing with pairing Kerberos (for authentication) with NIS is
that while you'll have decent authentication security, nothing prevents a
malicious third party from modifying the answer from `ypserv` for some user
to set the UID to 0, thus making that user root. If authentication is
happening by users typing passwords into SSH clients, which then get sent
to SSH servers to be validated against the KDC on machines that have been
so cracked, an attacker can steal passwords by subverting the SSH server
processes.

However, if you trust your users not to do that and you're on a relatively
small, self-contained and decently secured network, then it may be fine.
>From what you described earlier I think generating text files and
distributing them around (possibly with rdist or rsync) and pairing that
with kerberos would be less work and more robust.

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

From norman at oclsc.org  Wed Nov  7 09:31:44 2018
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 06 Nov 2018 19:31:44 -0400
Subject: [TUHS] /crp
Message-ID: <1541547109.9957.for-standards-violators@oclsc.org>

Interesting.  /crp was a regular part of the Research world
in the mid-1980s when I joined up.  It was nothing special,
just an extra file system for extra junk, which might or might
not be backed up depending on the system.

I had no idea its roots ran so far back in time.

I always thought it was an abbreviation for `crap,' though,
oddly, the conventional pronunciation seemed to be creep.

Norman Wilson
Toronto ON


From norman at oclsc.org  Wed Nov  7 09:59:53 2018
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 06 Nov 2018 19:59:53 -0400
Subject: [TUHS] YP / NIS / NIS+ / LDAP
Message-ID: <1541548796.10679.for-standards-violators@oclsc.org>

A. P. Garcia:

  I'd be interested in knowing where a pure unix environment
  exists, beyond my imagination and dreams that is.

====

For starters, the computing facility used for teaching
in the Department of Computer Science at the University
of Toronto.  Linux workstations throughout our labs; Linux
file servers and other back-ends, except OpenBSD for the
Kerberos KDCs and firewalls.

And yes, we use Kerberos, including Kerberized NFS for
(almost) all exports to lab workstations, which cannot
be made wholly secure against physical breakins by students.
(There's no practical way to prevent that entirely.)

Except we also use traditional UNIX /etc/shadow files
and non-Kerberized NFS for systems that are physically
secure, including the host to which people can ssh from
outside.  If you don't type a password when you log in,
you cannot get a Kerberos TGT, so you wouldn't have access
to your home directory were it Kerberized there; and we
aren't willing to (and probably couldn't) forbid use of
.ssh/authorized_keys for users who know how to do that.

Because we need to maintain the password in two places,
and because we create logins automatically in bulk from
course-registration data, we've had to write some of our
own tools.  PAM and the ssh GSSAPI support suffice for
logging in, but not for password changes or account
creation and removal.

Someday we will have time to look at LDAP.  Meanwhile we
distribute /etc/passwd and /etc/shadow files (the latter
mostly blanked out to most systems) via our configuration-
management system, which we need to have to manage many
other files anyway.

Norman Wilson
Toronto ON


From gtaylor at tnetconsulting.net  Wed Nov  7 10:35:04 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 6 Nov 2018 17:35:04 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
Message-ID: <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>

On 11/06/2018 03:24 PM, Dan Cross wrote:
> Isn't that authorization?

Not really.

Authentication is proving that you are who you claim to be.  -  Show 
your drivers license to the bouncer.

Authorization is deciding if the authenticated entity is allowed to have 
access or not.  -  Is your name on the list of people allowed into the 
nightclub?

Access Control - The bouncer, allowing you in or physically barring you 
from entering.

Each is a discrete function.  They all work in close concert with each 
other.

> Not really. It provides the data that lets one perform a relatively weak 
> validation of e.g. a password, but it is not *itself* an authentication 
> protocol.

Fair enough.

> Older versions of Kerberos often included modified versions of popular 
> servers and their clients that had been modified to use the kerberos 
> protocol for authentication, and also often to encrypt communications.

I take it that you mean that the Kerberos software that was distributed 
also included an alternate telnet / rsh / etc daemon that took advantage 
of Kerberos.

> For example, the version of `telnet` that shipped with MIT kerberos back 
> in the day had an option that could be used to encrypt the data stream; 
> similarly with rlogin, et al.

*nod*

> I have a dim memory that the version of FTP might support encryption 
> for the control connection but not data connections (but I also might be 
> purely imagining that).

Maybe.  There has been a LOT of energy put into FTP.

> I'm guessing most of this stuff has been dropped from more recent 
> distributions

Likely.

> because...really...telnet?

~chuckle~

I supported multiple old Solaris 6 machines about 5 years ago that I 
still had to use telnet to connect to.

I feel like telnet as a service REALLY does need to go away.  That being 
said, I still find the telnet (or any NVT) client a valuable diagnostic 
tool.

> What I meant is that SSH supports a limited sense of checking whether 
> a given key matches and making a yea or nay decision based on that.

I'm not sure I understand what you're alluding to.  But that's getting 
off topic.  So I digress.

> Correct. `ypcat passwd` often gave you a bunch of hashed passwords in 
> field two of a stream 7th Edition /etc/passwd formatted entries.

I would have hoped that there would have been some intelligence to only 
return the record of the person requesting the information.  Or that the 
password field was redacted for other users.

I guess the ypcat binary could be augmented to do that filtering client 
side.  But that still leaves the underlying problem there for alternate 
NIS clients.

> I have, again, some vague memory that at some point this was changed so 
> that root on the localhost could get a shadow-style map, but normal users 
> couldn't see the password hashes. But I might totally be making that up, 
> and of course, it wasn't robust security since what went over the wire 
> wasn't encrypted and breaking root on a host could still get you all 
> the hashes on the network.

It's still subject to alternate ypcat impersonation binaries too.

> Contrast with Kerberos, where breaking root on a host doesn't compromise 
> much beyond that host (modulo leveraging that to steal user passwords 
> and the like).

ACK

> Ha! That's a hoot.

;-)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/54a12263/attachment.bin>

From gtaylor at tnetconsulting.net  Wed Nov  7 10:40:41 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Tue, 6 Nov 2018 17:40:41 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAEoi9W6fQw05GvrfWkkT0ABLG=JLvkUJ_hg=sj+TbENsav9enQ@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
 <CAEoi9W6d5KCExxGHdOoCyae154r4u_NvMYj40w0OCNXF7kRQxw@mail.gmail.com>
 <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net>
 <CAEoi9W6fQw05GvrfWkkT0ABLG=JLvkUJ_hg=sj+TbENsav9enQ@mail.gmail.com>
Message-ID: <15182b20-017f-1744-6dfd-e83359b157a7@spamtrap.tnetconsulting.net>

On 11/06/2018 03:29 PM, Dan Cross wrote:
> It wouldn't do it, but I guess it depends on how much you trust your 
> environment and your users etc.

That's not quite what I had expected, but it is an answer to the 
question that I asked.

> If you're intent on using a network directory service, I'd bite the 
> bullet and invest in setting up Kerberos and LDAP. The thing with pairing 
> Kerberos (for authentication) with NIS is that while you'll have decent 
> authentication security, nothing prevents a malicious third party from 
> modifying the answer from `ypserv` for some user to set the UID to 0, 
> thus making that user root.

ACK

> If authentication is happening by users typing passwords into SSH clients, 
> which then get sent to SSH servers to be validated against the KDC on 
> machines that have been so cracked, an attacker can steal passwords by 
> subverting the SSH server processes.

What would the user be typing their password into?  The SSH client to 
authenticate to the SSH daemon?  Or kinit (et al) on the remote system?

I would have thought that the ideal situation would be for the user to 
kinit on their client, then authenticate to ssh using Kerberos.

I'm guessing they would need to do something to extend their Kerberos 
tickets therefrom.  I don't know if they would need to kinit on the 
remote system, or if there's something like agent forwarding for Kerberos.

> However, if you trust your users not to do that and you're on a 
> relatively small, self-contained and decently secured network, then it 
> may be fine.

ACK

> From what you described earlier I think generating text files and 
> distributing them around (possibly with rdist or rsync) and pairing that 
> with kerberos would be less work and more robust.

Possibly.

Though I don't consider that to be a central directory server.  Instead 
I consider it to be replicating information locally.  I'm sure it has 
it's pros and cons.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181106/64fa7fea/attachment.bin>

From pete at dunnington.plus.com  Wed Nov  7 11:03:08 2018
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Wed, 7 Nov 2018 01:03:08 +0000
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
Message-ID: <1a28d6a4-7f9a-4e91-db5e-fa14bc06b48d@dunnington.plus.com>

On 06/11/2018 05:24, Grant Taylor via TUHS wrote:
> On 11/05/2018 03:34 PM, Dan Cross wrote:

>> Security, in general, usually seeks to address five questions:
>>
>> 1. Authentication - Is some entity who it claims to be?
>> 2. Authorization - Is some entity allowed to perform some action?
>> 3. Privacy - Can a third party snoop on a private conversation between 
>> two entities?
>> 4. Integrity - Can a third party alter communications between two 
>> entities in an undetectable way?
>> 5. Non-repudiation - Can it be definitively shown that some entity was 
>> a party to some communication?
> 
> The 3rd A that I'm used to is "Access Control".  Is the requested action 
> allowed given the above information.

Access Control = Authorisation.
Everywhere I've been, AAA = Authentication, Authorisation, Accounting.

-- 
Pete
Pete Turnbull


From krewat at kilonet.net  Wed Nov  7 11:38:53 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 6 Nov 2018 20:38:53 -0500
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <CAEoi9W6fQw05GvrfWkkT0ABLG=JLvkUJ_hg=sj+TbENsav9enQ@mail.gmail.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <CAFCBnZsmLWuCaJo2w4ekR42yaS9XszR1h-H82t49agin-ORgBg@mail.gmail.com>
 <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net>
 <CAEoi9W6d5KCExxGHdOoCyae154r4u_NvMYj40w0OCNXF7kRQxw@mail.gmail.com>
 <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net>
 <CAEoi9W6fQw05GvrfWkkT0ABLG=JLvkUJ_hg=sj+TbENsav9enQ@mail.gmail.com>
Message-ID: <601667f4-46a7-dfdf-a1ee-5f7bd4720b8d@kilonet.net>

On 11/6/2018 5:29 PM, Dan Cross wrote:
> If authentication is happening by users typing passwords into SSH 
> clients, which then get sent to SSH servers to be validated against 
> the KDC on machines that have been so cracked, an attacker can steal 
> passwords by subverting the SSH server processes.

One of the most fun things I've done in the past few years was to take 
OpenSSH and make it dump the attempted password while hackers are trying 
to brute-force my inbound SSH.

They've stopped for some reason. Now they just try TELNET over and over 
again. Mostly from exploited cameras.

art k.



From arnold at skeeve.com  Wed Nov  7 18:58:57 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 07 Nov 2018 01:58:57 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <20181105190424.GE19335@mcvoy.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com>
 <201811051838.wA5Icosk029361@freefriends.org>
 <20181105190424.GE19335@mcvoy.com>
Message-ID: <201811070858.wA78wvfU016909@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> The caches worked across reboots.  I left not long after we completed 1.0,
> Bob Mende (RIP) and some other folks took the mmap based dbm (I called
> mdbm) and put locks in each page so you could have multiple writers.
> That code made its way to yahoo and just got used for everything, they
> made it C++ (not a fan of that but whatever) and evolved it farther than
> I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
> They open sourced their stuff.

Any idea where to find this now?

Thanks,

Arnold


From arnold at skeeve.com  Wed Nov  7 19:05:58 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 07 Nov 2018 02:05:58 -0700
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
Message-ID: <201811070905.wA795wxP017303@freefriends.org>

Dan Cross <crossd at gmail.com> wrote:

> What was the introduction of DNS into the mix like? I can imagine that that
> changed all sorts of assumptions about failure modes and the like.

I'm not sure what you're asking.  When DNS came along, it became
a matter of editing /etc/nsswitch.conf to include dns as one of the
options along with files and yp/nis.  I think the average user didn't
see any big difference since all the apps (ftp, telnet) just went
through gethostbyname().

DNS configuration files were a trip, especially for someone used to the
very simple Unix configuration files like /etc/passwd and /etc/hosts.
Circa 1985/1986 I was responsible for bringing up DNS at the Emory U
campus.  Once in place, things pretty much just worked. Or at least,
from this distant vantage point, that's what I seem to remember.

Arnold


From pete at dunnington.plus.com  Wed Nov  7 21:37:32 2018
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Wed, 7 Nov 2018 11:37:32 +0000
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
 <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>
Message-ID: <ec991a24-fe7c-232c-df00-162699ba615a@dunnington.plus.com>

On 07/11/2018 00:35, Grant Taylor via TUHS wrote:
> On 11/06/2018 03:24 PM, Dan Cross wrote:
>> Isn't that authorization?
> 
> Not really.
> 
> Authentication is proving that you are who you claim to be.  -  Show 
> your drivers license to the bouncer.
> 
> Authorization is deciding if the authenticated entity is allowed to have 
> access or not.  -  Is your name on the list of people allowed into the 
> nightclub?
> 
> Access Control - The bouncer, allowing you in or physically barring you 
> from entering.

Not really.  You go past the bouncer as an immediate consequence of 
authorization.  The third 'A' is normally accounting: the bouncer notes 
the time you entered in the visitors book or logbook, and sometimes also 
notes the time you leave.  Just about every network access service does 
this, and "access control" is the whole AAA thing combined.

Have you ever seen a system that confirmed authentication and 
authorisation but then denied access (other than through a fault)? 
Denying access would be by a (possibly temporary) denial of authorisation.

-- 
Pete
Pete Turnbull


From ron at ronnatalie.com  Wed Nov  7 22:18:18 2018
From: ron at ronnatalie.com (ron at ronnatalie.com)
Date: Wed, 7 Nov 2018 07:18:18 -0500
Subject: [TUHS] /crp
In-Reply-To: <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
 <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
Message-ID: <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com>

:
> 
> > An early UNIX paper shows the system had four RK05's (4872 512-byte
> > blocks on UNIX, for some reason only 4800 used on the DEC OSs ...
> > remember we had to poke ROLLIN to copy the full UNIX partition
> > standalone).
> 
> Bad blocks?  I think I have an article in AUUGN where I proposed that bad
> blocks be assigned (somehow) to a pseudo-file as inode #0 (or -1?); that
way,
> the "dump" utility would not see it, and neither would the FS tools (but a
disk
> image would, of course).

No, not to my knowledge.   The DEC drivers just left off the last 72
sectors.   There was no provision using them for block replacement.
The utilities just stopped at 4800.




From arnold at skeeve.com  Thu Nov  8 00:05:45 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 07 Nov 2018 07:05:45 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <201811070858.wA78wvfU016909@freefriends.org>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com>
 <201811051838.wA5Icosk029361@freefriends.org>
 <20181105190424.GE19335@mcvoy.com>
 <201811070858.wA78wvfU016909@freefriends.org>
Message-ID: <201811071405.wA7E5j56030566@freefriends.org>

arnold at skeeve.com wrote:

> Larry McVoy <lm at mcvoy.com> wrote:
>
> > The caches worked across reboots.  I left not long after we completed 1.0,
> > Bob Mende (RIP) and some other folks took the mmap based dbm (I called
> > mdbm) and put locks in each page so you could have multiple writers.
> > That code made its way to yahoo and just got used for everything, they
> > made it C++ (not a fan of that but whatever) and evolved it farther than
> > I ever imagined.  They had DBs that were 100's of gigs ~20 years ago.
> > They open sourced their stuff.
>
> Any idea where to find this now?
>
> Thanks,
>
> Arnold

And, I *still* haven't learned to ask Google first.  A quick search
finds these:

https://github.com/yahoo/mdbm
https://yahooeng.tumblr.com/post/104861108931/mdbm-high-speed-database

Enjoy,

Arnold


From clemc at ccc.com  Thu Nov  8 01:02:54 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Nov 2018 10:02:54 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
Message-ID: <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>

On Mon, Nov 5, 2018 at 7:35 PM Dan Cross <crossd at gmail.com> wrote:

> Spurred by the recent discussion of NIS, NIS+, LDAP et al, I'm curious
> what the landscape was like for distributing administrative information in
> early Unix networks.
>
> Specifically I'm thinking about things like the Newcastle Connection, etc.
>
> I imagine that PDP-11's connected to the ARPAnet running Unix would (e.g.,
> RFC 681 style) would have adapted the HOSTS.TXT format somehow. What about
> CHAOS? Newcastle? Datakit?
>
> What was the introduction of DNS into the mix like? I can imagine that
> that changed all sorts of assumptions about failure modes and the like.
>
> NIS and playing around with Hesiod are probably the earliest such things I
> ever saw, but I know there must have been prior art.
>
> Supposedly field 5 from /etc/passwd is the GECOS username for remote job
> entry (or printing)? How did that work?
>

Dan - all good questions, but I think you are mixing a few things (which is
easy to do as they all had different evolutionary paths).


   - ARPAnet was Rand, UCLA and UofI in the early to mid 70s.
   - UCLA line would fork competely with the original Locus work of the mid
   70's, which would reappear later in the 80's post BSD
   - IP Networking was done by BBN for 4.1BSD in the late 70s - originally
   as an OS independant stack (hence it has its own memory manager to
   insulated it from the local S).  Besides UNIX I think it went into HP's MPE
   and maybe a couple f other systems.
   - The BBN IP stack was then repliced into UNIX by UCB/CRSG as 4.1A with
   Joy's sockets layer in 82/83
   - HOST.TXT was finaly abandoned and BIND was then done (primarily at UCB
   by peed on by many) - I want to say eary 80's  the SCCS files might give
   you some hints.
   - Hesiod was MIT/Athenia and NIS by Sun were  later developed somewhat
   in the same time frame   (mid to late 80s)
   - CHAOS was completely seperate, although influenced the BBN code and
   was the early/mid 70s.
   - BTL's DataKit of course, had the UoI (Chesson) influence was late 70s.
   - Best I can tell Newcastle was complete seperate from all of this (also
   late 70s).


Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/b0f4b4f2/attachment.html>

From clemc at ccc.com  Thu Nov  8 01:05:47 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Nov 2018 10:05:47 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
Message-ID: <CAC20D2P2U7MkkQrK0jgygzGAi5NDKbKcnXCZZxoiXGihALrSaQ@mail.gmail.com>

And I left out the whole X.500 DAP which begat ??UMich's I think? LDAP -
which was mid to late 1980s.
ᐧ

On Wed, Nov 7, 2018 at 10:02 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Nov 5, 2018 at 7:35 PM Dan Cross <crossd at gmail.com> wrote:
>
>> Spurred by the recent discussion of NIS, NIS+, LDAP et al, I'm curious
>> what the landscape was like for distributing administrative information in
>> early Unix networks.
>>
>> Specifically I'm thinking about things like the Newcastle Connection, etc.
>>
>> I imagine that PDP-11's connected to the ARPAnet running Unix would
>> (e.g., RFC 681 style) would have adapted the HOSTS.TXT format somehow. What
>> about CHAOS? Newcastle? Datakit?
>>
>> What was the introduction of DNS into the mix like? I can imagine that
>> that changed all sorts of assumptions about failure modes and the like.
>>
>> NIS and playing around with Hesiod are probably the earliest such things
>> I ever saw, but I know there must have been prior art.
>>
>> Supposedly field 5 from /etc/passwd is the GECOS username for remote job
>> entry (or printing)? How did that work?
>>
>
> Dan - all good questions, but I think you are mixing a few things (which
> is easy to do as they all had different evolutionary paths).
>
>
>    - ARPAnet was Rand, UCLA and UofI in the early to mid 70s.
>    - UCLA line would fork competely with the original Locus work of the
>    mid 70's, which would reappear later in the 80's post BSD
>    - IP Networking was done by BBN for 4.1BSD in the late 70s -
>    originally as an OS independant stack (hence it has its own memory manager
>    to insulated it from the local S).  Besides UNIX I think it went into HP's
>    MPE and maybe a couple f other systems.
>    - The BBN IP stack was then repliced into UNIX by UCB/CRSG as 4.1A
>    with Joy's sockets layer in 82/83
>    - HOST.TXT was finaly abandoned and BIND was then done (primarily at
>    UCB by peed on by many) - I want to say eary 80's  the SCCS files might
>    give you some hints.
>    - Hesiod was MIT/Athenia and NIS by Sun were  later developed somewhat
>    in the same time frame   (mid to late 80s)
>    - CHAOS was completely seperate, although influenced the BBN code and
>    was the early/mid 70s.
>    - BTL's DataKit of course, had the UoI (Chesson) influence was late
>    70s.
>    - Best I can tell Newcastle was complete seperate from all of this
>    (also late 70s).
>
>
> Clem
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/3390d227/attachment.html>

From clemc at ccc.com  Thu Nov  8 01:08:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Nov 2018 10:08:00 -0500
Subject: [TUHS] /crp
In-Reply-To: <1541547109.9957.for-standards-violators@oclsc.org>
References: <1541547109.9957.for-standards-violators@oclsc.org>
Message-ID: <CAC20D2N3ofDKNAES6Wj2TLxGNa8zHnMoLqrshxcAoQHhOGgPnw@mail.gmail.com>

On Tue, Nov 6, 2018 at 8:33 PM Norman Wilson <norman at oclsc.org> wrote:

>
> oddly, the conventional pronunciation seemed to be creep.
>
>
It's possible that was because the Apollo Domain system had an ssh-like
program called crp, that was prounced 'creep' which was pretty widely used
in those days.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/324f3891/attachment.html>

From clemc at ccc.com  Thu Nov  8 01:14:20 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Nov 2018 10:14:20 -0500
Subject: [TUHS] /crp
In-Reply-To: <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
 <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
 <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com>
Message-ID: <CAC20D2PkKf06Loh3_B_ze+qYt82qmYwfEWL7KOjxd98442QNkw@mail.gmail.com>

On Wed, Nov 7, 2018 at 9:09 AM <ron at ronnatalie.com> wrote:

> The DEC drivers just left off the last 72 sectors.   There was no
> provision using them for block replacement.
>
Minor update -- *no dynamic replacement provision*.  There was a standard
alone utility called BAD144 that implemented DEC Standard 144 (Bad
Blocks).   What would happen is that the format was messed with the point a
bad block at on the reserved sectors.

This scheme caused nasty performance issues because seek schedualing was
defeated; and since UNIX did not originally obey DEC STD144, the standard
UNIX scheme in those days was buy 'perfect' media.  BTW: the Ultrix team -
Fred Canter IIRC -- added support for BAD144, and I think DEC gave that
code to BSD evetually.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/d5a37475/attachment.html>

From rminnich at gmail.com  Thu Nov  8 01:52:47 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 7 Nov 2018 07:52:47 -0800
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <201811070905.wA795wxP017303@freefriends.org>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
Message-ID: <CAP6exYLGJKHLt99g2n4D-Bfan3rR2cTWfpJvju3-wK6MznOqBw@mail.gmail.com>

On Wed, Nov 7, 2018 at 3:38 AM <arnold at skeeve.com> wrote:

> I'm not sure what you're asking.  When DNS came along, it became
> a matter of editing /etc/nsswitch.conf to include dns as one of the
> options along with files and yp/nis.

This does not align with my memory at all. I was at udel until 1988
and we started dealing with dns ca. 1986, and the shared library stuff
I dealt with in sunos came later.

Was there really an nsswitch.conf before 1988 that used shared
libraries? When did you first see nsswitch.conf? I first saw the
shared libraries  with sunos 4.0 when I moved to super.org in 1988. I
always thought it started with them on Unix anyway.

In any event, dns was in some ways a big improvement in life. We were
ftp'ing the 256KiB host file from prep frequently (along with many)
and the load on prep, evidently, was getting high.

And a linear search of a 256KiB hosts file for every single
gethostbyname was getting ... noticeable. I assume this is part of why
stayopen was an option in the library.

People got upset about some things with DNS: "it's called prep, not
prep.ai.mit.edu, what is this nonsense?"

But we adjusted.


From paul.winalski at gmail.com  Thu Nov  8 02:43:04 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 7 Nov 2018 11:43:04 -0500
Subject: [TUHS] /crp
In-Reply-To: <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
 <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
Message-ID: <CABH=_VRAL+_fxKerFOV744LJzD8txRT-oXNkrRsOEzCFcFxcWA@mail.gmail.com>

On 11/6/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> Bad blocks?  I think I have an article in AUUGN where I proposed that bad
> blocks be assigned (somehow) to a pseudo-file as inode #0 (or -1?); that
> way, the "dump" utility would not see it, and neither would the FS tools
> (but a disk image would, of course).

That is how VMS handles bad blocks.  When the system detects them,
they are allocated to file BADBLK.SYS;1 in the volume's root
directory.  Of course, these days the disk hardware controller handles
bad blocks.  The VMS engineering group once got a bug report
complaining that when a privileged user issued the command "type
dba0:[000000]badblk.sys" there were scads and scads of bad block error
messages.

"Doctor, it hurts when I do this...."

-Paul W.


From nobozo at gmail.com  Thu Nov  8 03:02:11 2018
From: nobozo at gmail.com (Jon Forrest)
Date: Wed, 7 Nov 2018 09:02:11 -0800
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
Message-ID: <24017adc-f2b5-10be-2445-19c43480bb30@gmail.com>



On 11/7/2018 7:02 AM, Clem Cole wrote:

>   * ARPAnet was Rand, UCLA and UofI in the early to mid 70s.

For what it's worth, the first 4 nodes on the Arpanet were
UCLA, SRI, UCSB (my alma mater), and U of Utah.

I arrived at UCSB in 1973 and its presence on the ARPAnet wasn't
something that most people there knew about. I certainly didn't.

Jon



From crossd at gmail.com  Thu Nov  8 03:15:32 2018
From: crossd at gmail.com (Dan Cross)
Date: Wed, 7 Nov 2018 12:15:32 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <201811070905.wA795wxP017303@freefriends.org>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
Message-ID: <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>

On Wed, Nov 7, 2018 at 4:05 AM <arnold at skeeve.com> wrote:

> Dan Cross <crossd at gmail.com> wrote:
> > What was the introduction of DNS into the mix like? I can imagine that
> that
> > changed all sorts of assumptions about failure modes and the like.
>
> I'm not sure what you're asking.


Sorry, this was indeed vague.

Ron alluded to what I was asking about; namely, what were the circumstances
that gave rise to the creation of DNS in the first place? I imagine an
unwieldy HOSTS.TXT file being FTP'd daily combined with a linear scan (or
an expensive step to create a DBM file or something) had a lot to do with
it.

When DNS came along, it became
> a matter of editing /etc/nsswitch.conf to include dns as one of the
> options along with files and yp/nis.  I think the average user didn't
> see any big difference since all the apps (ftp, telnet) just went
> through gethostbyname().
>

This doesn't mesh with my memory. I recall building BIND from source and
having to rebuild network programs (e.g. on 4.3 on the RT or VAXen) to pick
up the new version of libresolv.a, and hacking the resolver library into
libc.so on Suns. I remember using resolv.conf fairly early on, but my
memory is that nsswitch.conf came later (Solaris 2.x era?). Ultrix did have
a configuration file for where to do host lookups, but I think the set of
sources was fixed: files, NIS or DNS. This would have been in the Ultrix
4.4 or 4.5 era on MIPS. I remember seeing some description of a
configuration file accompanied by an editorialized comment saying something
like, "this is an idea that's time has come: Ultrix has had it for several
years." The dig on uglix was, well, kind of funny (I had a DECstation at
home at the time).

DNS configuration files were a trip, especially for someone used to the
> very simple Unix configuration files like /etc/passwd and /etc/hosts.
> Circa 1985/1986 I was responsible for bringing up DNS at the Emory U
> campus.  Once in place, things pretty much just worked. Or at least,
> from this distant vantage point, that's what I seem to remember.
>

Ha! Yeah, tell me about it. We used to format our SOA records so that the
'(' was on a line by itself, indented to 'SOA'. At some point, a minor
point revision to BIND changed the parsing behavior so that this was a
syntax error; there was no warning that this would be the case. I
complained on a BIND mailing list and was told, "this is in the RFC." It
wasn't clear to me where, in the documentation, it was specified that the
file format understood by BIND was the RFC-standard format.

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

From gtaylor at tnetconsulting.net  Thu Nov  8 03:30:58 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Wed, 7 Nov 2018 10:30:58 -0700
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <ec991a24-fe7c-232c-df00-162699ba615a@dunnington.plus.com>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
 <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>
 <ec991a24-fe7c-232c-df00-162699ba615a@dunnington.plus.com>
Message-ID: <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net>

On 11/07/2018 04:37 AM, Pete Turnbull wrote:
> Not really.  You go past the bouncer as an immediate consequence of 
> authorization.

I disagree.

To me these are two very distinct things.

I view authorization as a low pressure yes / no answer to should this 
access be allowed or not.

The access control (bouncer) is the high pressure and high risk exposed 
surface that people beat on to try to force their way in.

Much like how a low base current can control a high collector current on 
a transistor.

> The third 'A' is normally accounting: the bouncer notes the time you 
> entered in the visitors book or logbook, and sometimes also notes the 
> time you leave.  Just about every network access service does this, and 
> "access control" is the whole AAA thing combined.

I'll agree that accounting, or logging, is desired.  But many of the 
bouncers that I've seen don't do any logging (accounting) at all.  They 
simply enforce the decisions of other people (entities).

s/bouncer/security guard/ and I'll agree that logging (accounting) is 
typically done.

Does a turn stile do any logging?  Or does it simply allow somebody 
through if they provide the token?

> Have you ever seen a system that confirmed authentication and 
> authorisation but then denied access (other than through a fault)?

My ignorance does not preclude such from existing.

Think about someone approaching a checkpoint:

1)  They must authenticate themselves.
2)  They must be authorized to pass.
3)  The retractable tank traps (meant to be robust enough to stop a 
speeding car) must be retracted.

#3 is the access control that is independent of #1 & #2 as well as takes 
time to move.

I view the access control as the physical (or logical) barrier that 
allows or prevents things based on input of others.

> Denying access would be by a (possibly temporary) denial of authorisation.

I disagree.  You are still authorized.  You are still permitted to do 
$theThing.

Reusing the a tank trap comparison, does the drivers authentication or 
authorization status change between the time the guard says "Okay" and 
the time the driver leaves the check point?  The access control takes 
time to execute, namely the time it takes the guard to initiate 
retracting the tank trap and the time it takes for the tank trap to 
retract.  This entire time the driver is still authenticated and still 
authorized.  But access is still being prevented.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/2dee70e0/attachment.bin>

From krewat at kilonet.net  Thu Nov  8 04:27:51 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 7 Nov 2018 13:27:51 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAP6exYLGJKHLt99g2n4D-Bfan3rR2cTWfpJvju3-wK6MznOqBw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAP6exYLGJKHLt99g2n4D-Bfan3rR2cTWfpJvju3-wK6MznOqBw@mail.gmail.com>
Message-ID: <32e54039-2523-5641-fac2-3062ac717130@kilonet.net>

On 11/7/2018 10:52 AM, ron minnich wrote:
> On Wed, Nov 7, 2018 at 3:38 AM<arnold at skeeve.com>  wrote:
>
>> I'm not sure what you're asking.  When DNS came along, it became
>> a matter of editing /etc/nsswitch.conf to include dns as one of the
>> options along with files and yp/nis.
> This does not align with my memory at all. I was at udel until 1988
> and we started dealing with dns ca. 1986, and the shared library stuff
> I dealt with in sunos came later.
I first saw nsswitch.conf on Solaris. And lo-and-behold:

"Sun Microsystems <https://en.wikipedia.org/wiki/Sun_Microsystems> first 
developed NSS for their Solaris 
<https://en.wikipedia.org/wiki/Solaris_%28operating_system%29> operating 
system, but subsequently programmers ported it to many other operating 
systems including FreeBSD <https://en.wikipedia.org/wiki/FreeBSD>, 
NetBSD <https://en.wikipedia.org/wiki/NetBSD>, Linux 
<https://en.wikipedia.org/wiki/Linux>, HP-UX 
<https://en.wikipedia.org/wiki/HP-UX>, IRIX 
<https://en.wikipedia.org/wiki/IRIX> and AIX 
<https://en.wikipedia.org/wiki/AIX_operating_system>."

https://en.wikipedia.org/wiki/Name_Service_Switch

How true that is, I'd love to know.

art k.

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

From aaron at aaronsplace.co.uk  Thu Nov  8 05:08:50 2018
From: aaron at aaronsplace.co.uk (Aaron Jackson)
Date: Wed, 07 Nov 2018 19:08:50 +0000
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
Message-ID: <87h8gsu2m5.fsf@walrus.rhwyd.co.uk>

> Dan - all good questions, but I think you are mixing a few things (which is
> easy to do as they all had different evolutionary paths).
>
>
>    - ARPAnet was Rand, UCLA and UofI in the early to mid 70s.
>    - UCLA line would fork competely with the original Locus work of the mid
>    70's, which would reappear later in the 80's post BSD
>    - IP Networking was done by BBN for 4.1BSD in the late 70s - originally
>    as an OS independant stack (hence it has its own memory manager to
>    insulated it from the local S).  Besides UNIX I think it went into HP's MPE
>    and maybe a couple f other systems.
>    - The BBN IP stack was then repliced into UNIX by UCB/CRSG as 4.1A with
>    Joy's sockets layer in 82/83
>    - HOST.TXT was finaly abandoned and BIND was then done (primarily at UCB
>    by peed on by many) - I want to say eary 80's  the SCCS files might give
>    you some hints.
>    - Hesiod was MIT/Athenia and NIS by Sun were  later developed somewhat
>    in the same time frame   (mid to late 80s)
>    - CHAOS was completely seperate, although influenced the BBN code and
>    was the early/mid 70s.
>    - BTL's DataKit of course, had the UoI (Chesson) influence was late 70s.
>    - Best I can tell Newcastle was complete seperate from all of this (also
>    late 70s).
>
>
> Clem
> ᐧ

Perhaps also worthy of a mention is Network Registration Service (NRS)
used in the UK academic network (JANET). Similar idea to
HOSTS.TXT. Periodic download and munge.

More interestingly though, NRS used the opposite ordering to DNS, so
"cs.nott.ac.uk" was "uk.ac.nott.cs", which became a problem when
Czechoslovakia got their TLD (.cs) in the 80s as the both DNS and NRS
were used in parallel for some period of time.

I believe NRS was still being used to some capacity by the time
Czechoslovakia split in 93.

Aaron

--
Aaron Jackson - M6PIU
http://aaronsplace.co.uk/


From jim.epost at gmail.com  Thu Nov  8 05:48:01 2018
From: jim.epost at gmail.com (Jim Davis)
Date: Wed, 7 Nov 2018 12:48:01 -0700
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
Message-ID: <CA+r1Zhg0m+4=2i_rfA75+RwWSG01T=j333vOgFzf_8qx4ekjSg@mail.gmail.com>

On Wed, Nov 7, 2018 at 9:43 AM Clem Cole <clemc at ccc.com> wrote:

> ARPAnet was Rand, UCLA and UofI in the early to mid 70s.

And my alma mater, the University of Utah
(https://www.lib.utah.edu/digital-scholarship/arpanet/index.php)

-- 
Jim


From clemc at ccc.com  Thu Nov  8 05:51:00 2018
From: clemc at ccc.com (Clem Cole)
Date: Wed, 7 Nov 2018 14:51:00 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CA+r1Zhg0m+4=2i_rfA75+RwWSG01T=j333vOgFzf_8qx4ekjSg@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <CAC20D2NnhJ66r4YPfnaVm3hz1+Tgmrs97nA7Y6NcG_evctfQnw@mail.gmail.com>
 <CA+r1Zhg0m+4=2i_rfA75+RwWSG01T=j333vOgFzf_8qx4ekjSg@mail.gmail.com>
Message-ID: <CAC20D2P_6yKS88aQcurRrZMrsswRPB5P3rA8TCWgRAUFxaz86w@mail.gmail.com>

Sorry - if this was not clear -- the  original UNIX work for the ArpaNet
was UCL, Rand and UoI
ᐧ

On Wed, Nov 7, 2018 at 2:48 PM Jim Davis <jim.epost at gmail.com> wrote:

> On Wed, Nov 7, 2018 at 9:43 AM Clem Cole <clemc at ccc.com> wrote:
>
> > ARPAnet was Rand, UCLA and UofI in the early to mid 70s.
>
> And my alma mater, the University of Utah
> (https://www.lib.utah.edu/digital-scholarship/arpanet/index.php)
>
> --
> Jim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/e2d9147d/attachment.html>

From lm at mcvoy.com  Thu Nov  8 06:15:20 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 7 Nov 2018 12:15:20 -0800
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
Message-ID: <20181107201520.GA14737@mcvoy.com>

On Wed, Nov 07, 2018 at 12:15:32PM -0500, Dan Cross wrote:
> On Wed, Nov 7, 2018 at 4:05 AM <arnold at skeeve.com> wrote:
> When DNS came along, it became
> > a matter of editing /etc/nsswitch.conf to include dns as one of the
> > options along with files and yp/nis.  I think the average user didn't
> > see any big difference since all the apps (ftp, telnet) just went
> > through gethostbyname().
> 
> This doesn't mesh with my memory. I recall building BIND from source and
> having to rebuild network programs (e.g. on 4.3 on the RT or VAXen) to pick
> up the new version of libresolv.a, and hacking the resolver library into
> libc.so on Suns. I remember using resolv.conf fairly early on, but my
> memory is that nsswitch.conf came later (Solaris 2.x era?). 

Yeah, this is right, I remember doing this as well and I worked at Sun
at that point.  It was a pain.  


From henry.r.bent at gmail.com  Thu Nov  8 06:15:24 2018
From: henry.r.bent at gmail.com (Henry Bent)
Date: Wed, 7 Nov 2018 15:15:24 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
Message-ID: <CAEdTPBeK0A3fh3yTMZ8DY1Dm0ajrXeU28E_RReVai+ihJtLBMg@mail.gmail.com>

On Wed, 7 Nov 2018 at 14:57, Dan Cross <crossd at gmail.com> wrote:

>
> This doesn't mesh with my memory. I recall building BIND from source and
> having to rebuild network programs (e.g. on 4.3 on the RT or VAXen) to pick
> up the new version of libresolv.a, and hacking the resolver library into
> libc.so on Suns. I remember using resolv.conf fairly early on, but my
> memory is that nsswitch.conf came later (Solaris 2.x era?). Ultrix did have
> a configuration file for where to do host lookups, but I think the set of
> sources was fixed: files, NIS or DNS. This would have been in the Ultrix
> 4.4 or 4.5 era on MIPS. I remember seeing some description of a
> configuration file accompanied by an editorialized comment saying something
> like, "this is an idea that's time has come: Ultrix has had it for several
> years." The dig on uglix was, well, kind of funny (I had a DECstation at
> home at the time).
>

Ultrix 4.0 (1990) had /etc/svc.conf for controlling distributed service
lookups, and you are correct that the only options were local, yp, and
bind.  Ultrix 3 (1988) had /etc/svcorder which was much more limited, only
allowing for setting the order of host lookups, but it did have support for
resolv.conf and BIND lookups (which still works!).

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

From grawity at gmail.com  Thu Nov  8 07:11:28 2018
From: grawity at gmail.com (=?UTF-8?Q?Mantas_Mikul=C4=97nas?=)
Date: Wed, 7 Nov 2018 23:11:28 +0200
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
Message-ID: <CAPWNY8WOCzNuOcuBZOr7fY3gGRNqzLTGQ-65ULTPRXug=aRCoA@mail.gmail.com>

On Wed, Nov 7, 2018 at 9:57 PM Dan Cross <crossd at gmail.com> wrote:

> On Wed, Nov 7, 2018 at 4:05 AM <arnold at skeeve.com> wrote:
>
>> When DNS came along, it became
>> a matter of editing /etc/nsswitch.conf to include dns as one of the
>> options along with files and yp/nis.  I think the average user didn't
>> see any big difference since all the apps (ftp, telnet) just went
>> through gethostbyname().
>>
>
> This doesn't mesh with my memory. I recall building BIND from source and
> having to rebuild network programs (e.g. on 4.3 on the RT or VAXen) to pick
> up the new version of libresolv.a, and hacking the resolver library into
> libc.so on Suns. I remember using resolv.conf fairly early on, but my
> memory is that nsswitch.conf came later (Solaris 2.x era?). Ultrix did have
> a configuration file for where to do host lookups, but I think the set of
> sources was fixed: files, NIS or DNS.
>

I always assumed that nsswitch came much later than DNS, based just on the
fact that Linux glibc on older systems still ships an /etc/host.conf
"resolver configuration file" that has such parameters as "order
hosts,bind,nis" (although they're inoperative).

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/eb5bf033/attachment.html>

From pechter at gmail.com  Thu Nov  8 07:28:26 2018
From: pechter at gmail.com (William Pechter)
Date: Wed, 7 Nov 2018 16:28:26 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <32e54039-2523-5641-fac2-3062ac717130@kilonet.net>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAP6exYLGJKHLt99g2n4D-Bfan3rR2cTWfpJvju3-wK6MznOqBw@mail.gmail.com>
 <32e54039-2523-5641-fac2-3062ac717130@kilonet.net>
Message-ID: <1c69da8e-3286-46ce-91fc-7da658ee8c14.maildroid@localhost>

I remember that early linux used /etc/host.conf -- or hosts.conf for DNS vs hosts file or to.

Hacking the SunOS4.1.3 library with the resolv21 fixes to add DNS w/o NIS was fun too.  Both about 1991 for me iirc.

Bill

Sent from MailDroid

-----Original Message-----
From: Arthur Krewat <krewat at kilonet.net>
To: tuhs at minnie.tuhs.org
Sent: Wed, 07 Nov 2018 16:22
Subject: Re: [TUHS] Directory services in early Unix networks?

On 11/7/2018 10:52 AM, ron minnich wrote:
> On Wed, Nov 7, 2018 at 3:38 AM<arnold at skeeve.com>  wrote:
>
>> I'm not sure what you're asking.  When DNS came along, it became
>> a matter of editing /etc/nsswitch.conf to include dns as one of the
>> options along with files and yp/nis.
> This does not align with my memory at all. I was at udel until 1988
> and we started dealing with dns ca. 1986, and the shared library stuff
> I dealt with in sunos came later.
I first saw nsswitch.conf on Solaris. And lo-and-behold:

"Sun Microsystems <https://en.wikipedia.org/wiki/Sun_Microsystems> first 
developed NSS for their Solaris 
<https://en.wikipedia.org/wiki/Solaris_%28operating_system%29> operating 
system, but subsequently programmers ported it to many other operating 
systems including FreeBSD <https://en.wikipedia.org/wiki/FreeBSD>, 
NetBSD <https://en.wikipedia.org/wiki/NetBSD>, Linux 
<https://en.wikipedia.org/wiki/Linux>, HP-UX 
<https://en.wikipedia.org/wiki/HP-UX>, IRIX 
<https://en.wikipedia.org/wiki/IRIX> and AIX 
<https://en.wikipedia.org/wiki/AIX_operating_system>."

https://en.wikipedia.org/wiki/Name_Service_Switch

How true that is, I'd love to know.

art k.

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

From dave at horsfall.org  Thu Nov  8 08:01:50 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 8 Nov 2018 09:01:50 +1100 (EST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
 <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>
 <ec991a24-fe7c-232c-df00-162699ba615a@dunnington.plus.com>
 <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.1811080900370.78183@aneurin.horsfall.org>

On Wed, 7 Nov 2018, Grant Taylor via TUHS wrote:

> Much like how a low base current can control a high collector current on 
> a transistor.

A fellow electronics bod, I see :-)

-- Dave


From pete at dunnington.plus.com  Thu Nov  8 09:00:56 2018
From: pete at dunnington.plus.com (Pete Turnbull)
Date: Wed, 7 Nov 2018 23:00:56 +0000
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
 <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>
 <ec991a24-fe7c-232c-df00-162699ba615a@dunnington.plus.com>
 <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net>
Message-ID: <68ffd6da-4017-16ff-c3fc-3d01a813493f@dunnington.plus.com>

On 07/11/2018 17:30, Grant Taylor via TUHS wrote:
> On 11/07/2018 04:37 AM, Pete Turnbull wrote:
>> Not really.  You go past the bouncer as an immediate consequence of 
>> authorization.
> 
> I disagree.

You're entitled to your own opinion of the meaning of the term AAA, of 
course, and I understand some of the points you make, but I never 
claimed the three parts are necessarily atomic.  I was merely explaining 
my experience and knowledge of AAA (as a systems administrator, network 
manager and member of CERT and later CSIRT in a large enterprise) from 
working with Hewlett Packard, Cisco, Juniper, Aruba, Sun, SGI, 
Microsoft, eduroam, RADIUS, ...

-- 
Pete
Pete Turnbull


From robpike at gmail.com  Thu Nov  8 09:30:14 2018
From: robpike at gmail.com (Rob Pike)
Date: Thu, 8 Nov 2018 10:30:14 +1100
Subject: [TUHS] /crp
In-Reply-To: <CAC20D2N3ofDKNAES6Wj2TLxGNa8zHnMoLqrshxcAoQHhOGgPnw@mail.gmail.com>
References: <1541547109.9957.for-standards-violators@oclsc.org>
 <CAC20D2N3ofDKNAES6Wj2TLxGNa8zHnMoLqrshxcAoQHhOGgPnw@mail.gmail.com>
Message-ID: <CAKzdPgzPtnPQoUwGpTeaQjhfW8zUHsOnAbtw=eOB0454TyUUjg@mail.gmail.com>

/crp was "creep" before Apollo even existed.

-rob


On Thu, Nov 8, 2018 at 3:45 AM Clem Cole <clemc at ccc.com> wrote:

>
>
> On Tue, Nov 6, 2018 at 8:33 PM Norman Wilson <norman at oclsc.org> wrote:
>
>>
>> oddly, the conventional pronunciation seemed to be creep.
>>
>>
> It's possible that was because the Apollo Domain system had an ssh-like
> program called crp, that was prounced 'creep' which was pretty widely used
> in those days.
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181108/c29d6563/attachment.html>

From grog at lemis.com  Thu Nov  8 09:40:37 2018
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Thu, 8 Nov 2018 10:40:37 +1100
Subject: [TUHS] /crp
In-Reply-To: <CAC20D2PkKf06Loh3_B_ze+qYt82qmYwfEWL7KOjxd98442QNkw@mail.gmail.com>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
 <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
 <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com>
 <CAC20D2PkKf06Loh3_B_ze+qYt82qmYwfEWL7KOjxd98442QNkw@mail.gmail.com>
Message-ID: <20181107234037.GA3826@eureka.lemis.com>

On Wednesday,  7 November 2018 at 10:14:20 -0500, Clem Cole wrote:
> On Wed, Nov 7, 2018 at 9:09 AM <ron at ronnatalie.com> wrote:
>
>> The DEC drivers just left off the last 72 sectors.   There was no
>> provision using them for block replacement.
>
> Minor update -- *no dynamic replacement provision*.  There was a
> standard alone utility called BAD144 that implemented DEC Standard
> 144 (Bad Blocks).

Yes, this was also present in early FreeBSD distributions.  I have a
vague recollection that people warned against using it.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181108/14db9a63/attachment.sig>

From wkt at tuhs.org  Thu Nov  8 11:12:07 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 8 Nov 2018 11:12:07 +1000
Subject: [TUHS] Unix Philosophy Revisited
Message-ID: <20181108011207.GA27042@minnie.tuhs.org>

https://opensource.com/article/18/11/revisiting-unix-philosophy-2018

Just saw this article that reminds us why the Unix philosophy was/is good
for certain classes or problems.

	Warren


From dave at horsfall.org  Thu Nov  8 11:48:30 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 8 Nov 2018 12:48:30 +1100 (EST)
Subject: [TUHS] YP / NIS / NIS+ / LDAP
In-Reply-To: <alpine.BSF.2.21.9999.1811080900370.78183@aneurin.horsfall.org>
References: <f99e4c98-d584-d823-a581-0d6c3b9c3420@spamtrap.tnetconsulting.net>
 <alpine.DEB.2.20.1811051132410.13752@mira.opentrend.net>
 <c710dafc-9edc-cd29-3aeb-dc0fa6badeff@spamtrap.tnetconsulting.net>
 <CAPWNY8WqB0fO=a_sNq5NezO7xh3-c4iO3gyoFUZXk5e7=v179w@mail.gmail.com>
 <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net>
 <CAEoi9W4HBH7y5wf+7Ah0Rrjh_yk5KSvsZY--2M-FM7D61S-1OQ@mail.gmail.com>
 <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net>
 <CAEoi9W7mJD2y29KPj1av_Lpnpd=AYgLwL-G7HjKYjo-B69ejHA@mail.gmail.com>
 <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net>
 <ec991a24-fe7c-232c-df00-162699ba615a@dunnington.plus.com>
 <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net>
 <alpine.BSF.2.21.9999.1811080900370.78183@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.1811081248040.78183@aneurin.horsfall.org>

Sorry; that last message was supposed to have gone direct...

-- Dave


From imp at bsdimp.com  Thu Nov  8 13:04:23 2018
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 7 Nov 2018 20:04:23 -0700
Subject: [TUHS] /crp
In-Reply-To: <20181107234037.GA3826@eureka.lemis.com>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
 <alpine.BSF.2.21.9999.1811070844190.78183@aneurin.horsfall.org>
 <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com>
 <CAC20D2PkKf06Loh3_B_ze+qYt82qmYwfEWL7KOjxd98442QNkw@mail.gmail.com>
 <20181107234037.GA3826@eureka.lemis.com>
Message-ID: <CANCZdfoX1i8R-LkB_mgkZ7Acj1c91psOC=XKdKD_Ha_gys9a3A@mail.gmail.com>

On Wed, Nov 7, 2018 at 7:26 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Wednesday,  7 November 2018 at 10:14:20 -0500, Clem Cole wrote:
> > On Wed, Nov 7, 2018 at 9:09 AM <ron at ronnatalie.com> wrote:
> >
> >> The DEC drivers just left off the last 72 sectors.   There was no
> >> provision using them for block replacement.
> >
> > Minor update -- *no dynamic replacement provision*.  There was a
> > standard alone utility called BAD144 that implemented DEC Standard
> > 144 (Bad Blocks).
>
> Yes, this was also present in early FreeBSD distributions.  I have a
> vague recollection that people warned against using it.
>

It was OK for the super-duper old IDE drives from the IBM/AT and 80386 era.
It was better for the ESDI drives because those tended to ship with a list
of bad blocks printed on the label (which was itself a carry over from the
MFM days). The MFM drives *did* have a DEC standard to list bad blocks and
reserve spare cylinders which was derived from the earlier rkXX drives.
bad144 was for the rkXX drives and then adopted, badly, for the newer
drives types and wasn't super-great by the time FreeBSD came along...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181107/97b1c63c/attachment.html>

From arnold at skeeve.com  Thu Nov  8 21:34:27 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 08 Nov 2018 04:34:27 -0700
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <20181107201520.GA14737@mcvoy.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
 <20181107201520.GA14737@mcvoy.com>
Message-ID: <201811081134.wA8BYRl9001763@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> On Wed, Nov 07, 2018 at 12:15:32PM -0500, Dan Cross wrote:
> > On Wed, Nov 7, 2018 at 4:05 AM <arnold at skeeve.com> wrote:
> > When DNS came along, it became
> > > a matter of editing /etc/nsswitch.conf to include dns as one of the
> > > options along with files and yp/nis.  I think the average user didn't
> > > see any big difference since all the apps (ftp, telnet) just went
> > > through gethostbyname().
> > 
> > This doesn't mesh with my memory. I recall building BIND from source and
> > having to rebuild network programs (e.g. on 4.3 on the RT or VAXen) to pick
> > up the new version of libresolv.a, and hacking the resolver library into
> > libc.so on Suns. I remember using resolv.conf fairly early on, but my
> > memory is that nsswitch.conf came later (Solaris 2.x era?). 
>
> Yeah, this is right, I remember doing this as well and I worked at Sun
> at that point.  It was a pain.  

OK, so now that everyone mentions it, I was wrong. I think I only
had to do this same kind of thing once though.

We ran the Mt. Xinu 4.3 BSD + NFS and it had YP also, so at some
point they were doing it and I sorta think we had /etc/nsswitch.conf
on the vaxen, but I could be wrong. We definitely had it on the SunOS 4.0
Sun servers that we bought later on.

Our connection was via CSNet - slow X.25 line to Georgia Tech and from
there to the rest of the world. We most certainly did NOT do daily FTPs
of the HOSTS.TXT file or anything like that.  At the time we had very
few TCP/IP-savy users; you could probably count them on two hands and
have a few fingers left over. :-)

Those were the days. :-)

Arnold


From ches at cheswick.com  Fri Nov  9 00:25:22 2018
From: ches at cheswick.com (WIlliam Cheswick)
Date: Thu, 8 Nov 2018 09:25:22 -0500
Subject: [TUHS] Unix half a billion seconds old in 1985
In-Reply-To: <20181104233505.GA70281@eureka.lemis.com>
References: <alpine.BSF.2.21.9999.1811050746480.78183@aneurin.horsfall.org>
 <20181104233505.GA70281@eureka.lemis.com>
Message-ID: <CC3338EC-F33F-4CBB-8071-CF114DE1918C@cheswick.com>



> On Nov 4, 2018, at 6:35 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> 
> 
> Yes, on 9 September 2001

Sometime early in 2001 I looked this up and mentioned it to Ken.  As I recall, he
said it is Bonnie’s birthday.

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

From doug at cs.dartmouth.edu  Fri Nov  9 01:59:25 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 08 Nov 2018 10:59:25 -0500
Subject: [TUHS] Peter Adams photos
Message-ID: <201811081559.wA8FxPUq126164@tahoe.cs.Dartmouth.EDU>

Peter Adams, who photographed many Unix folks for his
"Faces of open source" series (http://facesofopensource.com/),
found trinkets from the Unix lab in the Bell Labs archives:
http://www.peteradamsphoto.com/unix-folklore/.

One item is more than a trinket. Belle, built by
Ken Thompson and Joe Condon, won the world computer
chess championship in 1980 and became the first
machine to gain a chess master rating. Physically,
it's about a two-foot cube.

Doug


From doug at cs.dartmouth.edu  Fri Nov  9 02:30:46 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 08 Nov 2018 11:30:46 -0500
Subject: [TUHS] [groff] How to show all hyphenation points?
Message-ID: <201811081630.wA8GUkXS135455@tahoe.cs.Dartmouth.EDU>

> I have a vague intuition right now that the hyphenation decisions
> ...
> should be accessible without having to invoke the output driver.

Would't that require some way to detect a hyphenation event?
Offhand, I can't think of a way to do that.

But if you know in advance what word's hyphenation is in
question, you could switch environments, use the .ll 1u 
trick in a diversion, and base your decision on the result.

Doug


From krewat at kilonet.net  Fri Nov  9 02:39:41 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 8 Nov 2018 11:39:41 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <201811081134.wA8BYRl9001763@freefriends.org>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
 <20181107201520.GA14737@mcvoy.com>
 <201811081134.wA8BYRl9001763@freefriends.org>
Message-ID: <4190e0c5-6293-caa1-8e4a-7f177f10f61d@kilonet.net>

On 11/8/2018 6:34 AM, arnold at skeeve.com wrote:
> We definitely had it on the SunOS 4.0
> Sun servers that we bought later on.
Still incorrect. ;)

It first showed up in Solaris, not SunOS.




From g.branden.robinson at gmail.com  Fri Nov  9 02:49:09 2018
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Thu, 8 Nov 2018 11:49:09 -0500
Subject: [TUHS] [groff] How to show all hyphenation points?
In-Reply-To: <201811081630.wA8GUkXS135455@tahoe.cs.Dartmouth.EDU>
References: <201811081630.wA8GUkXS135455@tahoe.cs.Dartmouth.EDU>
Message-ID: <20181108164907.xayhiclk5osnssly@crack.deadbeast.net>

[adding groff at gnu back into CC]

I think the TUHS guys might be wondering where this topic came from. :)

At 2018-11-08T11:30:46-0500, Doug McIlroy wrote:
> > I have a vague intuition right now that the hyphenation decisions
> > ...
> > should be accessible without having to invoke the output driver.
> 
> Would't that require some way to detect a hyphenation event?
> Offhand, I can't think of a way to do that.

That's a harder problem than I was trying to crack; I just wanted to be
able to ask the underlying *roff where it _might_ hyphenate a word, not
where it actually ended up hyphenating one on the output.

> But if you know in advance what word's hyphenation is in
> question, you could switch environments, use the .ll 1u 
> trick in a diversion, and base your decision on the result.

That had not occurred to me; I am not au fait with diversions.  Thanks!

-- 
Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181108/936a8709/attachment.sig>

From mah at mhorton.net  Fri Nov  9 02:55:57 2018
From: mah at mhorton.net (Mary Ann Horton)
Date: Thu, 8 Nov 2018 08:55:57 -0800
Subject: [TUHS] /crp
In-Reply-To: <04db01d47606$7b003700$7100a500$@ronnatalie.com>
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
Message-ID: <9b7eca07-8233-07c8-3ff7-297aa43759b1@mhorton.net>

I recall at Berkeley on the VAX we had a /crp filesystem, and it was for 
"crap" we didn't want to delete but wasn't very important.  I didn't 
realize it was inspired by Research.

At some point someone decided it would be nicer to rename it /arch as an 
"archive".

I still have a /arch on my personal machine, for stuff that's large and 
(almost) never changes, so it doesn't need to be backed up daily.  It 
lives on one of those external backup hard disks, and there are two of 
them, so one can be stored offsite.

     Mary Ann

On 11/6/18 11:25 AM, ron at ronnatalie.com wrote:
> An early UNIX paper shows the system had four RK05's (4872 512-byte blocks
> on UNIX, for some reason only 4800 used on the DEC OSs ... remember we had
> to poke ROLLIN to copy the full UNIX partition standalone).
> /dev/rk0 - available for user packs.
> /dev/rk1 - root
> /dev/rk2 - /usr
> /dev/rk3 - /crp
>
> I think it was just additional storage of "crap".
>
>> -----Original Message-----
>> From: TUHS <tuhs-bounces at minnie.tuhs.org> On Behalf Of Angelo
>> Papenhoff
>> Sent: Tuesday, November 6, 2018 12:10 PM
>> To: tuhs at minnie.tuhs.org
>> Subject: [TUHS] /crp
>>
>> I was wondering, what was the /crp mount point in early UNIX used for?
>> And what does "crp" mean? Does it mean what I think it does?
>> It is only mentioned in V3 it seems:
>> ./v4man/manx/unspk.8:unspk lives in /crp/vs   (v4/manx means pre-v4)
>> ./v3man/man6/yacc.6:SYNOPSIS /crp/scj/yacc  [ <grammar ]
>> ./v3man/man4/rk.4:/dev/rk3      /crp file system
>>
>> I suppose scj, doug or ken can help out.
>>
>> aap


From imp at bsdimp.com  Fri Nov  9 09:14:29 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 8 Nov 2018 16:14:29 -0700
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <4190e0c5-6293-caa1-8e4a-7f177f10f61d@kilonet.net>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
 <20181107201520.GA14737@mcvoy.com>
 <201811081134.wA8BYRl9001763@freefriends.org>
 <4190e0c5-6293-caa1-8e4a-7f177f10f61d@kilonet.net>
Message-ID: <CANCZdfoXr63jPV9fzV7zeS6gPmt6m4ZFdf=q6gvctL_yAeFitA@mail.gmail.com>

On Thu, Nov 8, 2018, 1:07 PM Arthur Krewat <krewat at kilonet.net wrote:

> On 11/8/2018 6:34 AM, arnold at skeeve.com wrote:
> > We definitely had it on the SunOS 4.0
> > Sun servers that we bought later on.
> Still incorrect. ;)
>
> It first showed up in Solaris, not SunOS.
>

Early directory services were rcp/ftp, in all their glory. :). Mostly
though at the small school I was at it was moot. THE VAX we had was 100%
ASCII terminals to access it, except if you were logging in from the
Tops-20 box via telnet from one of its ASCII terminals.

SunOS 4 definitely had YP. We used it in school when the Tops-20 machine
was replaced by a boatload of 68000 machines running SunOS and Suntools...
I can't recall if 3.5 also had it or not... it was later it changed to NIS.

Warner

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

From krewat at kilonet.net  Fri Nov  9 10:06:03 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 8 Nov 2018 19:06:03 -0500
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: <CANCZdfoXr63jPV9fzV7zeS6gPmt6m4ZFdf=q6gvctL_yAeFitA@mail.gmail.com>
References: <CAEoi9W7uCUgY3C1qTghi5QEBXDo4dwZqTc8T40LxUWCBr42zRA@mail.gmail.com>
 <201811070905.wA795wxP017303@freefriends.org>
 <CAEoi9W5bzit9y7oew9UCCHn_QHjFa+PCRe_LJPqF80kFUje+Tw@mail.gmail.com>
 <20181107201520.GA14737@mcvoy.com>
 <201811081134.wA8BYRl9001763@freefriends.org>
 <4190e0c5-6293-caa1-8e4a-7f177f10f61d@kilonet.net>
 <CANCZdfoXr63jPV9fzV7zeS6gPmt6m4ZFdf=q6gvctL_yAeFitA@mail.gmail.com>
Message-ID: <e30fb069-2f4d-6e00-4f37-93cdc5c06eaa@kilonet.net>

On 11/8/2018 6:14 PM, Warner Losh wrote:
>
> SunOS 4 definitely had YP. We used it in school when the Tops-20 
> machine was replaced by a boatload of 68000 machines running SunOS and 
> Suntools... I can't recall if 3.5 also had it or not... it was later 
> it changed to NIS.
>
Anything that had Sun's NFS had YP, at least as of version 2.0. It was 
part of the package.

Somewhere in Warren's archive is a source copy of NFS 2.0 from Sun that 
I donated. It's replete with all the YP stuff. Not sure if the following 
is the copy I donated, but it's close enough:

https://minnie.tuhs.org//cgi-bin/utree.pl?file=NFSv2/usr/src/usr.bin/ypcat.c

 From my copy:

-r--r--r--   1 krewat   kilonet     6356 Nov 20  1985 
./usr/src/usr.bin/ypcat.c

Interesting that the date is one day off.

The copy of NFS 2.0 that I donated was integrated with BSD 4.2 at 
Computer Graphics Lab at New York Institute of Technology. When they 
went kaput, I managed to get my hands on that NFS tape along with a slew 
of other stuff that I can't do anything with because it's all copywrited.

/etc/nsswitch.conf in Solaris originated with NIS+ (NISPLUS). Sun seems 
to be the origin, and it only came about because of NIS+. That's my 
theory and I'm sticking with it ;)

art k.







From a.phillip.garcia at gmail.com  Fri Nov  9 13:11:55 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Thu, 8 Nov 2018 22:11:55 -0500
Subject: [TUHS] Peter Adams photos
In-Reply-To: <201811081559.wA8FxPUq126164@tahoe.cs.Dartmouth.EDU>
References: <201811081559.wA8FxPUq126164@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAFCBnZvJ2SVNP7GJ8_YdnBdVioRTPKJyz=tkZSFCcZu603p5rg@mail.gmail.com>

On Thu, Nov 8, 2018, 1:23 PM Doug McIlroy <doug at cs.dartmouth.edu wrote:

> Peter Adams, who photographed many Unix folks for his
> "Faces of open source" series (http://facesofopensource.com/),
> found trinkets from the Unix lab in the Bell Labs archives:
> http://www.peteradamsphoto.com/unix-folklore/.
>
> One item is more than a trinket. Belle, built by
> Ken Thompson and Joe Condon, won the world computer
> chess championship in 1980 and became the first
> machine to gain a chess master rating. Physically,
> it's about a two-foot cube.
>
> Doug
>

Furthermore, Feng-hsiung Hsu at CMU essentially put Belle on a chip and
parallelized it, resulting in the chess computer Deep Thought -- which
became the first machine to defeat a human Grandmaster. It lost a historic
match against the world champion Garry Kasparov, but its successor, Deep
Blue, went on to defeat him.

My favorite anecdote that I've read regarding Belle was when Ken Thompson
took it out of the country for a competition. Someone, I'm assuming with
customs, asked him if Belle could be classified as munitions in any way. He
replied, "Only if you drop it out the window."

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

From lars at nocrew.org  Fri Nov  9 15:30:11 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 09 Nov 2018 05:30:11 +0000
Subject: [TUHS] /crp
In-Reply-To: <9b7eca07-8233-07c8-3ff7-297aa43759b1@mhorton.net> (Mary Ann
 Horton's message of "Thu, 8 Nov 2018 08:55:57 -0800")
References: <20181106170955.GA4087@indra.papnet.eu>
 <04db01d47606$7b003700$7100a500$@ronnatalie.com>
 <9b7eca07-8233-07c8-3ff7-297aa43759b1@mhorton.net>
Message-ID: <7wo9ayvmvw.fsf@junk.nocrew.org>

Mary Ann Horton wrote:
> I recall at Berkeley on the VAX we had a /crp filesystem

I'm patching 4.1BSD to add Chaosnet, and it does have /crp.


From doug at cs.dartmouth.edu  Fri Nov  9 22:52:34 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Fri, 09 Nov 2018 07:52:34 -0500
Subject: [TUHS] Peter Adams photos
Message-ID: <201811091252.wA9CqYbd059066@tahoe.cs.Dartmouth.EDU>

> My favorite anecdote that I've read regarding Belle was when Ken
> Thompson took it out of the country for a competition. Someone,
> I'm assuming with customs, asked him if Belle could be
> classified as munitions in any way. He replied, "Only if you
> drop it out the window."

That's not the half of it. Ken had been invited by Botvinnik,
a past world champion, to demonstrate Belle in Russia. Customs
spotted it in baggage and impounded it without Ken's knowledge.
When he arrived empty-handed in Moscow, his hosts abandoned
him to his own devices.

Late that fateful Friday afteroon, customs called Bell Labs
security, which in turn called Ken's department head--me. That
evening I called Bill Baker, the Labs' presi7, at home,
hoping he might use his high-level Washington connections
to spring Belle. No luck. Ken was in the dark about the whole
affair until Joe Condon managed to reach him at his hotel.
Customs kept the machine a month and released it only after the
Labs agreed to pay a modest fine. I believe Ken's remark about
the military potential of Belle was made in reply to a reporter.

Doug


From a.phillip.garcia at gmail.com  Sat Nov 10 01:36:54 2018
From: a.phillip.garcia at gmail.com (A. P. Garcia)
Date: Fri, 9 Nov 2018 10:36:54 -0500
Subject: [TUHS] Peter Adams photos
In-Reply-To: <201811091252.wA9CqYbd059066@tahoe.cs.Dartmouth.EDU>
References: <201811091252.wA9CqYbd059066@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAFCBnZu+E2oSxWmaVW=MkGzwjsSnms=Ncm6DA9hLz0++8OuCPA@mail.gmail.com>

On Fri, Nov 9, 2018, 10:19 AM Doug McIlroy <doug at cs.dartmouth.edu wrote:

> > My favorite anecdote that I've read regarding Belle was when Ken
> > Thompson took it out of the country for a competition. Someone,
> > I'm assuming with customs, asked him if Belle could be
> > classified as munitions in any way. He replied, "Only if you
> > drop it out the window."
>
> That's not the half of it. Ken had been invited by Botvinnik,
> a past world champion, to demonstrate Belle in Russia. Customs
> spotted it in baggage and impounded it without Ken's knowledge.
> When he arrived empty-handed in Moscow, his hosts abandoned
> him to his own devices.
>
> Late that fateful Friday afteroon, customs called Bell Labs
> security, which in turn called Ken's department head--me. That
> evening I called Bill Baker, the Labs' presi7, at home,
> hoping he might use his high-level Washington connections
> to spring Belle. No luck. Ken was in the dark about the whole
> affair until Joe Condon managed to reach him at his hotel.
> Customs kept the machine a month and released it only after the
> Labs agreed to pay a modest fine. I believe Ken's remark about
> the military potential of Belle was made in reply to a reporter.
>
> Doug
>

That certainly puts a damper on the punchline of the joke, but thank you
for sharing this story!

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

From richard at inf.ed.ac.uk  Sat Nov 10 03:05:21 2018
From: richard at inf.ed.ac.uk (Richard Tobin)
Date: Fri,  9 Nov 2018 17:05:21 +0000 (GMT)
Subject: [TUHS] Directory services in early Unix networks?
In-Reply-To: Warner Losh's message of Thu, 8 Nov 2018 16:14:29 -0700
Message-ID: <20181109170521.07D8F221BB9B@macaroni.inf.ed.ac.uk>


> SunOS 4 definitely had YP.

SunOS 2.0 had YP.

-- Richard

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



From wkt at tuhs.org  Sat Nov 10 11:58:07 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 10 Nov 2018 11:58:07 +1000
Subject: [TUHS] Rob Pike's Latest Unix Video
Message-ID: <20181110015807.GA12865@minnie.tuhs.org>

[from @rob_pike on twitter]: Something for the weekend: A talk I gave at the
office recently about my personal history with Unix.

https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be&t=226

Cheers, Warren


From wkt at tuhs.org  Sat Nov 10 14:18:08 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 10 Nov 2018 14:18:08 +1000
Subject: [TUHS] Weird e-mail delays on TUHS
Message-ID: <20181110041808.GA19817@minnie.tuhs.org>

All, for a while now there have been some weird multi-hour long delays
between e-mail arriving at TUHS and being forwarded on. I've just removed
a pile of queued messages which I think were causing mailman to have
palpitations. If you posted something on TUHS in the last few hours,
could you re-send it. Apologies for this.

Thanks, Warren


From pete at nomadlogic.org  Sat Nov 10 15:09:37 2018
From: pete at nomadlogic.org (Pete Wright)
Date: Fri, 9 Nov 2018 21:09:37 -0800
Subject: [TUHS] cute baby pictures and amazing stories
Message-ID: <6755a795-4053-4d9c-c19e-a949e0aedc88@nomadlogic.org>

really appreciate videos of talks like this as someone who wasn't lucky 
enough to be around to experience this in person but benefits from the 
things your generation built for us:

https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be

thanks rob!

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA



From bdwalton at gmail.com  Mon Nov 12 01:00:51 2018
From: bdwalton at gmail.com (Ben Walton)
Date: Sun, 11 Nov 2018 15:00:51 +0000
Subject: [TUHS] cute baby pictures and amazing stories
In-Reply-To: <6755a795-4053-4d9c-c19e-a949e0aedc88@nomadlogic.org>
References: <6755a795-4053-4d9c-c19e-a949e0aedc88@nomadlogic.org>
Message-ID: <CAP30j14jYB2Kp=49VzRFBt4GL=9PkVBSRK5aYzmAo02xz4LjwA@mail.gmail.com>

Interestingly, as of 2012, the UofT variant of ed referenced here was still
in active use. There was at least one professor that required it (rather
than the standard linux/solaris/whathaveyou ed) on machines she[1] used. It
was carried along all these years, most recently being packaged as an rpm
and made a standard part of every installation being done for systems I
tended. I expect it's still around in other parts of UofT as well, but
don't know for sure.

The code itself lacked many modern trimmings and still didn't pull in
various headers you'd expect in modern C programs because it had its own
implementations of things like isspace, etc. I'd always known it as "Henry
Spencer's ed" because that's the part of the UofT world I was working in. I
didn't realize the full heritage of it until this video. Very cool!

Thanks
-Ben

[1] Dr. Z was awesome, and I found it kinda nifty to keep this piece of
heritage alive.

On Sat, Nov 10, 2018 at 5:16 AM Pete Wright <pete at nomadlogic.org> wrote:

> really appreciate videos of talks like this as someone who wasn't lucky
> enough to be around to experience this in person but benefits from the
> things your generation built for us:
>
> https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be
>
> thanks rob!
>
> -pete
>
> --
> Pete Wright
> pete at nomadlogic.org
> @nomadlogicLA
>
>

-- 
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself.  Much more happiness,
truth, beauty and wisdom will come to you that way.

-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181111/54dc239a/attachment.html>

From wkt at tuhs.org  Wed Nov 14 07:55:31 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 14 Nov 2018 07:55:31 +1000
Subject: [TUHS] Article on the history of cat(1)
Message-ID: <20181113215531.GA24373@minnie.tuhs.org>

All, I just saw this link to an article on the history of cat(1):

https://twobithistory.org/2018/11/12/cat.html

Cheers, Warren


From dave at horsfall.org  Wed Nov 14 08:44:50 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 14 Nov 2018 09:44:50 +1100 (EST)
Subject: [TUHS] Article on the history of cat(1)
In-Reply-To: <20181113215531.GA24373@minnie.tuhs.org>
References: <20181113215531.GA24373@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>

On Wed, 14 Nov 2018, Warren Toomey wrote:

> All, I just saw this link to an article on the history of cat(1):
>
> https://twobithistory.org/2018/11/12/cat.html

Didn't know that cat(1) was still written in assemblee on Edition 6... 
My memory must be getting hazy (but yes, I did mount a mag tape as a file 
system, just to see if it would work).

-- Dave


From wkt at tuhs.org  Wed Nov 14 08:49:52 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 14 Nov 2018 08:49:52 +1000
Subject: [TUHS] Article on the history of cat(1)
In-Reply-To: <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>
References: <20181113215531.GA24373@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>
Message-ID: <20181113224952.GA29973@minnie.tuhs.org>

On Wed, Nov 14, 2018 at 09:44:50AM +1100, Dave Horsfall wrote:
> Didn't know that cat(1) was still written in assembly on Edition 6... 

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/cat.s

Cheers, Warren


From krewat at kilonet.net  Wed Nov 14 09:10:49 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Tue, 13 Nov 2018 18:10:49 -0500
Subject: [TUHS] Article on the history of cat(1)
In-Reply-To: <20181113224952.GA29973@minnie.tuhs.org>
References: <20181113215531.GA24373@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>
 <20181113224952.GA29973@minnie.tuhs.org>
Message-ID: <596cc328-cb06-d158-a455-e22618ac4ac8@kilonet.net>

On 11/13/2018 5:49 PM, Warren Toomey wrote:
> On Wed, Nov 14, 2018 at 09:44:50AM +1100, Dave Horsfall wrote:
>> Didn't know that cat(1) was still written in assembly on Edition 6...
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/cat.s
>
>

The very definition of simplicity and elegance.

I pine for those days. Or at least, what I used to do in MACRO-10 in 
high school ;)



From dave at horsfall.org  Wed Nov 14 09:14:49 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 14 Nov 2018 10:14:49 +1100 (EST)
Subject: [TUHS] Article on the history of cat(1)
In-Reply-To: <20181113224952.GA29973@minnie.tuhs.org>
References: <20181113215531.GA24373@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>
 <20181113224952.GA29973@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1811140957280.60610@aneurin.horsfall.org>

On Wed, 14 Nov 2018, Warren Toomey wrote:

>> Didn't know that cat(1) was still written in assembly on Edition 6...
>
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/cat.s

Thanks; then again, I never had a reason to poke around cat(1) (but I do 
remember adding a "-h" flag to pr(1) for a sub-header or something).

In fact, the only assembler stuff I remember modifying was deep in the 
kernel, to take advantage of Unibus timing (on the /40 at least), where 
the "obvious" code was sub-optimal; can't remember the details, but it 
saved a bus cycle or two.

Hell, I wish I still had that "CSU Tape"; it was Edition 6 with as much of 
Edition 7 (and AUSAM) that I could shoe-horn in, such as XON/XOFF for the 
TTY driver.  I was known as "Mr Unix 6-1/2" at the time...

Completely rewrote the 200-UT driver so that it actually worked (IanJ's 
driver was a horrible mess) and worked around an egregious bug on the 
Kronos side which they said was baked-in so deep that it couldn't be 
fixed.

Rewrote the plotter driver and Versatec LV-11 driver to use the buffer 
pool instead of the character queues, so they went like a bat out of hell.

Etc.

-- Dave


From robpike at gmail.com  Wed Nov 14 09:21:37 2018
From: robpike at gmail.com (Rob Pike)
Date: Wed, 14 Nov 2018 10:21:37 +1100
Subject: [TUHS] Article on the history of cat(1)
In-Reply-To: <alpine.BSF.2.21.9999.1811140957280.60610@aneurin.horsfall.org>
References: <20181113215531.GA24373@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>
 <20181113224952.GA29973@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140957280.60610@aneurin.horsfall.org>
Message-ID: <CAKzdPgwsf-h+V8b1yMq25PcFNu2Ux==q2Lpbvzitb3f7P-UKcA@mail.gmail.com>

I was offended by the -u flag in v7 cat, which was a necessary but
unfortunate consequence of preserving the original's semantics while
converting it to use the new standard I/O library. Dennis felt it was
important as a proof of the value of stdio; to me it was an indication that
stdio couldn't do everything. I rewrote cat to use just read and write, as
nature intended. I don't recall if my version is in any of v8 v9 v10 but
it, or something very like it, is in Plan 9:

% cat cat.c

#include <u.h>

#include <libc.h>


void

cat(int f, char *s)

{

char buf[8192];

long n;


while((n=read(f, buf, (long)sizeof buf))>0)

if(write(1, buf, n)!=n)

sysfatal("write error copying %s: %r", s);

if(n < 0)

sysfatal("error reading %s: %r", s);

}


void

main(int argc, char *argv[])

{

int f, i;


argv0 = "cat";

if(argc == 1)

cat(0, "<stdin>");

else for(i=1; i<argc; i++){

f = open(argv[i], OREAD);

if(f < 0)

sysfatal("can't open %s: %r", argv[i]);

else{

cat(f, argv[i]);

close(f);

}

}

exits(0);

}


%

-rob

P.S. I learned today that cat.c has a spurious trailing newline.

On Wed, Nov 14, 2018 at 10:15 AM Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 14 Nov 2018, Warren Toomey wrote:
>
> >> Didn't know that cat(1) was still written in assembly on Edition 6...
> >
> > https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s1/cat.s
>
> Thanks; then again, I never had a reason to poke around cat(1) (but I do
> remember adding a "-h" flag to pr(1) for a sub-header or something).
>
> In fact, the only assembler stuff I remember modifying was deep in the
> kernel, to take advantage of Unibus timing (on the /40 at least), where
> the "obvious" code was sub-optimal; can't remember the details, but it
> saved a bus cycle or two.
>
> Hell, I wish I still had that "CSU Tape"; it was Edition 6 with as much of
> Edition 7 (and AUSAM) that I could shoe-horn in, such as XON/XOFF for the
> TTY driver.  I was known as "Mr Unix 6-1/2" at the time...
>
> Completely rewrote the 200-UT driver so that it actually worked (IanJ's
> driver was a horrible mess) and worked around an egregious bug on the
> Kronos side which they said was baked-in so deep that it couldn't be
> fixed.
>
> Rewrote the plotter driver and Versatec LV-11 driver to use the buffer
> pool instead of the character queues, so they went like a bat out of hell.
>
> Etc.
>
> -- Dave
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181114/60090dfa/attachment.html>

From norman at oclsc.org  Wed Nov 14 09:27:49 2018
From: norman at oclsc.org (Norman Wilson)
Date: Tue, 13 Nov 2018 18:27:49 -0500
Subject: [TUHS] Article on the history of cat(1)
Message-ID: <1542151675.9670.for-standards-violators@oclsc.org>

Rob:

  I rewrote cat to use just read and write, as
  nature intended. I don't recall if my version is in any of v8 v9 v10 ...

====

It is.  It was /bin/cat when I arrived at Murray Hill in 1984.
I remember being delighted with the elegant way to get rid of
a flag I had never really liked either.

I never knew Dennis had dragged his heels at it.  It was (to me)
so obviously the right answer that I never asked!

Norman Wilson
Toronto ON


From dave at horsfall.org  Wed Nov 14 12:51:18 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 14 Nov 2018 13:51:18 +1100 (EST)
Subject: [TUHS] Article on the history of cat(1)
In-Reply-To: <20181114004018.GA23816@minnie.tuhs.org>
References: <20181113215531.GA24373@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140940440.60610@aneurin.horsfall.org>
 <20181113224952.GA29973@minnie.tuhs.org>
 <alpine.BSF.2.21.9999.1811140957280.60610@aneurin.horsfall.org>
 <20181114004018.GA23816@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.21.9999.1811141338430.60610@aneurin.horsfall.org>

On Wed, 14 Nov 2018, Warren Toomey wrote:

>> Hell, I wish I still had that "CSU Tape"; it was Edition 6 with as much 
>> of Edition 7 (and AUSAM) that I could shoe-horn in, such as XON/XOFF 
>> for the TTY driver.  I was known as "Mr Unix 6-1/2" at the time...
>
> Definitely look at the UNSW tapes I have:
> https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM
> and https://www.tuhs.org/Archive/Distributions/UNSW/
> in case any of these are what you are looking for.

I think I did before, but I confess I didn't spend much time on it.  My 
pride and joy was certainly the rewritten ei.c driver (implementing the 
200-UT batch protocol), and the clever workaround to an egregious KRONOS 
bug where it would get stuck in a POLL/REJECT loop (I merely sent a dummy 
command viz "Q,I" -- discarding the response -- because KRONOS was 
expecting a command instead of the correct REJECT being nothing to send 
from the batch emulator).

At the time, Unix got blamed because the smaller non-Unix /40s (running a 
standalone program) worked fine for some reason; my guess is that it 
implemented the broken protocol somehow.

-- Dave


From arnold at skeeve.com  Wed Nov 14 16:58:06 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Tue, 13 Nov 2018 23:58:06 -0700
Subject: [TUHS] Request for the story: Unix on the Cray 1 at Bell Labs
Message-ID: <201811140658.wAE6w6Ss008301@freefriends.org>

Hi All.

In https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be Rob Pike
mentions that DMR and Norman Wilson ported Unix to the Cray 1 and that
it was not straightforward.

This sounds interesting.  Norman: would you be kind enough to elaborate
on this?

Thanks,

Arnold


From ralph at inputplus.co.uk  Wed Nov 14 21:07:43 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Wed, 14 Nov 2018 11:07:43 +0000
Subject: [TUHS] Request for the story: Unix on the Cray 1 at Bell Labs
In-Reply-To: <201811140658.wAE6w6Ss008301@freefriends.org>
References: <201811140658.wAE6w6Ss008301@freefriends.org>
Message-ID: <20181114110743.2DD4C1F942@orac.inputplus.co.uk>

Hi Arnold,

> In https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be Rob
> Pike mentions that DMR and Norman Wilson ported Unix to the Cray 1 and
> that it was not straightforward.

Are you aware of https://www.bell-labs.com/usr/dmr/www/cray.html ?

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From arnold at skeeve.com  Wed Nov 14 21:47:58 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Wed, 14 Nov 2018 04:47:58 -0700
Subject: [TUHS] Request for the story: Unix on the Cray 1 at Bell Labs
In-Reply-To: <20181114110743.2DD4C1F942@orac.inputplus.co.uk>
References: <201811140658.wAE6w6Ss008301@freefriends.org>
 <20181114110743.2DD4C1F942@orac.inputplus.co.uk>
Message-ID: <201811141147.wAEBlw8b022053@freefriends.org>

Ralph Corderoy <ralph at inputplus.co.uk> wrote:

> Hi Arnold,
>
> > In https://www.youtube.com/watch?v=_2NI6t2r_Hs&feature=youtu.be Rob
> > Pike mentions that DMR and Norman Wilson ported Unix to the Cray 1 and
> > that it was not straightforward.
>
> Are you aware of https://www.bell-labs.com/usr/dmr/www/cray.html ?

I am now. :-)

I guess I'll have to pull down the papers. Nonetheless, if Norman
has any first-hand antecdotes, I'm sure they'd be of interest.

Thanks,

Arnold


From doug at cs.dartmouth.edu  Fri Nov 16 10:03:48 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 15 Nov 2018 19:03:48 -0500
Subject: [TUHS] man-page style
Message-ID: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>

Regardless of standards considerations, if there's any advice
that needs to be hammered into man authors, it's to be concise
and accurate, but not pedantic. As Will Strunk commanded,
"Omit needless words."

The most needless words of all are promotional. No man page
should utter words like "powerful", "extraordinarily versatile",
"user-friendly", or "has a wide range of options".

As another instance of the rule, it would be better to recommend
short subtitles than to help make them long by recommending
quotes. If anything is said about limited-length macros, it
would best be under BUGS.

As editor for v7-v10, I would not offer v7 as a canonical
model. It owed its use of boldface in SYNOPIS to the limited
number of fonts (Typically R,F,I,S) that could be on our
typesetter at the same time. For v9 we were able to follow
Kernighan and adopt a distinct literals font (L, which happened
to be Courier but could have been identified with bold had we
wished). I still think this is the best choice.

As for options, v7 is a very poor model. It has many pages
that describe options in line, just as v1 had done for its
few options (called flags pre-v7). By v10 all options were
displayed in a list format.

For nagging reasons of verbal continuity, the options displays
were prefaced by *needless words* like, "The following options
are recognized". A simple OPTIONS heading would be better.

Unfortunately, an OPTIONS heading would intrude between the
basic description and less important details that follow
the options. (I don't agree that it would come too closely
after DESCRIPTION; a majority of man pages already have even
shorter sections.)  OPTIONS could be moved to the end of
DESCRIPTION. However, options may well be the biggest reason
for quick peeks at man pages; they should be easy to spot. It
has reasonably been suggested that OPTIONS should be a .SS
subsection.  That might be followed by .SS DETAILS.

Doug


From doug at cs.dartmouth.edu  Fri Nov 16 11:43:52 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 15 Nov 2018 20:43:52 -0500
Subject: [TUHS] man-page style
Message-ID: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>

Sorry about the recent post. It may seem peripherally
connected to tuhs, but it got there due to overtrained
fingers (or overaged mind). It was intended for another list.

Doug


From robpike at gmail.com  Fri Nov 16 13:18:35 2018
From: robpike at gmail.com (Rob Pike)
Date: Fri, 16 Nov 2018 14:18:35 +1100
Subject: [TUHS] man-page style
In-Reply-To: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>

As someone whose résumé, the one that got me in the door at Bell Labs, was
formatted with nroff -man, I of course support the clarity and precision
Doug celebrates. I wish the rest of the world agreed, but it doesn't.
Although I hold the editor line for much of the documentation for Go, for
instance, I fend off frequent requests to rewrite and expand. Flab is felt
to be friendlier, much as I (and Doug, who taught me more about writing
than anyone else) would prefer the leaner cuts.

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

From ken at google.com  Fri Nov 16 13:38:49 2018
From: ken at google.com (Ken Thompson)
Date: Thu, 15 Nov 2018 19:38:49 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
Message-ID: <CAG=a+rgx4GF4Z+bwyKTTzr2UtBArisLgzdp_6JeP7d8q_Zy_pQ@mail.gmail.com>

and it takes a lot less typing.


On Thu, Nov 15, 2018 at 7:18 PM, Rob Pike <robpike at gmail.com> wrote:
> As someone whose résumé, the one that got me in the door at Bell Labs, was
> formatted with nroff -man, I of course support the clarity and precision
> Doug celebrates. I wish the rest of the world agreed, but it doesn't.
> Although I hold the editor line for much of the documentation for Go, for
> instance, I fend off frequent requests to rewrite and expand. Flab is felt
> to be friendlier, much as I (and Doug, who taught me more about writing than
> anyone else) would prefer the leaner cuts.
>
> -rob
>


From bakul at bitblocks.com  Fri Nov 16 13:50:26 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 15 Nov 2018 19:50:26 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CAG=a+rgx4GF4Z+bwyKTTzr2UtBArisLgzdp_6JeP7d8q_Zy_pQ@mail.gmail.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
 <CAG=a+rgx4GF4Z+bwyKTTzr2UtBArisLgzdp_6JeP7d8q_Zy_pQ@mail.gmail.com>
Message-ID: <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com>

I have to write and rewrite to try to make things clear and concise.
Certainly worth doing but for some of us it takes a lot more typing
and thinking!

> On Nov 15, 2018, at 7:38 PM, Ken Thompson via TUHS <tuhs at minnie.tuhs.org> wrote:
> 
> and it takes a lot less typing.
> 
> 
> On Thu, Nov 15, 2018 at 7:18 PM, Rob Pike <robpike at gmail.com> wrote:
>> As someone whose résumé, the one that got me in the door at Bell Labs, was
>> formatted with nroff -man, I of course support the clarity and precision
>> Doug celebrates. I wish the rest of the world agreed, but it doesn't.
>> Although I hold the editor line for much of the documentation for Go, for
>> instance, I fend off frequent requests to rewrite and expand. Flab is felt
>> to be friendlier, much as I (and Doug, who taught me more about writing than
>> anyone else) would prefer the leaner cuts.
>> 
>> -rob
>> 



From lm at mcvoy.com  Fri Nov 16 14:50:16 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 15 Nov 2018 20:50:16 -0800
Subject: [TUHS] man-page style
In-Reply-To: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
Message-ID: <20181116045016.GK3341@mcvoy.com>

>From my quotes page:

How good is good enough: documentation

    Looking at Sun man pages versus Linux man pages is like looking at a Van
    Gogh or Monet after studying the work of the high school football player
    taking art as an "easy" elective. 

Amy Graf, BitMover 


On Thu, Nov 15, 2018 at 07:03:48PM -0500, Doug McIlroy wrote:
> Regardless of standards considerations, if there's any advice
> that needs to be hammered into man authors, it's to be concise
> and accurate, but not pedantic. As Will Strunk commanded,
> "Omit needless words."
> 
> The most needless words of all are promotional. No man page
> should utter words like "powerful", "extraordinarily versatile",
> "user-friendly", or "has a wide range of options".
> 
> As another instance of the rule, it would be better to recommend
> short subtitles than to help make them long by recommending
> quotes. If anything is said about limited-length macros, it
> would best be under BUGS.
> 
> As editor for v7-v10, I would not offer v7 as a canonical
> model. It owed its use of boldface in SYNOPIS to the limited
> number of fonts (Typically R,F,I,S) that could be on our
> typesetter at the same time. For v9 we were able to follow
> Kernighan and adopt a distinct literals font (L, which happened
> to be Courier but could have been identified with bold had we
> wished). I still think this is the best choice.
> 
> As for options, v7 is a very poor model. It has many pages
> that describe options in line, just as v1 had done for its
> few options (called flags pre-v7). By v10 all options were
> displayed in a list format.
> 
> For nagging reasons of verbal continuity, the options displays
> were prefaced by *needless words* like, "The following options
> are recognized". A simple OPTIONS heading would be better.
> 
> Unfortunately, an OPTIONS heading would intrude between the
> basic description and less important details that follow
> the options. (I don't agree that it would come too closely
> after DESCRIPTION; a majority of man pages already have even
> shorter sections.)  OPTIONS could be moved to the end of
> DESCRIPTION. However, options may well be the biggest reason
> for quick peeks at man pages; they should be easy to spot. It
> has reasonably been suggested that OPTIONS should be a .SS
> subsection.  That might be followed by .SS DETAILS.
> 
> Doug

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


From dave at horsfall.org  Fri Nov 16 15:32:37 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 16 Nov 2018 16:32:37 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <20181116045016.GK3341@mcvoy.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
Message-ID: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>

On Thu, 15 Nov 2018, Larry McVoy wrote:

> How good is good enough: documentation
>
>    Looking at Sun man pages versus Linux man pages is like looking at a Van
>    Gogh or Monet after studying the work of the high school football player
>    taking art as an "easy" elective.
>
> Amy Graf, BitMover

The Unix manpage format is the epitome of perfection; they tell you 
everything you need to know, and in the right order.  Frequently I cannot 
recall a particular flag (but I know what it does), and it's right there 
at the start.

-- Dave


From ality at pbrane.org  Fri Nov 16 15:24:30 2018
From: ality at pbrane.org (Anthony Martin)
Date: Thu, 15 Nov 2018 21:24:30 -0800
Subject: [TUHS] man-page style
In-Reply-To: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
Message-ID: <20181116052314.GA26474@alice>

Doug McIlroy <doug at cs.dartmouth.edu> once said:
> For nagging reasons of verbal continuity, the options displays
> were prefaced by *needless words* like, "The following options
> are recognized". A simple OPTIONS heading would be better.

There's a good one in ls(1) from v8: "There are an unbelievable
number of options".

  Anthony


From gtaylor at tnetconsulting.net  Fri Nov 16 16:03:37 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 15 Nov 2018 23:03:37 -0700
Subject: [TUHS] man-page style
In-Reply-To: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
Message-ID: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>

On 11/15/2018 10:32 PM, Dave Horsfall wrote:
> The Unix manpage format is the epitome of perfection; they tell you 
> everything you need to know, and in the right order.  Frequently I 
> cannot recall a particular flag (but I know what it does), and it's 
> right there at the start.

I think man pages make a great reference.  But I don't think they are a 
good teaching source for someone that doesn't know the material or what 
the components are for.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181115/7bb72c63/attachment.bin>

From lm at mcvoy.com  Fri Nov 16 16:38:56 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 15 Nov 2018 22:38:56 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
Message-ID: <20181116063856.GL3341@mcvoy.com>

Sorry to hijack this but I gotta.  Because I love nroff/troff.

So I was talking to a tech guy at one of the wall street banks, Marc
Donner.  I told him about a thing I had done, I called it webroff,
it was a perl script that took roff -ms input and produced a website,
complete with a table of contents, a site map, view a section as a page,
view the whole thing as page, it was pretty cool.  Sort of old school in
web styling but super useful.  For a long time BitMover's website was
a webroff site.  We eventually moved on to a node.js pile of crap and
even the biggest webroff haters at my company admitted that was a mistake.

I was talking to Marc about it and saying how low level it was.  Marc had
some insight, he said that roff -ms mostly said what you wanted to do,
not how to do it.  That's why I could build the perl script, it was
the macros that made it work.

Roff macros are a lot like device drivers, we have this read/write/etc
view of the world and a shit ton of work gets done to make that world
view be simple but it isn't.  

And to go to my love of roff, back in 1998 I was program chair for
a Linux Expo confernce.  Which just meant I formatted the proceedings.
LaTex was all the rage but I encouraged roff.  The one guy that took
me up on it was "holy crap is this easier than LaTex, I love groff".

Like Git, the wrong answer won, I do think that you all should look
at groff, it's pretty cool, LaTex won but groff is still a thing that
has taken roff forward.


On Fri, Nov 16, 2018 at 02:18:35PM +1100, Rob Pike wrote:
> As someone whose r??sum??, the one that got me in the door at Bell Labs, was
> formatted with nroff -man, I of course support the clarity and precision
> Doug celebrates. I wish the rest of the world agreed, but it doesn't.
> Although I hold the editor line for much of the documentation for Go, for
> instance, I fend off frequent requests to rewrite and expand. Flab is felt
> to be friendlier, much as I (and Doug, who taught me more about writing
> than anyone else) would prefer the leaner cuts.
> 
> -rob

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


From mike.ab3ap at gmail.com  Fri Nov 16 23:29:17 2018
From: mike.ab3ap at gmail.com (Mike Markowski)
Date: Fri, 16 Nov 2018 08:29:17 -0500
Subject: [TUHS] man-page style
In-Reply-To: <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
 <CAG=a+rgx4GF4Z+bwyKTTzr2UtBArisLgzdp_6JeP7d8q_Zy_pQ@mail.gmail.com>
 <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com>
Message-ID: <CANq1pfkcT4Jh3SQGJB5nb1QfGZMaNPjezp+e+w5YBsHC=We17g@mail.gmail.com>

That reminds me of the famous quote (though not famous enough that I recall
who said it!): "I'm sorry this letter is so long. I didn't have time to
make it shorter."

Mike Markowski

On Thu, Nov 15, 2018 at 10:51 PM Bakul Shah <bakul at bitblocks.com> wrote:

> I have to write and rewrite to try to make things clear and concise.
> Certainly worth doing but for some of us it takes a lot more typing
> and thinking!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/427c6ecf/attachment.html>

From clemc at ccc.com  Fri Nov 16 23:42:24 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Nov 2018 08:42:24 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181116063856.GL3341@mcvoy.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
 <20181116063856.GL3341@mcvoy.com>
Message-ID: <CAC20D2OTLE2pqjkUKHZYdkT-Oxh2u60YKm0QO+hhZHxQM+=zKA@mail.gmail.com>

On Fri, Nov 16, 2018 at 1:39 AM Larry McVoy <lm at mcvoy.com> wrote:

> Marc had some insight, he said that roff -ms mostly said what you wanted
> to do, not how to do it.
>
Which of course is the basic foundation of Rob's and Brian's "UNIX
philosophy" from their >>still<< ever so relevent book UPE.

These are the core ideas that to me are the basis for a true 'thinking
persons view of computer world'  vs. the 'I can do anything view' or vs. 'I
don't care, you can do it for me.'  MS Word  (Windows philidophy) fron
Redmond tries to tell me what I should want something 'should' look like/do
- *i.e.* hey you user --  just need to 'fill in the blanks' and we will do
everything for you.  Which if what you want to do is what they thought of
and what they think is proper can be easy no doubt, but you are screwed if
what you value / desire is just a little different.    LaTex and friends
(VMS from the OS standpoint) strive to solve that by make everything
possible so it can be as 'pretty' as possible.

We were recently discussing Oster's new book and his term about 'deep
interfaces.'   To me the message of UPE (and the roff family) is simple:
I've thought about what I want: i.e.  Computer do what want you to do for me,
not what you think I should do or make me work so hard to get what I want
done, that is not worth the trouble.   Then make *that simple* for me to
describe to the computer and the complex part, be *handled by the system
doing the work*,  but the work should not be so 'hidden' that I as the user
of the system, can not describe something different than what you (the
system programmer) think I need to do or may be so complex for you as the
system implementor to do for me.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/b0fc35db/attachment.html>

From bakul at bitblocks.com  Fri Nov 16 23:44:15 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 16 Nov 2018 05:44:15 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CANq1pfkcT4Jh3SQGJB5nb1QfGZMaNPjezp+e+w5YBsHC=We17g@mail.gmail.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
 <CAG=a+rgx4GF4Z+bwyKTTzr2UtBArisLgzdp_6JeP7d8q_Zy_pQ@mail.gmail.com>
 <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com>
 <CANq1pfkcT4Jh3SQGJB5nb1QfGZMaNPjezp+e+w5YBsHC=We17g@mail.gmail.com>
Message-ID: <FBF2F3C9-4AFA-4167-97DE-C84291EBC058@bitblocks.com>

That was Pascal. Not C!

> On Nov 16, 2018, at 5:29 AM, Mike Markowski <mike.ab3ap at gmail.com> wrote:
> 
> That reminds me of the famous quote (though not famous enough that I recall who said it!): "I'm sorry this letter is so long. I didn't have time to make it shorter."
> 
> Mike Markowski
> 
>> On Thu, Nov 15, 2018 at 10:51 PM Bakul Shah <bakul at bitblocks.com> wrote:
>> I have to write and rewrite to try to make things clear and concise.
>> Certainly worth doing but for some of us it takes a lot more typing
>> and thinking!
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/0ac034b9/attachment.html>

From skogtun at gmail.com  Sat Nov 17 00:02:01 2018
From: skogtun at gmail.com (Harald Arnesen)
Date: Fri, 16 Nov 2018 15:02:01 +0100
Subject: [TUHS] man-page style
In-Reply-To: <CANq1pfkcT4Jh3SQGJB5nb1QfGZMaNPjezp+e+w5YBsHC=We17g@mail.gmail.com>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
 <CAKzdPgxQPuBdBq6_4WNNOx--fpeV+iGc5bDww5+agWKBXd7A8Q@mail.gmail.com>
 <CAG=a+rgx4GF4Z+bwyKTTzr2UtBArisLgzdp_6JeP7d8q_Zy_pQ@mail.gmail.com>
 <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com>
 <CANq1pfkcT4Jh3SQGJB5nb1QfGZMaNPjezp+e+w5YBsHC=We17g@mail.gmail.com>
Message-ID: <812dc8a4-9b4b-a59a-d87f-1c75c2119b66@gmail.com>

Mike Markowski [11/16/18 2:29 PM]:

> That reminds me of the famous quote (though not famous enough that I
> recall who said it!): "I'm sorry this letter is so long. I didn't have
> time to make it shorter."

According to Wikipedia, Blaise Pascal:

"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte."
("I would have written a shorter letter, but I did not have the time.")
-- 
Hilsen Harald


From jcapp at anteil.com  Sat Nov 17 01:33:05 2018
From: jcapp at anteil.com (Jim Capp)
Date: Fri, 16 Nov 2018 10:33:05 -0500 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
Message-ID: <17703613.640.1542382385149.JavaMail.root@zimbraanteil>

It was man pages that first caught my eye, placing me on a life-long path of working 
with Unix and its derivatives. 


I was working on a project for a telephone company, converting IBM 2780 Bisync to 
async, and was given a manual and root access to a Xenix machine. I had cut my 
teeth on a Radio Shack TRS-80 and knew BASIC and Z80 machine code. 


The machine had BASIC, so that is where I started. I had spent an afternoon 
writing a hex dump program before I discovered "od". I spent the next day reading 
all the man pages. I was amazed with their simplicity and clarity. 


Having finished the man pages, I read the Unix Programmer's Manual cover to cover. 
I re-wrote the hex dump in C just for fun. I was sold. 


The remarkable simplicity of Unix, the kernel, the commands, the documentation, 
is a beautiful thing. And I was fortunate to have found it early in my career. 


It was also a time, when the manuals were concise enough to read them all 
in a few day's time. 



To put that into perspective, it took me weeks to acquire a copy of the documentation 
for IBM 2780 Bisync, and even then it left me with more questions. 


I was simply amazed to have found such an elegant system. That it came with 
documentation on every aspect of the system was almost to good to be true. 


For a young programmer starting out in the world, man pages were like gold. 


Jim 





From: "Grant Taylor via TUHS" <tuhs at minnie.tuhs.org> 
To: tuhs at minnie.tuhs.org 
Sent: Friday, November 16, 2018 1:03:37 AM 
Subject: Re: [TUHS] man-page style 

On 11/15/2018 10:32 PM, Dave Horsfall wrote: 
> The Unix manpage format is the epitome of perfection; they tell you 
> everything you need to know, and in the right order. Frequently I 
> cannot recall a particular flag (but I know what it does), and it's 
> right there at the start. 

I think man pages make a great reference. But I don't think they are a 
good teaching source for someone that doesn't know the material or what 
the components are for. 



-- 
Grant. . . . 
unix || die 

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

From ches at cheswick.com  Sat Nov 17 01:37:51 2018
From: ches at cheswick.com (WIlliam Cheswick)
Date: Fri, 16 Nov 2018 10:37:51 -0500
Subject: [TUHS] man-page style
In-Reply-To: <17703613.640.1542382385149.JavaMail.root@zimbraanteil>
References: <17703613.640.1542382385149.JavaMail.root@zimbraanteil>
Message-ID: <4829D87A-1170-4E45-8D55-1FD047CDFAA0@cheswick.com>

 I agree, and would like to add that Lorinda Cherry’s permuted index of the Unix commands was a perfect
match to those succinct man pages, easing me into the world of all those filters.



From clemc at ccc.com  Sat Nov 17 01:48:06 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Nov 2018 10:48:06 -0500
Subject: [TUHS] man-page style
In-Reply-To: <4829D87A-1170-4E45-8D55-1FD047CDFAA0@cheswick.com>
References: <17703613.640.1542382385149.JavaMail.root@zimbraanteil>
 <4829D87A-1170-4E45-8D55-1FD047CDFAA0@cheswick.com>
Message-ID: <CAC20D2O6vJ=mnXX6X4_9V52iY8R-ByJLtAkLRFNRJhLxK0rK9Q@mail.gmail.com>

+1
ᐧ

On Fri, Nov 16, 2018 at 10:44 AM WIlliam Cheswick <ches at cheswick.com> wrote:

>  I agree, and would like to add that Lorinda Cherry’s permuted index of
> the Unix commands was a perfect
> match to those succinct man pages, easing me into the world of all those
> filters.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/7e3bf0b8/attachment.html>

From paul.winalski at gmail.com  Sat Nov 17 02:55:28 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 16 Nov 2018 11:55:28 -0500
Subject: [TUHS] man-page style
In-Reply-To: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
Message-ID: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>

On 11/16/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> On 11/15/2018 10:32 PM, Dave Horsfall wrote:
>> The Unix manpage format is the epitome of perfection; they tell you
>> everything you need to know, and in the right order.  Frequently I
>> cannot recall a particular flag (but I know what it does), and it's
>> right there at the start.
>
> I think man pages make a great reference.  But I don't think they are a
> good teaching source for someone that doesn't know the material or what
> the components are for.
>
I agree with Grant.  If you want to know what a particular command
does and what its options are, man pages are fantastic.  If you are a
new or casual user trying to find out what command(s) to use to
accomplish a particular task, the man pages are an exercise in
frustration and futility.  Other OSes have done a better job in that
area (the VMS and DTSS HELP commands come to mind).  IMO ideally one
should have both--a generalized "help" command for those trying to
find out what command to use, and "man" as reference material.  UNIX
and Linux have never had a proper help facility.  Or at least I never
was able to find it.

-Paul W.


From lm at mcvoy.com  Sat Nov 17 03:13:18 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 16 Nov 2018 09:13:18 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
Message-ID: <20181116171318.GC30000@mcvoy.com>

On Fri, Nov 16, 2018 at 11:55:28AM -0500, Paul Winalski wrote:
> On 11/16/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> > On 11/15/2018 10:32 PM, Dave Horsfall wrote:
> >> The Unix manpage format is the epitome of perfection; they tell you
> >> everything you need to know, and in the right order.  Frequently I
> >> cannot recall a particular flag (but I know what it does), and it's
> >> right there at the start.
> >
> > I think man pages make a great reference.  But I don't think they are a
> > good teaching source for someone that doesn't know the material or what
> > the components are for.
> >
> I agree with Grant.  If you want to know what a particular command
> does and what its options are, man pages are fantastic.  If you are a
> new or casual user trying to find out what command(s) to use to
> accomplish a particular task, the man pages are an exercise in
> frustration and futility.  Other OSes have done a better job in that
> area (the VMS and DTSS HELP commands come to mind).  IMO ideally one
> should have both--a generalized "help" command for those trying to
> find out what command to use, and "man" as reference material.  UNIX
> and Linux have never had a proper help facility.  Or at least I never
> was able to find it.

I think there was a help at one point but it got lost.  PWB maybe?
There is still apropos which can be useful.

What helped me starting out was one of those trifold summaries of
common commands.

ls for directory listings?  Very poor choice for newbies but pleasant
once you know it is there.  Short is nice for common stuff.

I just remember a steep learning curve initially.  But you got over
it pretty quickly and then things were pleasant.  I found the Unix
docs to be great but hard to figure where things were at first. 
Once you were past that, smooth sailing.


From paul.winalski at gmail.com  Sat Nov 17 03:31:14 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Fri, 16 Nov 2018 12:31:14 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181116171318.GC30000@mcvoy.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <20181116171318.GC30000@mcvoy.com>
Message-ID: <CABH=_VT0TFOJAP+zDwhJtGb9s0kfB_7-KOMKM3fTXh2i7XrEeQ@mail.gmail.com>

On 11/16/18, Larry McVoy <lm at mcvoy.com> wrote:
>
> I think there was a help at one point but it got lost.  PWB maybe?
> There is still apropos which can be useful.
>
Except for two things:

(1) You have to know to type "apropos" in the first place.  Completely
non-obvious to the newbies who really need it.

(2) I don't know how apropos is implemented, but it appears to be a
rather simple-minded (as opposed to the DWIM-style search of Google
and its friends) textual search engine for man pages.  I never got the
hang of it.  For me it always either turned up nothing or produced
reams of hits--too big a haystack to find the needle of info I was
looking for.

Very much a stylistic thing, and a matter of taste IMO.  As you say,
the command interface to Unix has a steep learning curve, but it is a
system designed by experts for experts.

-Paul W.


From jcapp at anteil.com  Sat Nov 17 03:33:15 2018
From: jcapp at anteil.com (Jim Capp)
Date: Fri, 16 Nov 2018 12:33:15 -0500 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <20181116171318.GC30000@mcvoy.com>
Message-ID: <14895316.657.1542389595317.JavaMail.root@zimbraanteil>

>On Fri, Nov 16, 2018 at 11:55:28AM -0500, Paul Winalski wrote: 
>> On 11/16/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote: 
>> > On 11/15/2018 10:32 PM, Dave Horsfall wrote: 
>> >> The Unix manpage format is the epitome of perfection; they tell you 
>> >> everything you need to know, and in the right order. Frequently I 
>> >> cannot recall a particular flag (but I know what it does), and it's 
>> >> right there at the start. 
>> > 
>> > I think man pages make a great reference. But I don't think they are a 
>> > good teaching source for someone that doesn't know the material or what 
>> > the components are for. 
>> > 
>> I agree with Grant. If you want to know what a particular command 
>> does and what its options are, man pages are fantastic. If you are a 
>> new or casual user trying to find out what command(s) to use to 
.> accomplish a particular task, the man pages are an exercise in. 
>> frustration and futility. Other OSes have done a better job in that 
>> area (the VMS and DTSS HELP commands come to mind). IMO ideally one 
>> should have both--a generalized "help" command for those trying to 
>> find out what command to use, and "man" as reference material. UNIX 
>> and Linux have never had a proper help facility. Or at least I never 
>> was able to find it. 
> 
>I think there was a help at one point but it got lost. PWB maybe? 
>There is still apropos which can be useful. 
> 
>What helped me starting out was one of those trifold summaries of 
>common commands. 
> 
>ls for directory listings? Very poor choice for newbies but pleasant 
>once you know it is there. Short is nice for common stuff. 
> 
>I just remember a steep learning curve initially. But you got over 
>it pretty quickly and then things were pleasant. I found the Unix 
>docs to be great but hard to figure where things were at first. 
>Once you were past that, smooth sailing. 



PWB was great too, but what was most useful to me was the 
"UNIX programmer's manual" from Bell Telephone Laboratories (c) 1979, 1983 


The first volume included all the man pages, a quick reference, and an index. 


The second volume contained all the "how to" guides, including concise summaries 
of the facilities available on UNIX, the original UNIX paper from Ritchie and Thompson, 
UNIX for Beginners from Kernighan, NROFF/TROFF User's Manual, TROFF Tutorial, 
C Programming Language, Lint, Make, YACC, LEX, AWK, and on and on. 


The combination of those two volumes was invaluable. 



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

From toby at telegraphics.com.au  Sat Nov 17 03:29:13 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 16 Nov 2018 12:29:13 -0500
Subject: [TUHS] man-page style
In-Reply-To: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
Message-ID: <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>

On 2018-11-16 11:55 AM, Paul Winalski wrote:
> On 11/16/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>> On 11/15/2018 10:32 PM, Dave Horsfall wrote:
>>> The Unix manpage format is the epitome of perfection; they tell you
>>> everything you need to know, and in the right order.  Frequently I
>>> cannot recall a particular flag (but I know what it does), and it's
>>> right there at the start.
>>
>> I think man pages make a great reference.  But I don't think they are a
>> good teaching source for someone that doesn't know the material or what
>> the components are for.
>>
> I agree with Grant.  If you want to know what a particular command
> does and what its options are, man pages are fantastic.  If you are a
> new or casual user trying to find out what command(s) to use to
> accomplish a particular task, the man pages are an exercise in
> frustration and futility.  Other OSes have done a better job in that
> area (the VMS and DTSS HELP commands come to mind).  IMO ideally one
> should have both--a generalized "help" command for those trying to
> find out what command to use, and "man" as reference material.  UNIX
> and Linux have never had a proper help facility.  Or at least I never
> was able to find it.

GNU understood the difference, and wrote separate manuals (e.g. `info
bash`, `info bison`, etc).

> 
> -Paul W.
> 



From lm at mcvoy.com  Sat Nov 17 03:36:31 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 16 Nov 2018 09:36:31 -0800
Subject: [TUHS] man-page style
In-Reply-To: <14895316.657.1542389595317.JavaMail.root@zimbraanteil>
References: <20181116171318.GC30000@mcvoy.com>
 <14895316.657.1542389595317.JavaMail.root@zimbraanteil>
Message-ID: <20181116173631.GI30000@mcvoy.com>

On Fri, Nov 16, 2018 at 12:33:15PM -0500, Jim Capp wrote:
> PWB was great too, but what was most useful to me was the 
> "UNIX programmer's manual" from Bell Telephone Laboratories (c) 1979, 1983 
> 
> The first volume included all the man pages, a quick reference, and an index. 
> 
> The second volume contained all the "how to" guides, including concise summaries 
> of the facilities available on UNIX, the original UNIX paper from Ritchie and Thompson, 
> UNIX for Beginners from Kernighan, NROFF/TROFF User's Manual, TROFF Tutorial, 
> C Programming Language, Lint, Make, YACC, LEX, AWK, and on and on. 
> 
> The combination of those two volumes was invaluable. 

I still have the BSD versions of those, I think it expanded to 3 with 
a systems admin volume.  I agree, super useful.


From imp at bsdimp.com  Sat Nov 17 04:00:59 2018
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 16 Nov 2018 11:00:59 -0700
Subject: [TUHS] man-page style
In-Reply-To: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
Message-ID: <CANCZdfr4L0i+Vcb6WKASv=B1x8yibo2fBT7u9ok90KsHxOJQ1A@mail.gmail.com>

On Fri, Nov 16, 2018 at 9:56 AM Paul Winalski <paul.winalski at gmail.com>
wrote:

>  agree with Grant.  If you want to know what a particular command
> does and what its options are, man pages are fantastic.  If you are a
> new or casual user trying to find out what command(s) to use to
> accomplish a particular task, the man pages are an exercise in
> frustration and futility.  Other OSes have done a better job in that
> area (the VMS and DTSS HELP commands come to mind).  IMO ideally one
> should have both--a generalized "help" command for those trying to
> find out what command to use, and "man" as reference material.  UNIX
> and Linux have never had a proper help facility.  Or at least I never
> was able to find it.
>

I've often wanted a 'man -v' which printed a more-verbose version of the
man page, if it were available, otherwise the standard one for
less-often-used commands that are a pita learn at the start, but once you
learn you just want a quick refresher.

Pike could then do a paper 'make -v considered harmful' :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/4c5b8f25/attachment.html>

From gtaylor at tnetconsulting.net  Sat Nov 17 04:16:18 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 16 Nov 2018 11:16:18 -0700
Subject: [TUHS] man-page style
In-Reply-To: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
Message-ID: <afb27494-e2cd-784f-3cf5-08798448f42f@spamtrap.tnetconsulting.net>

On 11/16/2018 09:55 AM, Paul Winalski wrote:
> I agree with Grant.

;-)

> If you want to know what a particular command does and what its options 
> are, man pages are fantastic.

Agreed.

Though, some man pages can still feel overwhelming.  Bash and Zsh (full) 
man pages come to mind.

> If you are a new or casual user trying to find out what command(s) to 
> use to accomplish a particular task, the man pages are an exercise in 
> frustration and futility.

I tend to equate it to trying to learn to program (read: logic behind 
programming) and a given languages (read: syntax, structure, idioms, 
etc) at the same time, you're functionally dealing with two 
interconnected variables in an equation that are almost inseparable.

You almost need to learn other languages to start isolating the the 
logic from the syntax by replacing the syntax with different syntax.

IMHO it's a LOT easier to have an idea what you want to do and then find 
out how to do it than trying to do both at the same time.

> Other OSes have done a better job in that area (the VMS and DTSS HELP 
> commands come to mind).  IMO ideally one should have both--a generalized 
> "help" command for those trying to find out what command to use, and 
> "man" as reference material.  UNIX and Linux have never had a proper 
> help facility.  Or at least I never was able to find it.

I like the sound of that as I start dabbling with OpenVMS.  :-)

I've always liked to find some how-to / tutorials as a starting place to 
give broad overviews and then quickly migrate to and supplement with man 
pages to learn command specifics and behavior.  The how-to provides the 
logic and the man pages provide the syntax.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/9451ff08/attachment.bin>

From jon at fourwinds.com  Sat Nov 17 03:39:58 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 16 Nov 2018 09:39:58 -0800
Subject: [TUHS] man-page style
In-Reply-To: <20181116171318.GC30000@mcvoy.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <20181116171318.GC30000@mcvoy.com>
Message-ID: <201811161739.wAGHdw3O023003@darkstar.fourwinds.com>

Thanks Doug for accidentally starting this thread :-)

I'm a big fan of the "original-style" man pages.  Brevity was really
important when working remote and having to look things up via a
TI Silent 700 at 30 characters per second.

I feel like the GNU project is responsible for destroying the usefulness
of man pages with their "info" stuff.  Nothing more helpful than getting
a man page that says that it's not the man page and that one should look
elsewhere using a different and very clunky program.  Started the decline
of being able to find everything in one place in a consistent manner.

And just to rant, I really hate documentation that begins with how to get,
build, and install software.  I think that most folks looking at docs are
wanting to know how to use it, and having to skip over the least-important
stuff which is first is annoying, especially when one gets past it to
discover that the rest of the doc was never written.

Anyway, the sake of argument, I'm gonna postulate that the more recent,
useless man pages are a sympton of poor software design.  I'll make the
claim that the loss of the "do one thing and do it well and make it
composable" UNIX philosophy is exposed in many of the very complex
utilities with huge numbers of dash options.

Jon


From tom.manos at gmail.com  Sat Nov 17 04:47:11 2018
From: tom.manos at gmail.com (Tom Manos)
Date: Fri, 16 Nov 2018 13:47:11 -0500
Subject: [TUHS] man-page style
In-Reply-To: <4829D87A-1170-4E45-8D55-1FD047CDFAA0@cheswick.com>
References: <17703613.640.1542382385149.JavaMail.root@zimbraanteil>
 <4829D87A-1170-4E45-8D55-1FD047CDFAA0@cheswick.com>
Message-ID: <CAOs6KDdriNOsniDBWRSHebBzpkqBvD0EuHHzjckujO4Q5rM4hA@mail.gmail.com>

Unlike many of us here, I started with UNIX a bit later, at Naval
Postgraduate School, in the mid '80s. It was a relatively early BSD, and I
didn't learn it much except to know that I wanted to understand it better,
but didn't have time. Mostly I had to write C programs.

Just a bit later I had the opportunity to purchase and run Microport
SysV/AT on 286 hardware, and was an immediate convert. I continued using
Microport systems through SVR4. Like others, I found the manuals' thickness
and terseness a turn-off until I bought a book.

I think it was "Introducing the UNIX System" by Henry McGilton and Rachel
Morgan (I still have my copy). A little over 500 pages of UNIX goodness
that taught me all the basics. My experience was that once you know the
basic commands you need for day to day life in UNIX, the manuals become
very helpful. If you can work with sh, ls, awk, find, grep, ps, an editor,
and a few others, the manuals supplement that knowledge with everything
else you need. Additionally, the manuals make a little more sense each time
you read them. Of course, actually administering a UNIX system without
prior knowledge, OJT or a book, using just the manual pages, is next to
impossible.

BTW, I still run SVR4/MP here at home on period hardware. It's a joy to use.

Tom

---

On Fri, Nov 16, 2018 at 10:44 AM WIlliam Cheswick <ches at cheswick.com> wrote:

>  I agree, and would like to add that Lorinda Cherry’s permuted index of
> the Unix commands was a perfect
> match to those succinct man pages, easing me into the world of all those
> filters.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/cd4b2db2/attachment.html>

From clemc at ccc.com  Sat Nov 17 04:57:33 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Nov 2018 13:57:33 -0500
Subject: [TUHS] man-page style
In-Reply-To: <201811161739.wAGHdw3O023003@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <20181116171318.GC30000@mcvoy.com>
 <201811161739.wAGHdw3O023003@darkstar.fourwinds.com>
Message-ID: <CAC20D2NLTVK_rfmvkf8YoonErRmDYfwxj77NE1q4q2JtMnNa0g@mail.gmail.com>

On Fri, Nov 16, 2018 at 1:40 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Thanks Doug for accidentally starting this thread :-)
>
+1


> I feel like the GNU project is responsible for destroying the usefulness of
> man pages with their "info" stuff.
>
Come on Jon - don't you live in emacs all day long ;-)  .. sigh....


>  I'll make the claim that the loss of the "do one thing and do it well
> ..."

Actually I blame the VAX and larger address spaces for much of that and no
enough real teaching of what I refer to as 'good taste.'   When you had to
think about keeping it small and decomposable, you did.   My own sisters
and brothers at UCB started us down this path I fear.

Truth is, it is a tough call, learning when 'good enough' is all you need.
 When its easy to add to things to something you have, you get GNU (or cat
-v as Rob pointed out years ago or my least favorite - sendmail - there is
>>no<< reason why SMTPD was part of sendmail as an example).

I've meantion before on this list, the day I showed Dennis that fact that
the System V boot system was larger than the 6th edition kernel, you knew
we had a problem.   The argument of course is - "well look how well it
works and I can do this X" -- sorry not good enough.

In the late 70s, Mashy had a wonderful ACM lecture called 'Small is
Beautiful' and he had some excellent pictures that demonstrated the problem
visually.   I love to see him resurect that talk and try to get 'modern'
programmers try to understand his message.

That said, I admit I do like many things on my moderm MBP and I would not
want to go back to running 6th Edition, but I swear there is a happy ground
somewhere in between.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/a476d261/attachment.html>

From cym224 at gmail.com  Sat Nov 17 05:05:10 2018
From: cym224 at gmail.com (Nemo)
Date: Fri, 16 Nov 2018 14:05:10 -0500
Subject: [TUHS] man-page style
In-Reply-To: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAJfiPzw-cBeCxi5xjMGFigMLY=MMiqMShbg43hFYzxWsvyB2SA@mail.gmail.com>

On 15/11/2018, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> Sorry about the recent post. It may seem peripherally
> connected to tuhs, but it got there due to overtrained
> fingers (or overaged mind). It was intended for another list.

Nevertheless, the post was delightful.

N.

>
> Doug
>


From jnc at mercury.lcs.mit.edu  Sat Nov 17 05:29:41 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Fri, 16 Nov 2018 14:29:41 -0500 (EST)
Subject: [TUHS] man-page style
Message-ID: <20181116192941.DFB6218C073@mercury.lcs.mit.edu>

    > From: Clem Cole

    > Actually I blame the VAX and larger address spaces for much of that and
    > no enough real teaching of what I refer to as 'good taste.'  When you
    > had to think about keeping it small and decomposable, you did. ...
    > Truth is, it is a tough call, learning when 'good enough' is all you
    > need. ... The argument of course is - "well look how well it works and I
    > can do this X" -- sorry not good enough.

Exactly; the bloat in the later Unix versions killed what I feel was the
_single best thing_ about early Unix - which was its awesome, un-matched
bang/buck ratio.

_That_ is what made me such a huge fan of Unix, even though as an operating
system person, I was, and remain, a big fan of Multics (maybe the only person
in the world who really likes both :-), which I still think was a better
long-term path for OSes (long discussion of why elided to keep this short).

I mean, as an operating system, I don't find Unix that memorable; it's (until
recently) a monolithic kernel, with all that entails. Doing networking work on
it was a total PITA! When I looked across as what Dave Clark was able to do on
Multics, with its single-level memory, and layered OS, doing TCP/IP, I was
sky-blue pink with envy.

     Noel


From chet.ramey at case.edu  Sat Nov 17 05:35:16 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 16 Nov 2018 14:35:16 -0500
Subject: [TUHS] man-page style
In-Reply-To: <afb27494-e2cd-784f-3cf5-08798448f42f@spamtrap.tnetconsulting.net>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <afb27494-e2cd-784f-3cf5-08798448f42f@spamtrap.tnetconsulting.net>
Message-ID: <d421a47a-a939-46b1-3b1d-842031975619@case.edu>

On 11/16/18 1:16 PM, Grant Taylor via TUHS wrote:

> 
> Though, some man pages can still feel overwhelming.  Bash and Zsh (full)
> man pages come to mind.

You should try the POSIX standard. :-)

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From dave at horsfall.org  Sat Nov 17 06:45:49 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Nov 2018 07:45:49 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <CABH=_VT0TFOJAP+zDwhJtGb9s0kfB_7-KOMKM3fTXh2i7XrEeQ@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <20181116171318.GC30000@mcvoy.com>
 <CABH=_VT0TFOJAP+zDwhJtGb9s0kfB_7-KOMKM3fTXh2i7XrEeQ@mail.gmail.com>
Message-ID: <alpine.BSF.2.21.9999.1811170744250.60610@aneurin.horsfall.org>

On Fri, 16 Nov 2018, Paul Winalski wrote:

> (1) You have to know to type "apropos" in the first place.  Completely
> non-obvious to the newbies who really need it.

I don't think I've ever used "apropos" in my life; "man -k" works for me.

-- Dave


From gtaylor at tnetconsulting.net  Sat Nov 17 06:46:22 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 16 Nov 2018 13:46:22 -0700
Subject: [TUHS] man-page style
In-Reply-To: <20181116192941.DFB6218C073@mercury.lcs.mit.edu>
References: <20181116192941.DFB6218C073@mercury.lcs.mit.edu>
Message-ID: <590e188f-092b-afd6-ff0a-4b6db8dc0f8d@spamtrap.tnetconsulting.net>

On 11/16/2018 12:29 PM, Noel Chiappa wrote:
> _That_ is what made me such a huge fan of Unix, even though as an 
> operating system person, I was, and remain, a big fan of Multics (maybe 
> the only person in the world who really likes both :-), which I still 
> think was a better long-term path for OSes (long discussion of why elided 
> to keep this short).

Can I ask for the longer discussion?  It sounds like an enlightening 
sidebar that would be good to have over a cup of COFFee.  Maybe the 
barista on the COFF mailing list will brew you a cup to discuss this 
there.  ~wink~wink~nudge~nudge~



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/5dc2b58c/attachment.bin>

From dave at horsfall.org  Sat Nov 17 06:50:16 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Nov 2018 07:50:16 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <14895316.657.1542389595317.JavaMail.root@zimbraanteil>
References: <14895316.657.1542389595317.JavaMail.root@zimbraanteil>
Message-ID: <alpine.BSF.2.21.9999.1811170746430.60610@aneurin.horsfall.org>

On Fri, 16 Nov 2018, Jim Capp wrote:

> PWB was great too, but what was most useful to me was the "UNIX 
> programmer's manual" from Bell Telephone Laboratories (c) 1979, 1983

[...]

That sounds remarkably like the "Unix Documention" [sic] that Dr. John 
Lions had printed, way before his famous books.  The two manuals contained 
all the man pages, an intro to "ed", "roff", C etc, which is how I taught 
myself Unix and C before he started teaching it (I was originally hired to 
support RSX-11D!).

-- Dave


From gtaylor at tnetconsulting.net  Sat Nov 17 06:50:37 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 16 Nov 2018 13:50:37 -0700
Subject: [TUHS] man-page style
In-Reply-To: <d421a47a-a939-46b1-3b1d-842031975619@case.edu>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <afb27494-e2cd-784f-3cf5-08798448f42f@spamtrap.tnetconsulting.net>
 <d421a47a-a939-46b1-3b1d-842031975619@case.edu>
Message-ID: <195e8a24-4f40-5f08-5be7-9bb2e7296b62@spamtrap.tnetconsulting.net>

On 11/16/2018 12:35 PM, Chet Ramey wrote:
> You should try the POSIX standard. :-)

/me touches his nose and says "Not me!"

That being said, I'm slowly embarking on OpenVMS.  I'll see what I feel 
like after that.  Though it may have more of an overlap with POSIX than 
I realize.  Particularly if I look at DECnet phase V.  (Granted, that's 
just networking, which is a subset of POSIX.)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/fd0b5ccd/attachment.bin>

From dave at horsfall.org  Sat Nov 17 06:52:18 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Nov 2018 07:52:18 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
Message-ID: <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>

On Fri, 16 Nov 2018, Toby Thain wrote:

> GNU understood the difference, and wrote separate manuals (e.g. `info 
> bash`, `info bison`, etc).

GNU "info" is one of the most non-intuitive interfaces that I've ever had 
the displeasure to use.  Or maybe that's just me...

-- Dave


From lm at mcvoy.com  Sat Nov 17 06:55:48 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 16 Nov 2018 12:55:48 -0800
Subject: [TUHS] man-page style
In-Reply-To: <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
Message-ID: <20181116205548.GL30000@mcvoy.com>

On Sat, Nov 17, 2018 at 07:52:18AM +1100, Dave Horsfall wrote:
> On Fri, 16 Nov 2018, Toby Thain wrote:
> 
> >GNU understood the difference, and wrote separate manuals (e.g. `info
> >bash`, `info bison`, etc).
> 
> GNU "info" is one of the most non-intuitive interfaces that I've ever had
> the displeasure to use.  Or maybe that's just me...
> 
> -- Dave

It's not just you, it's anyone who prefers vi to emacs.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From chet.ramey at case.edu  Sat Nov 17 06:56:53 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Fri, 16 Nov 2018 15:56:53 -0500
Subject: [TUHS] man-page style
In-Reply-To: <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
Message-ID: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>

On 11/16/18 3:52 PM, Dave Horsfall wrote:
> On Fri, 16 Nov 2018, Toby Thain wrote:
> 
>> GNU understood the difference, and wrote separate manuals (e.g. `info
>> bash`, `info bison`, etc).
> 
> GNU "info" is one of the most non-intuitive interfaces that I've ever had
> the displeasure to use.  Or maybe that's just me...

If you don't use emacs, you won't like it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From jcapp at anteil.com  Sat Nov 17 06:59:11 2018
From: jcapp at anteil.com (Jim Capp)
Date: Fri, 16 Nov 2018 15:59:11 -0500 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
Message-ID: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>

> GNU "info" is one of the most non-intuitive interfaces that I've ever had 
> the displeasure to use. Or maybe that's just me... 

I would cringe anytime I had to use "info" ... I always wondered where it came 
from and why they didn't just stick to traditional man pages. 


Jim 

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

From jcapp at anteil.com  Sat Nov 17 07:05:41 2018
From: jcapp at anteil.com (Jim Capp)
Date: Fri, 16 Nov 2018 16:05:41 -0500 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
Message-ID: <200652.696.1542402341716.JavaMail.root@zimbraanteil>

> If you don't use emacs, you won't like it. 


Let's not start any new emacs vs. vi flame wars. 


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

From khm at sciops.net  Sat Nov 17 07:09:59 2018
From: khm at sciops.net (Kurt H Maier)
Date: Fri, 16 Nov 2018 13:09:59 -0800
Subject: [TUHS] man-page style
In-Reply-To: <200652.696.1542402341716.JavaMail.root@zimbraanteil>
References: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <200652.696.1542402341716.JavaMail.root@zimbraanteil>
Message-ID: <20181116210959.GA26307@wopr>

On Fri, Nov 16, 2018 at 04:05:41PM -0500, Jim Capp wrote:
> > If you don't use emacs, you won't like it.
>
>
> Let's not start any new emacs vs. vi flame wars.
       
Nobody said anything about vi.  emacs integration is an explicit design
parameter for GNU texinfo.  It's almost impossible to answer any
questions about its design without starting your answer by saying "well,
in emacs..."
           
khm



From toby at telegraphics.com.au  Sat Nov 17 07:24:42 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 16 Nov 2018 16:24:42 -0500
Subject: [TUHS] man-page style
In-Reply-To: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
Message-ID: <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au>

On 2018-11-16 3:59 PM, Jim Capp wrote:
>> GNU "info" is one of the most non-intuitive interfaces that I've ever had
>> the displeasure to use.  Or maybe that's just me...
> 
> I would cringe anytime I had to use "info" ... I always wondered where
> it came
> from and why they didn't just stick to traditional man pages.

Hypertext navigation, ToC, indexes. Features we expect from whole books
(the manuals) and not from reference cards.

`info` and `man` solve two different problems, regardless of one's
opinion of the interface to the former (which can be learned, it's no
more arcane than `vi`).

--T

> 
> Jim
> 



From dave at horsfall.org  Sat Nov 17 07:26:24 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Nov 2018 08:26:24 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
Message-ID: <alpine.BSF.2.21.9999.1811170824340.60610@aneurin.horsfall.org>

On Thu, 15 Nov 2018, Grant Taylor via TUHS wrote:

> I think man pages make a great reference.  But I don't think they are a 
> good teaching source for someone that doesn't know the material or what 
> the components are for.

True, but as I mentioned elsewhere we at UNSW has the advantage of a 
docset that Dr John Lions had published; I read them cover to cover and 
taught myself Unix that way.

-- Dave


From lars at nocrew.org  Sat Nov 17 07:28:47 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 16 Nov 2018 21:28:47 +0000
Subject: [TUHS] man-page style
In-Reply-To: <26292231.693.1542401951390.JavaMail.root@zimbraanteil> (Jim
 Capp's message of "Fri, 16 Nov 2018 15:59:11 -0500 (EST)")
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
Message-ID: <7w5zwwbtkg.fsf@junk.nocrew.org>

Jim Capp wrote:
> I would cringe anytime I had to use "info" ... I always wondered where
> it came from

It came from ITS.  That may explain some things.


From gtaylor at tnetconsulting.net  Sat Nov 17 07:29:16 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Fri, 16 Nov 2018 14:29:16 -0700
Subject: [TUHS] man-page style
In-Reply-To: <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au>
Message-ID: <b643972e-2ec6-7a4d-de9f-2ed3e59789a6@spamtrap.tnetconsulting.net>

On 11/16/2018 02:24 PM, Toby Thain wrote:
> `info` and `man` solve two different problems, regardless of one's 
> opinion of the interface to the former (which can be learned, it's no 
> more arcane than `vi`).

I feel like the man vs info war (IMHO it's a war) on Linux has gone too 
far.  Far enough that there are some tools that have between woefully 
inadequate man pages to missing man pages in favor of info documentation.

It's worse than solving different problems.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/6224cf45/attachment.bin>

From toby at telegraphics.com.au  Sat Nov 17 07:35:32 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Fri, 16 Nov 2018 16:35:32 -0500
Subject: [TUHS] man-page style
In-Reply-To: <b643972e-2ec6-7a4d-de9f-2ed3e59789a6@spamtrap.tnetconsulting.net>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au>
 <b643972e-2ec6-7a4d-de9f-2ed3e59789a6@spamtrap.tnetconsulting.net>
Message-ID: <1c88a059-5a40-c084-9b78-c5b2139e1b37@telegraphics.com.au>

On 2018-11-16 4:29 PM, Grant Taylor via TUHS wrote:
> On 11/16/2018 02:24 PM, Toby Thain wrote:
>> `info` and `man` solve two different problems, regardless of one's
>> opinion of the interface to the former (which can be learned, it's no
>> more arcane than `vi`).
> 
> I feel like the man vs info war (IMHO it's a war) on Linux has gone too
> far.  Far enough that there are some tools that have between woefully
> inadequate man pages to missing man pages in favor of info documentation.

So you might be glad that Apple seems to have stopped shipping `info`
manuals for the tools that have them :-)

Progress, eh?

> 
> It's worse than solving different problems.
> 
> 
> 



From dave at horsfall.org  Sat Nov 17 07:37:49 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 17 Nov 2018 08:37:49 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
Message-ID: <alpine.BSF.2.21.9999.1811170835110.60610@aneurin.horsfall.org>

On Fri, 16 Nov 2018, Jim Capp wrote:

> I would cringe anytime I had to use "info" ... I always wondered where 
> it camefrom and why they didn't just stick to traditional man pages.

I understand it's because John Gilmore has some sort of an aversion to 
nroff; he is quoted somewhere as "The GNU project does not use nroff" (not 
"free" enough for his delicate sensibilities, maybe?).

-- Dave


From jon at fourwinds.com  Sat Nov 17 07:13:16 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Fri, 16 Nov 2018 13:13:16 -0800
Subject: [TUHS] man-page style
In-Reply-To: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
Message-ID: <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>

Chet Ramey writes:
> On 11/16/18 3:52 PM, Dave Horsfall wrote:
> > On Fri, 16 Nov 2018, Toby Thain wrote:
> > 
> >> GNU understood the difference, and wrote separate manuals (e.g. `info
> >> bash`, `info bison`, etc).
> > 
> > GNU "info" is one of the most non-intuitive interfaces that I've ever had
> > the displeasure to use.  Or maybe that's just me...
>
> If you don't use emacs, you won't like it.

Well, not wanting to start a flame war here, but I don't use emacs.  While
it's a good piece of software, I just want a text editor.  Emacs sort of
violates my UNIX-sense as it does many things instead of doing one thing
well.

But really the issue is that info introduced a new interface on a system
that already had one that people were accustomed to.  This is something
that perpetually annoys me in the software world; people introducing new
ways of doing things that aren't improvements, just different.  Just makes
life harder for everyone else.

As an example, I recently did a deep dive trying to figure out why promises
were added to JavaScript.  Actually has nothing to do with the first
10000000000 search results.  They were done for a particular reason that I
don't agree with but were an excuse for someone to force their preferred
coding style on others.  And the details are not a topic for this list.

Jon


From emu at e-bbes.com  Sat Nov 17 07:12:06 2018
From: emu at e-bbes.com (emanuel stiebler)
Date: Fri, 16 Nov 2018 16:12:06 -0500
Subject: [TUHS] man-page style
In-Reply-To: <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
Message-ID: <51ac4ab6-df97-144d-c7c8-b9cb081d2b93@e-bbes.com>

On 2018-11-16 15:52, Dave Horsfall wrote:
> On Fri, 16 Nov 2018, Toby Thain wrote:

> GNU "info" is one of the most non-intuitive interfaces that I've ever
> had the displeasure to use.  Or maybe that's just me...

It isn't only you. If I don't find a "man" page for it, then I just
google ...


From clemc at ccc.com  Sat Nov 17 08:24:35 2018
From: clemc at ccc.com (Clem Cole)
Date: Fri, 16 Nov 2018 17:24:35 -0500
Subject: [TUHS] man-page style
In-Reply-To: <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
Message-ID: <CAC20D2O2Q7kM+AEobt7P2pbA1JidRBp_xW-1Xwdm4mSdNfL=pQ@mail.gmail.com>

On Fri, Nov 16, 2018 at 4:40 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Emacs sort of violates my UNIX-sense as it does many things instead of
> doing one thing well.
>
Exactly -- the idea is emacs is its own 'system' and you need to view the
world through it.

The funny thing is I had learned emacs >>before<< ed when I was PDP-10
hacking (i.e when it was a set of TECO macros).  But ed for UNIX, was what
we had and I learned it.   It got the job done.  I was happy.    When emacs
later appeared on UNIX, it really was not any better than what I had.. I
could use both, but I quickly discovered I did not want to be inside of
emacs all the time on UNIX (too slow and cranky).  Since I followed the old
UNIX rule of 'type of the cshell and program the bourne'   -- I was
unwilling to give into the emacs way, it made no sense to me to continue.
I'm happy for those that like it and hey to each her/his own.

As was discussed a few days ago in the ed/qed history -- ed was fine.  And
UNIX was SO much faster than the PDP-10s to do almost anything I wanted to
do.   And, when 'fred' and other video front ends for ed appeared, they
made perfect sense - they were just ed with some way to move the 'soft'
cursor since it was video not paper.  They too were fast and simple.  Which
really was no different than the vi subcommand for ex, when it came along
(FWIW: fred was the Cornell video front end for ed that I first saw on 6th
edition I think, although it might have been 5th edition.   Fred was 'hard
coded' for the few terminals we had - DEC vt52, PE 'fox, and the Lear
Siegler ADM3A').  I switched to vi later really because of termcap and ease
of adding terminal support.

But really the issue is that info introduced a new interface on a system
> that already had one that people were accustomed to.  This is something
> that perpetually annoys me in the software world; people introducing new
> ways of doing things that aren't improvements, just different.  Just makes
> life harder for everyone else.
>
The rule of 'least astonishment' -- instead of making UNIX like ITS or
whatever, 'info' seems like it is trying to force a new world on to someone
because that programmer likes some other way bettter. i.e.
https://xkcd.com/927/

I would not have minded having the 'info' interface so much if Gnu had kept
'man' as the high order bit and created the 'info' pages by 'mining' the
man ones -- *i.e.* offering a second interface to the same information.
But instead, they tried to force people to use 'info' instead of man and
left the rela information out of man - trying to force you to their
perfered interface.   The believe that under the rule of 'Gnu is not Unix'
- rms felt licensed to do so.  Except the Gnu >>team<< cloned the UNIX
interface and all of the UNIX tools - hence violating the rule of least
astonishment.

I think this is not a lot different than saying since Gnu is not Unix, we
want a different (better) interface and we will not use read/write -- in
Gnu we will have open/close/mmap ---  just think what what have happenned.
 Not saying it might not have been 'better' but it would not have been
'Unix' -- same 'license' - Gnu is Not Unix -- but code would not have
worked.    So instead rms tries to force a new human interface and guess
what, you have to reprogram a lot of people.

Clem
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/f9d9b63d/attachment.html>

From bakul at bitblocks.com  Sat Nov 17 08:25:56 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 16 Nov 2018 14:25:56 -0800
Subject: [TUHS] man-page style
In-Reply-To: Your message of "Fri, 16 Nov 2018 11:55:28 -0500."
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
Message-ID: <20181116222603.A8363156E40C@mail.bitblocks.com>

On Fri, 16 Nov 2018 11:55:28 -0500 Paul Winalski <paul.winalski at gmail.com> wrote:
> On 11/16/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
> >
> > I think man pages make a great reference.  But I don't think they are a
> > good teaching source for someone that doesn't know the material or what
> > the components are for.
> >
> I agree with Grant.  If you want to know what a particular command
> does and what its options are, man pages are fantastic.  If you are a
> new or casual user trying to find out what command(s) to use to
> accomplish a particular task, the man pages are an exercise in
> frustration and futility.  

When I first came to Unix, I read man pages for every one of
the commands in /bin and experimented with them and tried out
various options. Being a fan of recursion the first thing I
tried was "man man"!  Then I went through all the man pages in
other section to learn about libc functions, special devices
and so on.  I knew about "apropos" (though don't recall if it
was in v7) but I didn't really use it all that much.  Or the
inverted index.

I tend to think software has more in common with carpentry
than science or engineering and like all good craftsman,
knowing how to use all the tools in your workshop is
essential. If you get lucky you get to be an apprentice to a
good mentor but I didn't have that luxury in a startup.

>                            Other OSes have done a better job in that
> area (the VMS and DTSS HELP commands come to mind).  IMO ideally one
> should have both--a generalized "help" command for those trying to
> find out what command to use, and "man" as reference material.  UNIX
> and Linux have never had a proper help facility.  Or at least I never
> was able to find it.

I had usd VMS befoe Unix. Not for long but I don't recall its
help facility being particularly superior.

Each of us learns differently so there is no one true style.


From steve at quintile.net  Sat Nov 17 06:04:47 2018
From: steve at quintile.net (Steve Simon)
Date: Fri, 16 Nov 2018 20:04:47 +0000
Subject: [TUHS] TUHS Digest, Vol 36, Issue 21
In-Reply-To: <mailman.3.1542333602.25720.tuhs@minnie.tuhs.org>
References: <mailman.3.1542333602.25720.tuhs@minnie.tuhs.org>
Message-ID: <CD862992-6A0E-4BCA-986F-F3127C8DD18E@quintile.net>


re: learning unix

i started using Mike Lesk’s learn(1).

-Steve





From earl.baugh at gmail.com  Sat Nov 17 10:25:09 2018
From: earl.baugh at gmail.com (Earl Baugh)
Date: Fri, 16 Nov 2018 19:25:09 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181116222603.A8363156E40C@mail.bitblocks.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <20181116222603.A8363156E40C@mail.bitblocks.com>
Message-ID: <7006C2DA-5945-49D4-A264-050034A4FEAB@gmail.com>

I started on Unix in the ‘80’s and it was to help out a friend with adding waves to a ray tracing system he was building. I knew C at the time... my friend gave me like 5 vi commands and sat me down in front of the terminal with a visual bell. (Luckily I don’t have epilepsy or all that flashing would have had me in seizures :-) )

After answering about 30 questions about library calls available, he taught me the most useful thing I ever learned for Unix. “man -k | grep <word>”.  From there on out, I was on my own and completely equipped to learn all I needed. 

As a side note, when I saw Google fir the first time, I said “oh, man -k | grep for the web....”

Earl 


> On Nov 16, 2018, at 5:25 PM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
>> On Fri, 16 Nov 2018 11:55:28 -0500 Paul Winalski <paul.winalski at gmail.com> wrote:
>>> On 11/16/18, Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:
>>> 
>>> I think man pages make a great reference.  But I don't think they are a
>>> good teaching source for someone that doesn't know the material or what
>>> the components are for.
>>> 
>> I agree with Grant.  If you want to know what a particular command
>> does and what its options are, man pages are fantastic.  If you are a
>> new or casual user trying to find out what command(s) to use to
>> accomplish a particular task, the man pages are an exercise in
>> frustration and futility.  
> 
> When I first came to Unix, I read man pages for every one of
> the commands in /bin and experimented with them and tried out
> various options. Being a fan of recursion the first thing I
> tried was "man man"!  Then I went through all the man pages in
> other section to learn about libc functions, special devices
> and so on.  I knew about "apropos" (though don't recall if it
> was in v7) but I didn't really use it all that much.  Or the
> inverted index.
> 
> I tend to think software has more in common with carpentry
> than science or engineering and like all good craftsman,
> knowing how to use all the tools in your workshop is
> essential. If you get lucky you get to be an apprentice to a
> good mentor but I didn't have that luxury in a startup.
> 
>>                           Other OSes have done a better job in that
>> area (the VMS and DTSS HELP commands come to mind).  IMO ideally one
>> should have both--a generalized "help" command for those trying to
>> find out what command to use, and "man" as reference material.  UNIX
>> and Linux have never had a proper help facility.  Or at least I never
>> was able to find it.
> 
> I had usd VMS befoe Unix. Not for long but I don't recall its
> help facility being particularly superior.
> 
> Each of us learns differently so there is no one true style.


From akosela at andykosela.com  Sat Nov 17 13:29:24 2018
From: akosela at andykosela.com (Andy Kosela)
Date: Fri, 16 Nov 2018 21:29:24 -0600
Subject: [TUHS] man-page style
In-Reply-To: <17703613.640.1542382385149.JavaMail.root@zimbraanteil>
References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <17703613.640.1542382385149.JavaMail.root@zimbraanteil>
Message-ID: <CALMnNGjX5wG5eG3sPiYQc5JTf4uzHAJybYDacHfbf_UtB5F9Mg@mail.gmail.com>

On Friday, November 16, 2018, Jim Capp <jcapp at anteil.com> wrote:

> It was man pages that first caught my eye, placing me on a life-long path
> of working
> with Unix and its derivatives.
>
> I was working on a project for a telephone company, converting IBM 2780
> Bisync to
> async, and was given a manual and root access to a Xenix machine.  I had
> cut my
> teeth on a Radio Shack TRS-80 and knew BASIC and Z80 machine code.
>
> The machine had BASIC, so that is where I started.  I had spent an
> afternoon
> writing a hex dump program before I discovered "od".  I spent the next day
> reading
> all the man pages.  I was amazed with their simplicity and clarity.
>
> Having finished the man pages, I read the Unix Programmer's Manual cover to
> cover.
> I re-wrote the hex dump in C just for fun.  I was sold.
>
> The remarkable simplicity of Unix, the kernel, the commands, the
> documentation,
> is a beautiful thing.  And I was fortunate to have found it early in my
> career.
>
> It was also a time, when the manuals were concise enough to read them all
> in a few day's time.
>
>
Yup.  Things were much more simple at that time.  Now try to do the same
with modern "Unix": more than 15 millions lines of code in Linux, more than
10 millions in FreeBSD, some man pages are literally pages and pages of
bizarre options, and userland is just a complicated mess of hundreds of
commands that you never used in your entire life... Add some spice in the
form of systemd and you got the modern "Unix".

Enjoy programming in such a "simple" and "concise" environment now...

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181116/6394f7a5/attachment.html>

From lars at nocrew.org  Sat Nov 17 17:50:16 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 17 Nov 2018 07:50:16 +0000
Subject: [TUHS] man-page style
In-Reply-To: <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> (Jon
 Steinhart's message of "Fri, 16 Nov 2018 13:13:16 -0800")
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
Message-ID: <7wpnv49m87.fsf@junk.nocrew.org>

Jon Steinhart wrote:
> Emacs sort of violates my UNIX-sense as it does many things instead of
> doing one thing well.

It probably should!  Emacs is very much divorced from the Unix
philosopy.  However, it's perfectly in synch with how things are done in
ITS.  I'd like to argue that if you use Emacs, you're actually using a
piece of ITS.

Clem Cole:
> Exactly -- the idea is emacs is its own 'system' and you need to view
> the world through it.

Yes, much like a Lisp machine.  Stallman worked on ITS and Lisp machines
before developing GNU Emacs (from Gosling's version), and it clearly
shows.

I happen to like ITS and Lisp, so Emacs is a perfect fit for me.


From lars at nocrew.org  Sat Nov 17 23:10:40 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 17 Nov 2018 13:10:40 +0000
Subject: [TUHS] Chaosnet for 4.1BSD
Message-ID: <7wh8gfalyn.fsf@junk.nocrew.org>

Hello,

For your information (and to reduce my guilt for posting off topic
sometimes), I have 4.1BSD running with Chaosnet patches from MIT.  I'm
adding a Unibus CH11 network interface to SIMH.  It's not working fully
yet, but it's close.

Best regards,
Lars Brinkhoff


From Caipenghui_c at 163.com  Sat Nov 17 23:34:10 2018
From: Caipenghui_c at 163.com (Caipenghui)
Date: Sat, 17 Nov 2018 13:34:10 +0000
Subject: [TUHS] C game
Message-ID: <E73DEF7C-6E18-4096-A31B-D5DA7B39F789@163.com>

Hello, everyone:

Recommend a few c language to write on the computer that do not have a network, best can compile to run with GCC. This will kill my time. I like to play with greedy snake written in c language, which is really interesting. Thank you very much!

Caipenghui
Nov 17, 2018



From jnc at mercury.lcs.mit.edu  Sun Nov 18 01:39:19 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sat, 17 Nov 2018 10:39:19 -0500 (EST)
Subject: [TUHS] man-page style
Message-ID: <20181117153919.6468B18C073@mercury.lcs.mit.edu>

    > From: Lars Brinkhoff

    > Emacs is very much divorced from the Unix philosopy. However, it's
    > perfectly in synch with how things are done in ITS.

Hmm. It is complicated, but... the vast majority of my keystrokes are typed
into Epsilon (a wonderful, small, fast EMACS-type editor for Windows, etc
which one can customize in C) - especially since I started, very early on (V6)
to run my shell in an EMACS window, so I could edit commands, and thus I was
pretty much always typing to EMACS. So, it makes sense to me to have it be
powerful - albeit potentially a bit complex.

I say 'potentially' because one could after all restrict oneself to the 4
basic motion commands, and 'delete character'; you don't have to learn what
CRTL-ALT-SHIFT-Q does.

    > Stallman .. developing GNU Emacs (from Gosling's version)

Err, I'm not sure how much influence Gosling's was. He had, after all, done
the original EMACS on ITS; I got the impression he just set off on his own
path to do GNU Emacs. (Why else would it be implemented in LISP? :-).

	Noel


From lars at nocrew.org  Sun Nov 18 01:40:53 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sat, 17 Nov 2018 15:40:53 +0000
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
 (jsteve@superglobalmegacorp.com's message of "Sat, 17 Nov 2018
 21:41:05 +0800")
References: <7wh8gfalyn.fsf@junk.nocrew.org>
 <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
Message-ID: <7wbm6naf0a.fsf@junk.nocrew.org>

jsteve at superglobalmegacorp.com writes:
> Please post updates as you go!!!

Sure, at least it's both historical and Unix.

The CH11 device is for all SIMH Unibus computers, so VAX, PDP-11, and
PDP-10 (KS1).  There supposedly were patches for PDP-11 Unix too, but I
haven't seen them so far.

> I'm always interested in obsolete dead ends like this !

Why oh why is there such a high correlation between archaic obsolete
systems and sheer hacking joy?  I'm just dying to have MagicSix on
Chaosnet, but it's not to be.


From lm at mcvoy.com  Sun Nov 18 02:41:41 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 17 Nov 2018 08:41:41 -0800
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <7wbm6naf0a.fsf@junk.nocrew.org>
References: <7wh8gfalyn.fsf@junk.nocrew.org>
 <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
 <7wbm6naf0a.fsf@junk.nocrew.org>
Message-ID: <20181117164141.GF5875@mcvoy.com>

On Sat, Nov 17, 2018 at 03:40:53PM +0000, Lars Brinkhoff wrote:
> Why oh why is there such a high correlation between archaic obsolete
> systems and sheer hacking joy?  

I'm not doing that hacking, too old and burnt out, but for those who
still have some juice left my guess is it is fun because the older
systems were pretty simple.  A kernel and a few well known device
drivers is not a lot of code (the millions of lines of Linux kernel
code is almost all drivers).


From mparson at bl.org  Sun Nov 18 00:49:14 2018
From: mparson at bl.org (Michael Parson)
Date: Sat, 17 Nov 2018 08:49:14 -0600
Subject: [TUHS] man-page style
In-Reply-To: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
Message-ID: <bdc303a0bec5c53b437be107895c6d06@bl.org>



On 2018-11-16 14:56, Chet Ramey wrote:
> On 11/16/18 3:52 PM, Dave Horsfall wrote:
>> On Fri, 16 Nov 2018, Toby Thain wrote:
>> 
>>> GNU understood the difference, and wrote separate manuals (e.g. `info
>>> bash`, `info bison`, etc).
>> 
>> GNU "info" is one of the most non-intuitive interfaces that I've ever 
>> had
>> the displeasure to use.  Or maybe that's just me...
> 
> If you don't use emacs, you won't like it.

I don't like gnu info, but when I do need to read those docs, I use 
pinfo instead, which is more like using lynx to read basic hypertext 
docs.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From arnold at skeeve.com  Sun Nov 18 04:14:53 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 17 Nov 2018 11:14:53 -0700
Subject: [TUHS] man-page style
In-Reply-To: <20181116045016.GK3341@mcvoy.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
Message-ID: <201811171814.wAHIErpp025616@freefriends.org>

Larry McVoy <lm at mcvoy.com> wrote:

> From my quotes page:
>
> How good is good enough: documentation
>
>     Looking at Sun man pages versus Linux man pages is like looking at a Van
>     Gogh or Monet after studying the work of the high school football player
>     taking art as an "easy" elective. 
>
> Amy Graf, BitMover 

The man page authors / tech writers at Sun were paid to write man
pages, and learned / were taught how to do it well. The Linux stuff is
done by volunteers.  You're comparing apples and oranges.

Arnold


From arnold at skeeve.com  Sun Nov 18 04:16:06 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 17 Nov 2018 11:16:06 -0700
Subject: [TUHS] man-page style
In-Reply-To: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
Message-ID: <201811171816.wAHIG6gJ025678@freefriends.org>

Grant Taylor via TUHS <tuhs at minnie.tuhs.org> wrote:

> On 11/15/2018 10:32 PM, Dave Horsfall wrote:
> > The Unix manpage format is the epitome of perfection; they tell you 
> > everything you need to know, and in the right order.?? Frequently I 
> > cannot recall a particular flag (but I know what it does), and it's 
> > right there at the start.
>
> I think man pages make a great reference.  But I don't think they are a 
> good teaching source for someone that doesn't know the material or what 
> the components are for.

Indeed, the latter was the point of the famed 2nd volume of the Unix
programmer's manual.  The shame is that it was not propogated into
most of the Unix descendants as the man pages were.

Arnold


From gtaylor at tnetconsulting.net  Sun Nov 18 04:21:00 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Sat, 17 Nov 2018 11:21:00 -0700
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <7wbm6naf0a.fsf@junk.nocrew.org>
References: <7wh8gfalyn.fsf@junk.nocrew.org>
 <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
 <7wbm6naf0a.fsf@junk.nocrew.org>
Message-ID: <d1d1c907-39fe-c5e7-a383-c8bbf5f2136c@spamtrap.tnetconsulting.net>

On 11/17/2018 08:40 AM, Lars Brinkhoff wrote:
> Why oh why is there such a high correlation between archaic obsolete 
> systems and sheer hacking joy?  I'm just dying to have MagicSix on 
> Chaosnet, but it's not to be.

I think it has something to do with wanting to verses needing to (for 
one reason or another).

I've always found it easier to help someone else solve their problem 
than it is to solve the same problem for myself.  I attributed that to 
the desire vs need.  Maybe the attribution should be more to the company 
than the singularity.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181117/f345f269/attachment.bin>

From khm at sciops.net  Sun Nov 18 04:21:08 2018
From: khm at sciops.net (Kurt H Maier)
Date: Sat, 17 Nov 2018 10:21:08 -0800
Subject: [TUHS] man-page style
In-Reply-To: <201811171814.wAHIErpp025616@freefriends.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <201811171814.wAHIErpp025616@freefriends.org>
Message-ID: <20181117182108.GA15914@wopr>

On Sat, Nov 17, 2018 at 11:14:53AM -0700, arnold at skeeve.com wrote:
>
> The man page authors / tech writers at Sun were paid to write man
> pages, and learned / were taught how to do it well. The Linux stuff is
> done by volunteers.  You're comparing apples and oranges.
        
How do we kill this meme?  Linux is open to contribution by volunteers
but the overwhelming majority of the work done on the OS for *at least*
the last ten years has been by professionals who are paid to work on
Linux.  Pretending otherwise is disingenuous, and anyway I'm not sure
why the OS that powers pacemakers and self-driving car research gets to
be held to a lower standard.
       
khm


From arnold at skeeve.com  Sun Nov 18 05:42:15 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sat, 17 Nov 2018 12:42:15 -0700
Subject: [TUHS] man-page style
In-Reply-To: <20181117182108.GA15914@wopr>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <201811171814.wAHIErpp025616@freefriends.org>
 <20181117182108.GA15914@wopr>
Message-ID: <201811171942.wAHJgFBm029182@freefriends.org>

Kurt H Maier <khm at sciops.net> wrote:

> On Sat, Nov 17, 2018 at 11:14:53AM -0700, arnold at skeeve.com wrote:
> >
> > The man page authors / tech writers at Sun were paid to write man
> > pages, and learned / were taught how to do it well. The Linux stuff is
> > done by volunteers.  You're comparing apples and oranges.
>         
> How do we kill this meme?  Linux is open to contribution by volunteers
> but the overwhelming majority of the work done on the OS for *at least*
> the last ten years has been by professionals who are paid to work on
> Linux.

Is this true of the user land as well?  Maybe gcc, gdb and glibc, but most
of the day-to-day standard Unix commands are volunteer-maintained.

> I'm not sure why the OS that powers pacemakers and self-driving car
> research gets to be held to a lower standard.

A valid point.


From noel.hunt at gmail.com  Sun Nov 18 06:02:27 2018
From: noel.hunt at gmail.com (Noel Hunt)
Date: Sun, 18 Nov 2018 07:02:27 +1100
Subject: [TUHS] man-page style
In-Reply-To: <20181117182108.GA15914@wopr>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <201811171814.wAHIErpp025616@freefriends.org>
 <20181117182108.GA15914@wopr>
Message-ID: <CAGfO01ygn7TtAtDxPpenCsnc6sK=5vFpYTuORMTP_-niSjkoZg@mail.gmail.com>

Surely then, your remarks are a more damning
assessment of the Linux manuals, in that the
terrible state of the documentation is now a
result of 'professionals'.


On Sun, Nov 18, 2018 at 5:21 AM Kurt H Maier <khm at sciops.net> wrote:

> On Sat, Nov 17, 2018 at 11:14:53AM -0700, arnold at skeeve.com wrote:
> >
> > The man page authors / tech writers at Sun were paid to write man
> > pages, and learned / were taught how to do it well. The Linux stuff is
> > done by volunteers.  You're comparing apples and oranges.
>
> How do we kill this meme?  Linux is open to contribution by volunteers
> but the overwhelming majority of the work done on the OS for *at least*
> the last ten years has been by professionals who are paid to work on
> Linux.  Pretending otherwise is disingenuous, and anyway I'm not sure
> why the OS that powers pacemakers and self-driving car research gets to
> be held to a lower standard.
>
> khm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181118/1dda5901/attachment.html>

From tytso at mit.edu  Sun Nov 18 06:36:02 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sat, 17 Nov 2018 15:36:02 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181117182108.GA15914@wopr>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <201811171814.wAHIErpp025616@freefriends.org>
 <20181117182108.GA15914@wopr>
Message-ID: <20181117203602.GA32299@thunk.org>

On Sat, Nov 17, 2018 at 10:21:08AM -0800, Kurt H Maier wrote:
> On Sat, Nov 17, 2018 at 11:14:53AM -0700, arnold at skeeve.com wrote:
> >
> > The man page authors / tech writers at Sun were paid to write man
> > pages, and learned / were taught how to do it well. The Linux stuff is
> > done by volunteers.  You're comparing apples and oranges.
>         
> How do we kill this meme?  Linux is open to contribution by volunteers
> but the overwhelming majority of the work done on the OS for *at least*
> the last ten years has been by professionals who are paid to work on
> Linux.

This is true.  Alas, very few of these professionals are technical
writers.  The business model and incentives are different, furthermore
resources such as StackExchange don't exist tend to disincentivize
companies from investing in tech writers --- with notable exceptions
being documentation specific to Red Hat, SuSE, etc.

With commercial products that have competition, prospective customers
can say, "SunOS documentation isn't sufficiently thorough!  I'm
switching to VMS so I can have that wall of three ring binders" :-)

Without that competition, companies are less incentivized to divert
resources to luxuries like documentation --- and the commoditization
of Unix-like systems has reduced the available resources that
companies have available when they are trying to make budgeting
decisions.

(Although I will say, speaking of budgeting decisions, the amount of
human resources I've sent consumed in IBM Fall Plan and Spring Re-Plan
would, if converted from managers and senior engineers to tech
writers, be enough for a truly awesome amount of documentation.  My
condolences to my friends at Red Hat who will soon be getting to
enjoy the wonders of IBM corporate processes.  :-)

	      	     	       	       - Ted


From dave at horsfall.org  Sun Nov 18 07:07:29 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Sun, 18 Nov 2018 08:07:29 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <bdc303a0bec5c53b437be107895c6d06@bl.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <bdc303a0bec5c53b437be107895c6d06@bl.org>
Message-ID: <alpine.BSF.2.21.9999.1811180804130.60610@aneurin.horsfall.org>

On Sat, 17 Nov 2018, Michael Parson wrote:

> I don't like gnu info, but when I do need to read those docs, I use 
> pinfo instead, which is more like using lynx to read basic hypertext 
> docs.

Wow - just what I need!  Thanks.

BTW, I tried "[p]info info" on a Penguin box, and got basically the 
manpage...

-- Dave (VK2KFU)


From wkt at tuhs.org  Sun Nov 18 08:00:17 2018
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 18 Nov 2018 08:00:17 +1000
Subject: [TUHS] C game
In-Reply-To: <E73DEF7C-6E18-4096-A31B-D5DA7B39F789@163.com>
References: <E73DEF7C-6E18-4096-A31B-D5DA7B39F789@163.com>
Message-ID: <20181117220017.GA16015@minnie.tuhs.org>

On Sat, Nov 17, 2018 at 01:34:10PM +0000, Caipenghui wrote:
> Hello, everyone:
> 
> Recommend a few c language to write on the computer that do not have a network, best can compile to run with GCC. This will kill my time. I like to play with greedy snake written in c language, which is really interesting. Thank you very much!

A meta-game would be to read through the C programs at
https://www.ioccc.org/
and try to deduce how they work :-)

Cheers, Warren


From ralph at inputplus.co.uk  Sun Nov 18 09:38:32 2018
From: ralph at inputplus.co.uk (Ralph Corderoy)
Date: Sat, 17 Nov 2018 23:38:32 +0000
Subject: [TUHS] man-page style
In-Reply-To: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
Message-ID: <20181117233832.9E28A215C0@orac.inputplus.co.uk>

Hi Jim,

> > GNU "info" is one of the most non-intuitive interfaces that I've
> > ever had the displeasure to use. Or maybe that's just me... 
>
> I would cringe anytime I had to use "info" ... I always wondered where
> it came from

>From somewhere that didn't fit in well with Unix.
Its saving grace is piping info(1) made it just dump all the text,
skipping its UI, e.g.  `info gcc | less'.  Because it used to print
formatting progress to stderr!?, it used to need less's `G' then `g' to
skip to the end, getting all the formatting work out of the way, and
then back to the start to redraw the screen, dumping the stderr.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy


From mutiny.mutiny at india.com  Sun Nov 18 10:31:11 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Sun, 18 Nov 2018 00:31:11 +0000 (UTC)
Subject: [TUHS] man-page style
In-Reply-To: <20181117233832.9E28A215C0@orac.inputplus.co.uk>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>,
 <20181117233832.9E28A215C0@orac.inputplus.co.uk>
Message-ID: <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>



At 17 Nov 2018 23:39:45 +0000 (+00:00) from Ralph Corderoy <ralph at inputplus.co.uk>:
> 
> From somewhere that didn't fit in well with Unix.
its based on TekInfo, whereas 'Tek' allegedly refers to the anachronistic Tape Editor and Corrector, developed by a student (Dan Murphy) in 1964 on a PDP-1 without a operation system. According to the myth TekInfo was build on top of the Tape Editor, and finally made it on *NIX.

'Info' really doesn't fit in well with Unix. Its alien and another failed approach. Almost all 'GNU' man pages state, that the 'full' documentation is only available via 'info'. In real 99% of all 'info' requests  result in 'info' processing a man page. Thus its redundant and should be removed from all *NIX systems. Even in emacs some progressive developers recommend to replace 'info' by html or something else modern.


From tytso at mit.edu  Sun Nov 18 10:40:20 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Sat, 17 Nov 2018 19:40:20 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181117233832.9E28A215C0@orac.inputplus.co.uk>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <20181117233832.9E28A215C0@orac.inputplus.co.uk>
Message-ID: <20181118004020.GC32299@thunk.org>

On Sat, Nov 17, 2018 at 11:38:32PM +0000, Ralph Corderoy wrote:
> 
> From somewhere that didn't fit in well with Unix.
> Its saving grace is piping info(1) made it just dump all the text,
> skipping its UI, e.g.  `info gcc | less'.  Because it used to print
> formatting progress to stderr!?, it used to need less's `G' then `g' to
> skip to the end, getting all the formatting work out of the way, and
> then back to the start to redraw the screen, dumping the stderr.

There is a place for quick reference guides, and a place for a
full-fledged manual, and very often both are available.  So people who
are comparing, unfavorably, man pages and info files, are really
comparing apples and oranges.  (Or perhaps, just enjoy trying to tell
info files to get off their lawn.  :-)

If you think the *contents* of the info file are terrible, then
presumably you would also object to BSD's Programmer's Supplementary
Documents (PSD), User Supplmenetary Documents (USD), or System
Manager's Manual (SMM).

And if it's just that you hate hypertext, that's just the formatting,
and it's quite possible to convert the formatting into your choice of
text, PDF, HTML, ePub, etc.  You can take the source file for the info
file, called the texinfo file, and process it using TeX to generate a
dead-tree version of the file.  Or you can convert the texinfo file to
HTML, for thsoe who like browsers.  Or further convert the HTML to
ePub and then you can read it in your favorite eBook reader.

Cheers,

					- Ted


From toby at telegraphics.com.au  Sun Nov 18 13:00:45 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Sat, 17 Nov 2018 22:00:45 -0500
Subject: [TUHS] man-page style
In-Reply-To: <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <20181117233832.9E28A215C0@orac.inputplus.co.uk>
 <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>
Message-ID: <15c4f386-85b0-3b5f-625c-e3bda1506d96@telegraphics.com.au>

On 2018-11-17 7:31 PM, Donald ODona wrote:
> 
> 
> At 17 Nov 2018 23:39:45 +0000 (+00:00) from Ralph Corderoy <ralph at inputplus.co.uk>:
>>
>> From somewhere that didn't fit in well with Unix.
> its based on TekInfo, whereas 'Tek' allegedly refers to the anachronistic Tape Editor and Corrector, developed by a student (Dan Murphy) in 1964 on a PDP-1 without a operation system. According to the myth TekInfo was build on top of the Tape Editor, and finally made it on *NIX.
> 
> 'Info' really doesn't fit in well with Unix. Its alien and another failed approach. Almost all 'GNU' man pages state, that the 'full' documentation is only available via 'info'. In real 99% of all 'info' requests  result in 'info' processing a man page.


In many notable examples, that is not true: e.g. GNU make, bash or bison
come quickly to mind. You can't fully learn how to use tools like these
from the abbreviated man page; for one thing, the man page only mentions
a fraction of the features.

`info` provides a comprehensive, well written manual and tutorial for
these tools. If you haven't seen them, have a good look. Removing `info`
would leave them only partially documented and without tutorials.

--Toby


 Thus its redundant and should be removed from all *NIX systems. Even in
emacs some progressive developers recommend to replace 'info' by html or
something else modern.
> 



From lars at nocrew.org  Sun Nov 18 15:01:05 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 18 Nov 2018 05:01:05 +0000
Subject: [TUHS] man-page style
In-Reply-To: <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>
 (Donald ODona's message of "Sun, 18 Nov 2018 00:31:11 +0000 (UTC)")
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <20181117233832.9E28A215C0@orac.inputplus.co.uk>
 <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>
Message-ID: <7wh8gf6ktq.fsf@junk.nocrew.org>

Donald ODona wrote:
> its based on TekInfo, whereas 'Tek' allegedly refers to the
> anachronistic Tape Editor and Corrector, developed by a student (Dan
> Murphy) in 1964 on a PDP-1 without a operation system. According to
> the myth TekInfo was build on top of the Tape Editor, and finally made
> it on *NIX.

Murphy's editor is called TECO:
http://tenex.opost.com/anhc-31-4-anec.pdf

I never heard of TekInfo, or a connection between TECO and INFO.  Where
does this myth come from?

I'm not sure exactly how INFO in ITS evolved.  Maybe it was a separate
program at first, but the latest version is an application written on
top of EMACS.


From lars at nocrew.org  Sun Nov 18 15:29:14 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Sun, 18 Nov 2018 05:29:14 +0000
Subject: [TUHS] man-page style
In-Reply-To: <7wh8gf6ktq.fsf@junk.nocrew.org> (Lars Brinkhoff's message of
 "Sun, 18 Nov 2018 05:01:05 +0000")
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <20181117233832.9E28A215C0@orac.inputplus.co.uk>
 <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>
 <7wh8gf6ktq.fsf@junk.nocrew.org>
Message-ID: <7wd0r36jit.fsf@junk.nocrew.org>

> I'm not sure exactly how INFO in ITS evolved.  Maybe it was a separate
> program at first, but the latest version is an application written on
> top of EMACS.

Sorry, I didn't check thoroughly enough.  Before EMACS, INFO was written
in PDP-10 assembly language.


From jsteve at superglobalmegacorp.com  Sat Nov 17 23:41:05 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Sat, 17 Nov 2018 21:41:05 +0800
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <7wh8gfalyn.fsf@junk.nocrew.org>
References: <7wh8gfalyn.fsf@junk.nocrew.org>
Message-ID: <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>

Please post updates as you go!!!

I'm always interested in obsolete dead ends like this !

Sent from my Windows 10 Nokia Lumia 1520

From: Lars Brinkhoff
Sent: Saturday, November 17, 2018 9:11 PM
To: tuhs at tuhs.org
Subject: [TUHS] Chaosnet for 4.1BSD

Hello,

For your information (and to reduce my guilt for posting off topic
sometimes), I have 4.1BSD running with Chaosnet patches from MIT.  I'm
adding a Unibus CH11 network interface to SIMH.  It's not working fully
yet, but it's close.

Best regards,
Lars Brinkhoff

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

From jsteve at superglobalmegacorp.com  Sun Nov 18 22:50:30 2018
From: jsteve at superglobalmegacorp.com (jsteve at superglobalmegacorp.com)
Date: Sun, 18 Nov 2018 20:50:30 +0800
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <7wbm6naf0a.fsf@junk.nocrew.org>
References: <7wh8gfalyn.fsf@junk.nocrew.org>
 <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
 <7wbm6naf0a.fsf@junk.nocrew.org>
Message-ID: <b060da67-27dd-4072-be9d-1c4dac8f59d1@SG2APC01FT063.eop-APC01.prod.protection.outlook.com>

When everyone was reading iron man, spider man, x-men I was the weirdo reading “What if?”

Sure tcpip scales, but it wasn’t the first, nor the last..  Much like many of these old systems, owning one is far from practical, let alone a functioning one, but emulation is so convenient.

Just as dynamips is another great hero of emulation, bringing all kinds of networking topologies into play.

I guess it's also a break from the x86_64/arm64 boring of the day to day.

Sent from my Windows 10 Nokia Lumia 1520

From: Lars Brinkhoff
Sent: Saturday, November 17, 2018 11:41 PM
To: jsteve at superglobalmegacorp.com
Cc: tuhs at tuhs.org
Subject: Re: [TUHS] Chaosnet for 4.1BSD

jsteve at superglobalmegacorp.com writes:
> Please post updates as you go!!!

Sure, at least it's both historical and Unix.

The CH11 device is for all SIMH Unibus computers, so VAX, PDP-11, and
PDP-10 (KS1).  There supposedly were patches for PDP-11 Unix too, but I
haven't seen them so far.

> I'm always interested in obsolete dead ends like this !

Why oh why is there such a high correlation between archaic obsolete
systems and sheer hacking joy?  I'm just dying to have MagicSix on
Chaosnet, but it's not to be.

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

From chet.ramey at case.edu  Mon Nov 19 12:53:45 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 18 Nov 2018 21:53:45 -0500
Subject: [TUHS] man-page style
In-Reply-To: <200652.696.1542402341716.JavaMail.root@zimbraanteil>
References: <200652.696.1542402341716.JavaMail.root@zimbraanteil>
Message-ID: <151330e9-8fa4-8577-dc44-3dc76464ab6c@case.edu>

On 11/16/18 4:05 PM, Jim Capp wrote:
>> If you don't use emacs, you won't like it.
> 
> Let's not start any new emacs vs. vi flame wars.

No flames; no vi vs. emacs. Info is explicitly designed to emulate emacs
info mode.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Nov 19 12:58:36 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 18 Nov 2018 21:58:36 -0500
Subject: [TUHS] man-page style
In-Reply-To: <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
Message-ID: <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>

On 11/16/18 4:13 PM, Jon Steinhart wrote:

> Well, not wanting to start a flame war here, but I don't use emacs.  While
> it's a good piece of software, I just want a text editor.  Emacs sort of
> violates my UNIX-sense as it does many things instead of doing one thing
> well.

That's fine. Everyone gets to use whatever they want.

> But really the issue is that info introduced a new interface on a system
> that already had one that people were accustomed to.

Improvement is in the eye of the beholder. RMS and other folks consider
info, with its hyperlinks, indexes, and tree-based navigation the superior
alternative.  Not just different, but better.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Nov 19 12:59:51 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 18 Nov 2018 21:59:51 -0500
Subject: [TUHS] man-page style
In-Reply-To: <b643972e-2ec6-7a4d-de9f-2ed3e59789a6@spamtrap.tnetconsulting.net>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au>
 <b643972e-2ec6-7a4d-de9f-2ed3e59789a6@spamtrap.tnetconsulting.net>
Message-ID: <96209d8f-bc2f-fce0-a53c-411f564f2be4@case.edu>

On 11/16/18 4:29 PM, Grant Taylor via TUHS wrote:
> On 11/16/2018 02:24 PM, Toby Thain wrote:
>> `info` and `man` solve two different problems, regardless of one's
>> opinion of the interface to the former (which can be learned, it's no
>> more arcane than `vi`).
> 
> I feel like the man vs info war (IMHO it's a war) on Linux has gone too
> far.  Far enough that there are some tools that have between woefully
> inadequate man pages to missing man pages in favor of info documentation.

Agreed. That's why I supply both, with much the same content.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Nov 19 13:02:33 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 18 Nov 2018 22:02:33 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181117153919.6468B18C073@mercury.lcs.mit.edu>
References: <20181117153919.6468B18C073@mercury.lcs.mit.edu>
Message-ID: <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>

On 11/17/18 10:39 AM, Noel Chiappa wrote:
>     > From: Lars Brinkhoff
> 
>     > Emacs is very much divorced from the Unix philosopy. However, it's
>     > perfectly in synch with how things are done in ITS.
> 
> Hmm. It is complicated, but... the vast majority of my keystrokes are typed
> into Epsilon (a wonderful, small, fast EMACS-type editor for Windows, etc
> which one can customize in C) - especially since I started, very early on (V6)
> to run my shell in an EMACS window, so I could edit commands, and thus I was
> pretty much always typing to EMACS. So, it makes sense to me to have it be
> powerful - albeit potentially a bit complex.
> 
> I say 'potentially' because one could after all restrict oneself to the 4
> basic motion commands, and 'delete character'; you don't have to learn what
> CRTL-ALT-SHIFT-Q does.

It's not clear how widespread this is, but on my Mac OS X system, emacs
key bindings are pervasive. TextEdit, text controls in apps and browsers,
pretty much everything understands the basic emacs keybinding.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Nov 19 13:05:59 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 18 Nov 2018 22:05:59 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181117182108.GA15914@wopr>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <201811171814.wAHIErpp025616@freefriends.org> <20181117182108.GA15914@wopr>
Message-ID: <82357ec2-bcf6-7016-e74b-15d0ab018bb8@case.edu>

On 11/17/18 1:21 PM, Kurt H Maier wrote:
> On Sat, Nov 17, 2018 at 11:14:53AM -0700, arnold at skeeve.com wrote:
>>
>> The man page authors / tech writers at Sun were paid to write man
>> pages, and learned / were taught how to do it well. The Linux stuff is
>> done by volunteers.  You're comparing apples and oranges.
>         
> How do we kill this meme?  

As soon as volunteers like Arnold, who maintains a widely-used piece
of the Linux infrastructure, get paid.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From chet.ramey at case.edu  Mon Nov 19 13:09:47 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Sun, 18 Nov 2018 22:09:47 -0500
Subject: [TUHS] man-page style
In-Reply-To: <15c4f386-85b0-3b5f-625c-e3bda1506d96@telegraphics.com.au>
References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil>
 <20181117233832.9E28A215C0@orac.inputplus.co.uk>
 <1684725999.70092.1542501071189.JavaMail.tomcat@india-live-be03>
 <15c4f386-85b0-3b5f-625c-e3bda1506d96@telegraphics.com.au>
Message-ID: <ab10442a-9cd7-9161-54fe-1e48b4e1ce9a@case.edu>

On 11/17/18 10:00 PM, Toby Thain wrote:
> On 2018-11-17 7:31 PM, Donald ODona wrote:
>>
>>
>> At 17 Nov 2018 23:39:45 +0000 (+00:00) from Ralph Corderoy <ralph at inputplus.co.uk>:
>>>
>>> From somewhere that didn't fit in well with Unix.
>> its based on TekInfo, whereas 'Tek' allegedly refers to the anachronistic Tape Editor and Corrector, developed by a student (Dan Murphy) in 1964 on a PDP-1 without a operation system. According to the myth TekInfo was build on top of the Tape Editor, and finally made it on *NIX.
>>
>> 'Info' really doesn't fit in well with Unix. Its alien and another failed approach. Almost all 'GNU' man pages state, that the 'full' documentation is only available via 'info'. In real 99% of all 'info' requests  result in 'info' processing a man page.
> 
> 
> In many notable examples, that is not true: e.g. GNU make, bash or bison
> come quickly to mind. You can't fully learn how to use tools like these
> from the abbreviated man page; for one thing, the man page only mentions
> a fraction of the features.

The man page for bash includes everything. The info manual includes more
examples. I think other authors should follow that model, but I'm not going
to tell a volunteer what he has to do, and I understand how difficult it is
to maintain parallel content.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From jon at fourwinds.com  Mon Nov 19 13:11:13 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Sun, 18 Nov 2018 19:11:13 -0800
Subject: [TUHS] man-page style
In-Reply-To: <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
Message-ID: <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>

Chet Ramey writes:
> On 11/16/18 4:13 PM, Jon Steinhart wrote:
> > But really the issue is that info introduced a new interface on a system
> > that already had one that people were accustomed to.
>
> Improvement is in the eye of the beholder. RMS and other folks consider
> info, with its hyperlinks, indexes, and tree-based navigation the superior
> alternative.  Not just different, but better.

Well, of course it is.  And as long as one doesn't care much about existing
community one can do what one wants.  Sort of like Americans expecting others
to speak to them in English when they travel instead of understanding that
they're in a different environment and it makes more sense to learn the culture
as it's unlikely that everybody is gonna change just for you.  This is not a
unique problem with man vs info.  I see it in the large number of different
make utilities, package managers, and so on that really don't provide new
functionality but do make it much harder to be a practicioner since one has a
lot more stuff to learn for no real benefit.

So were it me, I would have looked at the current culture in the UNIX environment
and figured out how it gracefully extend it for new functionality.  To me, that's
a mark of good engineering instead of being a bull in a china shop.  A good example
of that in a different field is the way in which FM stereo was finessed in such a
way as to not break existing mono receivers.  Would have been easy to just toss it
and make everybody buy new gear, but I prefer the more elegant solution.

Jon


From ggm at algebras.org  Mon Nov 19 13:21:24 2018
From: ggm at algebras.org (George Michaelson)
Date: Mon, 19 Nov 2018 13:21:24 +1000
Subject: [TUHS] man-page style
In-Reply-To: <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
Message-ID: <CAKr6gn1FL4ektTZWLdYLu69Zw8BOJ4NibWLT9mS-xzQYbafHDg@mail.gmail.com>

Mike Lesk had a really good rap about his work on Library information
systems and the work they did at Bell (or maybe one of the schools of
library sciences).

The principle was, that "simple" users wanted nested menu and "power"
users wanted commands. They did A/B testing and a bunch of work to
show that if you trained people in the keystrokes for the commandline,
they got significantly more productive.

Mike also said (I may be mis-remembering, but this is what I took from
the conversation) that people's prior experiental sense of what they
wanted had as much influence on what they thought, as the quality of
the system.

So if (like me) you walked into the SOS room at the lab, on a
Dec-10... you wound up wired to go with ed/ex/vi family interaction.
If you walked into the teco room you came out more wired for emacs. I
think this is very probably true, purely on my own sample of one. If
I'd walked into the LISP room, I would probably now be a lowly paid
quant in a small bank, failing badly instead of having walked into the
pascal room, and being an imperative language person earning the huge
bucks coding menu systems. No wait.. thats not right..
On Mon, Nov 19, 2018 at 1:11 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> Chet Ramey writes:
> > On 11/16/18 4:13 PM, Jon Steinhart wrote:
> > > But really the issue is that info introduced a new interface on a system
> > > that already had one that people were accustomed to.
> >
> > Improvement is in the eye of the beholder. RMS and other folks consider
> > info, with its hyperlinks, indexes, and tree-based navigation the superior
> > alternative.  Not just different, but better.
>
> Well, of course it is.  And as long as one doesn't care much about existing
> community one can do what one wants.  Sort of like Americans expecting others
> to speak to them in English when they travel instead of understanding that
> they're in a different environment and it makes more sense to learn the culture
> as it's unlikely that everybody is gonna change just for you.  This is not a
> unique problem with man vs info.  I see it in the large number of different
> make utilities, package managers, and so on that really don't provide new
> functionality but do make it much harder to be a practicioner since one has a
> lot more stuff to learn for no real benefit.
>
> So were it me, I would have looked at the current culture in the UNIX environment
> and figured out how it gracefully extend it for new functionality.  To me, that's
> a mark of good engineering instead of being a bull in a china shop.  A good example
> of that in a different field is the way in which FM stereo was finessed in such a
> way as to not break existing mono receivers.  Would have been easy to just toss it
> and make everybody buy new gear, but I prefer the more elegant solution.
>
> Jon


From lm at mcvoy.com  Mon Nov 19 13:32:05 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 18 Nov 2018 19:32:05 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CAKr6gn1FL4ektTZWLdYLu69Zw8BOJ4NibWLT9mS-xzQYbafHDg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAKr6gn1FL4ektTZWLdYLu69Zw8BOJ4NibWLT9mS-xzQYbafHDg@mail.gmail.com>
Message-ID: <20181119033205.GJ341@mcvoy.com>

I'm in the middle of a family / college mess.  So I have no deep reply,
but every day this list gives me more insight into how we got here.
Just wanted to say thanks and tell people to keep popping up and tell
their stories.

On Mon, Nov 19, 2018 at 01:21:24PM +1000, George Michaelson wrote:
> Mike Lesk had a really good rap about his work on Library information
> systems and the work they did at Bell (or maybe one of the schools of
> library sciences).
> 
> The principle was, that "simple" users wanted nested menu and "power"
> users wanted commands. They did A/B testing and a bunch of work to
> show that if you trained people in the keystrokes for the commandline,
> they got significantly more productive.
> 
> Mike also said (I may be mis-remembering, but this is what I took from
> the conversation) that people's prior experiental sense of what they
> wanted had as much influence on what they thought, as the quality of
> the system.
> 
> So if (like me) you walked into the SOS room at the lab, on a
> Dec-10... you wound up wired to go with ed/ex/vi family interaction.
> If you walked into the teco room you came out more wired for emacs. I
> think this is very probably true, purely on my own sample of one. If
> I'd walked into the LISP room, I would probably now be a lowly paid
> quant in a small bank, failing badly instead of having walked into the
> pascal room, and being an imperative language person earning the huge
> bucks coding menu systems. No wait.. thats not right..
> On Mon, Nov 19, 2018 at 1:11 PM Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > Chet Ramey writes:
> > > On 11/16/18 4:13 PM, Jon Steinhart wrote:
> > > > But really the issue is that info introduced a new interface on a system
> > > > that already had one that people were accustomed to.
> > >
> > > Improvement is in the eye of the beholder. RMS and other folks consider
> > > info, with its hyperlinks, indexes, and tree-based navigation the superior
> > > alternative.  Not just different, but better.
> >
> > Well, of course it is.  And as long as one doesn't care much about existing
> > community one can do what one wants.  Sort of like Americans expecting others
> > to speak to them in English when they travel instead of understanding that
> > they're in a different environment and it makes more sense to learn the culture
> > as it's unlikely that everybody is gonna change just for you.  This is not a
> > unique problem with man vs info.  I see it in the large number of different
> > make utilities, package managers, and so on that really don't provide new
> > functionality but do make it much harder to be a practicioner since one has a
> > lot more stuff to learn for no real benefit.
> >
> > So were it me, I would have looked at the current culture in the UNIX environment
> > and figured out how it gracefully extend it for new functionality.  To me, that's
> > a mark of good engineering instead of being a bull in a china shop.  A good example
> > of that in a different field is the way in which FM stereo was finessed in such a
> > way as to not break existing mono receivers.  Would have been easy to just toss it
> > and make everybody buy new gear, but I prefer the more elegant solution.
> >
> > Jon

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


From dave at horsfall.org  Mon Nov 19 14:15:11 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 19 Nov 2018 15:15:11 +1100 (EST)
Subject: [TUHS] man-page style
In-Reply-To: <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>
References: <20181117153919.6468B18C073@mercury.lcs.mit.edu>
 <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>
Message-ID: <alpine.BSF.2.21.9999.1811191509050.60610@aneurin.horsfall.org>

On Sun, 18 Nov 2018, Chet Ramey wrote:

> It's not clear how widespread this is, but on my Mac OS X system, emacs 
> key bindings are pervasive. TextEdit, text controls in apps and 
> browsers, pretty much everything understands the basic emacs keybinding.

As a Mac user I never noticed that, but I'll admit to using EMACS key 
bindings in the various shells, despite being a VI user...  A bit like 
using CSH at the terminal, but never for scripting :-)

-- Dave


From khm at sciops.net  Mon Nov 19 14:43:23 2018
From: khm at sciops.net (Kurt H Maier)
Date: Sun, 18 Nov 2018 20:43:23 -0800
Subject: [TUHS] man-page style
In-Reply-To: <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>
References: <20181117153919.6468B18C073@mercury.lcs.mit.edu>
 <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>
Message-ID: <20181119044323.GA93395@wopr>

On Sun, Nov 18, 2018 at 10:02:33PM -0500, Chet Ramey wrote:
>
> It's not clear how widespread this is, but on my Mac OS X system, emacs
> key bindings are pervasive. TextEdit, text controls in apps and browsers,
> pretty much everything understands the basic emacs keybinding.
>
          
It's fairly widespread, because much inherited from TENEX the same
keybindings that emacs inherited -- including tcsh, as an example.  vi 
itself supports most of them, albeit only when in 'insert' mode.
       
khm


From lars at nocrew.org  Mon Nov 19 15:59:53 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 19 Nov 2018 05:59:53 +0000
Subject: [TUHS] man-page style
In-Reply-To: <151330e9-8fa4-8577-dc44-3dc76464ab6c@case.edu> (Chet Ramey's
 message of "Sun, 18 Nov 2018 21:53:45 -0500")
References: <200652.696.1542402341716.JavaMail.root@zimbraanteil>
 <151330e9-8fa4-8577-dc44-3dc76464ab6c@case.edu>
Message-ID: <7w36rx4nfq.fsf@junk.nocrew.org>

Chet Ramey wrote:
> No flames; no vi vs. emacs. Info is explicitly designed to emulate emacs
> info mode.

It's even better.  I believe it's designed to emulate something that
existed before Emacs.


From lars at nocrew.org  Mon Nov 19 16:13:41 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Mon, 19 Nov 2018 06:13:41 +0000
Subject: [TUHS] man-page style
In-Reply-To: <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> (Jon
 Steinhart's message of "Sun, 18 Nov 2018 19:11:13 -0800")
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
Message-ID: <7wy39p388a.fsf@junk.nocrew.org>

Jon Steinhart wrote:
> Chet Ramey wrote:
>> Improvement is in the eye of the beholder. RMS and other folks consider
>> info, with its hyperlinks, indexes, and tree-based navigation the superior
>> alternative.  Not just different, but better.
> So were it me, I would have looked at the current culture in the UNIX
> environment and figured out how it gracefully extend it for new
> functionality.

Yes, that's would have been very reasonable.

But I have the impression that GNU from the outset was supposed to go
beyond Unix.  My vague memory is that the phrase "GNU's not Unix" kind
of implied "we're making a copy of Unix... but we'll change it any way
we see fit".  The announcement figured things like a Lisp-based
windowing system and Chaosnet.

Remember that Stallman came from a dozen years of working with ITS and
Lisp machines.  It seems likely he wanted to pick the best parts and
transplant them on top of Unix, making GNU.  To some degree, he
succeeded: Emacs is EMACS, unexec is PDUMP, Emacs Lisp is Maclisp, Info
is INFO, GCC internals kind of wants to be Lisp.

Not arguing for or against here, just trying to provide some historical
background as I see it.


From imp at bsdimp.com  Mon Nov 19 17:05:08 2018
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 19 Nov 2018 00:05:08 -0700
Subject: [TUHS] man-page style
In-Reply-To: <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
Message-ID: <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>

On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Emacs sort of
> violates my UNIX-sense as it does many things instead of doing one thing
> well.


I'd argue that's not a bad thing. When people tried to add macros to make
or sendmail, you wound up with crazy like imake or the crazy sendfile.m4
stuff. Of course, sendmail and one thing aren't mates, but sometimes you
need to do a few, well chosen things well to avoid the crazy that trying to
misuse something will bring to the table.

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

From bakul at bitblocks.com  Mon Nov 19 17:20:12 2018
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 18 Nov 2018 23:20:12 -0800
Subject: [TUHS] man-page style
In-Reply-To: Your message of "Mon, 19 Nov 2018 00:05:08 -0700."
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
Message-ID: <20181119072022.E3EE4156E40C@mail.bitblocks.com>

On Mon, 19 Nov 2018 00:05:08 -0700 Warner Losh <imp at bsdimp.com> wrote:
>
> On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> > Emacs sort of
> > violates my UNIX-sense as it does many things instead of doing one thing
> > well.

This is only half the story. Unix also provides a way to
assemble these tools to carry out a specific task.

> I'd argue that's not a bad thing. When people tried to add macros to make
> or sendmail, you wound up with crazy like imake or the crazy sendfile.m4
> stuff. Of course, sendmail and one thing aren't mates, but sometimes you
> need to do a few, well chosen things well to avoid the crazy that trying to
> misuse something will bring to the table.

The problem was sendmail didn't have a decent builtin glue
language to customize it. More generally, you can't just
provide domain specific objects, you have to provide a domain
specific algebra as well, so to speak. And you don't have to
provide domain specific syntax.


From steffen at sdaoden.eu  Mon Nov 19 23:08:54 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 19 Nov 2018 14:08:54 +0100
Subject: [TUHS] man-page style
In-Reply-To: <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
Message-ID: <20181119130854.cB3nR%steffen@sdaoden.eu>

Chet Ramey wrote in <e8810295-5146-e126-a4d8-65e814f4b431 at case.edu>:
 |On 11/16/18 4:13 PM, Jon Steinhart wrote:
 |
 |> Well, not wanting to start a flame war here, but I don't use emacs. \
 |>  While
 |> it's a good piece of software, I just want a text editor.  Emacs sort of
 |> violates my UNIX-sense as it does many things instead of doing one thing
 |> well.
 |
 |That's fine. Everyone gets to use whatever they want.
 |
 |> But really the issue is that info introduced a new interface on a system
 |> that already had one that people were accustomed to.
 |
 |Improvement is in the eye of the beholder. RMS and other folks consider
 |info, with its hyperlinks, indexes, and tree-based navigation the superior
 |alternative.  Not just different, but better.

roff, however, does provide the power to support all that: all
you need to do is to write the macros that do this for you.
One thing i have never understood is that.  Just do it.  I always
wondered at first when i saw coming along the blue links in the
man markup that the Linux world introduced.  Which is very
half-assed!

Mind you, i have to say, i actually have written such a thing for
the mdoc(7) manual macros (called mdocmx), and it gives you
interactivity on a normal terminal, or in HTML, or in PDF, it
gives you TOC and it could give you more.  I couldn't even live
without it no more, it improves living with the large manual of
the MUA i maintain tremendously.

Half-assed, too, is that even after fourty or more years of Unix
manual pages you cannot even search properly in a displayed manual
page, or at least you will not find anything that uses the usual
and old-style BS formatting sequences (that my mdocmx uses to
embed the informations, for example).  I never thought about that,
but Jörg Schilling mentioned that his pager (as simply as it may
be) is capable of doing so (by reduction, he said, though).

But the largest pain is non-existent, incomplete, or unfindable
documentation.  This cannot be said about bash or mksh, not about
tmux or screen, not about the documentation of Plan9, and not
over the MUA i maintain i hope.  But i have just moved over to
Linux on bare metal, and even though the Linux man-page project
has made an _immense_ effort and has achieved equal improvements,
it took a long time to get all this going (on a minimal
Distribution which does not do all of that automatically for you,
because years of experience have created an internal database full
of hints which are used to do-the-right-thing).

I could actually enumerate a scary long list of problems (on two
old notebooks, a MacBook Air and an Acer Aspire, external Seagate
USB disk, USB WLAN), but from back in the Eighties or even older
is that US keyboard do not honour "ISO_Level3_Shift" unless
setxkbmap 'us(intl)' is called.  I mean, you use xev(1) and the
event flies by, but the driver does not do anything with it.  How
do you find that out.  Just like with many other things you have
to face a lot of those toilet writings that make up the internet
before you get something good.  The ArchLinux wiki is very often
a useful and helpful source, but better not look in the web
support forums of the large distributions, who get paid, if you
can look into them at all.

It seems the wonderful tradition of HOWTOs or good things
including documentation under /usr/share (on BSDs) has been
entirely lost.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


From mutiny.mutiny at india.com  Mon Nov 19 23:20:57 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Mon, 19 Nov 2018 13:20:57 +0000 (UTC)
Subject: [TUHS] man-page style
In-Reply-To: <20181119130854.cB3nR%steffen@sdaoden.eu>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>,
 <20181119130854.cB3nR%steffen@sdaoden.eu>
Message-ID: <412092435.71876.1542633657282.JavaMail.tomcat@india-live-be04>

At 19 Nov 2018 03:11:00 +0000 (+00:00) from Chet Ramey <chet.ramey at case.edu>:
>
> The man page for bash includes everything. The info manual includes more
> examples. I think other authors should follow that model, but I'm not going
> to tell a volunteer what he has to do, and I understand how difficult it is
> to maintain parallel content.

'info' is technologically spoken 'superior'. However replacing 'info' by html, what someone recommended for 'emacs'(sic!), is even more superior.

However superior isn't really of great importance. nroff is good enough, its used by millions of *NIX users since more than 40 years, whereas 'info' is only used by a small sect.
Hence, I recommend to stop using 'info' at all, avoiding the maintenance of parallel and unused contents.


From chet.ramey at case.edu  Tue Nov 20 00:00:32 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 19 Nov 2018 09:00:32 -0500
Subject: [TUHS] man-page style
In-Reply-To: <7w36rx4nfq.fsf@junk.nocrew.org>
References: <200652.696.1542402341716.JavaMail.root@zimbraanteil>
 <151330e9-8fa4-8577-dc44-3dc76464ab6c@case.edu>
 <7w36rx4nfq.fsf@junk.nocrew.org>
Message-ID: <e5241f8e-bf9a-ec27-a638-a83ebf661d12@case.edu>

On 11/19/18 12:59 AM, Lars Brinkhoff wrote:
> Chet Ramey wrote:
>> No flames; no vi vs. emacs. Info is explicitly designed to emulate emacs
>> info mode.
> 
> It's even better.  I believe it's designed to emulate something that
> existed before Emacs.

Emacs info mode emulates something that existed before ITS/TENEX EMACS.
When Brian wrote Info, he emulated gnu emacs.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From chet.ramey at case.edu  Tue Nov 20 00:06:44 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Mon, 19 Nov 2018 09:06:44 -0500
Subject: [TUHS] man-page style
In-Reply-To: <7wy39p388a.fsf@junk.nocrew.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <7wy39p388a.fsf@junk.nocrew.org>
Message-ID: <05d2fdec-17a0-4347-a95d-17c0cc07d23b@case.edu>

On 11/19/18 1:13 AM, Lars Brinkhoff wrote:
> Jon Steinhart wrote:
>> Chet Ramey wrote:
>>> Improvement is in the eye of the beholder. RMS and other folks consider
>>> info, with its hyperlinks, indexes, and tree-based navigation the superior
>>> alternative.  Not just different, but better.
>> So were it me, I would have looked at the current culture in the UNIX
>> environment and figured out how it gracefully extend it for new
>> functionality.
> 
> Yes, that's would have been very reasonable.

It was an explicit goal. From the GNU manifesto:

"GNU will be able to run Unix programs, but will not be identical to Unix.
We will make all improvements that are convenient, based on our experience
with other operating systems."

and

"Unix is not my ideal system, but it is not too bad. The essential features
of Unix seem to be good ones, and I think I can fill in what Unix lacks
without spoiling them."

Of course, one man's graceful extension is the next man's graceless
pillaging.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From clemc at ccc.com  Tue Nov 20 01:35:05 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Nov 2018 10:35:05 -0500
Subject: [TUHS] man-page style
In-Reply-To: <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
Message-ID: <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>

On Sun, Nov 18, 2018 at 10:11 PM Jon Steinhart <jon at fourwinds.com> wrote:

> Sort of like Americans expecting others to speak to them in English when
> they travel instead of understanding that they're in a different
> environment and it makes more sense to learn the culture as it's unlikely
> that everybody is gonna change just for you.

Amen, brother Jon, can we get another Amen..




> This is not a unique problem with man vs info.  I see it in the large
> number of different make utilities, package managers, and so on that
> really don't provide new functionality but do make it much harder to be a
> practitioner since one has a lot more stuff to learn for no real benefit.
>
Exactly!!


>
> So were it me, I would have looked at the current culture in the UNIX
> environment and figured out how it gracefully extend it for new
> functionality.  To me, that's
> a mark of good engineering instead of being a bull in a china shop.

I referred to this previously as the principle of 'least astonishment.'

Again - the argument for doing what he (and his followers did was) 'Gnu is
Not Unix' - but my reply is that they created UNIX when they were done.
They road the research train, then BSD rode the same UNIX train to start
and now ride the UNIX look/work alike, Linux, rides it still.    And
because it was incremental on the past, we get more behind it.

A much as I'm live and left live, and to each her/his own -- if GNU had
been a new system, then I might be a lot more willing to accept that the
argument.  But what was build was (and is) not.  GNU is just the current
and expanded UNIX implementation.  And the so its have the man page being
useless and expecting people to use info in just wrong.   Even if you are
used it it (ok, so you found English speakers when you travelled).

And Ted is not that I don't use the unix documents (full papers) - hey I
do.   That is how I learned to use 'make' when it appeared (or C for that
matter) from documents in /usr/doc. \

What started this whole thread was Doug's comment about how succinct and
to the point man was.  If was a fine interface for >>UNIX<<.   Man (using
roff) was what people expect.  It's not about better or worse -- it worked
and worked well.

As I said, if man had been maintained as the primary >>manual<< style
interface and /usr/doc/<PROG>/foo.ms as the primary scheme (which >>IS<<
what BSD did), then you don't fail the rule of least astonishment.  Then
create a *roff -Tinfo | info_create backend, that produced the info files;
those that want it, get it and love it.   Those that >>expect<< man to work
because its UNIX, get what they expect.  No one is 'astonished.'

A good example of that in a different field is the way in which FM stereo
> was finessed in such a
> way as to not break existing mono receivers.  Would have been easy to just
> toss it
> and make everybody buy new gear, but I prefer the more elegant solution.
>
Yep.   Metcalfe's Law -- adding too and improving on the past; makes more
people happy.   Yep, it is sometimes 'harder ' for the developer and some
compromises do result.   But the result is a bigger pie and happier group
in total.  Think of the contemporary system to Linux (including Plan9 for
the matter) -- which were 'better' and which are we still using.   Its not
that there are not good ideas.

The 'better than' argument fails when the difference ('betterness') is
shallow and not something that really is remarkable (I like it and use it
is not good enough).   Respecting the past and ensuring the 'old ways' work
is good business.  And that is the problem.   When you are the creator of
the alternate scheme, its hard to not understand how much better something
is.  Being different and better >>sometimes<< can pay off (check out:  –Bret
Victor’s: The Future of Programming:
https://www.youtube.com/watch?v=8pTEmbeENF4 –His talk in 2013, but set and
presented it as if he were talking in the 1970s); but if you look each of
these things he is talking about is remarkably different --  man vs. info
(or ed/vi vs teco/emacs for that matter, I'm not sure really are/were).

Clem
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181119/e76948f8/attachment.html>

From david at kdbarto.org  Tue Nov 20 01:41:23 2018
From: david at kdbarto.org (David)
Date: Mon, 19 Nov 2018 07:41:23 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
Message-ID: <7171EAB7-9557-4822-8FCE-5C7B1AD19B06@kdbarto.org>


> On Nov 19, 2018, at 7:35 AM, Clem Cole <clemc at ccc.com> wrote:
> 
> 
> 
> On Sun, Nov 18, 2018 at 10:11 PM Jon Steinhart <jon at fourwinds.com <mailto:jon at fourwinds.com>> wrote:
> Sort of like Americans expecting others to speak to them in English when they travel instead of understanding that they're in a different environment and it makes more sense to learn the culture as it's unlikely that everybody is gonna change just for you.
> Amen, brother Jon, can we get another Amen..
> 
As a recent traveller overseas, Amen to that.

> 
> What started this whole thread was Doug's comment about how succinct and  to the point man was.  If was a fine interface for >>UNIX<<.   Man (using roff) was what people expect.  It's not about better or worse -- it worked and worked well.
> 
> 
> Clem
> ᐧ
> ᐧ

The problem, as we have all converged on, is that writing well is hard. Writing concise, targeted prose, is even harder. So we get bloat in man pages or the info system which is just (IMHO) more bloat because people don’t want to spend the time writing well.

	David

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

From jon at fourwinds.com  Tue Nov 20 02:48:52 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 19 Nov 2018 08:48:52 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
Message-ID: <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>

Warner Losh writes:
> On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart <jon at fourwinds.com> wrote:
>
> > Emacs sort of
> > violates my UNIX-sense as it does many things instead of doing one thing
> > well.
>
>
> I'd argue that's not a bad thing. When people tried to add macros to make
> or sendmail, you wound up with crazy like imake or the crazy sendfile.m4
> stuff. Of course, sendmail and one thing aren't mates, but sometimes you
> need to do a few, well chosen things well to avoid the crazy that trying to
> misuse something will bring to the table.
>
> Warner

Funny that you bring this up as I was just talking to Eric about this.
I was telling him that someone had recently asked me why sendmail was
so complicated, and I explained to them that it was because email wasn't
always like it is today; that there were many disparate email systems and
sendmail glued them all together.  Eric said something like yeah, and I
would have liked to have a better syntax but memory was too constrained
at the time to let me do anything better.


From jon at fourwinds.com  Tue Nov 20 03:06:04 2018
From: jon at fourwinds.com (Jon Steinhart)
Date: Mon, 19 Nov 2018 09:06:04 -0800
Subject: [TUHS] man-page style
In-Reply-To: <7171EAB7-9557-4822-8FCE-5C7B1AD19B06@kdbarto.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <7171EAB7-9557-4822-8FCE-5C7B1AD19B06@kdbarto.org>
Message-ID: <201811191706.wAJH64eZ007537@darkstar.fourwinds.com>

David writes:
> The problem, as we have all converged on, is that writing well is hard. Writing
> concise, targeted prose, is even harder. So we get bloat in man pages or the
> info system which is just (IMHO) more bloat because people don’t want to spend
> the time writing well.

I'm going to be a bit contrary here.  Yes, writing is hard, but not that hard.
Designing is what's harder.  I'm gonna make the claim that a lot of projects
today aren't designed.  They're implemented, and when someone gets something
that sort of works they write down a few notes about what was hard for them
(if we're lucky) and passes that off as documentation.  We're in an era in
which it is so easy to just try things that many don't bother which what I'd
call design.  No surprise that "documentation" from "undesigned" isn't good.


From tytso at mit.edu  Tue Nov 20 03:39:52 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Mon, 19 Nov 2018 12:39:52 -0500
Subject: [TUHS] man-page style
In-Reply-To: <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
Message-ID: <20181119173952.GA19377@thunk.org>

On Mon, Nov 19, 2018 at 10:35:05AM -0500, Clem Cole wrote:
> And Ted is not that I don't use the unix documents (full papers) - hey I
> do.   That is how I learned to use 'make' when it appeared (or C for that
> matter) from documents in /usr/doc. \
> 
> What started this whole thread was Doug's comment about how succinct and
> to the point man was.  If was a fine interface for >>UNIX<<.   Man (using
> roff) was what people expect.  It's not about better or worse -- it worked
> and worked well.

For what it's worth, that's a Debian packaging standard.  All
executables are supposed to have a man page.  In some cases it may be
no more than a short summary of the options and then a reference to
the info manual if you want to learn more.  If the upstream package
does not provide a man page, Debian maintainers are supposed to create
a man page, and hopefully contribute it back upstream.

This isn't always the case; but if there isn't a man page, that's
always grounds for filing a Debian bug report.

> As I said, if man had been maintained as the primary >>manual<< style
> interface and /usr/doc/<PROG>/foo.ms as the primary scheme (which >>IS<<
> what BSD did), then you don't fail the rule of least astonishment.  Then
> create a *roff -Tinfo | info_create backend, that produced the info files;
> those that want it, get it and love it.   Those that >>expect<< man to work
> because its UNIX, get what they expect.  No one is 'astonished.'

I'm not convinced the original BSD man page for, say, "make" is really
sufficient to learn how to use make effectively w/o the expanded,
non-man page write up in BSD Unix's Programmers Supplementary
Documents.  So I dare say the goal that the man page should be the
primary manual was a bit of an aspiration goal as well.

That being said, I'm not convinced nroff is powerful enough to be a
source language for info files and HTML files.  For one thing, it
doesn't have the ability to specify hyperlinks.  The GNU an-ext.tmac
extensions does define macros to provide *external* hyperlinks to WWW
URL's.  However, even that doesn't have the ability to specify
*internal* hyperlinks to other sections of the document.

Cheers,

						- Ted


From clemc at ccc.com  Tue Nov 20 04:40:43 2018
From: clemc at ccc.com (Clem Cole)
Date: Mon, 19 Nov 2018 13:40:43 -0500
Subject: [TUHS] man-page style
In-Reply-To: <20181119173952.GA19377@thunk.org>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <20181119173952.GA19377@thunk.org>
Message-ID: <CAC20D2NKcBwdqiFTO4COeimyKEHx=LCvn_62-9i5=EpRS2BosQ@mail.gmail.com>

As is often in these disagreements, I suspect agree more than disagree.
But some of the absolute edges/where you start or stop is where we pick
different things.

On Mon, Nov 19, 2018 at 12:39 PM Theodore Y. Ts'o <tytso at mit.edu> wrote:

>
>
> For what it's worth, that's a Debian packaging standard.  All
> executables are supposed to have a man page.

Right, thank you and I applaud them for that...   As you and others have
pointed out, Debian != Gnu



> In some cases it may be
> no more than a short summary of the options and then a reference to
> the info manual if you want to learn more.

I think that's somewhat backwards in he spirit of 'UNIX'...  the man and
info pages should reference the manual in /usr/doc/foo/
I think the question really comes to what we see 'info' as.    It >>seems<<
to me that you look at info as the 'manual' for the program which many of
us do not; to me info, like man is a quick reference.




>
> I'm not convinced the original BSD man page for, say, "make" is really
> sufficient to learn how to use make effectively w/o the expanded,
> non-man page write up in BSD Unix's Programmers Supplementary
> Documents.

On this we agree, and it is how I learned make in ~77/78 timeframe when
make came to us (I think via UNIX/TS), modulo staring at makefiles and
copying them.
Truth is I did not read Feldman's paper to start because it was not online
and we don't have the storage for it.  I mostly learned make by duplicating
makefiles I found and if I did not understand something - reading the
code.   I did read the paper at some point and mostly understood it.  But
it was not until Steve Talbot set out to write the original Tektronix Make
manual (which later became the first 'Unix in a NutShell' book for Tim
O'Rielly) that I really 'got it.'   Talbot would pester me, Steve Glaser,
Steinhart, Zuhl and the other UNIX jockeys at Tektronix asking how things
worked.  Then he wrote it down and wrote a wonderful book.  It's simple, to
the point -- make in a nutshell -- what you need to know to use it.  To
this day, when someone asks me about make I loan then a copy of the Steve's
book as the starting point.   Once they understand that, I show the Gnu
extensions ;-)

So I dare say the goal that the man page should be the
> primary manual was a bit of an aspiration goal as well.
>
Ah, I think this is were you not hearing what I'm saying...   the 'primary
manual' as you call it is the document in /usr/doc/make in this case.  But
[as others have pointed out, writing that >well<< can be hard]. FWIW:
Feldman's description of make in /usr/doc of Seventh Edition pales compared
to Steve Talbots - but Talbiot was a professional tech writer and while
Feldman's writing is better than my own, he does not write as well as
Talbot IMO.

Anyway, the man page is the reference as Doug pointed out to start this
thread.  It needs to be complete but succinct -> the facts and what I, the
user of the program, need quickly.   Which when done well, is exactly what
it should be.  It can teach, but does probably if the tool is complex,
should not. If the command is simple (cat or maybe the original tr), it
really only a page or so in lenth, because it does not need to be.  If its
more complex, say make or sh; there needs to be the /usr/doc/{make,sh}/*
files that example it.

info should just be a different interface to man.  No more, not less -- the
reference - not the manual.




>
> That being said, I'm not convinced nroff is powerful enough to be a source
> language for info files and HTML files.
>
Mumble, I'll not go down rat hole.  Others, like Larry already have. Truth
is I've never found something I could not do with roff.

Clem
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181119/382035f6/attachment.html>

From tytso at mit.edu  Tue Nov 20 08:08:55 2018
From: tytso at mit.edu (Theodore Y. Ts'o)
Date: Mon, 19 Nov 2018 17:08:55 -0500
Subject: [TUHS] man-page style
In-Reply-To: <CAC20D2NKcBwdqiFTO4COeimyKEHx=LCvn_62-9i5=EpRS2BosQ@mail.gmail.com>
References: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <20181119173952.GA19377@thunk.org>
 <CAC20D2NKcBwdqiFTO4COeimyKEHx=LCvn_62-9i5=EpRS2BosQ@mail.gmail.com>
Message-ID: <20181119220855.GB17374@thunk.org>

On Mon, Nov 19, 2018 at 01:40:43PM -0500, Clem Cole wrote:
> As is often in these disagreements, I suspect agree more than disagree.
> But some of the absolute edges/where you start or stop is where we pick
> different things.
> 
> > For what it's worth, that's a Debian packaging standard.  All
> > executables are supposed to have a man page.
> 
> Right, thank you and I applaud them for that...   As you and others have
> pointed out, Debian != Gnu

Well, technically Debian's Linux is named "Debian GNU/Linux".  It's
not recognized by the FSF as free (Debian cares about allowing users
to have Laptops which aren't paperweights, even if it does mean making
available firmware for which source is not available), so they
recommend distributions such as gNewSense, which is a Debian-based
fork that is now inactive.

Personally, I find debates about whether or not Debian != GNU to be
much like the bickering between the Judean People's Front versus
People's Front of Judea, the latter of which sends a crack squad to
commit mass suicide at the end of the movie "Life of Brian".  :-)

Unless the claim is the only thing which is GNU is HURD?

> > In some cases it may be
> > no more than a short summary of the options and then a reference to
> > the info manual if you want to learn more.
> 
> I think that's somewhat backwards in he spirit of 'UNIX'...  the man and
> info pages should reference the manual in /usr/doc/foo/
> I think the question really comes to what we see 'info' as.    It >>seems<<
> to me that you look at info as the 'manual' for the program which many of
> us do not; to me info, like man is a quick reference.

The info pages are *in* /usr/share/doc/... on a Debian system.  And if
you were to take a look at the info files for, say, GNU Make, it very
much is a full manual.

Note: In Debian, "info make" will show the man page if you don't have
the info pages installed, which are part of the make-doc package.
Perhaps this is why you think info is a quick reference?

> Ah, I think this is were you not hearing what I'm saying...   the 'primary
> manual' as you call it is the document in /usr/doc/make in this case.  But
> [as others have pointed out, writing that >well<< can be hard]. FWIW:
> Feldman's description of make in /usr/doc of Seventh Edition pales compared
> to Steve Talbots - but Talbiot was a professional tech writer and while
> Feldman's writing is better than my own, he does not write as well as
> Talbot IMO.

In the case of the info pages for make, the FSF may very well have
been able to engage a professional tech writer to help with writing
the GNU make manual.  The FSF does make money selling dead-tree
editions of the make manual.  It doesn't make a lot of money, since
the exact same version is installed in /usr/share/doc/... as as an
info file, but there are those who prefer thumbing through a dead-tree
copy of a manual instead of reading it a screen.

> info should just be a different interface to man.  No more, not less -- the
> reference - not the manual.

Info is optimized for significantely large pieces of documentation
than man pages.  So for example, Perl tries to document everything via
multiple man pages, but since man uses a simple text pager, and it
deosn't have hyperlinks, I don't actually find Perl's attempt to be
either a reference *or* a manual to be terribly useful.  I would much
*prefer* if the perl manual were available as a set of info pages,
since having internal hypertext links and a real indexing mechanism
would make it far superior than trying to navigate perl's man page
hierarchy.

As it is, I tend to just give up and use Google plus various web
pages, including StackExchange, but that doesn't work well if I'm
off-line.  Info pages work just *fine* off-line.  Or, as you've
pointed out many people do, I'll take existing perl scripts and copy
snippets out of them, using the cargo-cult school of programming.  But
using perl's man pages is mostly an exercise in frustration.

						- Ted


From mparson at bl.org  Tue Nov 20 08:18:49 2018
From: mparson at bl.org (Michael Parson)
Date: Mon, 19 Nov 2018 16:18:49 -0600
Subject: [TUHS] man-page style
In-Reply-To: <alpine.BSF.2.21.9999.1811191509050.60610@aneurin.horsfall.org>
References: <20181117153919.6468B18C073@mercury.lcs.mit.edu>
 <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>
 <alpine.BSF.2.21.9999.1811191509050.60610@aneurin.horsfall.org>
Message-ID: <3c7cb03bb23814934ba4ce5735e28b85@bl.org>


On 2018-11-18 22:15, Dave Horsfall wrote:
> On Sun, 18 Nov 2018, Chet Ramey wrote:
> 
>> It's not clear how widespread this is, but on my Mac OS X system, 
>> emacs key bindings are pervasive. TextEdit, text controls in apps and 
>> browsers, pretty much everything understands the basic emacs 
>> keybinding.
> 
> As a Mac user I never noticed that, but I'll admit to using EMACS key
> bindings in the various shells, despite being a VI user...  A bit like
> using CSH at the terminal, but never for scripting :-)

I first learned about shell shortcuts from an emacs user, and I briefly 
considered picking up emacs... Then I found out I could enable vi 
keybinding in my shell and squashed that impulse. :)

The only emacs keybindings I still use in the shell are ^R for searching 
my history, ^W for deleting words, and occasional use of ^K for killing 
text to EOL.  Other than ^R, I swap between the vi and emacs bindings 
for those others, just depending on where my cursor is on the line.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ


From ggm at algebras.org  Tue Nov 20 10:55:41 2018
From: ggm at algebras.org (George Michaelson)
Date: Tue, 20 Nov 2018 10:55:41 +1000
Subject: [TUHS] man-page style
In-Reply-To: <3c7cb03bb23814934ba4ce5735e28b85@bl.org>
References: <20181117153919.6468B18C073@mercury.lcs.mit.edu>
 <e3239d92-0395-6c16-b01e-2e138e7a17b5@case.edu>
 <alpine.BSF.2.21.9999.1811191509050.60610@aneurin.horsfall.org>
 <3c7cb03bb23814934ba4ce5735e28b85@bl.org>
Message-ID: <CAKr6gn0_zCUiVy_A--3N5xrrka5-wR4Lx4qy2Xgcu1h+6smXTA@mail.gmail.com>

The infection vector feels to me to be X10->X11 -> Xorg.

When X became the ubiquitous desktop system in UNIX, it was bringing
with it the MIT key bindings for editing text inside panes in X
applications (clients). This was by default the Emacs bindings.

The default (pre Bash) shell on BSD, and hence Solaris, was BSD
derived csh. Thus tcsh which had by default emacs bindings. Ksh
required more licence hoops, in some cases you had to buy it. I . am
unsure if its default was vi mode, but the net impact was: if you ran
any desktop system on the main arc of purchase in a university or near
relationship, you ran Dec Ultrix (X11) or OSF/1 (X11) or SunOS (X11,
after their initial foray into their own) or Unisys/Motorola terminals
on a cray (X10/X11) or Humingbird X client on a WIndows PC (X11) or a
tectronix X terminal (X11) or an NCD x terminal (X11)

We got to default edit in the Mosaic for the URL browser bar, by way
of X11 clients: look at that ma: it inherited the MIT emacs key
bindings.

X was the virus. Emacs key bindings went viral.
On Tue, Nov 20, 2018 at 8:19 AM Michael Parson <mparson at bl.org> wrote:
>
>
> On 2018-11-18 22:15, Dave Horsfall wrote:
> > On Sun, 18 Nov 2018, Chet Ramey wrote:
> >
> >> It's not clear how widespread this is, but on my Mac OS X system,
> >> emacs key bindings are pervasive. TextEdit, text controls in apps and
> >> browsers, pretty much everything understands the basic emacs
> >> keybinding.
> >
> > As a Mac user I never noticed that, but I'll admit to using EMACS key
> > bindings in the various shells, despite being a VI user...  A bit like
> > using CSH at the terminal, but never for scripting :-)
>
> I first learned about shell shortcuts from an emacs user, and I briefly
> considered picking up emacs... Then I found out I could enable vi
> keybinding in my shell and squashed that impulse. :)
>
> The only emacs keybindings I still use in the shell are ^R for searching
> my history, ^W for deleting words, and occasional use of ^K for killing
> text to EOL.  Other than ^R, I swap between the vi and emacs bindings
> for those others, just depending on where my cursor is on the line.
>
> --
> Michael Parson
> Pflugerville, TX
> KF5LGQ


From arnold at skeeve.com  Tue Nov 20 16:52:38 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 19 Nov 2018 23:52:38 -0700
Subject: [TUHS] man-page style
In-Reply-To: <CAC20D2NKcBwdqiFTO4COeimyKEHx=LCvn_62-9i5=EpRS2BosQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <20181119173952.GA19377@thunk.org>
 <CAC20D2NKcBwdqiFTO4COeimyKEHx=LCvn_62-9i5=EpRS2BosQ@mail.gmail.com>
Message-ID: <201811200652.wAK6qcV1020423@freefriends.org>

Clem Cole <clemc at ccc.com> wrote:

> I think that's somewhat backwards in he spirit of 'UNIX'...  the man and
> info pages should reference the manual in /usr/doc/foo/

The goal for Info was to *be* the equivalent of /usr/doc/foo. Along the
way the default for Info changed to go to the 'invoking' section of a
manual so that you saw the options, arguably the most immediately
useful part of a man page, attempting to give the user the best of both
worlds.

All that said, I think this topic has been beaten to death. Info
did not successfully replace man pages.  As a file format, I think
that Info has very little left to offer.

What I do *love* is the Texinfo markup language, which is wonderful
for producing book-style documents.  And what's nice is that a
single input file can produce PDF, HTML and DocBook (as well as Info).

Arnold


From otto at drijf.net  Tue Nov 20 17:10:09 2018
From: otto at drijf.net (Otto Moerbeek)
Date: Tue, 20 Nov 2018 08:10:09 +0100
Subject: [TUHS] man-page style
In-Reply-To: <201811200652.wAK6qcV1020423@freefriends.org>
References: <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <20181119173952.GA19377@thunk.org>
 <CAC20D2NKcBwdqiFTO4COeimyKEHx=LCvn_62-9i5=EpRS2BosQ@mail.gmail.com>
 <201811200652.wAK6qcV1020423@freefriends.org>
Message-ID: <20181120071009.GJ18762@clue.drijf.net>

On Mon, Nov 19, 2018 at 11:52:38PM -0700, arnold at skeeve.com wrote:

> Clem Cole <clemc at ccc.com> wrote:
> 
> > I think that's somewhat backwards in he spirit of 'UNIX'...  the man and
> > info pages should reference the manual in /usr/doc/foo/
> 
> The goal for Info was to *be* the equivalent of /usr/doc/foo. Along the
> way the default for Info changed to go to the 'invoking' section of a
> manual so that you saw the options, arguably the most immediately
> useful part of a man page, attempting to give the user the best of both
> worlds.
> 
> All that said, I think this topic has been beaten to death. Info
> did not successfully replace man pages.  As a file format, I think
> that Info has very little left to offer.
> 
> What I do *love* is the Texinfo markup language, which is wonderful
> for producing book-style documents.  And what's nice is that a
> single input file can produce PDF, HTML and DocBook (as well as Info).
> 
> Arnold

I'd like to mention mandoc. It takes mdoc or man pages and produces
output in various formats. See e.g. http://man.openbsd.org/mandoc. The
formatting and links are derived from the semantic info in the source
pages.x

	-Otto



From dave at horsfall.org  Wed Nov 28 07:47:28 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 28 Nov 2018 08:47:28 +1100 (EST)
Subject: [TUHS] In Memoriam: J.F.Ossanna
Message-ID: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>

We lost J.F. Ossanna on this day in 1977; he had a hand in developing 
Unix, and was responsible for "roff" and its descendants.  Remember him, 
the next time you see "jfo" in Unix documentation.

-- Dave


From ken at google.com  Wed Nov 28 09:08:36 2018
From: ken at google.com (Ken Thompson)
Date: Tue, 27 Nov 2018 15:08:36 -0800
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
Message-ID: <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>

joe was much more than that. he knew how
to play the system. example:
out of whole cloth, he invented a form to
order a teletype and opx (bell labs extension)
installed in the home. he then filled out the
form for each of the unix-room dennisons.
there was a phone call from a confused
clerk, and then we all got teletypes and
data sets at home. as an aside, the opx
came with free watts (long distance which
was very expensive in those days.)


On Tue, Nov 27, 2018 at 1:47 PM, Dave Horsfall <dave at horsfall.org> wrote:
> We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix,
> and was responsible for "roff" and its descendants.  Remember him, the next
> time you see "jfo" in Unix documentation.
>
> -- Dave


From tuhs at eric.allman.name  Wed Nov 28 10:09:12 2018
From: tuhs at eric.allman.name (Eric Allman)
Date: Tue, 27 Nov 2018 16:09:12 -0800
Subject: [TUHS]  man-page style
In-Reply-To: <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
Message-ID: <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>

[I sent this almost a week ago, but it never showed up, probably because
my From address didn't match my subscription address.  Apologies if this
is a dup.]

On 2018-11-19 07:35 , Clem Cole wrote:
> As I said, if man had been maintained as the primary >>manual<< style
> interface and /usr/doc/<PROG>/foo.ms <http://foo.ms> as the primary
> scheme (which >>IS<< what BSD did), then you don't fail the rule of
> least astonishment. 

On 2018-11-19 09:39 , Theodore Y. Ts'o wrote:
> I'm not convinced the original BSD man page for, say, "make" is really
> sufficient to learn how to use make effectively w/o the expanded,
> non-man page write up in BSD Unix's Programmers Supplementary
> Documents.  So I dare say the goal that the man page should be the
> primary manual was a bit of an aspiration goal as well.

The /usr/doc/<PROG>/... convention started at least as far back as 7th
Edition (and I think 6th as well).  There was no attempt to make the man
page for yacc or troff document everything you needed to know --- they
basically listed the command line arguments and gave you a pointer to
the real manual, which went into far more depth than would be feasible
in a man page, sometimes including things like tables and figures (using
tbl and fig, of course).

Speaking of troff, that was interesting documentation.  Ossanna's
documentation told you exactly what all of the commands did, but didn't
say why they did it.  Many of the features seemed absolutely crazy at
first.  I probably read that document 50 times when writing the -me
macros, every time having a light bulb go off in my head.  I finally
concluded that _everything_ was needed to do something useful, and you
could do pretty much _anything_ with the available tools (including
things like page balancing).  A master work of design, and blissfully
complete documentation (even if a bit obscure to the newbie).

eric


From tuhs at eric.allman.name  Wed Nov 28 10:10:43 2018
From: tuhs at eric.allman.name (Eric Allman)
Date: Tue, 27 Nov 2018 16:10:43 -0800
Subject: [TUHS]  man-page style
In-Reply-To: <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
Message-ID: <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>

[I sent this almost a week ago, but it never showed up, probably because
my From address didn't match my subscription address.  Apologies if this
is a dup.]

I confirm Jon's observation.  It's true, sendmail wasn't "designed" in
the waterfall model sense, because at the time the email world was a
disaster, with new networks appearing seemingly daily, each of which
seemed to feel a need to come up with a new syntax for addresses.  Some
of those syntaxes were left-associative and some right-associative, and
there was no "correct" answer --- different sites wanted to parse the
same email address differently.  For example, consider:

	decvax!research!foo at berkeley

If you're on decvax you should send this to research.  If you're at
Berkeley you should send this to decvax.  And if you're on some other
site with an ARPAnet connection but without UUCP, you should send it to
Berkeley.  I concluded that something arbitrarily flexible (which meant
Turing Complete) was necessary.  Also, since some sites didn't
understand things like "@" signs in addresses, it was necessary to
rewrite the header so "reply" would work.  And all of this had to fit
into a 16-bit address space.

Life is easier today: the world has agreed on "user at domain", the
multitude of networks (e.g., UUCP, DECnet, CSNet, Berknet, ChaosNet,
PurdueNet, and possibly my favorite, a network out of the UK that used
"user at domain" but with the domain reversed, e.g., eric at edu.berkeley.cs
instead of eric at cs.berkeley.edu) is down to effectively one, and the
only 16-bit machines out there are not-very-powerful microcontrollers.
If I were building sendmail in this very different world, it would look
very different.

eric


On 2018-11-19 08:48 , Jon Steinhart wrote:
> Warner Losh writes:
>> On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart <jon at fourwinds.com> wrote:
>>
>>> Emacs sort of
>>> violates my UNIX-sense as it does many things instead of doing one thing
>>> well.
>>
>>
>> I'd argue that's not a bad thing. When people tried to add macros to make
>> or sendmail, you wound up with crazy like imake or the crazy sendfile.m4
>> stuff. Of course, sendmail and one thing aren't mates, but sometimes you
>> need to do a few, well chosen things well to avoid the crazy that trying to
>> misuse something will bring to the table.
>>
>> Warner
> 
> Funny that you bring this up as I was just talking to Eric about this.
> I was telling him that someone had recently asked me why sendmail was
> so complicated, and I explained to them that it was because email wasn't
> always like it is today; that there were many disparate email systems and
> sendmail glued them all together.  Eric said something like yeah, and I
> would have liked to have a better syntax but memory was too constrained
> at the time to let me do anything better.
> 


From g.branden.robinson at gmail.com  Wed Nov 28 10:36:40 2018
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 27 Nov 2018 19:36:40 -0500
Subject: [TUHS] man-page style
In-Reply-To: <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
Message-ID: <20181128003638.6jwx6fs4zxwzaote@crack.deadbeast.net>

At 2018-11-27T16:09:12-0800, Eric Allman wrote:
> Speaking of troff, that was interesting documentation.  Ossanna's
> documentation told you exactly what all of the commands did, but didn't
> say why they did it.  Many of the features seemed absolutely crazy at
> first.  I probably read that document 50 times when writing the -me
> macros, every time having a light bulb go off in my head.  I finally
> concluded that _everything_ was needed to do something useful, and you
> could do pretty much _anything_ with the available tools (including
> things like page balancing).  A master work of design, and blissfully
> complete documentation (even if a bit obscure to the newbie).

Hi Eric,

I've been working on groff, and a while back, amid tidying up the
groff_me(7) man page, I added the following to the Notes section:

.
It is not known for certain what the \(lqe\(rq in \(lqme\(rq stands for,
but one can infer a derivation from the first initial of Eric P.\&
Allman (then of the University of California), who wrote the original
technical papers documenting the package.
.

I've done some digging but could not locate an authoritative statement.
Would you like to make one?

This list has been helpful in clearing up some other historical
inaccuracies in the groff man pages, though surely some remain.

Regards,
Branden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181127/c996c81f/attachment.sig>

From tuhs at eric.allman.name  Wed Nov 28 10:57:43 2018
From: tuhs at eric.allman.name (Eric Allman)
Date: Tue, 27 Nov 2018 16:57:43 -0800
Subject: [TUHS] man-page style
In-Reply-To: <20181128003638.6jwx6fs4zxwzaote@crack.deadbeast.net>
References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
 <20181128003638.6jwx6fs4zxwzaote@crack.deadbeast.net>
Message-ID: <5684e5c4-f8ad-0b32-20f1-b4375733f2d2@neophilic.com>

On 2018-11-27 4:36 PM, G. Branden Robinson wrote:
> Hi Eric,
> 
> I've been working on groff, and a while back, amid tidying up the
> groff_me(7) man page, I added the following to the Notes section:
> 
> .
> It is not known for certain what the \(lqe\(rq in \(lqme\(rq stands for,
> but one can infer a derivation from the first initial of Eric P.\&
> Allman (then of the University of California), who wrote the original
> technical papers documenting the package.
> .
> 
> I've done some digging but could not locate an authoritative statement.
> Would you like to make one?

That's basically correct, but there is a back story.  When I started
writing the -me macros it began as something in my private tree (I don't
remember what I called it).  Then some other folks on the INGRES project
wanted to use it, but our system admin at the time didn't want to dicker
with the system namespace at the behest of a mere undergraduate, so he
didn't like anything that was actually descriptive lest people think it
was "official".  He finally consented to "-meric" (which I always
hated), since it was obviously non-official.  By the time my macros
became popular around Berkeley it got shortened to "-me", much to my relief.

Of course, if AT&T had been willing to let Berkeley have -ms then most
likely -me would never have happened at all.  Without a macro package,
nroff/troff is basically unusable; -me stepped into the vacuum.

Amusingly enough, one of the most popular features of -me was ".th"
mode, which set all the parameters to match the official constraints for
a U.C. Berkeley Ph.D. thesis.  It was guaranteed to get past the "dragon
lady" who would reject the thesis if the margins were wrong.

eric


From g.branden.robinson at gmail.com  Wed Nov 28 11:26:51 2018
From: g.branden.robinson at gmail.com (G. Branden Robinson)
Date: Tue, 27 Nov 2018 20:26:51 -0500
Subject: [TUHS] man-page style
In-Reply-To: <5684e5c4-f8ad-0b32-20f1-b4375733f2d2@neophilic.com>
References: <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
 <20181128003638.6jwx6fs4zxwzaote@crack.deadbeast.net>
 <5684e5c4-f8ad-0b32-20f1-b4375733f2d2@neophilic.com>
Message-ID: <20181128012650.vfd26xlimeoa4cqc@crack.deadbeast.net>

At 2018-11-27T16:57:43-0800, Eric Allman wrote:
> > It is not known for certain what the \(lqe\(rq in \(lqme\(rq stands for,
> > but one can infer a derivation from the first initial of Eric P.\&
> > Allman (then of the University of California), who wrote the original
> > technical papers documenting the package.
[...]
> That's basically correct, but there is a back story.  When I started
> writing the -me macros it began as something in my private tree (I don't
> remember what I called it).  Then some other folks on the INGRES project
> wanted to use it, but our system admin at the time didn't want to dicker
> with the system namespace at the behest of a mere undergraduate, so he
> didn't like anything that was actually descriptive lest people think it
> was "official".  He finally consented to "-meric" (which I always
> hated), since it was obviously non-official.  By the time my macros
> became popular around Berkeley it got shortened to "-me", much to my relief.

The shortening also prevented associations with an ignominious character
in an episode of the original _Star Trek_[1], which would surely have
been especially bad marketing in the geek culture of the time.

> Of course, if AT&T had been willing to let Berkeley have -ms then most
> likely -me would never have happened at all.  Without a macro package,
> nroff/troff is basically unusable; -me stepped into the vacuum.

I'm thinking it was an even larger example of silly cussedness because
by then, weren't the mm macros considered the new hotness at AT&T?

> Amusingly enough, one of the most popular features of -me was ".th"
> mode, which set all the parameters to match the official constraints for
> a U.C. Berkeley Ph.D. thesis.  It was guaranteed to get past the "dragon
> lady" who would reject the thesis if the margins were wrong.

It takes a computer to beat a computer.  :)

Thank you!  I'll update the man page.  We seem to be finally be on the
precipice of a groff 1.22.4 release (knock touchpad).

Regards,
Branden

[1] "Bread and Circuses"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181127/51cf6dfc/attachment.sig>

From lm at mcvoy.com  Wed Nov 28 12:57:39 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 27 Nov 2018 18:57:39 -0800
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
Message-ID: <20181128025739.GA5701@mcvoy.com>

As a long time roff fan (I still use it, yes, I've learned LaTex, I much
prefer roff), I'm hugely bummed that Joe left us so early.  I feel like
there would be more fun stories, like Ken's story.

If I remember correctly, he wrote the first (Unix *) version of roff in
PDP-11 assembly, right?  Granted, PDP-11 assembly is perhaps the most 
pleasant assembly ever, but it is still assembly.  Roff is a non-trivial
program, I can't say that I've every written anything remotely that big
in assembly (the only thing I'm proud of is writing swtch() in VAX, 68K,
and some other CPU that I can't remember, but that was tiny, hard to get
right, but tiny).  I've got mad respect for what he did, I feel like the
whole roff thing doesn't get enough respect.  It wasn't just roff, though
that started it, it was pic (I *love* pic), eqn, all the other filters
that go down to roff.  For lmbench I wrote my own grap like tools 
because grap wasn't open source.

I was talking to Marc Donner, a Morgan Stanley techy (since moved on
to google and who knows where) about why I liked roff.  At the time
I had built webroff which took roff -ms input and made websites.
Marc pointed out that the reason I liked roff was, for the most part,
it didn't say how to do something (that was buried in the macros),
it said what you wanted to do.

Ken, if you have more Joe stories I'd love to hear them, I feel like
I missed out on a cool person.

(*) I know that nroff was "new run off" and it came from somewhere,
MIT?  Some old system, but it wasn't invented in Unix.  That said,
I've never seen docs for the previous system and I kinda think Joe
took it to the next level.  If you haven't studied the docs and
written macros, you should.  It's a pretty neat system.

On Tue, Nov 27, 2018 at 03:08:36PM -0800, Ken Thompson via TUHS wrote:
> joe was much more than that. he knew how
> to play the system. example:
> out of whole cloth, he invented a form to
> order a teletype and opx (bell labs extension)
> installed in the home. he then filled out the
> form for each of the unix-room dennisons.
> there was a phone call from a confused
> clerk, and then we all got teletypes and
> data sets at home. as an aside, the opx
> came with free watts (long distance which
> was very expensive in those days.)
> 
> 
> On Tue, Nov 27, 2018 at 1:47 PM, Dave Horsfall <dave at horsfall.org> wrote:
> > We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix,
> > and was responsible for "roff" and its descendants.  Remember him, the next
> > time you see "jfo" in Unix documentation.
> >
> > -- Dave

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


From ken at google.com  Wed Nov 28 14:48:52 2018
From: ken at google.com (Ken Thompson)
Date: Tue, 27 Nov 2018 20:48:52 -0800
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <20181128025739.GA5701@mcvoy.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
Message-ID: <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>

another joe:

echo 1 was a 100 foot balloon that was
launched into space  in the early 60s. this
was the first satellite that was easily visible
to the naked eye.

joe wrote a set of fortran programs that
tracked the orbit of echo and calculated
the direction to look from a point on earth.
to do this, he had to learn fortran and
orbital dynamics.

the programs were used to point antennas
to send emf from california. bouncing off
echo and received at bell labs in
new jersey. thus, thanks to joe, echo was
the first communications satellite.

by the time i came to bell labs (1966) the
program, azel, for azimuth/elevation, was
expanded to track planets, moons, satellites,
etc. moreover, it tracked the shadow of the
earth cast by the sun (night). it could predict
within a few seconds when echo would wink
on or off as it passed through the shadow.

a version of azel was maintained all the time
i was at bell labs. we used it to predict
eclipses, transits, occultations etc. when
we first got a voice synthesizer, the day's
predictions were spoken at 5pm in case
there was anything interesting.

anyway, at 5pm on june 8, 1983 the voice
announced an "occultation of mercury"
for early the next morning.

no one had heard of such a thing. it was
extremely rare. mercury had to be at
about its max elongation; the moon had
to be only a few hours old (or young);
it had to be dark; the moon and mercury
had to be above the horizon; and lastly,
the moon had to occult mercury.

we all (me, lee mcmahon, dennis ritchie,
rob pike, and bob morris) frantically tried
to verify that it was real. it was, but it
would only be about 5 degrees above
the horizon facing right into new york city.
not a chance. we all went home.

later that night we were writing to each
other and calculating that in an airplane
at 10,000 feet, the event moved up to 10
or 15 degrees above the horizon. also,
in an airplane, we could avoid nyc.

so at 3am, we (me, rob pike, rae mclellan)
went to the airport equipped with cameras
and binoculars. we flew north as high as the
plane would go. we might be the only
people in the world who have seen an
occultation of mercury. thank you joe.


On Tue, Nov 27, 2018 at 6:57 PM, Larry McVoy <lm at mcvoy.com> wrote:
> As a long time roff fan (I still use it, yes, I've learned LaTex, I much
> prefer roff), I'm hugely bummed that Joe left us so early.  I feel like
> there would be more fun stories, like Ken's story.
>
> If I remember correctly, he wrote the first (Unix *) version of roff in
> PDP-11 assembly, right?  Granted, PDP-11 assembly is perhaps the most
> pleasant assembly ever, but it is still assembly.  Roff is a non-trivial
> program, I can't say that I've every written anything remotely that big
> in assembly (the only thing I'm proud of is writing swtch() in VAX, 68K,
> and some other CPU that I can't remember, but that was tiny, hard to get
> right, but tiny).  I've got mad respect for what he did, I feel like the
> whole roff thing doesn't get enough respect.  It wasn't just roff, though
> that started it, it was pic (I *love* pic), eqn, all the other filters
> that go down to roff.  For lmbench I wrote my own grap like tools
> because grap wasn't open source.
>
> I was talking to Marc Donner, a Morgan Stanley techy (since moved on
> to google and who knows where) about why I liked roff.  At the time
> I had built webroff which took roff -ms input and made websites.
> Marc pointed out that the reason I liked roff was, for the most part,
> it didn't say how to do something (that was buried in the macros),
> it said what you wanted to do.
>
> Ken, if you have more Joe stories I'd love to hear them, I feel like
> I missed out on a cool person.
>
> (*) I know that nroff was "new run off" and it came from somewhere,
> MIT?  Some old system, but it wasn't invented in Unix.  That said,
> I've never seen docs for the previous system and I kinda think Joe
> took it to the next level.  If you haven't studied the docs and
> written macros, you should.  It's a pretty neat system.
>
> On Tue, Nov 27, 2018 at 03:08:36PM -0800, Ken Thompson via TUHS wrote:
>> joe was much more than that. he knew how
>> to play the system. example:
>> out of whole cloth, he invented a form to
>> order a teletype and opx (bell labs extension)
>> installed in the home. he then filled out the
>> form for each of the unix-room dennisons.
>> there was a phone call from a confused
>> clerk, and then we all got teletypes and
>> data sets at home. as an aside, the opx
>> came with free watts (long distance which
>> was very expensive in those days.)
>>
>>
>> On Tue, Nov 27, 2018 at 1:47 PM, Dave Horsfall <dave at horsfall.org> wrote:
>> > We lost J.F. Ossanna on this day in 1977; he had a hand in developing Unix,
>> > and was responsible for "roff" and its descendants.  Remember him, the next
>> > time you see "jfo" in Unix documentation.
>> >
>> > -- Dave
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm


From fabio at esse.ch  Wed Nov 28 15:22:06 2018
From: fabio at esse.ch (Fabio Scotoni)
Date: Wed, 28 Nov 2018 06:22:06 +0100
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <20181128025739.GA5701@mcvoy.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
Message-ID: <987b698b-aeb8-5f85-a926-d142699237ea@esse.ch>

On 11/28/18 3:57 AM, Larry McVoy wrote:
> (*) I know that nroff was "new run off" and it came from somewhere,
> MIT?  Some old system, but it wasn't invented in Unix.  That said,
> I've never seen docs for the previous system and I kinda think Joe
> took it to the next level.  If you haven't studied the docs and
> written macros, you should.  It's a pretty neat system.

Kristaps Dzonsons actually went digging for that as part of his "History 
of UNIX Manpages" essay[1].  The abridged version is that roff goes back 
to a number of rewrites, the original being apparently RUNOFF on CTSS at 
MIT.  Source code for RUNOFF and documentation for various parts of 
troff history have been preserved on that page.  It looks 
well-researched, though I have no knowledge first hand.

[1] https://manpages.bsd.lv/history.html


From mutiny.mutiny at india.com  Wed Nov 28 19:20:36 2018
From: mutiny.mutiny at india.com (Donald ODona)
Date: Wed, 28 Nov 2018 09:20:36 +0000 (UTC)
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
Message-ID: <487083359.83071.1543396836749.JavaMail.tomcat@india-live-be03>

Joe sold the (not really existent) UNIX system to the patent department of AT&T, which in turn bought the urgently needed PDP11. Without that there would be no UNIX. Without Joe there would be no UNIX. 

At 27 Nov 2018 21:48:51 +0000 (+00:00) from Dave Horsfall <dave at horsfall.org>:
> We lost J.F. Ossanna on this day in 1977; he had a hand in developing 
> Unix, and was responsible for "roff" and its descendants.  Remember him, 
> the next time you see "jfo" in Unix documentation.
> 
> -- Dave


From jnc at mercury.lcs.mit.edu  Wed Nov 28 23:09:45 2018
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Wed, 28 Nov 2018 08:09:45 -0500 (EST)
Subject: [TUHS] In Memoriam: J.F.Ossanna
Message-ID: <20181128130945.3CE5D18C08E@mercury.lcs.mit.edu>

    > From: Larry McVoy

    > (*) I know that nroff was "new run off" and it came from somewhere, MIT?
    > Some old system ... I've never seen docs for the previous system and I
    > kinda think Joe took it to the next level.

Definitely!

The original 'runoff' was on CTSS, written by Jerry Saltzer. It had a
companion program, 'typset', which was an editor for preparing runoff input. A
memo describing them is available here:

  http://web.mit.edu/Saltzer/www/publications/ctss/AH.9.01.html

>From the look of things, it didn't have any macro capability.

Runoff was moved to Multics fairly early: here's its entry from the Multics
glossary:

  A Multics BCPL version of runoff was written by Doug McIlroy and Bob
  Morris. A version of runoff in PL/I was written by Dennis Capps in
  1974.
  ...
  Multics documentation was transitioned from the Flexowriters to use of
  runoff when the system became self-hosting about 1968. runoff was used for
  manuals, release bulletins, internal memos and other documentation for most
  of the 70s. To support this use, Multics runoff had many features such as
  multi-pass execution and variable definition and expansion that went far
  beyond the CTSS version. Multics manuals were formatted with complex macros,
  included by the document source, that handled tables of contents and
  standard formatting, and supported the single sourcing of the commands
  manual and the info files for commands.

So the BCPL version would have been before Bell exited the project. I'm not
sure if the 'macros' comment refers to the BCPL version, or the PL/I. Here's
the Multics 'info' segment about runoff:

  http://web.mit.edu/multics-history/source/Multics/doc/info_segments/runoff.info

which doesn't mention macros, but lists a few things that might be used for
macros. It refers to "the runoff command in the MPM Commands" volume (a
reference to "Multics Programmer's manual: Commands and Active Functions") for
details; this is available on bitsavers, see page 3-619 in "AG92-03A",
February 1980 edition.

	Noel


From crossd at gmail.com  Thu Nov 29 00:44:44 2018
From: crossd at gmail.com (Dan Cross)
Date: Wed, 28 Nov 2018 09:44:44 -0500
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
Message-ID: <CAEoi9W6-Nz-N7nMbMdfN7jhA9Fw1pfVBVGd8iVF0Rbivjd4T4A@mail.gmail.com>

On Tue, Nov 27, 2018 at 11:50 PM Ken Thompson via TUHS <tuhs at minnie.tuhs.org>
wrote:

> another joe:
>
> echo 1 was a 100 foot balloon that was
> launched into space  in the early 60s. this
> was the first satellite that was easily visible
> to the naked eye.
>
> joe wrote a set of fortran programs that
> tracked the orbit of echo and calculated
> the direction to look from a point on earth.
> to do this, he had to learn fortran and
> orbital dynamics.
>
> the programs were used to point antennas
> to send emf from california. bouncing off
> echo and received at bell labs in
> new jersey. thus, thanks to joe, echo was
> the first communications satellite.
>
> by the time i came to bell labs (1966) the
> program, azel, for azimuth/elevation, was
> expanded to track planets, moons, satellites,
> etc. moreover, it tracked the shadow of the
> earth cast by the sun (night). it could predict
> within a few seconds when echo would wink
> on or off as it passed through the shadow.
>

This is an amazing story; thanks for sharing, Ken.

There is an interesting film about project ECHO on youtube:
https://www.youtube.com/watch?v=sY8MeZ6lpwI

While it doesn't mention Joe Ossanna directly, there is a small part in the
film where the satellite is located after being launched. Given your story,
one might reasonably assume that that part of the narrative refers
to Ossanna's program, albeit indirectly.

Btw: I've heard that interference detected through the horn antenna at the
Holmdel site lead was explained by cosmic background radiation that was
attributed to the Big Bang; this apparently provided critical observational
evidence that led to the acceptance of the Big Bang theory.

a version of azel was maintained all the time
> i was at bell labs. we used it to predict
> eclipses, transits, occultations etc. when
> we first got a voice synthesizer, the day's
> predictions were spoken at 5pm in case
> there was anything interesting.
>
> anyway, at 5pm on june 8, 1983 the voice
> announced an "occultation of mercury"
> for early the next morning.
>
> no one had heard of such a thing. it was
> extremely rare. mercury had to be at
> about its max elongation; the moon had
> to be only a few hours old (or young);
> it had to be dark; the moon and mercury
> had to be above the horizon; and lastly,
> the moon had to occult mercury.
>
> we all (me, lee mcmahon, dennis ritchie,
> rob pike, and bob morris) frantically tried
> to verify that it was real. it was, but it
> would only be about 5 degrees above
> the horizon facing right into new york city.
> not a chance. we all went home.
>
> later that night we were writing to each
> other and calculating that in an airplane
> at 10,000 feet, the event moved up to 10
> or 15 degrees above the horizon. also,
> in an airplane, we could avoid nyc.
>
> so at 3am, we (me, rob pike, rae mclellan)
> went to the airport equipped with cameras
> and binoculars. we flew north as high as the
> plane would go. we might be the only
> people in the world who have seen an
> occultation of mercury. thank you joe.
>

!! That's neat.

        - Dan C.

On Tue, Nov 27, 2018 at 6:57 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > As a long time roff fan (I still use it, yes, I've learned LaTex, I much
> > prefer roff), I'm hugely bummed that Joe left us so early.  I feel like
> > there would be more fun stories, like Ken's story.
> >
> > If I remember correctly, he wrote the first (Unix *) version of roff in
> > PDP-11 assembly, right?  Granted, PDP-11 assembly is perhaps the most
> > pleasant assembly ever, but it is still assembly.  Roff is a non-trivial
> > program, I can't say that I've every written anything remotely that big
> > in assembly (the only thing I'm proud of is writing swtch() in VAX, 68K,
> > and some other CPU that I can't remember, but that was tiny, hard to get
> > right, but tiny).  I've got mad respect for what he did, I feel like the
> > whole roff thing doesn't get enough respect.  It wasn't just roff, though
> > that started it, it was pic (I *love* pic), eqn, all the other filters
> > that go down to roff.  For lmbench I wrote my own grap like tools
> > because grap wasn't open source.
> >
> > I was talking to Marc Donner, a Morgan Stanley techy (since moved on
> > to google and who knows where) about why I liked roff.  At the time
> > I had built webroff which took roff -ms input and made websites.
> > Marc pointed out that the reason I liked roff was, for the most part,
> > it didn't say how to do something (that was buried in the macros),
> > it said what you wanted to do.
> >
> > Ken, if you have more Joe stories I'd love to hear them, I feel like
> > I missed out on a cool person.
> >
> > (*) I know that nroff was "new run off" and it came from somewhere,
> > MIT?  Some old system, but it wasn't invented in Unix.  That said,
> > I've never seen docs for the previous system and I kinda think Joe
> > took it to the next level.  If you haven't studied the docs and
> > written macros, you should.  It's a pretty neat system.
> >
> > On Tue, Nov 27, 2018 at 03:08:36PM -0800, Ken Thompson via TUHS wrote:
> >> joe was much more than that. he knew how
> >> to play the system. example:
> >> out of whole cloth, he invented a form to
> >> order a teletype and opx (bell labs extension)
> >> installed in the home. he then filled out the
> >> form for each of the unix-room dennisons.
> >> there was a phone call from a confused
> >> clerk, and then we all got teletypes and
> >> data sets at home. as an aside, the opx
> >> came with free watts (long distance which
> >> was very expensive in those days.)
> >>
> >>
> >> On Tue, Nov 27, 2018 at 1:47 PM, Dave Horsfall <dave at horsfall.org>
> wrote:
> >> > We lost J.F. Ossanna on this day in 1977; he had a hand in developing
> Unix,
> >> > and was responsible for "roff" and its descendants.  Remember him,
> the next
> >> > time you see "jfo" in Unix documentation.
> >> >
> >> > -- Dave
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181128/a5cc73c2/attachment.html>

From paul.winalski at gmail.com  Thu Nov 29 03:08:17 2018
From: paul.winalski at gmail.com (Paul Winalski)
Date: Wed, 28 Nov 2018 12:08:17 -0500
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
Message-ID: <CABH=_VS0thKQW_cg3FjA0+1SL7NOw0yTAzMDk9fMKwyhUxms+A@mail.gmail.com>

On 11/27/18, Ken Thompson via TUHS <tuhs at minnie.tuhs.org> wrote:
> another joe:
>
> echo 1 was a 100 foot balloon that was
> launched into space  in the early 60s. this
> was the first satellite that was easily visible
> to the naked eye.
>
> joe wrote a set of fortran programs that
> tracked the orbit of echo and calculated
> the direction to look from a point on earth.
> to do this, he had to learn fortran and
> orbital dynamics.
>
> by the time i came to bell labs (1966) the
> program, azel, for azimuth/elevation, was
> expanded to track planets, moons, satellites,
> etc. moreover, it tracked the shadow of the
> earth cast by the sun (night). it could predict
> within a few seconds when echo would wink
> on or off as it passed through the shadow.
>
> a version of azel was maintained all the time
> i was at bell labs. we used it to predict
> eclipses, transits, occultations etc. when
> we first got a voice synthesizer, the day's
> predictions were spoken at 5pm in case
> there was anything interesting.
>
What a great story.  There is today a website (heavens-above.com) that
does the same thing as Joe's azel.  Amateur Astronomers visit it
regularly to get the night's predictions for visible satellite
transits, visible passes of the International Space Station, etc.  I
had no idea the idea went back that far.

-Paul W.


From lm at mcvoy.com  Thu Nov 29 03:17:25 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 28 Nov 2018 09:17:25 -0800
Subject: [TUHS] stories
Message-ID: <20181128171725.GJ5701@mcvoy.com>

Ken's story got me thinking about stuff I would still like to learn
and his comment about "when I got to Bell Labs"... made me wonder
how did Ken, Dennis, Brian, Joe and the rest of the crew make their
way to Bell Labs?

When I was just starting out, Sun was sort of the Bell Labs of the
time (not that Sun was the same as Bell Labs but it was sort of
the center of the Unix universe in my mind).  So I wanted to go
there and had to work at it a bit but I got there.

Was Bell Labs in the 60's like that?  If you were a geek was that
the place to go?  I was born in '62 so I don't have any memory of
how well known the Labs were back then.

So how was it that so many smart - and somewhat like minded it seems -
people end up there?

--lm


From earl.baugh at gmail.com  Thu Nov 29 03:57:48 2018
From: earl.baugh at gmail.com (Earl Baugh)
Date: Wed, 28 Nov 2018 12:57:48 -0500
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
Message-ID: <CANcLFn58t6CbO9Q2v6SYJgr9kZ24AY+1yXr108j=-U9bEL3uWQ@mail.gmail.com>

I don't know if this was just me, but the inner geek in me first thought
was  "How did the pictures turn out"? :-)
(the second thought was "Joe is now a hero to me" even thought I didn't
meet him... and this sounds sooo much like what
I've done with other geeky friends in college,  etc... ).

An example today, I got a Bluetooth water bottle (as part of a reward for
something at work)
and when I set it up it needed a firmware update, which I thought was cool
(and my wife just rolled her eyes...). :-)

Earl

On Tue, Nov 27, 2018 at 11:50 PM Ken Thompson via TUHS <tuhs at minnie.tuhs.org>
wrote:

> another joe:
>
> echo 1 was a 100 foot balloon that was
> launched into space  in the early 60s. this
> was the first satellite that was easily visible
> to the naked eye.
>
> joe wrote a set of fortran programs that
> tracked the orbit of echo and calculated
> the direction to look from a point on earth.
> to do this, he had to learn fortran and
> orbital dynamics.
>
> the programs were used to point antennas
> to send emf from california. bouncing off
> echo and received at bell labs in
> new jersey. thus, thanks to joe, echo was
> the first communications satellite.
>
> by the time i came to bell labs (1966) the
> program, azel, for azimuth/elevation, was
> expanded to track planets, moons, satellites,
> etc. moreover, it tracked the shadow of the
> earth cast by the sun (night). it could predict
> within a few seconds when echo would wink
> on or off as it passed through the shadow.
>
> a version of azel was maintained all the time
> i was at bell labs. we used it to predict
> eclipses, transits, occultations etc. when
> we first got a voice synthesizer, the day's
> predictions were spoken at 5pm in case
> there was anything interesting.
>
> anyway, at 5pm on june 8, 1983 the voice
> announced an "occultation of mercury"
> for early the next morning.
>
> no one had heard of such a thing. it was
> extremely rare. mercury had to be at
> about its max elongation; the moon had
> to be only a few hours old (or young);
> it had to be dark; the moon and mercury
> had to be above the horizon; and lastly,
> the moon had to occult mercury.
>
> we all (me, lee mcmahon, dennis ritchie,
> rob pike, and bob morris) frantically tried
> to verify that it was real. it was, but it
> would only be about 5 degrees above
> the horizon facing right into new york city.
> not a chance. we all went home.
>
> later that night we were writing to each
> other and calculating that in an airplane
> at 10,000 feet, the event moved up to 10
> or 15 degrees above the horizon. also,
> in an airplane, we could avoid nyc.
>
> so at 3am, we (me, rob pike, rae mclellan)
> went to the airport equipped with cameras
> and binoculars. we flew north as high as the
> plane would go. we might be the only
> people in the world who have seen an
> occultation of mercury. thank you joe.
>
>
> On Tue, Nov 27, 2018 at 6:57 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > As a long time roff fan (I still use it, yes, I've learned LaTex, I much
> > prefer roff), I'm hugely bummed that Joe left us so early.  I feel like
> > there would be more fun stories, like Ken's story.
> >
> > If I remember correctly, he wrote the first (Unix *) version of roff in
> > PDP-11 assembly, right?  Granted, PDP-11 assembly is perhaps the most
> > pleasant assembly ever, but it is still assembly.  Roff is a non-trivial
> > program, I can't say that I've every written anything remotely that big
> > in assembly (the only thing I'm proud of is writing swtch() in VAX, 68K,
> > and some other CPU that I can't remember, but that was tiny, hard to get
> > right, but tiny).  I've got mad respect for what he did, I feel like the
> > whole roff thing doesn't get enough respect.  It wasn't just roff, though
> > that started it, it was pic (I *love* pic), eqn, all the other filters
> > that go down to roff.  For lmbench I wrote my own grap like tools
> > because grap wasn't open source.
> >
> > I was talking to Marc Donner, a Morgan Stanley techy (since moved on
> > to google and who knows where) about why I liked roff.  At the time
> > I had built webroff which took roff -ms input and made websites.
> > Marc pointed out that the reason I liked roff was, for the most part,
> > it didn't say how to do something (that was buried in the macros),
> > it said what you wanted to do.
> >
> > Ken, if you have more Joe stories I'd love to hear them, I feel like
> > I missed out on a cool person.
> >
> > (*) I know that nroff was "new run off" and it came from somewhere,
> > MIT?  Some old system, but it wasn't invented in Unix.  That said,
> > I've never seen docs for the previous system and I kinda think Joe
> > took it to the next level.  If you haven't studied the docs and
> > written macros, you should.  It's a pretty neat system.
> >
> > On Tue, Nov 27, 2018 at 03:08:36PM -0800, Ken Thompson via TUHS wrote:
> >> joe was much more than that. he knew how
> >> to play the system. example:
> >> out of whole cloth, he invented a form to
> >> order a teletype and opx (bell labs extension)
> >> installed in the home. he then filled out the
> >> form for each of the unix-room dennisons.
> >> there was a phone call from a confused
> >> clerk, and then we all got teletypes and
> >> data sets at home. as an aside, the opx
> >> came with free watts (long distance which
> >> was very expensive in those days.)
> >>
> >>
> >> On Tue, Nov 27, 2018 at 1:47 PM, Dave Horsfall <dave at horsfall.org>
> wrote:
> >> > We lost J.F. Ossanna on this day in 1977; he had a hand in developing
> Unix,
> >> > and was responsible for "roff" and its descendants.  Remember him,
> the next
> >> > time you see "jfo" in Unix documentation.
> >> >
> >> > -- Dave
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181128/52809fbb/attachment.html>

From rminnich at gmail.com  Thu Nov 29 04:23:42 2018
From: rminnich at gmail.com (ron minnich)
Date: Wed, 28 Nov 2018 10:23:42 -0800
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
Message-ID: <CAP6exY+9+YdawXwXvUjgLdXvU4sjuT=RdHks3KD_V_LfD3GFew@mail.gmail.com>

Just curious, was that voice synthesizer a votrax or some other thing?


From ches at cheswick.com  Thu Nov 29 05:03:26 2018
From: ches at cheswick.com (WIlliam Cheswick)
Date: Wed, 28 Nov 2018 14:03:26 -0500
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CABH=_VS0thKQW_cg3FjA0+1SL7NOw0yTAzMDk9fMKwyhUxms+A@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
 <CABH=_VS0thKQW_cg3FjA0+1SL7NOw0yTAzMDk9fMKwyhUxms+A@mail.gmail.com>
Message-ID: <32C0991D-E4AE-4729-B133-7FB84A0E83E1@cheswick.com>


> On Nov 28, 2018, at 12:08 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
>> a version of azel was maintained all the time
>> i was at bell labs. we used it to predict
>> eclipses, transits, occultations etc. when
>> we first got a voice synthesizer, the day's
>> predictions were spoken at 5pm in case
>> there was anything interesting.

Was this the source or inspiration for astro(1)?  Ken’s astro was run daily to announce
things in the Unix room, and in my home up until recently to time turning on the lights in the
evening.  (My home still does the Unix-room style astro announcements, but in the morning
at 8:05).

It is available in the Plan 9 for Unix stuff (https://codeload.github.com/9fans/plan9port/zip/master <https://codeload.github.com/9fans/plan9port/zip/master>)


ches

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

From ches at cheswick.com  Thu Nov 29 05:04:39 2018
From: ches at cheswick.com (WIlliam Cheswick)
Date: Wed, 28 Nov 2018 14:04:39 -0500
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <CABH=_VS0thKQW_cg3FjA0+1SL7NOw0yTAzMDk9fMKwyhUxms+A@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
 <CABH=_VS0thKQW_cg3FjA0+1SL7NOw0yTAzMDk9fMKwyhUxms+A@mail.gmail.com>
Message-ID: <90E67DFA-981B-42C6-8F59-CED4B3B30BEB@cheswick.com>

>Just curious, was that voice synthesizer a votrax or some other thing?

Doug, tell the Disney story!

ches



From dave at horsfall.org  Thu Nov 29 13:54:27 2018
From: dave at horsfall.org (Dave Horsfall)
Date: Thu, 29 Nov 2018 14:54:27 +1100 (EST)
Subject: [TUHS] In Memoriam: J.F.Ossanna
In-Reply-To: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.1811291439470.14680@aneurin.horsfall.org>

Blimey!  I never thought that I would get such a huge response; there's no 
way that I can summarise everything in a single paragraph next year, but 
I'll see what I can do.

Thanks, JFO, for everything.

-- Dave


From lars at nocrew.org  Thu Nov 29 15:51:14 2018
From: lars at nocrew.org (Lars Brinkhoff)
Date: Thu, 29 Nov 2018 05:51:14 +0000
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
 (jsteve@superglobalmegacorp.com's message of "Sat, 17 Nov 2018
 21:41:05 +0800")
References: <7wh8gfalyn.fsf@junk.nocrew.org>
 <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
Message-ID: <7w1s74o2i5.fsf@junk.nocrew.org>

jsteve at superglobalmegacorp.com writes:
> > I have 4.1BSD running with Chaosnet patches from MIT. I'm adding a
> > Unibus CH11 network interface to SIMH. It's not working fully yet,
> > but it's close.
> Please post updates as you go!!!

It's working now.  I have also tested MINITS running on the pdp11
simulator.  MINITS is a Chaosnet gateway, router, terminal concentrator,
graphical display, printer server, etc.

At one point there existed Chaosnet patches for PDP-11 Unix V7, but so
far I haven't found them.


From kevin.bowling at kev009.com  Thu Nov 29 17:20:11 2018
From: kevin.bowling at kev009.com (Kevin Bowling)
Date: Thu, 29 Nov 2018 00:20:11 -0700
Subject: [TUHS] stories
In-Reply-To: <20181128171725.GJ5701@mcvoy.com>
References: <20181128171725.GJ5701@mcvoy.com>
Message-ID: <CAK7dMtBDGKt5JtTKiaW9NBcd7neZskX45FBhWef0=ah3bA5G9Q@mail.gmail.com>

Amateur historian perspective on what supported this, not sure how
recruiting and day to day worked hopefully first parties can teach us.

* Military Industrial Complex promoted projects of grandeur in large
industrials like Bell that are probably beyond comprehension of most
recent generations (Dew line
https://www.youtube.com/watch?v=rSSrPCE0smo, SAC-NORAD, SAGE, AUTOVON,
Telstar, etc)
* Subscriber base of general public telecom had immense scale and
reliability requirements that supported both rapid R&D and
engineering/operations progress
* Power of monopoly (see Peter Thiel's Zero to One book)

I think in light of scale and difficulty of all the work going on in
physics, electronics manufacturing/scaling, optics, RF etc the
computing work was relatively small in scope to administrators.  Why
would you not create an OS or microprocessor in such an environment?

I have some good books on this to recommend:
* The Idea Factory - most recent and popular
* A History of Engineering and Science in the Bell System - 6 volumes
on different topics that show a pretty insane progression over 100
years, not sure any other company had endured that much change

There are some organizations that are vaguely like that today like IBM
Research, SRI, Riken.  There used to be more like Xerox PARC.

I do wonder if things like twitter and facebook have in effect dumbed
down the population through increased distraction and reduced
attention span.  I believe there are some studies on the later.  As
far as market forces, lots of smart people are working at stupid
companies like Facebook and Google these days.  So people are less
effectively organized and working on less interesting things with less
attention span.

Regards,
Kevin
On Wed, Nov 28, 2018 at 10:17 AM Larry McVoy <lm at mcvoy.com> wrote:
>
> Ken's story got me thinking about stuff I would still like to learn
> and his comment about "when I got to Bell Labs"... made me wonder
> how did Ken, Dennis, Brian, Joe and the rest of the crew make their
> way to Bell Labs?
>
> When I was just starting out, Sun was sort of the Bell Labs of the
> time (not that Sun was the same as Bell Labs but it was sort of
> the center of the Unix universe in my mind).  So I wanted to go
> there and had to work at it a bit but I got there.
>
> Was Bell Labs in the 60's like that?  If you were a geek was that
> the place to go?  I was born in '62 so I don't have any memory of
> how well known the Labs were back then.
>
> So how was it that so many smart - and somewhat like minded it seems -
> people end up there?
>
> --lm


From arnold at skeeve.com  Thu Nov 29 17:25:56 2018
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Thu, 29 Nov 2018 00:25:56 -0700
Subject: [TUHS] man-page style
In-Reply-To: <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
Message-ID: <201811290725.wAT7PuE1019145@freefriends.org>

Eric Allman <tuhs at eric.allman.name> wrote:

> [I sent this almost a week ago, but it never showed up, probably because
> Speaking of troff, that was interesting documentation.  Ossanna's
> documentation told you exactly what all of the commands did, but didn't
> say why they did it.  Many of the features seemed absolutely crazy at
> first.  I probably read that document 50 times when writing the -me
> macros, every time having a light bulb go off in my head.  I finally
> concluded that _everything_ was needed to do something useful, and you
> could do pretty much _anything_ with the available tools (including
> things like page balancing).  A master work of design, and blissfully
> complete documentation (even if a bit obscure to the newbie).

Any chance you, or someone else, could write that missing manual that
explains the "why" of the various troff features?

I've been through CSTR 54 a few times too, although I haven't tried
to write a macro package from scratch, and I have to admit that there
are things that mystify me.

Thanks!

Arnold


From imp at bsdimp.com  Fri Nov 30 01:35:16 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 29 Nov 2018 08:35:16 -0700
Subject: [TUHS] Chaosnet for 4.1BSD
In-Reply-To: <7w1s74o2i5.fsf@junk.nocrew.org>
References: <7wh8gfalyn.fsf@junk.nocrew.org>
 <8dfb5a4b-ed9c-4ec4-bc46-dbb17647aacb@SG2APC01FT033.eop-APC01.prod.protection.outlook.com>
 <7w1s74o2i5.fsf@junk.nocrew.org>
Message-ID: <CANCZdfoE6Rixitnqkb6XHe_=OQRHJOvxyOYqSeJzgKn7oaMTsA@mail.gmail.com>

On Wed, Nov 28, 2018 at 10:51 PM Lars Brinkhoff <lars at nocrew.org> wrote:

> jsteve at superglobalmegacorp.com writes:
> > > I have 4.1BSD running with Chaosnet patches from MIT. I'm adding a
> > > Unibus CH11 network interface to SIMH. It's not working fully yet,
> > > but it's close.
> > Please post updates as you go!!!
>
> It's working now.  I have also tested MINITS running on the pdp11
> simulator.  MINITS is a Chaosnet gateway, router, terminal concentrator,
> graphical display, printer server, etc.
>
> At one point there existed Chaosnet patches for PDP-11 Unix V7, but so
> far I haven't found them.
>

They sound interesting... hopefully the resurface. The hackmem describes
all the changes needed, but it's a poor substitute for the code.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181129/5eb410d4/attachment.html>

From doug at cs.dartmouth.edu  Fri Nov 30 03:07:33 2018
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 29 Nov 2018 12:07:33 -0500
Subject: [TUHS] In Memoriam: J. F. Ossanna
Message-ID: <201811291707.wATH7XsM107856@tahoe.cs.Dartmouth.EDU>

> Joe sold the (not really existent) UNIX system to the patent department of AT&T,
> which in turn bought the urgently needed PDP11. Without that there would be no
> UNIX. Without Joe there would be no UNIX.

That one's an urban legend. The PDP-11 was indeed a gift from another department,
thanks to a year-end budget surplus. Unix was up and running on that machine when
Joe corralled the patent department.

Nevertheless the story is consistent with Joe's talent for playing (or skirting)
the system to get things done. After Joe, the talent resurfaced in the
person of Fred Grampp. Lots of tales await Grampp's popping up from Dave
Horsford's calendar.

> Runoff was moved to Multics fairly early: here's its entry from the Multics
> glossary: "A Multics BCPL version of runoff was written by Doug McIlroy
> and Bob  Morris."

Morris did one port and called it roff. I did the BCPL one, adding registers,
but not macros. Molly Wagner contributed a hyphenation algorithm. Ken
and/or Dennis redid roff in PDP-11 assembler. Joe started afresh for the
grander nroff, including macros. Then Joe bought a phototypesetter ...

> Sun was sort of the Bell Labs of the time ... I wanted to go there and had
> to work at it a bit but I got there. Was Bell Labs in the 60's like that?

Yes, in desirability. But Bell Labs had far more diverse interests. Telephones,
theoretical physics, submarine cables, music, speech, fiber optics, Apollo.
Wahtever you wanted to know or work on, you were likely to find kindred
types and willing management.

> was that voice synthesizer a votrax or some other thing?

Yes. Credit Joe again. He had a penchant for hooking up novel equipment.
When the Votrax arrived, its output was made accessible by phone and also
by loudspeaker in the Unix lab. You had to feed it a stream of ASCII-
encoded phonemes. Lee McMahon promptly became adept at writing them
down. After a couple of days' play in the lab, Lee was working in his
office with the Votrax on speakerphone in the background. Giving no
notice, he typed the phonemes for "It sounds better over the telephone".
Everyone in the lab heard it clearly--our own "Watson, come here" moment.

But phonemes are tedious. Believing that it could ease the
task of phonetic transcription, I wrote a phonics program, "speak",
through which you could feed English text for conversion to
phonemes. At speak's inaugural run, Bob Morris typed one word,
"oarlock", and pronounced the program a success. Luckily he didn't
try "coworker", which the program would have rendered as "cow orker".
Max Matthews from acoustics research called it a breakthrough.
The acoustics folks could synthesize much better speech, but it
took minutes of computing to synthesize seconds of sounds. So
the Unix lab heard more synthetic speech in a few days than the
experts had created over all time.

One thing we learned is that people quickly get used
to poor synthetic speech just like they get used to
foreign accents. In fact, non-native speakers opined
that the Votrax was easier to understand than real people,
probably due to the bit of silence that the speak program
inserted between words to help with mental segmentation.
One evening someone in the Unix room playing with the
synthesizer noticed a night janitor listening in from
the corridor. In a questionable abuse of a non-exempt
employee, the Unix person typed, "Stop hanging around
around and get back to work." The poor janitor fled.

AT&T installed speak for the public to play with at Epcot.
Worried that folks would enter bad words that everybody
standing around could hear, they asked if I could filter them
out. Sure, I said, just provide me with a list of what to
delete. Duly, I received on letterhead from the VP for
public relations a list of perhaps twenty bad words. (I have
always wondered about the politics of asking a secretary to
type that letter.) It was reported that girls would try the
machine on people's names, while boys would discover that
the machine "didn't know" bad words (though it would happily
pronounce phonetic misspellings). Alas, I mistakenly discarded
the infamous letter in cleaning house to leave Bell Labs.

Doug



From ewayte at gmail.com  Fri Nov 30 03:41:51 2018
From: ewayte at gmail.com (Eric Wayte)
Date: Thu, 29 Nov 2018 12:41:51 -0500
Subject: [TUHS] In Memoriam: J. F. Ossanna
In-Reply-To: <201811291707.wATH7XsM107856@tahoe.cs.Dartmouth.EDU>
References: <201811291707.wATH7XsM107856@tahoe.cs.Dartmouth.EDU>
Message-ID: <CAJc6K3XcdUMnfSMNbEo4Qypj_1BPcM6XV5ptB1=+CE8bLbM6=g@mail.gmail.com>

http://www.lostepcot.com/communicore.html - there's a description of
Phraser, which was the name given to speak at EPCOT.  I remember playing
with it, and getting it to say bad words!

On Thu, Nov 29, 2018 at 12:08 PM Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> > Joe sold the (not really existent) UNIX system to the patent department
> of AT&T,
> > which in turn bought the urgently needed PDP11. Without that there would
> be no
> > UNIX. Without Joe there would be no UNIX.
>
> That one's an urban legend. The PDP-11 was indeed a gift from another
> department,
> thanks to a year-end budget surplus. Unix was up and running on that
> machine when
> Joe corralled the patent department.
>
> Nevertheless the story is consistent with Joe's talent for playing (or
> skirting)
> the system to get things done. After Joe, the talent resurfaced in the
> person of Fred Grampp. Lots of tales await Grampp's popping up from Dave
> Horsford's calendar.
>
> > Runoff was moved to Multics fairly early: here's its entry from the
> Multics
> > glossary: "A Multics BCPL version of runoff was written by Doug McIlroy
> > and Bob  Morris."
>
> Morris did one port and called it roff. I did the BCPL one, adding
> registers,
> but not macros. Molly Wagner contributed a hyphenation algorithm. Ken
> and/or Dennis redid roff in PDP-11 assembler. Joe started afresh for the
> grander nroff, including macros. Then Joe bought a phototypesetter ...
>
> > Sun was sort of the Bell Labs of the time ... I wanted to go there and
> had
> > to work at it a bit but I got there. Was Bell Labs in the 60's like that?
>
> Yes, in desirability. But Bell Labs had far more diverse interests.
> Telephones,
> theoretical physics, submarine cables, music, speech, fiber optics, Apollo.
> Wahtever you wanted to know or work on, you were likely to find kindred
> types and willing management.
>
> > was that voice synthesizer a votrax or some other thing?
>
> Yes. Credit Joe again. He had a penchant for hooking up novel equipment.
> When the Votrax arrived, its output was made accessible by phone and also
> by loudspeaker in the Unix lab. You had to feed it a stream of ASCII-
> encoded phonemes. Lee McMahon promptly became adept at writing them
> down. After a couple of days' play in the lab, Lee was working in his
> office with the Votrax on speakerphone in the background. Giving no
> notice, he typed the phonemes for "It sounds better over the telephone".
> Everyone in the lab heard it clearly--our own "Watson, come here" moment.
>
> But phonemes are tedious. Believing that it could ease the
> task of phonetic transcription, I wrote a phonics program, "speak",
> through which you could feed English text for conversion to
> phonemes. At speak's inaugural run, Bob Morris typed one word,
> "oarlock", and pronounced the program a success. Luckily he didn't
> try "coworker", which the program would have rendered as "cow orker".
> Max Matthews from acoustics research called it a breakthrough.
> The acoustics folks could synthesize much better speech, but it
> took minutes of computing to synthesize seconds of sounds. So
> the Unix lab heard more synthetic speech in a few days than the
> experts had created over all time.
>
> One thing we learned is that people quickly get used
> to poor synthetic speech just like they get used to
> foreign accents. In fact, non-native speakers opined
> that the Votrax was easier to understand than real people,
> probably due to the bit of silence that the speak program
> inserted between words to help with mental segmentation.
> One evening someone in the Unix room playing with the
> synthesizer noticed a night janitor listening in from
> the corridor. In a questionable abuse of a non-exempt
> employee, the Unix person typed, "Stop hanging around
> around and get back to work." The poor janitor fled.
>
> AT&T installed speak for the public to play with at Epcot.
> Worried that folks would enter bad words that everybody
> standing around could hear, they asked if I could filter them
> out. Sure, I said, just provide me with a list of what to
> delete. Duly, I received on letterhead from the VP for
> public relations a list of perhaps twenty bad words. (I have
> always wondered about the politics of asking a secretary to
> type that letter.) It was reported that girls would try the
> machine on people's names, while boys would discover that
> the machine "didn't know" bad words (though it would happily
> pronounce phonetic misspellings). Alas, I mistakenly discarded
> the infamous letter in cleaning house to leave Bell Labs.
>
> Doug
>
>

-- 
Eric Wayte
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181129/638adb18/attachment.html>

From toby at telegraphics.com.au  Fri Nov 30 03:54:55 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 29 Nov 2018 12:54:55 -0500
Subject: [TUHS] [OT] azel - was Re:  In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
Message-ID: <c0f31860-8e96-f4ea-4442-17eaacb564bb@telegraphics.com.au>

On 2018-11-27 11:48 PM, Ken Thompson via TUHS wrote:
> ...
> a version of azel was maintained all the time
> i was at bell labs. 

As soon as I read this it's been on my mind to ask: Does this program
survive? Presumably it was Fortran? What did it run on?

--Toby



From imp at bsdimp.com  Fri Nov 30 03:57:07 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 29 Nov 2018 10:57:07 -0700
Subject: [TUHS] [OT] azel - was Re: In Memoriam: J.F.Ossanna
In-Reply-To: <c0f31860-8e96-f4ea-4442-17eaacb564bb@telegraphics.com.au>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
 <c0f31860-8e96-f4ea-4442-17eaacb564bb@telegraphics.com.au>
Message-ID: <CANCZdfpptsEL3Ay6B4fFn45wjEuRbmDoXwHBxinxw6qpS-e1DA@mail.gmail.com>

On Thu, Nov 29, 2018 at 10:55 AM Toby Thain <toby at telegraphics.com.au>
wrote:

> On 2018-11-27 11:48 PM, Ken Thompson via TUHS wrote:
> > ...
> > a version of azel was maintained all the time
> > i was at bell labs.
>
> As soon as I read this it's been on my mind to ask: Does this program
> survive? Presumably it was Fortran? What did it run on?
>

References to it are in the unix man pages, but the actual program doesn't
seem to be in the extant unix images.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181129/64f06cd7/attachment.html>

From tuhs at eric.allman.name  Fri Nov 30 04:20:26 2018
From: tuhs at eric.allman.name (Eric Allman)
Date: Thu, 29 Nov 2018 10:20:26 -0800
Subject: [TUHS] man-page style
In-Reply-To: <201811290725.wAT7PuE1019145@freefriends.org>
References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU>
 <20181116045016.GK3341@mcvoy.com>
 <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
 <201811290725.wAT7PuE1019145@freefriends.org>
Message-ID: <2155b676-a250-926c-1236-1e413cb2019f@neophilic.com>


On 2018-11-28 23:25 , arnold at skeeve.com wrote:

> Any chance you, or someone else, could write that missing manual that
> explains the "why" of the various troff features?
> 
> I've been through CSTR 54 a few times too, although I haven't tried
> to write a macro package from scratch, and I have to admit that there
> are things that mystify me.

At this point it's been so many years since I was actively working on
troff that it would require more-or-less starting from zero.  Perhaps
when I retire I'll have that kind of time.

eric


From lm at mcvoy.com  Fri Nov 30 04:48:45 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Nov 2018 10:48:45 -0800
Subject: [TUHS] man-page style
In-Reply-To: <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
Message-ID: <20181129184845.GB18414@mcvoy.com>

> If I were building sendmail in this very different world, it would look
> very different.
> 
> eric

Indeed.  Sendmail got a lot of hate but mostly from people in pure
user at host.domain worlds.  I lived in the UUCP / BitNet / Arpanet
world and while sendmail was definitely not the easiest thing to
configure, once you got it right it just kept working (unlike UUCP
that seemed to need constant babysitting).


From lm at mcvoy.com  Fri Nov 30 04:52:15 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Nov 2018 10:52:15 -0800
Subject: [TUHS] man-page style
In-Reply-To: <2155b676-a250-926c-1236-1e413cb2019f@neophilic.com>
References: <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <e8810295-5146-e126-a4d8-65e814f4b431@case.edu>
 <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com>
 <CAC20D2PgaGSHbQuL+xuq0jpDGYVkTpG7chNcbWcVK-T=j80Sjg@mail.gmail.com>
 <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com>
 <201811290725.wAT7PuE1019145@freefriends.org>
 <2155b676-a250-926c-1236-1e413cb2019f@neophilic.com>
Message-ID: <20181129185215.GC18414@mcvoy.com>

On 2018-11-28 23:25 , arnold at skeeve.com wrote:
> Any chance you, or someone else, could write that missing manual that
> explains the "why" of the various troff features?
> 
> I've been through CSTR 54 a few times too, although I haven't tried
> to write a macro package from scratch, and I have to admit that there
> are things that mystify me.

There is a lot to be mystified about in *roff but there is a lot to like
as well.  If you are going to start to look into one, I'd strongly urge
you to look at groff & friends.  It's by far the most actively developed
tool in the roff family.

I'm happy to answer what questions I can (though there is stuff that's
faded like the whole environment stack thing).  I've not written an
entire macro package either, but I've written a bunch of macros.  And
done a bunch of stuff in pic, I love pic.  I got James to put the

`i'th last <whatever>

construct into pic.  Super useful.


From gtaylor at tnetconsulting.net  Fri Nov 30 05:13:53 2018
From: gtaylor at tnetconsulting.net (Grant Taylor)
Date: Thu, 29 Nov 2018 12:13:53 -0700
Subject: [TUHS] man-page style
In-Reply-To: <20181129184845.GB18414@mcvoy.com>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
Message-ID: <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>

On 11/29/2018 11:48 AM, Larry McVoy wrote:
> Indeed.  Sendmail got a lot of hate but mostly from people in pure 
> user at host.domain worlds.

Do you have any idea why the user at host.domain community hated on 
Sendmail more than other communities?

> I lived in the UUCP / BitNet / Arpanet world and while sendmail was 
> definitely not the easiest thing to configure, once you got it right it 
> just kept working (unlike UUCP that seemed to need constant babysitting).

I think that's still fair to say.

Though simple Sendmail configurations are relatively easy to set up.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20181129/c9e0f30b/attachment.bin>

From lm at mcvoy.com  Fri Nov 30 05:28:35 2018
From: lm at mcvoy.com (Larry McVoy)
Date: Thu, 29 Nov 2018 11:28:35 -0800
Subject: [TUHS] man-page style
In-Reply-To: <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>
References: <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>
Message-ID: <20181129192835.GE18414@mcvoy.com>

On Thu, Nov 29, 2018 at 12:13:53PM -0700, Grant Taylor via TUHS wrote:
> On 11/29/2018 11:48 AM, Larry McVoy wrote:
> >Indeed.  Sendmail got a lot of hate but mostly from people in pure
> >user at host.domain worlds.
> 
> Do you have any idea why the user at host.domain community hated on Sendmail
> more than other communities?

I can't back this up with a citation but my belief is that was just that
everything worked for them, it was a simple system, you could write an
SMTP server in a tiny perl script, so why all the complexity?

If you live in a simple world you see things as being simple.  Sendmail
was not living in a simple world.

> >I lived in the UUCP / BitNet / Arpanet world and while sendmail was
> >definitely not the easiest thing to configure, once you got it right it
> >just kept working (unlike UUCP that seemed to need constant babysitting).
> 
> I think that's still fair to say.
> 
> Though simple Sendmail configurations are relatively easy to set up.

Yeah, it's been easy since whoever did the macros so you picked a config
close to yours, changed a couple of host names and off you go.

It's surprisingly similar to troff.  Writing docs in raw troff is doable,
I've done it a bunch of times, but it's more pleasant with a macro 
package (I'm a fan of -ms, tried the others, just keep coming back to
-ms because it hits the sweet spot of enough stuff without being overly
complicated).


From chet.ramey at case.edu  Fri Nov 30 05:32:32 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 29 Nov 2018 11:32:32 -0800
Subject: [TUHS] man-page style
In-Reply-To: <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>
Message-ID: <09bb6a45-f01f-5889-ea1e-40e36ffe6f26@case.edu>

On 11/29/18 11:13 AM, Grant Taylor via TUHS wrote:
> On 11/29/2018 11:48 AM, Larry McVoy wrote:
>> Indeed.  Sendmail got a lot of hate but mostly from people in pure
>> user at host.domain worlds.
> 
> Do you have any idea why the user at host.domain community hated on Sendmail
> more than other communities?

They didn't need its flexibility, so they had all kinds of bones to pick
with the architecture.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From imp at bsdimp.com  Fri Nov 30 05:36:56 2018
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 29 Nov 2018 12:36:56 -0700
Subject: [TUHS] man-page style
In-Reply-To: <09bb6a45-f01f-5889-ea1e-40e36ffe6f26@case.edu>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>
 <09bb6a45-f01f-5889-ea1e-40e36ffe6f26@case.edu>
Message-ID: <CANCZdfrBO_OQipeHovXakVGdXqzbZw-_Az4U2Vzw+RivMTNQRQ@mail.gmail.com>

On Thu, Nov 29, 2018 at 12:33 PM Chet Ramey <chet.ramey at case.edu> wrote:

> On 11/29/18 11:13 AM, Grant Taylor via TUHS wrote:
> > On 11/29/2018 11:48 AM, Larry McVoy wrote:
> >> Indeed.  Sendmail got a lot of hate but mostly from people in pure
> >> user at host.domain worlds.
> >
> > Do you have any idea why the user at host.domain community hated on
> Sendmail
> > more than other communities?
>
> They didn't need its flexibility, so they had all kinds of bones to pick
> with the architecture.
>

The problem we had at the university was that it got things almost right.
Almost. And to track down WTF the macros were doing that caused the almost
was, well, almost impossible due to the twisty, turny nature of the
implementation that made the twists in colossal cave  look sane and
predictable.

Without extreme tweaking, it wouldn't handle foo!bar!bas%bitnet at grubkle.edu
correctly...  Mostly because it was ambiguous and the definition of correct
changed as we went from being a UUCP leaf node to being a full denizen of
the internet on NSFNET.

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

From chet.ramey at case.edu  Fri Nov 30 05:40:34 2018
From: chet.ramey at case.edu (Chet Ramey)
Date: Thu, 29 Nov 2018 11:40:34 -0800
Subject: [TUHS] man-page style
In-Reply-To: <CANCZdfrBO_OQipeHovXakVGdXqzbZw-_Az4U2Vzw+RivMTNQRQ@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811161628370.60610@aneurin.horsfall.org>
 <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net>
 <CABH=_VTVJJPcDr8jKWCbL648ViLsLYXLmvu9HzW94sddHTs9WA@mail.gmail.com>
 <c986a077-3680-bb2d-cdb5-66bfc445903f@telegraphics.com.au>
 <alpine.BSF.2.21.9999.1811170750360.60610@aneurin.horsfall.org>
 <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu>
 <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com>
 <CANCZdfrCt7OZ=EBN7tbGwgxgmGp6rpEN1AkdTuGB=EqF-RheeA@mail.gmail.com>
 <201811191648.wAJGmqGd005247@darkstar.fourwinds.com>
 <c0725307-e4df-632f-6ef3-75041108b3fb@neophilic.com>
 <20181129184845.GB18414@mcvoy.com>
 <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net>
 <09bb6a45-f01f-5889-ea1e-40e36ffe6f26@case.edu>
 <CANCZdfrBO_OQipeHovXakVGdXqzbZw-_Az4U2Vzw+RivMTNQRQ@mail.gmail.com>
Message-ID: <7dbc6279-c7e4-01fa-7cef-3d6fe4bf9306@case.edu>

On 11/29/18 11:36 AM, Warner Losh wrote:

> Without extreme tweaking, it wouldn't handle foo!bar!bas%bitnet at grubkle.edu
> <mailto:bas%25bitnet at grubkle.edu> correctly...  Mostly because it was
> ambiguous and the definition of correct changed as we went from being a
> UUCP leaf node to being a full denizen of the internet on NSFNET.

Exactly. That is inherently ambiguous and subject to local policy. There is
almost no way to handle it "correctly" in all situations.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://tiswww.cwru.edu/~chet/


From krewat at kilonet.net  Fri Nov 30 06:03:38 2018
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 29 Nov 2018 15:03:38 -0500
Subject: [TUHS] In Memoriam: J. F. Ossanna
In-Reply-To: <201811291707.wATH7XsM107856@tahoe.cs.Dartmouth.EDU>
References: <201811291707.wATH7XsM107856@tahoe.cs.Dartmouth.EDU>
Message-ID: <33fa3ae3-f08e-4d02-96f0-85216e39f698@kilonet.net>

On 11/29/2018 12:07 PM, Doug McIlroy wrote:
>> Sun was sort of the Bell Labs of the time ... I wanted to go there and had
>> to work at it a bit but I got there. Was Bell Labs in the 60's like that?
> Yes, in desirability. But Bell Labs had far more diverse interests. Telephones,
> theoretical physics, submarine cables, music, speech, fiber optics, Apollo.
> Wahtever you wanted to know or work on, you were likely to find kindred
> types and willing management.
>
This sounds like the environment I went into at Nynex Science and 
Technology in White Plains, NY during the mid 90's. Labs all over the 
building, each one doing some groundbreaking (to me) research into cell 
phone coverage, voice recognition and synthesis, and a bunch of other 
things.

I did a short consulting stint there as IT support staff, probably not 
more than 6 months. I generally ruffled the feathers of the older 
support staff when it came to "fixing" things that were easy to fix. 
Like the bright (or not, to them) idea of moving everyone from disparate 
mail servers to one domain, and no longer needing to know which server a 
certain person's email account was on. {suna,sunb,sunc,etc}. I was 
getting tired of having to login to the boxes to see where a personal 
email account was. So I stayed late one night, made it so you could 
address anyone as "@*.domain" or just "@domain", and it would be routed 
accordingly, and wind up in the right place. They actually made me put 
it back the way it was the next day.

So, in terms of research, the place was awesome, I learned and was 
exposed to a lot of interesting topics. I could spend hours in a lab 
talking to the people there, brainstorming about all sorts of things.

But in terms of IT support, it was top-down committee-style system 
administration, and the older/more-senior IT people were not exactly the 
brightest bulbs. One of the IT managers there loved me, and would talk 
to me for hours about how to make things better. But his boss would tamp 
down any ideas of altering things even when the end-users wouldn't 
notice a difference except there was a newer easier way of doing the 
same thing.

Oh well, I never really played well with others anyway ;)

https://www.nytimes.com/1988/04/20/business/business-technology-baby-bells-moving-into-the-lab.html

art k.

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

From toby at telegraphics.com.au  Fri Nov 30 06:11:30 2018
From: toby at telegraphics.com.au (Toby Thain)
Date: Thu, 29 Nov 2018 15:11:30 -0500
Subject: [TUHS] [OT] azel - was Re: In Memoriam: J.F.Ossanna
In-Reply-To: <CAG=a+rhvgikmvEPS_Z-umK2XPYfaxHmov_3QZuD0GcE97BN1qw@mail.gmail.com>
References: <alpine.BSF.2.21.9999.1811280844370.14680@aneurin.horsfall.org>
 <CAG=a+rhFd--aL6UDus4woGc_1YHLzmj+2j1EscQ=z_HH4xEU5w@mail.gmail.com>
 <20181128025739.GA5701@mcvoy.com>
 <CAG=a+rhnRWn4a7vnr51_Yeqfq5UA7_Hm5p8sy8jvNK64h=W7Fw@mail.gmail.com>
 <c0f31860-8e96-f4ea-4442-17eaacb564bb@telegraphics.com.au>
 <CAG=a+rhvgikmvEPS_Z-umK2XPYfaxHmov_3QZuD0GcE97BN1qw@mail.gmail.com>
Message-ID: <164a3eec-839f-f5aa-5d20-7b20264c4a88@telegraphics.com.au>

On 2018-11-29 1:04 PM, Ken Thompson wrote:
> its name became astro and it is on the old backup tapes.
> written in c. it has old elements for everything. published

Thanks.

Was it rewritten? Your story has it dating at least back to 1966, which
made me think it might not have been C.

--Toby

> elements are now in a different form and a different time
> base, so it needs updating to bring it into the 21st century.
> if all you want is the earth, moon, and sun, then it might
> be ok. the earth rotation fudge (delta-t) might need to be
> re-estimated to get second accuracy.
> 
> 
> On Thu, Nov 29, 2018 at 9:54 AM, Toby Thain <toby at telegraphics.com.au> wrote:
>> On 2018-11-27 11:48 PM, Ken Thompson via TUHS wrote:
>>> ...
>>> a version of azel was maintained all the time
>>> i was at bell labs.
>>
>> As soon as I read this it's been on my mind to ask: Does this program
>> survive? Presumably it was Fortran? What did it run on?
>>
>> --Toby
>>
> 



