The Unix Heritage Society mailing list
 help / Atom feed
* [TUHS] [OT] Re:  earliest Unix roff
  2019-09-16 17:37                 ` Jon Steinhart
@ 2019-09-16 18:09                   ` " KatolaZ
  2019-09-16 18:19                     ` Jon Steinhart
  0 siblings, 1 reply; 11+ messages in thread
From: KatolaZ @ 2019-09-16 18:09 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

On Mon, Sep 16, 2019 at 10:37:03AM -0700, Jon Steinhart wrote:

[cut]

> 
> It seems to me that you're missing the point here.  It's not a question of
> whether or not GNU programs have good documentation.  It's the fact that
> GNU made it hard to find documentation because they took one pile and split
> it into two with no guide to what was in each pile.  It's not that their
> documentation was good or bad, it's that they made it hard to find any
> documentation.
> 
> Maybe it's because I'm a child of the 60s, but I'm with Arlo Guthrie on this
> one (from Alice's Restaurant): "And we decided that one big pile is better
> than two little piles, and rather than bring that one up we decided to throw
> ours down."
>

Dear Jon, I am a child of the 70s, so I know the drill ;)

What I am saying is that the vast majority of the software from the
GNU project actually has a good-quality manpage acoompanying it. And
it also has the same documentation in info format. Hence I see no
point in vomiting on info (which I mostly dislike anyway, as I said),
as on any other document format, as long as the same information is
made available via manpages as well, as it is the case for most of the
software present in current Unix systems, wherever it comes from. The
split caused by the introduction of info has mainly been cured by the
community, maybe too late, but still.

We can discuss whether the split was necessary or "right" in the first
instance, as we could discuss whether it was good or not for cat(1) to
leave Murray Hill in 1979 with no options and come back from Berkley
with a source code doubled in size and 9 options in 1982. We could do
that, but perhaps we shouldn't get too partisan, since the history of
Unix is not a simple single-threaded and linear one, as the many
insightful contributions posted in this ML show. It's a continuum,
where it is difficult to find any single element which is totally
right or totally wrong.

I honestly see more danger in the recent trend that avoids
documentation altogether, except for a scant README.md file at the top
of the sources. There is an entire generation of developers who see
little value in producing (and using) online documentation, where by
online I mean manpage-like or info-like docs. For the simple reason
that the main way in which documentation is produced and distributed
has changed a lot in the last 25 years. Now it's all about googling
the right words, unfortunately.

We can keep blaming RMS, info, or the GNU project, but indeed blaming
them for the Web would be a bit too much ;)

And this is perhaps becoming OT anyway.

HND

Enzo Nicosia



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re:  earliest Unix roff
  2019-09-16 18:09                   ` [TUHS] [OT] " KatolaZ
