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: On 10/31/18, Warren Toomey 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: References: <20181031043810.GA10775@minnie.tuhs.org> Message-ID: On Wed, Oct 31, 2018 at 12:51 PM Paul Winalski 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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> 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: References: <20181031043810.GA10775@minnie.tuhs.org> Message-ID: <20181031205738.vb2yba55cdrh5vdt@crack.deadbeast.net> At 2018-10-31T11:47:20-0400, Paul Winalski wrote: > On 10/31/18, Warren Toomey 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: 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: <20181029021023.GA27974@eureka.lemis.com> <20181029071652.zzauekw6ikpqd4ur@h-174-65.A328.priv.bahnhof.se> <5B2BFC4F-6FAC-4104-9BCC-2D3C5C0B0970@johnlabovitz.com> <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: References: <20181031043810.GA10775@minnie.tuhs.org> Message-ID: 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: References: <20181031043810.GA10775@minnie.tuhs.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> <20181101074231.GA4844@vagabond> Message-ID: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: On Thu, Nov 1, 2018 at 7:48 AM Dave Horsfall 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: 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: 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 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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: On Thu, Nov 1, 2018 at 7:05 AM Clem Cole 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: On Thu, Nov 1, 2018 at 10:20 AM ron minnich 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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: On Thu, Nov 1, 2018 at 9:38 AM Clem Cole wrote: > > > On Thu, Nov 1, 2018 at 10:20 AM ron minnich 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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: On Thu, Nov 1, 2018 at 9:44 AM Warner Losh 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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: On Thu, Nov 1, 2018 at 10:48 AM ron minnich wrote: > > > On Thu, Nov 1, 2018 at 9:44 AM Warner Losh 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: 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." References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: <20181102052434.93EC6156E40C@mail.bitblocks.com> On Thu, 01 Nov 2018 09:48:38 -0700 ron minnich wrote: > > On Thu, Nov 1, 2018 at 9:44 AM Warner Losh 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" To:"Warner Losh" Cc:"Steve Johnson" , "The Eunuchs Hysterical Society" 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: 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"     ...      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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> Message-ID: <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net> On Nov 1, 2018, at 3:20 AM, Dave Horsfall 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 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: On Sun, Nov 4, 2018, 4:28 AM Chris Hanson 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: 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: 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 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> <20181101074231.GA4844@vagabond> <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net> Message-ID: On Sun, Nov 4, 2018 at 4:00 AM Chris Hanson 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net> Message-ID: On Sun, Nov 4, 2018 at 9:31 AM ron minnich wrote: > On Sun, Nov 4, 2018 at 4:00 AM Chris Hanson > 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: 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> <20181101074231.GA4844@vagabond> <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 wrote: > >> On Nov 1, 2018, at 3:20 AM, Dave Horsfall 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: 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: References: <20181031043810.GA10775@minnie.tuhs.org> <20181101074231.GA4844@vagabond> <9AD89116-0552-440F-A251-1E93AA150B93@eschatologist.net> Message-ID: On Sun, Nov 4, 2018 at 9:06 AM Warner Losh 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: 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: 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: 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: On Nov 4, 2018, at 4:28 AM, arnold at skeeve.com wrote: > > Chris Hanson 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: References: 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 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: References: Message-ID: On Sun, Nov 4, 2018 at 2:35 PM 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. > It's over a billion and a half today: % date +%s 1541371441 Warner -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: 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: References: Message-ID: On Sun, Nov 4, 2018 at 11:34 PM 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. > 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: 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: References: 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: 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: References: Message-ID: 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: References: Message-ID: On Sun, Nov 4, 2018 at 4:44 PM Mantas Mikulėnas 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: 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: References: Message-ID: On Sunday, November 4, 2018, Warner Losh wrote: > > > On Sun, Nov 4, 2018 at 2:35 PM 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. >> > > 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: 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." References: Message-ID: <20181105004259.A0840156E40C@mail.bitblocks.com> On Sun, 04 Nov 2018 15:44:37 -0700 Warner Losh wrote: > > On Sun, Nov 4, 2018 at 2:35 PM 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. > > > > 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: <20181105004259.A0840156E40C@mail.bitblocks.com> Message-ID: 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 wrote: > On Sun, 04 Nov 2018 15:44:37 -0700 Warner Losh wrote: >> >> On Sun, Nov 4, 2018 at 2:35 PM 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. >> > >> >> 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: References: Message-ID: 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: References: 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: References: Message-ID: 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: 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: References: <20181105004259.A0840156E40C@mail.bitblocks.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: References: Message-ID: 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: 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: <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: 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: (Clem cole's message of "Sun, 4 Nov 2018 06:59:45 -0800") References: <7w36sh3qeh.fsf@junk.nocrew.org> 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 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: References: Message-ID: On Mon, Nov 5, 2018 at 9:19 AM Grant Taylor via TUHS 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: References: Message-ID: On Mon, Nov 5, 2018 at 9:24 AM Mantas Mikulėnas 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: References: <20181031043810.GA10775@minnie.tuhs.org> <7B5918F3-A65F-45FC-805A-07FE3FCE9253@eschatologist.net> <201811041228.wA4CSMIA017639@freefriends.org>, Message-ID: <2008946716.58169.1541427064505.JavaMail.tomcat@india-live-be01> At 4 Nov 2018 22:07:46 +0000 (+00:00) from Chris Hanson : > 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: <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: References: 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: 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: <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com> Message-ID: <201811051838.wA5Icosk029361@freefriends.org> Larry McVoy 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: <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 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: References: 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: 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: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net> Message-ID: 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: 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: References: 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: 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: <20181105034940.GE2660@mcvoy.com> <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net> Message-ID: 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: References: Message-ID: 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: References: Message-ID: On Sun, Nov 4, 2018, 4:34 PM Grant Taylor via TUHS 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: 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: <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com> <201811051838.wA5Icosk029361@freefriends.org> <20181105190424.GE19335@mcvoy.com> Message-ID: 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 wrote: > On Mon, Nov 05, 2018 at 11:38:50AM -0700, arnold at skeeve.com wrote: > > Larry McVoy 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: On Mon, Nov 5, 2018 at 11:00 PM Grant Taylor via TUHS 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: On Mon, Nov 5, 2018 at 4:00 PM Grant Taylor via TUHS 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: 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: References: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.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: 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: References: <20181105034940.GE2660@mcvoy.com> <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net> 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: 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: References: 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: 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: 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: <20181105034940.GE2660@mcvoy.com> <58d73d5b-d00f-4670-7e32-8410e0ef0225@spamtrap.tnetconsulting.net> <121753c0-ad8b-428f-498b-002749baf132@spamtrap.tnetconsulting.net> Message-ID: [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: 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: 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: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net> Message-ID: On Mon, Nov 5, 2018 at 7:33 PM Grant Taylor via TUHS 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: 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: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net> Message-ID: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> 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: 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: References: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.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 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> 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 ", > 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: 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: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net> <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net> Message-ID: 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: 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: References: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net> 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: 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: References: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS wrote: > > > > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS > 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018 at 8:40 AM Grant Taylor via TUHS 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: > On Nov 5, 2018, at 5:34 PM, Dan Cross 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <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 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: > On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas wrote: > > On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS > wrote: > > > > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS > 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield wrote: > > > On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas wrote: > > On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS > wrote: > >> >> >> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS >> 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield wrote: > > > On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas wrote: > > On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS > wrote: > >> >> >> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS >> 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> Message-ID: <2B38E200-697F-4A26-9013-26C07B54351B@cogs.com> > On Nov 6, 2018, at 8:44 AM, Mantas Mikulėnas wrote: > > On Tue, Nov 6, 2018 at 3:21 PM Ben Greenfield > wrote: > > >> On Nov 6, 2018, at 1:53 AM, Mantas Mikulėnas > wrote: >> >> On Tue, Nov 6, 2018, 01:32 Ben Greenfield via TUHS > wrote: >> >> >> > On Nov 5, 2018, at 2:36 PM, Grant Taylor via TUHS > 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: 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: References: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net> <53d47030-c120-bb51-00f2-20f0fc2c2d77@kilonet.net> Message-ID: 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 [ References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> 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: 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 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 [ ./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 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 [ ./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: References: <3837fab8-05c2-4483-149e-07df4f69fcde@kilonet.net> <53d47030-c120-bb51-00f2-20f0fc2c2d77@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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <4d85ccda-7200-b6e7-8a27-5832e3bdcdba@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018 at 9:18 PM Grant Taylor via TUHS 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: 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018 at 1:40 AM Grant Taylor via TUHS 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: 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: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net> <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net> Message-ID: On Tue, Nov 6, 2018 at 1:42 AM Grant Taylor via TUHS 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> 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: 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: References: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net> <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net> 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <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: References: <6a64b957-5912-b102-c73c-d0b71bd24188@spamtrap.tnetconsulting.net> <968a530f-c456-e79f-3581-f84fdef73c19@spamtrap.tnetconsulting.net> 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: <20181105034940.GE2660@mcvoy.com> <20181105154404.GA19335@mcvoy.com> <201811051838.wA5Icosk029361@freefriends.org> <20181105190424.GE19335@mcvoy.com> Message-ID: <201811070858.wA78wvfU016909@freefriends.org> Larry McVoy 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: References: Message-ID: <201811070905.wA795wxP017303@freefriends.org> Dan Cross 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net> Message-ID: 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: References: <20181106170955.GA4087@indra.papnet.eu> <04db01d47606$7b003700$7100a500$@ronnatalie.com> 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: <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 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: References: Message-ID: On Mon, Nov 5, 2018 at 7:35 PM Dan Cross 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: 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: References: Message-ID: 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 wrote: > > > On Mon, Nov 5, 2018 at 7:35 PM Dan Cross 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: 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: On Tue, Nov 6, 2018 at 8:33 PM Norman Wilson 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: 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> <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com> Message-ID: On Wed, Nov 7, 2018 at 9:09 AM 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: 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: <201811070905.wA795wxP017303@freefriends.org> Message-ID: On Wed, Nov 7, 2018 at 3:38 AM 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: References: <20181106170955.GA4087@indra.papnet.eu> <04db01d47606$7b003700$7100a500$@ronnatalie.com> Message-ID: On 11/6/18, Dave Horsfall 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: References: 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: <201811070905.wA795wxP017303@freefriends.org> Message-ID: On Wed, Nov 7, 2018 at 4:05 AM wrote: > Dan Cross 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net> 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: 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: References: <201811070905.wA795wxP017303@freefriends.org> 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 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 first developed NSS for their Solaris operating system, but subsequently programmers ported it to many other operating systems including FreeBSD , NetBSD , Linux , HP-UX , IRIX and AIX ." 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: 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: References: 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: References: Message-ID: On Wed, Nov 7, 2018 at 9:43 AM Clem Cole 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: References: Message-ID: 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 wrote: > On Wed, Nov 7, 2018 at 9:43 AM Clem Cole 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: 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: References: <201811070905.wA795wxP017303@freefriends.org> 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 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: References: <201811070905.wA795wxP017303@freefriends.org> Message-ID: On Wed, 7 Nov 2018 at 14:57, Dan Cross 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: 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: References: <201811070905.wA795wxP017303@freefriends.org> Message-ID: On Wed, Nov 7, 2018 at 9:57 PM Dan Cross wrote: > On Wed, Nov 7, 2018 at 4:05 AM 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: 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: <201811070905.wA795wxP017303@freefriends.org> <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 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 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 first developed NSS for their Solaris operating system, but subsequently programmers ported it to many other operating systems including FreeBSD , NetBSD , Linux , HP-UX , IRIX and AIX ." 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: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net> <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net> Message-ID: 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: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net> <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: References: <1541547109.9957.for-standards-violators@oclsc.org> Message-ID: /crp was "creep" before Apollo even existed. -rob On Thu, Nov 8, 2018 at 3:45 AM Clem Cole wrote: > > > On Tue, Nov 6, 2018 at 8:33 PM Norman Wilson 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: 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: References: <20181106170955.GA4087@indra.papnet.eu> <04db01d47606$7b003700$7100a500$@ronnatalie.com> <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.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 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: 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: References: <0289fa26-d157-8a65-389e-61dd7a01fcc4@spamtrap.tnetconsulting.net> <7d595808-fff7-4c1c-d969-362693ab2672@spamtrap.tnetconsulting.net> <7e9e6546-6575-e4d5-caf8-52c504f5a953@spamtrap.tnetconsulting.net> <26af3c07-a35c-c464-4fc0-2c62556b8e95@spamtrap.tnetconsulting.net> Message-ID: 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> <218a01d47693$f83fd530$e8bf7f90$@ronnatalie.com> <20181107234037.GA3826@eureka.lemis.com> Message-ID: On Wed, Nov 7, 2018 at 7:26 PM Greg 'groggy' Lehey wrote: > On Wednesday, 7 November 2018 at 10:14:20 -0500, Clem Cole wrote: > > On Wed, Nov 7, 2018 at 9:09 AM 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: 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: <201811070905.wA795wxP017303@freefriends.org> <20181107201520.GA14737@mcvoy.com> Message-ID: <201811081134.wA8BYRl9001763@freefriends.org> Larry McVoy wrote: > On Wed, Nov 07, 2018 at 12:15:32PM -0500, Dan Cross wrote: > > On Wed, Nov 7, 2018 at 4:05 AM 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: <20181104233505.GA70281@eureka.lemis.com> Message-ID: > On Nov 4, 2018, at 6:35 PM, Greg 'groggy' Lehey 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: 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: <201811070905.wA795wxP017303@freefriends.org> <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: 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 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 [ > ./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: <201811070905.wA795wxP017303@freefriends.org> <20181107201520.GA14737@mcvoy.com> <201811081134.wA8BYRl9001763@freefriends.org> <4190e0c5-6293-caa1-8e4a-7f177f10f61d@kilonet.net> Message-ID: On Thu, Nov 8, 2018, 1:07 PM Arthur Krewat 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: 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: References: <201811070905.wA795wxP017303@freefriends.org> <20181107201520.GA14737@mcvoy.com> <201811081134.wA8BYRl9001763@freefriends.org> <4190e0c5-6293-caa1-8e4a-7f177f10f61d@kilonet.net> Message-ID: 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: On Thu, Nov 8, 2018, 1:23 PM Doug McIlroy 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: 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: On Fri, Nov 9, 2018, 10:19 AM Doug McIlroy > 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: 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: 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 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: 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: 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: References: <20181113215531.GA24373@minnie.tuhs.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> <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> <20181113224952.GA29973@minnie.tuhs.org> Message-ID: 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: References: <20181113215531.GA24373@minnie.tuhs.org> <20181113224952.GA29973@minnie.tuhs.org> Message-ID: 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 #include 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, ""); else for(i=1; i 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: 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> <20181113224952.GA29973@minnie.tuhs.org> <20181114004018.GA23816@minnie.tuhs.org> Message-ID: 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 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: 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: 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: References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU> Message-ID: and it takes a lot less typing. On Thu, Nov 15, 2018 at 7:18 PM, 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 > 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: References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU> 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 wrote: > > and it takes a lot less typing. > > > On Thu, Nov 15, 2018 at 7:18 PM, 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 >> 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: 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 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> 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: 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: References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU> 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> <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com> Message-ID: 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 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: 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> <20181116063856.GL3341@mcvoy.com> Message-ID: On Fri, Nov 16, 2018 at 1:39 AM Larry McVoy 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: 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: References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU> <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.com> Message-ID: That was Pascal. Not C! > On Nov 16, 2018, at 5:29 AM, Mike Markowski 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 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: 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: References: <201811160143.wAG1hqbV019990@tahoe.cs.Dartmouth.EDU> <63E23F12-DD93-410D-BFD7-621A25C5FF80@bitblocks.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" 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: 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: +1 ᐧ On Fri, Nov 16, 2018 at 10:44 AM WIlliam Cheswick 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: On 11/16/18, Grant Taylor via TUHS 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> 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 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <20181116171318.GC30000@mcvoy.com> Message-ID: On 11/16/18, Larry McVoy 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 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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: On 2018-11-16 11:55 AM, Paul Winalski wrote: > On 11/16/18, Grant Taylor via TUHS 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: On Fri, Nov 16, 2018 at 9:56 AM Paul Winalski 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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <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: 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 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <20181116171318.GC30000@mcvoy.com> <201811161739.wAGHdw3O023003@darkstar.fourwinds.com> Message-ID: On Fri, Nov 16, 2018 at 1:40 PM Jon Steinhart 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: 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: On 15/11/2018, Doug McIlroy 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <20181116171318.GC30000@mcvoy.com> Message-ID: 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: 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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> 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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> 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: 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: 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: 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: 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: 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: References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil> <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au> 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> Message-ID: On Fri, Nov 16, 2018 at 4:40 PM Jon Steinhart 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: 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." References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: <20181116222603.A8363156E40C@mail.bitblocks.com> On Fri, 16 Nov 2018 11:55:28 -0500 Paul Winalski wrote: > On 11/16/18, 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. > > > 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: References: Message-ID: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <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 ”. 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 wrote: > >> On Fri, 16 Nov 2018 11:55:28 -0500 Paul Winalski wrote: >>> On 11/16/18, 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. >>> >> 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: On Friday, November 16, 2018, Jim Capp 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> Message-ID: 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 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> Message-ID: <201811171816.wAHIG6gJ025678@freefriends.org> Grant Taylor via TUHS 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: 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: 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 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: 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 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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> Message-ID: 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: References: 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 : > > 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 : >> >> 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: 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: 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> Message-ID: 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: References: <26292231.693.1542401951390.JavaMail.root@zimbraanteil> <75c6879f-0701-0812-928c-9df8eea0c609@telegraphics.com.au> 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: 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: 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 : >>> >>> 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> Message-ID: 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 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: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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 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: References: <20181117153919.6468B18C073@mercury.lcs.mit.edu> Message-ID: 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: References: <20181117153919.6468B18C073@mercury.lcs.mit.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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> Message-ID: On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart 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: 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." References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> Message-ID: <20181119072022.E3EE4156E40C@mail.bitblocks.com> On Mon, 19 Nov 2018 00:05:08 -0700 Warner Losh wrote: > > On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> Message-ID: <20181119130854.cB3nR%steffen@sdaoden.eu> Chet Ramey wrote in : |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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> , <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 : > > 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> Message-ID: On Sun, Nov 18, 2018 at 10:11 PM Jon Steinhart 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//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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> Message-ID: <7171EAB7-9557-4822-8FCE-5C7B1AD19B06@kdbarto.org> > On Nov 19, 2018, at 7:35 AM, Clem Cole wrote: > > > > On Sun, Nov 18, 2018 at 10:11 PM Jon Steinhart > 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: 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> Message-ID: <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> Warner Losh writes: > On Fri, Nov 16, 2018 at 2:40 PM Jon Steinhart 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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//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: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> <20181119173952.GA19377@thunk.org> Message-ID: 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 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: 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: References: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> <20181119173952.GA19377@thunk.org> 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: References: <20181117153919.6468B18C073@mercury.lcs.mit.edu> 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> <3c7cb03bb23814934ba4ce5735e28b85@bl.org> Message-ID: 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 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: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> <20181119173952.GA19377@thunk.org> Message-ID: <201811200652.wAK6qcV1020423@freefriends.org> Clem Cole 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: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> <20181119173952.GA19377@thunk.org> <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 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: 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: References: Message-ID: 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 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: References: <201811160003.wAG03mlF139232@tahoe.cs.Dartmouth.EDU> <20181116045016.GK3341@mcvoy.com> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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//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//... 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> Message-ID: [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 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> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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: 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> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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: 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: References: 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 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: <20181128025739.GA5701@mcvoy.com> Message-ID: 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 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 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: <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: References: 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 : > 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: On Tue, Nov 27, 2018 at 11:50 PM Ken Thompson via TUHS 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 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 > 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: 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: On 11/27/18, Ken Thompson via TUHS 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: 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 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 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 > 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: 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: <32C0991D-E4AE-4729-B133-7FB84A0E83E1@cheswick.com> > On Nov 28, 2018, at 12:08 PM, Paul Winalski 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 ) ches -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: <20181128025739.GA5701@mcvoy.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: References: Message-ID: 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: 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 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.com> <6a179556-322c-8ba5-b957-5ae7a03ec610@neophilic.com> Message-ID: <201811290725.wAT7PuE1019145@freefriends.org> Eric Allman 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: On Wed, Nov 28, 2018 at 10:51 PM Lars Brinkhoff 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: 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: 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 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: 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: 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: References: <20181128025739.GA5701@mcvoy.com> Message-ID: On Thu, Nov 29, 2018 at 10:55 AM Toby Thain 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: 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> <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.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: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811190311.wAJ3BDHR028154@darkstar.fourwinds.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 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: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.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: 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: <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.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: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.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: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net> <09bb6a45-f01f-5889-ea1e-40e36ffe6f26@case.edu> Message-ID: On Thu, Nov 29, 2018 at 12:33 PM Chet Ramey 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: 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: References: <7a632484-cdc7-7c59-7077-7a2c752045da@spamtrap.tnetconsulting.net> <4c36b2b2-76df-435f-27bc-e1feb0647f36@case.edu> <201811162113.wAGLDGiQ031455@darkstar.fourwinds.com> <201811191648.wAJGmqGd005247@darkstar.fourwinds.com> <20181129184845.GB18414@mcvoy.com> <76bb3c3a-7717-caf8-c8ac-8afea3bf5bc4@spamtrap.tnetconsulting.net> <09bb6a45-f01f-5889-ea1e-40e36ffe6f26@case.edu> 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 > 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: 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: References: <20181128025739.GA5701@mcvoy.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 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 >> >