* 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 ` [TUHS] [OT] " Rob Pike
0 siblings, 2 replies; 12+ 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] 12+ messages in thread
* Re: [TUHS] [OT] Re: earliest Unix roff
2019-09-19 18:50 [TUHS] [OT] Re: earliest Unix roff Norman Wilson
@ 2019-09-19 19:00 ` Nemo Nusquam
2019-09-19 20:18 ` Larry McVoy
2019-09-19 22:44 ` [TUHS] [OT] " Rob Pike
1 sibling, 1 reply; 12+ 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] 12+ 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
2019-09-19 20:42 ` [TUHS] " Andy Kosela
0 siblings, 2 replies; 12+ 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] 12+ 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
2019-09-19 20:42 ` [TUHS] " Andy Kosela
1 sibling, 2 replies; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ 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; 12+ 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] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-19 20:18 ` Larry McVoy
2019-09-19 20:33 ` Arthur Krewat
@ 2019-09-19 20:42 ` Andy Kosela
1 sibling, 0 replies; 12+ messages in thread
From: Andy Kosela @ 2019-09-19 20:42 UTC (permalink / raw)
To: Larry McVoy; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Thursday, September 19, 2019, Larry McVoy <lm@mcvoy.com> 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
>
http://harmful.cat-v.org/cat-v/
--Andy
[-- Attachment #2: Type: text/html, Size: 912 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] [OT] Re: earliest Unix roff
2019-09-19 18:50 [TUHS] [OT] Re: earliest Unix roff Norman Wilson
2019-09-19 19:00 ` Nemo Nusquam
@ 2019-09-19 22:44 ` Rob Pike
1 sibling, 0 replies; 12+ 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] 12+ messages in thread
* Re: [TUHS] [OT] Re: earliest Unix roff
@ 2019-09-19 21:19 Norman Wilson
0 siblings, 0 replies; 12+ 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] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
@ 2019-09-16 14:51 Larry McVoy
2019-09-16 14:57 ` Clem Cole
0 siblings, 1 reply; 12+ messages in thread
From: Larry McVoy @ 2019-09-16 14:51 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 08:10:48AM -0400, Clem Cole wrote:
> On Mon, Sep 16, 2019 at 1:52 AM <arnold@skeeve.com> wrote:
>
> > I use the standalone Info reader (named info) if I want to look at the
> > Info output.
> >
> Fair enough, but be careful, while I admit I have not looked in a while,
> info(gnu) relies on emacs keybindings and a number of very emacs'ish things.
> Every time I have tried to deal with it, I have unprogram my fingers and
> reset them to emacs.
>
> If it would have used more(1) [or even less(1)] then I would not be as
> annoyed.
> Unix had fine tools [man(1), more(1), et al] and rms and friends felt the
> need to replace them with ITS-like programs.
I hate texinfo and friends. I get why it is better than man, but man was
good enough, more than good enough, and the GNU project took everything
it could find and destroyed the man pages.
If you have something like perl that needs a zillion sub pages, info
makes sense. For just a man page, info is horrible.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 14:51 [TUHS] " Larry McVoy
@ 2019-09-16 14:57 ` Clem Cole
2019-09-16 15:14 ` Richard Salz
0 siblings, 1 reply; 12+ messages in thread
From: Clem Cole @ 2019-09-16 14:57 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
On Mon, Sep 16, 2019 at 10:51 AM Larry McVoy <lm@mcvoy.com> wrote:
> I hate texinfo and friends. I get why it is better than man, but man was
> good enough, more than good enough, and the GNU project took everything
> it could find and destroyed the man pages.
>
Amen, bro. As I said, it was not 'social compliant' which was really a
not very nice thing to do. It's arrogant to say in effect "your way is
wrong, I'm going to try to kill it off."
>
> If you have something like perl that needs a zillion sub pages, info
> makes sense. For just a man page, info is horrible.
I'm not even sure, I like that, to be honest. I'm 'old school' enough to
rather use a book from ORA or the like.
[-- Attachment #2: Type: text/html, Size: 1693 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 14:57 ` Clem Cole
@ 2019-09-16 15:14 ` Richard Salz
2019-09-16 16:10 ` Larry McVoy
0 siblings, 1 reply; 12+ messages in thread
From: Richard Salz @ 2019-09-16 15:14 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
Is it any surprise that the early GNU effort was really trying to recreate
ITS? Can you really blame them? I'm grateful that they made `info` be a
standalone program. Putting the concept of "cursor position" into the
existing pagers (more/less/etc) and doing jump/xref/back would be more than
a stretch, IMO.
[-- Attachment #2: Type: text/html, Size: 370 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 15:14 ` Richard Salz
@ 2019-09-16 16:10 ` Larry McVoy
2019-09-16 16:16 ` Jon Steinhart
0 siblings, 1 reply; 12+ messages in thread
From: Larry McVoy @ 2019-09-16 16:10 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> Is it any surprise that the early GNU effort was really trying to recreate
> ITS? Can you really blame them? I'm grateful that they made `info` be a
> standalone program. Putting the concept of "cursor position" into the
> existing pagers (more/less/etc) and doing jump/xref/back would be more than
> a stretch, IMO.
It's what Clem said. You should acclimate yourself to your environment.
Pushing info into man environment is a lot like being an immigrant and
wanting to bring your laws into your new homeland. That isn't a thing
and shouldn't be a thing. Doesn't matter that people think ITS is better,
they are in Unix. If you think ITS is better, go live there.
When in Rome....
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:10 ` Larry McVoy
@ 2019-09-16 16:16 ` Jon Steinhart
2019-09-16 16:26 ` Larry McVoy
0 siblings, 1 reply; 12+ messages in thread
From: Jon Steinhart @ 2019-09-16 16:16 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
Larry McVoy writes:
> On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > Is it any surprise that the early GNU effort was really trying to recreate
> > ITS? Can you really blame them? I'm grateful that they made `info` be a
> > standalone program. Putting the concept of "cursor position" into the
> > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > a stretch, IMO.
>
> It's what Clem said. You should acclimate yourself to your environment.
> Pushing info into man environment is a lot like being an immigrant and
> wanting to bring your laws into your new homeland. That isn't a thing
> and shouldn't be a thing. Doesn't matter that people think ITS is better,
> they are in Unix. If you think ITS is better, go live there.
>
> When in Rome....
Well, in the shameless department, I can quote from my book:
Mucking up the ecosystem into which you release code does not
add value. Many developers behave as if they’re stereotypical
Americans vacationing in another country, or for that matter my
father-in-law visiting — the “I just came to your place, so do
things my way” attitude.
For example, UNIX systems have a command that displays manual pages
for programs. You can type man foo and it’ll show you the page
for the foo command. There’s also a convention that really complex
commands, such as yacc , have both a manual page and a longer, more
in-depth document that describes the program in more detail. When
the GNU project (which I’ll discuss shortly) added commands to
UNIX, it used its own texinfo system for manuals, which wasn’t
compatible with the man system. The result was that users would have
to try both the man and info commands to find documentation. Even
if, as some believe, the GNU approach was superior, any possible
benefits were outweighed by the UNIX community’s huge loss of
productivity that resulted from the fragmented ecosystem.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:16 ` Jon Steinhart
@ 2019-09-16 16:26 ` Larry McVoy
2019-09-16 16:31 ` Richard Salz
0 siblings, 1 reply; 12+ messages in thread
From: Larry McVoy @ 2019-09-16 16:26 UTC (permalink / raw)
To: Jon Steinhart; +Cc: The Eunuchs Hysterical Society
+1
On Mon, Sep 16, 2019 at 09:16:03AM -0700, Jon Steinhart wrote:
> Larry McVoy writes:
> > On Mon, Sep 16, 2019 at 11:14:25AM -0400, Richard Salz wrote:
> > > Is it any surprise that the early GNU effort was really trying to recreate
> > > ITS? Can you really blame them? I'm grateful that they made `info` be a
> > > standalone program. Putting the concept of "cursor position" into the
> > > existing pagers (more/less/etc) and doing jump/xref/back would be more than
> > > a stretch, IMO.
> >
> > It's what Clem said. You should acclimate yourself to your environment.
> > Pushing info into man environment is a lot like being an immigrant and
> > wanting to bring your laws into your new homeland. That isn't a thing
> > and shouldn't be a thing. Doesn't matter that people think ITS is better,
> > they are in Unix. If you think ITS is better, go live there.
> >
> > When in Rome....
>
> Well, in the shameless department, I can quote from my book:
>
> Mucking up the ecosystem into which you release code does not
> add value. Many developers behave as if they???re stereotypical
> Americans vacationing in another country, or for that matter my
> father-in-law visiting ??? the ???I just came to your place, so do
> things my way??? attitude.
>
> For example, UNIX systems have a command that displays manual pages
> for programs. You can type man foo and it???ll show you the page
> for the foo command. There???s also a convention that really complex
> commands, such as yacc , have both a manual page and a longer, more
> in-depth document that describes the program in more detail. When
> the GNU project (which I???ll discuss shortly) added commands to
> UNIX, it used its own texinfo system for manuals, which wasn???t
> compatible with the man system. The result was that users would have
> to try both the man and info commands to find documentation. Even
> if, as some believe, the GNU approach was superior, any possible
> benefits were outweighed by the UNIX community???s huge loss of
> productivity that resulted from the fragmented ecosystem.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:26 ` Larry McVoy
@ 2019-09-16 16:31 ` Richard Salz
2019-09-16 16:45 ` Larry McVoy
0 siblings, 1 reply; 12+ messages in thread
From: Richard Salz @ 2019-09-16 16:31 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 158 bytes --]
I don't think it's totally GNU's fault that it became Linux. They weren't
trying to be tourists in Rome, they were trying to create a new city of
their own.
[-- Attachment #2: Type: text/html, Size: 229 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:31 ` Richard Salz
@ 2019-09-16 16:45 ` Larry McVoy
2019-09-16 17:19 ` KatolaZ
0 siblings, 1 reply; 12+ messages in thread
From: Larry McVoy @ 2019-09-16 16:45 UTC (permalink / raw)
To: Richard Salz; +Cc: The Eunuchs Hysterical Society
On Mon, Sep 16, 2019 at 12:31:13PM -0400, Richard Salz wrote:
> I don't think it's totally GNU's fault that it became Linux. They weren't
> trying to be tourists in Rome, they were trying to create a new city of
> their own.
Yeah, except they didn't create their own city, they pooped all over a
different one. There is no defense for what they did. If they did the
right thing they would have created a markup language that could have
produced info files and man files.
It's not that hard, I wrote something called webroff that took -ms
format input and produced a website complete with the navigation tree,
it defaulted to showing you a page (each .NH) at time but it also had
a site map where you could see the entire document as a single page,
or each major section (.NH 1) as a page.
For more than a decade this was BitMover's home page. I can't tell
you how many sales calls I've been on and I've seen the entire web
site printed out on the manager's desk.
The reality is there was absolutely no need for a new format for
info files, they could have parsed man input and produced info
files and that's what they should have done.
Those who defend the choice of info over man just aren't real Unix
people. And that's fine, Unix isn't the only choice, they can go
run some other OS and be happy. But it's just rude to thrust info
into a Unix system. And lame because they could have parsed man
pages into info docs and then they are adopting the Unix way of
doing things and actually adding value.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 16:45 ` Larry McVoy
@ 2019-09-16 17:19 ` KatolaZ
2019-09-16 17:37 ` Jon Steinhart
0 siblings, 1 reply; 12+ messages in thread
From: KatolaZ @ 2019-09-16 17:19 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
On Mon, Sep 16, 2019 at 09:45:02AM -0700, Larry McVoy wrote:
[cut]
>
> Those who defend the choice of info over man just aren't real Unix
> people. And that's fine, Unix isn't the only choice, they can go
> run some other OS and be happy. But it's just rude to thrust info
> into a Unix system. And lame because they could have parsed man
> pages into info docs and then they are adopting the Unix way of
> doing things and actually adding value.
Sorry, but I totally don't see the point here. The problem is not the
technology, but the adopters. I personally don't like info at all, and
still swear whenever a software comes without a proper manpage, but
info has not been shovelled down your throat (or anybody else's, for
that matter). The adopters have decided that info was fine for their
use case. They could have written manpages and send patches over, and
in many cases they didn't.
There is plenty of software coming from the GNU project that has
comprehensive and clear manpages (just to cite a single example,
bash(1) comes with manpages, and no info doc). At the same time, there
is tons of "Unix" software around that comes without any documentation
*at all*, or with scant text files covering the bare basics.
Unfortunately this trend is only getting worse, and we have far too
many notaable examples here, not all of them coming from the GNU
project, or from the "ITS tradition", whatever it means for you.
I agree that whoever does not produce a readily usable documentaion
for their software has not really understood much of the Unix
philosophy. But that's not at all a matter of formats, rather of
culture.
Then, if you just want to vomit on info, or you prefer to use info as
another excuse to vomit on the GNU project, well go ahead. But the
actual issue is elsewhere (the lack of respect for the users, and the
tendency to hide stuff under the carpet), and has not been introduced
by the GNU project, at all.
My2Cents
Enzo Nicosia
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [TUHS] earliest Unix roff
2019-09-16 17:19 ` KatolaZ
@ 2019-09-16 17:37 ` Jon Steinhart
2019-09-16 18:09 ` [TUHS] [OT] " KatolaZ
0 siblings, 1 reply; 12+ messages in thread
From: Jon Steinhart @ 2019-09-16 17:37 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
KatolaZ writes:
> Sorry, but I totally don't see the point here. The problem is not the
> technology, but the adopters. I personally don't like info at all, and
> still swear whenever a software comes without a proper manpage, but
> info has not been shovelled down your throat (or anybody else's, for
> that matter). The adopters have decided that info was fine for their
> use case. They could have written manpages and send patches over, and
> in many cases they didn't.
>
> There is plenty of software coming from the GNU project that has
> comprehensive and clear manpages (just to cite a single example,
> bash(1) comes with manpages, and no info doc). At the same time, there
> is tons of "Unix" software around that comes without any documentation
> *at all*, or with scant text files covering the bare basics.
>
> Unfortunately this trend is only getting worse, and we have far too
> many notaable examples here, not all of them coming from the GNU
> project, or from the "ITS tradition", whatever it means for you.
>
> I agree that whoever does not produce a readily usable documentaion
> for their software has not really understood much of the Unix
> philosophy. But that's not at all a matter of formats, rather of
> culture.
>
> Then, if you just want to vomit on info, or you prefer to use info as
> another excuse to vomit on the GNU project, well go ahead. But the
> actual issue is elsewhere (the lack of respect for the users, and the
> tendency to hide stuff under the carpet), and has not been introduced
> by the GNU project, at all.
>
> My2Cents
>
> Enzo Nicosia
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."
Jon
^ permalink raw reply [flat|nested] 12+ messages in thread
* [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; 12+ 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] 12+ 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; 12+ 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] 12+ messages in thread
end of thread, other threads:[~2019-09-19 22:45 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-19 18:50 [TUHS] [OT] Re: earliest Unix roff 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 20:42 ` [TUHS] " Andy Kosela
2019-09-19 22:44 ` [TUHS] [OT] " Rob Pike
-- strict thread matches above, loose matches on Subject: below --
2019-09-19 21:19 Norman Wilson
2019-09-16 14:51 [TUHS] " 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).