@ 2019-09-16 18:19                     ` Jon Steinhart
  0 siblings, 0 replies; 11+ messages in thread
From: Jon Steinhart @ 2019-09-16 18:19 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

KatolaZ writes:
> Dear Jon, I am a child of the 70s, so I know the drill ;)
>
> What I am saying is that the vast majority of the software from the
> GNU project actually has a good-quality manpage acoompanying it. And
> it also has the same documentation in info format. Hence I see no
> point in vomiting on info (which I mostly dislike anyway, as I said),
> as on any other document format, as long as the same information is
> made available via manpages as well, as it is the case for most of the
> software present in current Unix systems, wherever it comes from. The
> split caused by the introduction of info has mainly been cured by the
> community, maybe too late, but still.
>
> We can discuss whether the split was necessary or "right" in the first
> instance, as we could discuss whether it was good or not for cat(1) to
> leave Murray Hill in 1979 with no options and come back from Berkley
> with a source code doubled in size and 9 options in 1982. We could do
> that, but perhaps we shouldn't get too partisan, since the history of
> Unix is not a simple single-threaded and linear one, as the many
> insightful contributions posted in this ML show. It's a continuum,
> where it is difficult to find any single element which is totally
> right or totally wrong.
>
> I honestly see more danger in the recent trend that avoids
> documentation altogether, except for a scant README.md file at the top
> of the sources. There is an entire generation of developers who see
> little value in producing (and using) online documentation, where by
> online I mean manpage-like or info-like docs. For the simple reason
> that the main way in which documentation is produced and distributed
> has changed a lot in the last 25 years. Now it's all about googling
> the right words, unfortunately.
>
> We can keep blaming RMS, info, or the GNU project, but indeed blaming
> them for the Web would be a bit too much ;)
>
> And this is perhaps becoming OT anyway.
>
> HND
>
> Enzo Nicosia

Well, maybe we're just violently agreeing.  Again, while I think that
info is klunky-feeling, my issue is the ecosystem fragmentation.

I think that it's not our place to discuss cat as Rob is on the list
and he owns that :-)

I do agree that the utter lack of any documentation is a bigger problem.
Or worse, the document that says how to download, build, and install a
package without ever saying what it does or how to use it.

I'm not blaming RMS or GNU, I'm just using them as examples of a way of
doing things that I don't like.  I certainly don't blame them for the web.
Please let's not get started on that!

Jon

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re:  earliest Unix roff
@ 2019-09-19 18:50 Norman Wilson
  2019-09-19 19:00 ` Nemo Nusquam
  2019-09-19 22:44 ` Rob Pike
  0 siblings, 2 replies; 11+ messages in thread
From: Norman Wilson @ 2019-09-19 18:50 UTC (permalink / raw)
  To: tuhs

KatolaZ:
> We can discuss whether the split was necessary or "right" in the first
> instance, as we could discuss whether it was good or not for cat(1) to
> leave Murray Hill in 1979 with no options and come back from Berkley
> with a source code doubled in size and 9 options in 1982.

We needn't discuss that (though of course there are opinions and
mine are the correct ones), but in the interest of historic accuracy,
I should point out by 1979 (V7) cat had developed a single option -u
to turn off stdio buffering.

Sometime before 1984 or so, that option was removed, and cat was
simplified to just
	while ((n = read(fd, buf, sizeof(buf))) > 0)
		write(1, buf, n)
(error checking elided for clarity)
which worked just fine for the rest of the life of the Research
system.

So it's true that BSD added needless (in my humble but correct
opinion) options, but not that it had none before they touched it.
Unless all those other programs were stuffed into cat in an earlier
Berkeley system, but I don't think they were.

Norman Wilson
Toronto ON
(Three cats, no options)

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 18:50 Norman Wilson
@ 2019-09-19 19:00 ` Nemo Nusquam
  2019-09-19 20:18   ` Larry McVoy
  2019-09-19 22:44 ` Rob Pike
  1 sibling, 1 reply; 11+ messages in thread
From: Nemo Nusquam @ 2019-09-19 19:00 UTC (permalink / raw)
  To: tuhs

On 09/19/19 14:50, Norman Wilson wrote (in part):
> So it's true that BSD added needless (in my humble but correct
> opinion) options, but not that it had none before they touched it.
> Unless all those other programs were stuffed into cat in an earlier
> Berkeley system, but I don't think they were.

Who said "Cat came back from Berkeley waving flags."?

N.

> Norman Wilson
> Toronto ON
> (Three cats, no options)


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 19:00 ` Nemo Nusquam
@ 2019-09-19 20:18   ` Larry McVoy
  2019-09-19 20:33     ` Arthur Krewat
  0 siblings, 1 reply; 11+ messages in thread
From: Larry McVoy @ 2019-09-19 20:18 UTC (permalink / raw)
  To: Nemo Nusquam; +Cc: tuhs

On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
> On 09/19/19 14:50, Norman Wilson wrote (in part):
> >So it's true that BSD added needless (in my humble but correct
> >opinion) options, but not that it had none before they touched it.
> >Unless all those other programs were stuffed into cat in an earlier
> >Berkeley system, but I don't think they were.
> 
> Who said "Cat came back from Berkeley waving flags."?

Rob Pike

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 20:18   ` Larry McVoy
@ 2019-09-19 20:33     ` Arthur Krewat
  2019-09-19 20:39       ` Jon Steinhart
  2019-09-19 21:46       ` Steve Nickolas
  0 siblings, 2 replies; 11+ messages in thread
From: Arthur Krewat @ 2019-09-19 20:33 UTC (permalink / raw)
  To: tuhs

Serious question:

Which is better, creating a whole new binary to put in /usr/bin to do a 
single task, or add a flag to cat?

Which is better, a proliferation of binaries w/standalone source code, 
or a single code tree that can handle slightly different tasks and save 
space?

:)

art k.

PS: Using argv[0] (as in a symbolic link) to alter a program's behavior 
instead of using flags is cheating on the above test.




On 9/19/2019 4:18 PM, Larry McVoy wrote:
> On Thu, Sep 19, 2019 at 03:00:16PM -0400, Nemo Nusquam wrote:
>> On 09/19/19 14:50, Norman Wilson wrote (in part):
>>> So it's true that BSD added needless (in my humble but correct
>>> opinion) options, but not that it had none before they touched it.
>>> Unless all those other programs were stuffed into cat in an earlier
>>> Berkeley system, but I don't think they were.
>> Who said "Cat came back from Berkeley waving flags."?
> Rob Pike
>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 20:33     ` Arthur Krewat
@ 2019-09-19 20:39       ` Jon Steinhart
  2019-09-19 21:46       ` Steve Nickolas
  1 sibling, 0 replies; 11+ messages in thread
From: Jon Steinhart @ 2019-09-19 20:39 UTC (permalink / raw)
  To: tuhs

Arthur Krewat writes:
> Serious question:
>
> Which is better, creating a whole new binary to put in /usr/bin to do a 
> single task, or add a flag to cat?
>
> Which is better, a proliferation of binaries w/standalone source code, 
> or a single code tree that can handle slightly different tasks and save 
> space?
>
> :)
>
> art k.
>
> PS: Using argv[0] (as in a symbolic link) to alter a program's behavior 
> instead of using flags is cheating on the above test.

I would argue the first.  In the case of current linux cat, I would make a
separate utility to number lines, a separate utility to squeeze out repeated
empty blank lines, a separate utility to show non printing characters that
might have an option to select the characters that would encompass -T.  All of
these are useful utilities by themselves.  Someone using a particular combo of
options a lot can always write their own scripts or use aliases.  That's the
beauty of composability.

Jon

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
@ 2019-09-19 21:19 Norman Wilson
  0 siblings, 0 replies; 11+ messages in thread
From: Norman Wilson @ 2019-09-19 21:19 UTC (permalink / raw)
  To: tuhs

Arthur Krewat:

  Which is better, creating a whole new binary to put in /usr/bin to do a 
  single task, or add a flag to cat?

  Which is better, a proliferation of binaries w/standalone source code, 
  or a single code tree that can handle slightly different tasks and save 
  space?

======

Which is simpler to write correctly, to debug, and to maintain:
a simple program that does a single task, or a huge single program
with lots of tasks mashed together?

Which is easier to understand and use, individual programs each
with a few options specialized to a particular task, or a monolith
with many more options some of which apply only to one task or
another, others to all?

What are you trying to optimize for?  The speed with which
programmers can churn out yet another featureful utility full
of bugs and corner cases, or the ease with which the end-user
can figure out what tool to use and how to use it?

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 20:33     ` Arthur Krewat
  2019-09-19 20:39       ` Jon Steinhart
@ 2019-09-19 21:46       ` Steve Nickolas
  2019-09-19 21:51         ` Larry McVoy
  1 sibling, 1 reply; 11+ messages in thread
From: Steve Nickolas @ 2019-09-19 21:46 UTC (permalink / raw)
  To: Arthur Krewat; +Cc: tuhs

On Thu, 19 Sep 2019, Arthur Krewat wrote:

> Serious question:
>
> Which is better, creating a whole new binary to put in /usr/bin to do a 
> single task, or add a flag to cat?
>
> Which is better, a proliferation of binaries w/standalone source code, or a 
> single code tree that can handle slightly different tasks and save space?
>
> :)
>
> art k.

I would argue that the more "Unix" way to do it is have the multiple 
binaries.  One job, one tool, and chain them together to make bigger 
tools.

-uso.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 21:46       ` Steve Nickolas
@ 2019-09-19 21:51         ` Larry McVoy
  0 siblings, 0 replies; 11+ messages in thread
From: Larry McVoy @ 2019-09-19 21:51 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: tuhs

On Thu, Sep 19, 2019 at 05:46:13PM -0400, Steve Nickolas wrote:
> On Thu, 19 Sep 2019, Arthur Krewat wrote:
> 
> >Serious question:
> >
> >Which is better, creating a whole new binary to put in /usr/bin to do a
> >single task, or add a flag to cat?
> >
> >Which is better, a proliferation of binaries w/standalone source code, or
> >a single code tree that can handle slightly different tasks and save
> >space?
> >
> >:)
> >
> >art k.
> 
> I would argue that the more "Unix" way to do it is have the multiple
> binaries.  One job, one tool, and chain them together to make bigger tools.

That worked when we were running on 64K machines.  Modern machines do
a lot more and the problem space is not always a pipeline.

You aren't going to write a web server by spawning 

	cat | encrypt | http_servlet

That doesn't scale.  At all.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [TUHS] [OT] Re: earliest Unix roff
  2019-09-19 18:50 Norman Wilson
  2019-09-19 19:00 ` Nemo Nusquam
@ 2019-09-19 22:44 ` Rob Pike
  1 sibling, 0 replies; 11+ messages in thread
From: Rob Pike @ 2019-09-19 22:44 UTC (permalink / raw)
  To: Norman Wilson; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

This was my fault, and it happened because I confronted DMR about the -u
flag for cat. He said it was there because it seemed important that cat be
writable in stdio, which was new at the time. I agreed but said the point
had been made and avoiding unnecessary flags was a higher goal. So cat was
simplified to do what it said, no more and no less, with read and write and
no nonsense.

-rob




On Fri, Sep 20, 2019 at 4:51 AM Norman Wilson <norman@oclsc.org> wrote:

> KatolaZ:
> > We can discuss whether the split was necessary or "right" in the first
> > instance, as we could discuss whether it was good or not for cat(1) to
> > leave Murray Hill in 1979 with no options and come back from Berkley
> > with a source code doubled in size and 9 options in 1982.
>
> We needn't discuss that (though of course there are opinions and
> mine are the correct ones), but in the interest of historic accuracy,
> I should point out by 1979 (V7) cat had developed a single option -u
> to turn off stdio buffering.
>
> Sometime before 1984 or so, that option was removed, and cat was
> simplified to just
>         while ((n = read(fd, buf, sizeof(buf))) > 0)
>                 write(1, buf, n)
> (error checking elided for clarity)
> which worked just fine for the rest of the life of the Research
> system.
>
> So it's true that BSD added needless (in my humble but correct
> opinion) options, but not that it had none before they touched it.
> Unless all those other programs were stuffed into cat in an earlier
> Berkeley system, but I don't think they were.
>
> Norman Wilson
> Toronto ON
> (Three cats, no options)
>

[-- Attachment #2: Type: text/html, Size: 2090 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, back to index

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-16 14:51 [TUHS] earliest Unix roff Larry McVoy
2019-09-16 14:57 ` Clem Cole
2019-09-16 15:14   ` Richard Salz
2019-09-16 16:10     ` Larry McVoy
2019-09-16 16:16       ` Jon Steinhart
2019-09-16 16:26         ` Larry McVoy
2019-09-16 16:31           ` Richard Salz
2019-09-16 16:45             ` Larry McVoy
2019-09-16 17:19               ` KatolaZ
2019-09-16 17:37                 ` Jon Steinhart
2019-09-16 18:09                   ` [TUHS] [OT] " KatolaZ
2019-09-16 18:19                     ` Jon Steinhart
2019-09-19 18:50 Norman Wilson
2019-09-19 19:00 ` Nemo Nusquam
2019-09-19 20:18   ` Larry McVoy
2019-09-19 20:33     ` Arthur Krewat
2019-09-19 20:39       ` Jon Steinhart
2019-09-19 21:46       ` Steve Nickolas
2019-09-19 21:51         ` Larry McVoy
2019-09-19 22:44 ` Rob Pike
2019-09-19 21:19 Norman Wilson

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox