Re: [TUHS] man Macro Package and pdfmark

Re: [TUHS] man Macro Package and pdfmark

[Don Hopkins]

Arnold wrote:

> Well said.  The markup language was clearly inspired by Scribe, which
> was quite popular in Academia (at least) at the time.
> 
> As a *markup language*, I personally find it superior to anything
> else currently in use, but that's a whole different discussion that
> on TUHS inevitably degenerates into the current spate of ranting,
> so I won't start on it.

So in other words, you mean:

@Flame(Off)

-Don

Re: [TUHS] man Macro Package and pdfmark

[Noel Chiappa]

    > From: Jon Steinhart

    > When you're looking for the documentation for pdf2svg, for example, and
    > there is no man page, how long does it take to figure out that there is
    > no documentation at all?

I am _sooo_ tempted to say 'What do you think source is for?' :-)

	Noel

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

On Mon, Feb 17, 2020 at 1:56 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Jon Steinhart
>
>     > When you're looking for the documentation for pdf2svg, for example,
> and
>     > there is no man page, how long does it take to figure out that there
> is
>     > no documentation at all?
>
> I am _sooo_ tempted to say 'What do you think source is for?' :-)
>
>         Noel
>
Ah, the old 'trust (read) the source Luke' defense ....

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

Re: [TUHS] man Macro Package and pdfmark

[CHARLES KESTER]

> On February 17, 2020 at 12:13 PM Clem Cole <clemc@ccc.com> wrote:
> 
> 
> On Mon, Feb 17, 2020 at 1:56 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
> wrote:
> 
> >     > From: Jon Steinhart
> >
> >     > When you're looking for the documentation for pdf2svg, for example,
> > and
> >     > there is no man page, how long does it take to figure out that there
> > is
> >     > no documentation at all?
> >
> > I am _sooo_ tempted to say 'What do you think source is for?' :-)
> >
> >         Noel
> >
> Ah, the old 'trust (read) the source Luke' defense ....

... which, unfortunately, is all too often invoked by people who fail
to honor the obligation it imposes to write clear, understandable code.

Re: [TUHS] man Macro Package and pdfmark

[Dave Horsfall]

On Mon, 17 Feb 2020, Noel Chiappa wrote:

> I am _sooo_ tempted to say 'What do you think source is for?' :-)

"Use the source, Luke" :-)

-- Dave

Re: [TUHS] man Macro Package and pdfmark

[Doug McIlroy]

> one of the things I wanted to do in my retirement was convert
> all the stuff that is in debian back from info to man(7)

*all* the stuff? Please don't do that literally. The garrulity
quotient of info pages dwarfs even that of the most excessive
modern man pages. But I appplaud the intent to assure man
pages are complete.

Doug

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

On Mon, Feb 17, 2020 at 10:22 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> *all* the stuff? Please don't do that literally. The garrulity
> quotient of info pages dwarfs even that of the most excessive
> modern man pages.


😂

But I appplaud the intent to assure man pages are complete.
>
The problem is that too many of the gnu style man pages are just written in
the key of -> "see figure one
<https://www.dourish.com/goodies/see-figure-1.html>" as documents telling
you to go to info (which I find maddening).  [I find it similar to ITS not
accepting a BS as the correction character, but instead picking it up and
then telling you to use DEL -- the designers know what you want, sigh].

I'd like simple man pages that are reasonable references. And then get the
rest of the needed documentation out info and the weird hyper texting stuff
into a paper (so you can read it linearly - the way we were taught as
children).   I loved the simple prose in the papers that usually
accompanied the traditional UNIX programs/tools.  I read them and reread
them as I learned to use the features and concepts provided by the more
complicated tools.  After that, the simple man pages were more than
sufficient to remind me of the specifics I needed  to use some features I
did not use every day.

Clem


One of my complaints with info is that as a format, it leads to documents
that does neither well.  They tend not to be reference documents like man
pages as you point out, but they are moisty often than not, particularly
good explanations either. Sigh...

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

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

>*all* the stuff? Please don't do that literally. The garrulity
>quotient of info pages dwarfs even that of the most excessive
;-)
>modern man pages. But I appplaud the intent to assure man
>pages are complete.
info pages clearly are redundant. Even worser under linux most of them visualizing man pages, whereas hardly any man page is missing.
They are emacs style help pages in the tradition of twenex/its, and I tell you that a few years ago one guy (not me) recommended in the emacs developer list to replace tekinfo by something modern like .html.

Thus the question isn't man or tekinfo for linux documentation but html/markup or or tekinfo for emacs build-in self documentation.

Re: [TUHS] man Macro Package and pdfmark

[Jon Steinhart]

Thomas Paulsen writes:
> >*all* the stuff? Please don't do that literally. The garrulity
> >quotient of info pages dwarfs even that of the most excessive
> ;-)
> >modern man pages. But I appplaud the intent to assure man
> >pages are complete.
> info pages clearly are redundant. Even worser under linux most of them
> visualizing man pages, whereas hardly any man page is missing.
> They are emacs style help pages in the tradition of twenex/its, and I tell
> you that a few years ago one guy (not me) recommended in the emacs developer
> list to replace tekinfo by something modern like .html.
>
> Thus the question isn't man or tekinfo for linux documentation but html/markup
> or or tekinfo for emacs build-in self documentation.

I think that this discussion is like bell-bottoms, it comes around every few years.

Like Clem, I prefer concise man pages and longer, separate documents for those
programs where it makes sense.  I consider man pages to be quick references.

But my real issue with texinfo wouldn't get solved with html pages many of which
already exist.  The problem is that the ecosystem has been fragmented by people
doing their "documentation" in their preferred formats instead of in a common (man)
format.  This makes the experience one of "is there any documentation?" followed by
"what's the incantation to get it?"  When you're looking for the documentation for
pdf2svg, for example, and there is no man page, how long does it take to figure out
that there is no documentation at all?

Jon

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

>Like Clem, I prefer concise man pages and longer, separate documents for those programs where it makes sense.  I consider man pages to be quick references.
reasonable. 
I write all my quick references in plain nroff since many years.  There are gui editors, gui viewers, and lots of cgi search engines && web viewers even with hyperlinks. Even under good ole emacs techinfo is redundant, as 'woman' can do hyperlinks, which were the only advantage of techinfo in a remote past, however time goes on. Today we have help2man, hence the lazy ones can do man pages too.


>The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man)
>format.  This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?"  When you're looking for the documentation for
>pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all?
that's true. In the early 90ths they forced us writing quick references with .html. Big confusion. Soon later I found myself converting .html back into nroff because thats the UNIX style.
I know some of us don't like to hear that, but with regards to the gnu tool chain, Richard did a lot of good things, however the politics of replacing man by techinfo  definitely wasn't. 

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

>Like Clem, I prefer concise man pages and longer, separate documents for those programs where it makes sense. I consider man pages to be quick references.
reasonable.
I write all my quick references in plain nroff since many years. There are gui editors, gui viewers, and lots of cgi search engines && web viewers even with hyperlinks. Even under good ole emacs techinfo is redundant, as 'woman' can do hyperlinks, which were the only advantage of techinfo in a remote past, however time goes on. Today we have help2man, hence the lazy ones can do man pages too.


'The problem is that the ecosystem has been fragmented by people doing their "documentation" in their preferred formats instead of in a common (man) format. This makes the experience one of "is there any documentation?" followed by "what's the incantation to get it?" When you're looking for the documentation for pdf2svg, for example, and there is no man page, how long does it take to figure out that there is no documentation at all? '

that's true. In the early 90ths they forced us writing quick references with .html. Big confusion. Soon later I found myself converting .html back into nroff because that's the UNIX style.
I know some of us don't like to hear that, but with regards to the gnu tool chain, Richard did a lot of good things, however the politics of replacing man by techinfo definitely wasn't.

Re: [TUHS] man Macro Package and pdfmark

[Warner Losh]

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

On Mon, Feb 17, 2020 at 3:51 PM Thomas Paulsen <thomas.paulsen@firemail.de>
wrote:

> >Like Clem, I prefer concise man pages and longer, separate documents for
> those programs where it makes sense. I consider man pages to be quick
> references.
> reasonable.
> I write all my quick references in plain nroff since many years. There are
> gui editors, gui viewers, and lots of cgi search engines && web viewers
> even with hyperlinks. Even under good ole emacs techinfo is redundant, as
> 'woman' can do hyperlinks, which were the only advantage of techinfo in a
> remote past, however time goes on. Today we have help2man, hence the lazy
> ones can do man pages too.
>
>
> 'The problem is that the ecosystem has been fragmented by people doing
> their "documentation" in their preferred formats instead of in a common
> (man) format. This makes the experience one of "is there any
> documentation?" followed by "what's the incantation to get it?" When you're
> looking for the documentation for pdf2svg, for example, and there is no man
> page, how long does it take to figure out that there is no documentation at
> all? '
>
> that's true. In the early 90ths they forced us writing quick references
> with .html. Big confusion. Soon later I found myself converting .html back
> into nroff because that's the UNIX style.
> I know some of us don't like to hear that, but with regards to the gnu
> tool chain, Richard did a lot of good things, however the politics of
> replacing man by techinfo definitely wasn't.
>

I think this showed the wisdom of deleting binaries from /usr/bin when
there was no man page for them...

Warner

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

Re: [TUHS] man Macro Package and pdfmark

[Bakul Shah]

On Mon, 17 Feb 2020 16:22:32 -0700 Warner Losh <imp@bsdimp.com> wrote:
>
> I think this showed the wisdom of deleting binaries from /usr/bin when
> there was no man page for them...

If some of us undertake to write a few man pages and review a
few written by others, over time we can make a sizable dent in
the problem.  Something worth considering for FreeBSD ports?

Of course, not as much fun as complaining and a lot more work :-)

Re: [TUHS] man Macro Package and pdfmark

[Dave Horsfall]

On Mon, 17 Feb 2020, Warner Losh wrote:

> I think this showed the wisdom of deleting binaries from /usr/bin when 
> there was no man page for them...

Was it Ken or Dennis who used to do that?  People quickly learned to write 
up a man page :-)

-- Dave

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

>> I think this showed the wisdom of deleting binaries from /usr/bin when there was no man page for them...

>Was it Ken or Dennis who used to do that?  People quickly learned to write
Brian?

Re: [TUHS] man Macro Package and pdfmark

[Richard Salz]

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

> 'The problem is that the ecosystem has been fragmented by people doing
their "documentation" in their preferred formats instead of in a common
(man) format.

Damn those unauthorized developers.  How dare they write code that doesn't
meet standards.

Get off my lawn.

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

Re: [TUHS] man Macro Package and pdfmark

[Jon Steinhart]

Richard Salz writes:
>
> > 'The problem is that the ecosystem has been fragmented by people doing
> their "documentation" in their preferred formats instead of in a common
> (man) format.
>
> Damn those unauthorized developers.  How dare they write code that doesn't
> meet standards.
>
> Get off my lawn.

The relevant TUHS part of it that maybe some folks here can speak to is how
did UNIX remain so cohesive for so long?  How were decisions made?  Of course,
this started to fall apart with System III and such as things got more clunky.

I've probably said this before, but today I see way too much "string theory
programming".  What I mean by that is the "I have an idea so I'll just start
my own universe that doesn't play well with others rather than extending the
existing ecosystem" model.  That's my beef with texinfo; there was already
an existing functional system and rather than making some improvements a new
incompatible universe was created.

Noel Chiappa writes:
> I am _sooo_ tempted to say 'What do you think source is for?' :-)

I think that this is part of the problem, have you looked at the source for
any modern package?  It's pretty impenetrable.  I see a lot of overly complex,
poorly written code with no documentation.  That makes it really difficult for
someone to extend or otherwise modify it.  It's probably easier to create a
new universe than understand an existing one.

Jon

Re: [TUHS] man Macro Package and pdfmark

[Larry McVoy]

On Mon, Feb 17, 2020 at 04:17:18PM -0800, Jon Steinhart wrote:
> Richard Salz writes:
> >
> > > 'The problem is that the ecosystem has been fragmented by people doing
> > their "documentation" in their preferred formats instead of in a common
> > (man) format.
> >
> > Damn those unauthorized developers.  How dare they write code that doesn't
> > meet standards.
> >
> > Get off my lawn.
> 
> The relevant TUHS part of it that maybe some folks here can speak to is how
> did UNIX remain so cohesive for so long?  How were decisions made?  Of course,
> this started to fall apart with System III and such as things got more clunky.

I think that part of it was that machines were small, both in memory and in
disk.  I did a huge programming project because I wanted to compress the
pathalias output; I had 20 users on a 40MB disk.  So big == evil.

The other thing, if we're talking about kernels, uniprocessor kernels
were pretty simple to understand compared to SMP, and NUMA, and the PCI
devices tree and a million other things that modern computers had.

v6 was documented in the lion book, you could read it all and understand
it in maybe a week or two?  That's not a thing any more.

> I've probably said this before, but today I see way too much "string theory
> programming".  What I mean by that is the "I have an idea so I'll just start
> my own universe that doesn't play well with others rather than extending the
> existing ecosystem" model.  That's my beef with texinfo; there was already
> an existing functional system and rather than making some improvements a new
> incompatible universe was created.

Yeah, you need a dictator that says that's not OK.

Re: [TUHS] man Macro Package and pdfmark

[Bakul Shah]

On Mon, 17 Feb 2020 16:17:18 -0800 Jon Steinhart <jon@fourwinds.com> wrote:
> Richard Salz writes:
> >
> > > 'The problem is that the ecosystem has been fragmented by people doing
> > their "documentation" in their preferred formats instead of in a common
> > (man) format.
> >
> > Damn those unauthorized developers.  How dare they write code that doesn't
> > meet standards.
> >
> > Get off my lawn.
>
> The relevant TUHS part of it that maybe some folks here can speak to is how
> did UNIX remain so cohesive for so long?  How were decisions made?  Of course,
> this started to fall apart with System III and such as things got more clunky.

Agree. I don't mind additional documentation but a man page is
strongly preferred.

> Noel Chiappa writes:
> > I am _sooo_ tempted to say 'What do you think source is for?' :-)
>
> I think that this is part of the problem, have you looked at the source for
> any modern package?  It's pretty impenetrable.  I see a lot of overly complex,
> poorly written code with no documentation.  That makes it really difficult for
> someone to extend or otherwise modify it.  It's probably easier to create a
> new universe than understand an existing one.

There is just so much more code now and the S/N ratio is
definitely worse but there is more good stuff as well.

My problems with using the source as documentation:
a) there is usually no or insufficient documentation about
   even what it is implementing let alone *how* it should be
   used,
b) you don't know if some behavior is an accident of the way
   the code behaves or actually part of some required (but
   unwritten) specification.
c) even if there some function header comments often there is no
   top level comment tying together eveyrthing. 
d) harder to see missing functionality.
e) impossible to grok large programs.

Re: [TUHS] man Macro Package and pdfmark

[Greg A. Woods]

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

At Mon, 17 Feb 2020 16:17:18 -0800, Jon Steinhart <jon@fourwinds.com> wrote:
Subject: Re: [TUHS] man Macro Package and pdfmark
>
> That's my beef with texinfo; there was already
> an existing functional system and rather than making some improvements a new
> incompatible universe was created.

Actually there wasn't a truly functional documentation system at the
time -- or at least it didn't reach far enough.

I.e. there was no open-source [nt]roff compatible program at the time,
and the mainly available proprietary one produced (for quality printing
purposes) only very convoluted hard-coded output for a quite esoteric
and rare piece of equipment.  AT&T's public attempt to solve this
(ditroff) just added more cost and arguably less availability.

Groff didn't arrive until 1990, and as remarkable as it was, it was
unfortunately written in C++ (which dissuaded many for a long time).

(Henry Spencer's "awf" (nroff in Awk) also came out in 1990, but besides
being also too late it was more of a toy; and Chris Lewis' PSroff, also
from just before 1990, only solved part of the problem.)

Texinfo was a legitimate attempt to solve the problem of missing tools,
and at the same time and tried (whether in vain or not) to improve on
what were rather widely believed to be major technical and cultural and
availability deficiencies in existing tools.

Personally I still mostly use Lout these days.  :-)

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] man Macro Package and pdfmark

[arnold]

"Greg A. Woods" <woods@robohack.ca> wrote:

> Texinfo was a legitimate attempt to solve the problem of missing tools,
> and at the same time and tried (whether in vain or not) to improve on
> what were rather widely believed to be major technical and cultural and
> availability deficiencies in existing tools.

Well said.  The markup language was clearly inspired by Scribe, which
was quite popular in Academia (at least) at the time.

As a *markup language*, I personally find it superior to anything
else currently in use, but that's a whole different discussion that
on TUHS inevitably degenerates into the current spate of ranting,
so I won't start on it.

> Personally I still mostly use Lout these days.  :-)

Wow. Is that still maintained?

Arnold

Re: [TUHS] man Macro Package and pdfmark

[Greg A. Woods]

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

At Tue, 18 Feb 2020 00:45:11 -0700, arnold@skeeve.com wrote:
Subject: Re: [TUHS] man Macro Package and pdfmark
>
> "Greg A. Woods" <woods@robohack.ca> wrote:
> >
> > Personally I still mostly use Lout these days.  :-)
>
> Wow. Is that still maintained?

Oh yeah, though it's kind of like TeX in that it has been very stable
and relatively bug-free for years now.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] man Macro Package and pdfmark

[Rich Morin]

Ahem.  Back in the 80's, I used both nroff and troff a fair amount.
For example, Vicki Brown and I used nroff, in combination with an
IBM I/O Selectric (Datel 30) to print most of her master's thesis.
I also used troff to typeset several books for Prime Time Freeware.
Mostly, I used pre-existing macro packages, but sometimes I had to
dive down to the bare metal.  It all worked, and was quite flexible,
but I really don't miss it for adding docs to software projects.

Lately, I've been using the built-in documentation tools for Elixir,
a functional programming language based on the Erlang VM and a lot
of Ruby syntax.  I'm pleased to say that it's really quite pleasant.

I create multi-line "attributes" using macros such as @doc.  These
are encoded using Markdown, which isn't perfect but seems adequate.
The results are converted into both HTML pages and interactive help
text, with automagical indexing.

I'm able to create "doctests" by embedding IEx (Interactive Elixir)
examples, eg:

    iex> 2 + 2
    4

These get tested automagically, providing a modicum of reliability
to the documentation.  Amusingly, I did something similar years ago,
extracting C code from the SYNOPSIS sections of Apple's man pages.
This let me find and report a few docubugs...

-r

Re: [TUHS] man Macro Package and pdfmark

[arnold]

Rich Morin <rdm@cfcl.com> wrote:

> Lately, I've been using the built-in documentation tools for Elixir,
> a functional programming language based on the Erlang VM and a lot
> of Ruby syntax.  I'm pleased to say that it's really quite pleasant.
>
> I create multi-line "attributes" using macros such as @doc.  These
> are encoded using Markdown, which isn't perfect but seems adequate.
> The results are converted into both HTML pages and interactive help
> text, with automagical indexing.

This sounds something like a poor man's version of Literate Programming,
invented by Donald Knuth for TeX et al.

That's another technology that I happen to like personally, but
which never became mainstream.  More's the pity (IMHO).

(I do know about Doug's review of DEK's program in the Programming
Pearls column. I think the problems there were not with Lit Prog
itself, but with how Knuth programs.  My own take on Literate Programming
can be seen at https://github.com/arnoldrobbins/texiwebjr.)

Yes, probably getting off topic, too.

Arnold

Re: [TUHS] man Macro Package and pdfmark

[U'll Be King of the Stars]

On 18/02/2020 12:28, arnold@skeeve.com wrote:
 > (I do know about Doug's review of DEK's program in the Programming
 > Pearls column. I think the problems there were not with Lit Prog
 > itself, but with how Knuth programs.

What are the issues with how Knuth programs?

Honestly I've never heard any criticisms before.

 > My own take on Literate Programming
 > can be seen at https://github.com/arnoldrobbins/texiwebjr.)

This looks _really_ cool.  I am looking forward to reading this in
detail and hopefully experimenting with it.

 > Yes, probably getting off topic, too.

Really?  But then how about this?

David R. Hanson, "C Interfaces and Implementations: Techniques for 
Creating Reusable Software", Addison-Wesley Professional, 1996.  Online 
at 
https://www.informit.com/store/c-interfaces-and-implementations-techniques-for-creating-9780201498417 
.

It is not only one of the best books about programming I've ever read. 
It's also one of the finest examples of literate programming I've seen.

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Re: [TUHS] man Macro Package and pdfmark

[arnold]

"U'll Be King of the Stars" <ullbeking@andrewnesbit.org> wrote:

> On 18/02/2020 12:28, arnold@skeeve.com wrote:
>  > (I do know about Doug's review of DEK's program in the Programming
>  > Pearls column. I think the problems there were not with Lit Prog
>  > itself, but with how Knuth programs.
>
> What are the issues with how Knuth programs?
>
> Honestly I've never heard any criticisms before.

This all dates from the mid-1980s. It's reproduced in Knuth's
book "Literate Progrmming", which you can find on Amazon and is
well worth owning. That book has some other gems, including his
famous paper "Structure Programming With goto Statements".

The original Programming Pearls column was published in CACM.
Google helps find it:

	https://dl.acm.org/doi/10.1145/5948.315654

>  > My own take on Literate Programming
>  > can be seen at https://github.com/arnoldrobbins/texiwebjr.)
>
> This looks _really_ cool.  I am looking forward to reading this in
> detail and hopefully experimenting with it.

Thanks!

> David R. Hanson, "C Interfaces and Implementations: Techniques for 
> Creating Reusable Software", Addison-Wesley Professional, 1996.  Online 
> at 
> https://www.informit.com/store/c-interfaces-and-implementations-techniques-for-creating-9780201498417 
> .

I have that book.

There's also the LCC C compiler book which was done in a literate style.

Arnold

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

hrrmpt...

On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods <woods@robohack.ca> wrote:

> At Mon, 17 Feb 2020 16:17:18 -0800, Jon Steinhart <jon@fourwinds.com>
> wrote:
> Subject: Re: [TUHS] man Macro Package and pdfmark
> >
> > That's my beef with texinfo; there was already
> > an existing functional system and rather than making some improvements a
> new
> > incompatible universe was created.
>
> Actually there wasn't a truly functional documentation system at the
> time -- or at least it didn't reach far enough.
>
> I.e. there was no open-source [nt]roff compatible program at the time,
> and the mainly available proprietary one produced (for quality printing
> purposes) only very convoluted hard-coded output for a quite esoteric
> and rare piece of equipment.  AT&T's public attempt to solve this
> (ditroff) just added more cost and arguably less availability.
>
ditroff was always >>open source<< and any licensee could get it and see
it.  The problem you are suggesting is that it was not >>free<< i.e. FOSS.
AT&T licensed it with a small set of fees.   IIRC $1K for the first CPU, an
$50 for each and redistribution license was $10K and $5/system.  The other
issue is you really needed Adobe's transcript package to effectively use it
on your Apple Laserwriter and other later PS based printers, as most people
lacked actual typesetters.

Please remember that >>all<< the Universities with $150 AT&T licensed and a
BSD license, had basic troff on their Vaxen with any BSD systems they had.
  So they all had it for 'free' (and open).  I'll accept Larry's previous
notes that not all people in those places had access to the sources, but
everyone should have had access to the binaries that came with the system.

For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the
like, it is possible it was different.  The fact is I know Masscomp
supplied ditroff on all systems and just ate the $5 license fee.   We also
license transcript from Adobe and included that.   My memory is that was
just a one-time charge and no redistribution.   I'm not sure what Sun did,
but I think they supplied the BSD troff, vcat and the like (Larry may know
for sure).  I'm pretty sure HP supplied at least the BSD/vcat family; but
they have updated to ditroff.   I've forgotten what DEC settled on. By the
time of Tru64 it was ditroff on the system, but with Ultrix it may have
been you got the troff/vcat off the BSD tape had their was a fee for the
ditroff/transcript package.

So the basic facts are is that in the Unix ecosystem, the nroff/troff
ecosystem was very much around before 1990's groff.   Frankly, the biggest
thing it did was enabled Linux to have a version of ditroff.   I know in my
own case, I would (horrors) carry the sources with me for the AT&T package
and Transcript for early PC based BSD's.   The truth is both packages were
(and are) easily findable in dark corners of the Internet.

I also request, that we refrain from the seemingly yearly Tex vs. troff
war. It's about as productive as the C vs Pascal or C++ vs Java
discussions. This thread started as Doug's observation about wanting man
pages and issues with Gnu's texinfo scheme.     It turns out man was based
on the [nr]roff family.  The reality is that any document compiler
>>could<< have been used.    If something other than the roff family was
used to create man pages, that would be a different discussion.

... and I like my lawn as it is ...

Clem

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

Re: [TUHS] man Macro Package and pdfmark

[arnold]

Clem Cole <clemc@ccc.com> wrote:

> ditroff was always >>open source<< and any licensee could get it and see
> it.  The problem you are suggesting is that it was not >>free<< i.e. FOSS.

I don't like your use of "open source"; it is way out of skew with
how it's used today.

> AT&T licensed it with a small set of fees.   IIRC $1K for the first CPU, an
> $50 for each and redistribution license was $10K and $5/system.

That was very painful for universities and/or small businesses. Sure
Sun and Masscomp could afford that. Your average computing center / 
computer science department / startup would have to think twice or thrice.

Per CPU licensing was particularly painful if you had a bunch
of workstations.

Arnold

Re: [TUHS] man Macro Package and pdfmark

[Larry McVoy]

On Tue, Feb 18, 2020 at 08:28:50AM -0700, arnold@skeeve.com wrote:
> Clem Cole <clemc@ccc.com> wrote:
> 
> > ditroff was always >>open source<< and any licensee could get it and see
> > it.  The problem you are suggesting is that it was not >>free<< i.e. FOSS.
> 
> I don't like your use of "open source"; it is way out of skew with
> how it's used today.
> 
> > AT&T licensed it with a small set of fees.   IIRC $1K for the first CPU, an
> > $50 for each and redistribution license was $10K and $5/system.
> 
> That was very painful for universities and/or small businesses. Sure
> Sun and Masscomp could afford that. Your average computing center / 
> computer science department / startup would have to think twice or thrice.
> 
> Per CPU licensing was particularly painful if you had a bunch
> of workstations.

Yeah, Clem sort of has a blind spot on licensing.  It's weird because I
agree with him on almost everything, it's sort of spooky how much we
agree.

My guess is that Clem was always at a University or a job where the fees
were mouse nuts and so it appeared to him that things just worked.  If
you were a grad student like me, who wanted roff on a PC, it was very
different.  And I suspect Clem has always been seen as one of the 
chosen few who get logins on the machines with source.  I was a nobody
and had to fight hard to get a login, I got it, but not until I was a
junior.

Re: [TUHS] man Macro Package and pdfmark

[Steve Nickolas]

On Tue, 18 Feb 2020, arnold@skeeve.com wrote:

> I don't like your use of "open source"; it is way out of skew with
> how it's used today.

Wasn't it always *intended* to mean the same thing as "Free Software" ?

(I use the phrase "freedom-compliant software" to be unambiguous, but it's 
a bit unwieldy.)

-uso.

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

Yes and the term "open" was coined by the marketing folks in uniforum to
describe the open interfaces and ability to see the sources (you might have
pay a license fee). Or it was not free.


Other people came later and missinterpreded the term.

Clem

On Tue, Feb 18, 2020 at 10:43 AM Steve Nickolas <usotsuki@buric.co> wrote:

> On Tue, 18 Feb 2020, arnold@skeeve.com wrote:
>
> > I don't like your use of "open source"; it is way out of skew with
> > how it's used today.
>
> Wasn't it always *intended* to mean the same thing as "Free Software" ?
>
> (I use the phrase "freedom-compliant software" to be unambiguous, but it's
> a bit unwieldy.)
>
> -uso.
>
-- 
Sent from a handheld expect more typos than usual

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

Re: [TUHS] man Macro Package and pdfmark

[Theodore Y. Ts'o]

On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote:
> On Tue, 18 Feb 2020, arnold@skeeve.com wrote:
> 
> > I don't like your use of "open source"; it is way out of skew with
> > how it's used today.
> 
> Wasn't it always *intended* to mean the same thing as "Free Software" ?

No, although the differences in practice are small.  "Free Software"
was defined by Stallman as meeting his "Four Freedoms".  Open
Source(tm) was derived from the Debian Free Software Guidelines, and
while the set of licenses which meet the "Free Software" definition
and those that meet the "Open Source(tm) definition mostly identical,
there are a few exceptions.

I refer folks to the Wikipedia entry for more details:

https://en.wikipedia.org/wiki/The_Free_Software_Definition

It is true that the most of the people who use Open Source instead of
Free Software are doing so mostly for branding reasons (e.g., Open
Source is considered less likely to scare the suits), but technically
they aren't the same.  And it is certainly true that way AT&T
distributed ditroff certainly isn't compliant with the Open Source
Definition (OSD).

Whether or not it meets Clem's "open source" (small o, small s),
depends on his definition, which appears to be, "functionally, since
everyone back then had an AT&T source license, we're all good".

						- Ted

Re: [TUHS] man Macro Package and pdfmark

[Steve Nickolas]

On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote:

> On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote:
>> On Tue, 18 Feb 2020, arnold@skeeve.com wrote:
>>
>>> I don't like your use of "open source"; it is way out of skew with
>>> how it's used today.
>>
>> Wasn't it always *intended* to mean the same thing as "Free Software" ?
>
> No, although the differences in practice are small.  "Free Software"
> was defined by Stallman as meeting his "Four Freedoms".  Open
> Source(tm) was derived from the Debian Free Software Guidelines, and
> while the set of licenses which meet the "Free Software" definition
> and those that meet the "Open Source(tm) definition mostly identical,
> there are a few exceptions.
>
> I refer folks to the Wikipedia entry for more details:
>
> https://en.wikipedia.org/wiki/The_Free_Software_Definition
>
> It is true that the most of the people who use Open Source instead of
> Free Software are doing so mostly for branding reasons (e.g., Open
> Source is considered less likely to scare the suits), but technically
> they aren't the same.  And it is certainly true that way AT&T
> distributed ditroff certainly isn't compliant with the Open Source
> Definition (OSD).
>
> Whether or not it meets Clem's "open source" (small o, small s),
> depends on his definition, which appears to be, "functionally, since
> everyone back then had an AT&T source license, we're all good".
>
> 						- Ted
>

I always understood "open source" to mean this: you have access to the 
code, you can share it, you can modify it, and any combination of the 
above (including commercial exploitation; basically a restatement of 
Stallman's freedoms in simpler words).

As any phrase gets skewed to mean something other than it was intended, 
when most people say "open source", they seem to only mean what I call 
"source-available" - i.e., that there is *some* means by which a mere 
mortal can gain access to the source, but there is no guarantee that they 
can actually DO anything with the source without getting sued into 
oblivion.  I usually say if the code doesn't offer the necessary freedom 
to make use of it. it's not "open source", it's just source.

(For the record: I shifted from the GNU side to the BSD side of the debate 
about 20 years ago.  But I hold no ill will toward people on the GNU 
side.)

-uso.

Re: [TUHS] man Macro Package and pdfmark

[Dave Horsfall]

On Tue, 18 Feb 2020, Steve Nickolas wrote:

> (For the record: I shifted from the GNU side to the BSD side of the 
> debate about 20 years ago.  But I hold no ill will toward people on the 
> GNU side.)

I've always stayed with BSD :-)  I regard the GPL as a virus and too 
restrictive, as it compels me to do certain things; if the only choice is 
to make use of a GPL library then I will write my own rather than have my 
work owned by Stallman et al.

-- Dave

Re: [TUHS] man Macro Package and pdfmark

[Wesley Parish]

IIRC, there was a meeting of various (FOSS) luminaries in the early or
mid-90s discussing rebranding Free Software (as in the FSF definition)
as it was far too easily misinterpreted as meaning
non-/anti-commercial. "Open Systems" had been around forever as a
description of how the Unix "ecosystem" worked - you had a common set
of APIs based on an originally common source base, and a common set of
communication protocols, that worked on a wide array of computer
systems, from real-time to supercomputers to mainframes and beyond.

With all due respect to Clem Cole, I don't recall ever seeing "open
source" used as a description of the Unix "ecosystem" during the 90s.
It was in the air with the (minimal) charges Prentice-Hall charged for
the Minix 0.x and 1.x disks and source; not dissimilar in that sense
to the charges the FSF were charging for their tapes at the time.

But all the Unix-y ads I can recall from the 90s talked about Open
Systems, and never Open Source. That came in following Linux and *BSD
radiation. But this is probably COFF's Harbour stuff ...

Wesley Parish

On 2/19/20, Steve Nickolas <usotsuki@buric.co> wrote:
> On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote:
>
>> On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote:
>>> On Tue, 18 Feb 2020, arnold@skeeve.com wrote:
>>>
>>>> I don't like your use of "open source"; it is way out of skew with
>>>> how it's used today.
>>>
>>> Wasn't it always *intended* to mean the same thing as "Free Software" ?
>>
>> No, although the differences in practice are small.  "Free Software"
>> was defined by Stallman as meeting his "Four Freedoms".  Open
>> Source(tm) was derived from the Debian Free Software Guidelines, and
>> while the set of licenses which meet the "Free Software" definition
>> and those that meet the "Open Source(tm) definition mostly identical,
>> there are a few exceptions.
>>
>> I refer folks to the Wikipedia entry for more details:
>>
>> https://en.wikipedia.org/wiki/The_Free_Software_Definition
>>
>> It is true that the most of the people who use Open Source instead of
>> Free Software are doing so mostly for branding reasons (e.g., Open
>> Source is considered less likely to scare the suits), but technically
>> they aren't the same.  And it is certainly true that way AT&T
>> distributed ditroff certainly isn't compliant with the Open Source
>> Definition (OSD).
>>
>> Whether or not it meets Clem's "open source" (small o, small s),
>> depends on his definition, which appears to be, "functionally, since
>> everyone back then had an AT&T source license, we're all good".
>>
>> 						- Ted
>>
>
> I always understood "open source" to mean this: you have access to the
> code, you can share it, you can modify it, and any combination of the
> above (including commercial exploitation; basically a restatement of
> Stallman's freedoms in simpler words).
>
> As any phrase gets skewed to mean something other than it was intended,
> when most people say "open source", they seem to only mean what I call
> "source-available" - i.e., that there is *some* means by which a mere
> mortal can gain access to the source, but there is no guarantee that they
> can actually DO anything with the source without getting sued into
> oblivion.  I usually say if the code doesn't offer the necessary freedom
> to make use of it. it's not "open source", it's just source.
>
> (For the record: I shifted from the GNU side to the BSD side of the debate
> about 20 years ago.  But I hold no ill will toward people on the GNU
> side.)
>
> -uso.
>

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

The term OSS to mean free as in beer is just not correct.   The sources
were always free a as in available to be read but just like today they are
licensed.

Ad for Universities. The point is if you had a vax you had troff as a
miniimun an $50 for ditroff was not a hardship.

If you had a binary workstation from DEC or Sun you got troff on the system
and if you got a masscomp you got ditroff.

The point is people had access to a working binary without spending any we
real extra money - which was Jons point.

The ecosystem under Unix was fine until the real a FOSS world which was
when groff appears.

On Tue, Feb 18, 2020 at 10:28 AM <arnold@skeeve.com> wrote:

> Clem Cole <clemc@ccc.com> wrote:
>
> > ditroff was always >>open source<< and any licensee could get it and see
> > it.  The problem you are suggesting is that it was not >>free<< i.e.
> FOSS.
>
> I don't like your use of "open source"; it is way out of skew with
> how it's used today.
>
> > AT&T licensed it with a small set of fees.   IIRC $1K for the first CPU,
> an
> > $50 for each and redistribution license was $10K and $5/system.
>
> That was very painful for universities and/or small businesses. Sure
> Sun and Masscomp could afford that. Your average computing center /
> computer science department / startup would have to think twice or thrice.
>
> Per CPU licensing was particularly painful if you had a bunch
> of workstations.
>
> Arnold
>
-- 
Sent from a handheld expect more typos than usual

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

Re: [TUHS] man Macro Package and pdfmark

[Chet Ramey]

On 2/18/20 10:48 AM, Clem Cole wrote:
> The term OSS to mean free as in beer is just not correct.   The sources
> were always free a as in available to be read but just like today they are
> licensed. 

I'm not sure that "open source" as a synonym for "source code available
for purchase" is valid.


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

But that is how it was formed by the original commercial unix folks (which
I was one).    We talked about the open systems community.  Look at some of
the uniforum docs in the archives from the mid 1980s if you don't believe
me. That is what was meant because we could not say Unix and at the term in
the commercial community it was Unix vs proprietary systems aka VMS, MPE,
Kronos et al.

The context of the day that was exactly what we meant.  That said, I'll
grant you you words change meaning over time, but I was and do use the term
in context of the original open systems community - which I was a founder.

If you mean FOSS then say that, if you mean an open system with published
interfaces and available sources, that by definition open source software.

So please don't try tell me what we meant. Eric Raymond is probably the
person where I  started to see the warp of its meaning.

That's why I always say FOSS when I mean free in the context of RMS.
 Also remember most of the current FOSS movement the code is very
restrictioned in it's license.  The difference is if you have to pay a fee
for it and what you can do with the derivative works

Fyi if you want to discuss free or not that discussion needs to move to
COFF.  This is certain a discussion from an old f*RTS perspective.

On Tue, Feb 18, 2020 at 11:02 AM Chet Ramey <chet.ramey@case.edu> wrote:

> On 2/18/20 10:48 AM, Clem Cole wrote:
> > The term OSS to mean free as in beer is just not correct.   The sources
> > were always free a as in available to be read but just like today they
> are
> > licensed.
>
> I'm not sure that "open source" as a synonym for "source code available
> for purchase" is valid.
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/
>
-- 
Sent from a handheld expect more typos than usual

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

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

[-- Attachment #1: Type: text/html, Size: 523 bytes --]

Re: [TUHS] man Macro Package and pdfmark

[Rich Morin]

> On Feb 18, 2020, at 07:28, arnold@skeeve.com wrote:
> 
> Clem Cole <clemc@ccc.com> wrote:
> 
>> ditroff was always >>open source<< and any licensee could get it and see
>> it.  The problem you are suggesting is that it was not >>free<< i.e. FOSS.
> 
> I don't like your use of "open source"; it is way out of skew with
> how it's used today.

"How I coined the term 'open source'", by Christine Peterson
https://opensource.com/article/18/2/coining-term-open-source-software

-r

Re: [TUHS] man Macro Package and pdfmark

[Henry Bent]

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

On Tue, Feb 18, 2020, 10:13 Clem Cole <clemc@ccc.com> wrote:

>
>
> For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the
> like, it is possible it was different.  The fact is I know Masscomp
> supplied ditroff on all systems and just ate the $5 license fee.   We
> also license transcript from Adobe and included that.   My memory is that
> was just a one-time charge and no redistribution.   I'm not sure what Sun
> did, but I think they supplied the BSD troff, vcat and the like (Larry may
> know for sure).  I'm pretty sure HP supplied at least the BSD/vcat family;
> but they have updated to ditroff.   I've forgotten what DEC settled on. By
> the time of Tru64 it was ditroff on the system, but with Ultrix it may have
> been you got the troff/vcat off the BSD tape had their was a fee for the
> ditroff/transcript package.
>

Off the top of my head, SGI also did this. Man pages in the standard IRIX
distribution were provided pre-formatted ("catman") and any sort of roff
was a separately available, for extra $, product called Documenter's
Workbench.  I know that this was the case in IRIX 4 and 5 (early-mid '90s),
not sure about earlier, and I believe that IRIX 6 finally rolled it into
the standard distribution.

The trouble was that if you had a package that provided standard man pages,
you had no way to format them unless you were able to get a hold of groff
or the like. Not an ideal situation.

-Henry

>

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

Re: [TUHS] man Macro Package and pdfmark

[Greg A. Woods]

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

At Tue, 18 Feb 2020 10:11:45 -0500, Clem Cole <clemc@ccc.com> wrote:
Subject: Re: [TUHS] man Macro Package and pdfmark
>
> On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods <woods@robohack.ca> wrote:
> >
> > I.e. there was no open-source [nt]roff compatible program at the time,
> > and the mainly available proprietary one produced (for quality printing
> > purposes) only very convoluted hard-coded output for a quite esoteric
> > and rare piece of equipment.  AT&T's public attempt to solve this
> > (ditroff) just added more cost and arguably less availability.
> >
> ditroff was always >>open source<< and any licensee could get it and see
> it.  The problem you are suggesting is that it was not >>free<< i.e. FOSS.

Indeed.  I was going to use the word "freeware", but it seems to have
gone out of common use in favour of the now more common "open-source",
as in https://opensource.org/

At the times I referred to the lack of freely available AT&T source code
was extremely limiting in how people viewed the availability of such
"add-on" tools for Unix -- including the C compiler!  AT&T's break-up of
the "Unix" distribution into separately licensed chunks was, from my
perspective, one of the main driving forces behind the creation and
adoption of so many clones and alternatives -- no matter how far they
strayed from the original Unix philosophy.

> For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the
> like, it is possible it was different.

It was _very_ different.

If you weren't out in the trenches of end-user Unix-based systems at the
time it may not have been as obvious as to just how restrictive it was
to have proprietary fee-based licensing of such add-on software.  Most
end-users couldn't even pay their vendors for ditroff -- their vendors
didn't want to have to license it from AT&T, even when they had
advocates inside the companies (e.g. I did some work supporting software
for a couple such vendors and was never able to convince them).  Some,
as you mention, were all-in, but it wasn't until UNIX System V Release 4
became more widely available that systems based on it were more likely
to have ditroff, and sometimes (though much more rarely) the "new" dpost
post-processor was also included.  I don't know if there were different
licensing terms for SysVr4 or not.  Don't get me started on how hard it
also was to get some end users to buy a C compiler too.

For the entire decade of the 1990s I was still one of the only people I
knew (outside of those I knew in AT&T Canada and their customers) who
owned a system that included ditroff and dpost and could print directly
to a PostScript laser printer -- and that's despite living in the same
city where SoftQuad was re-licensing ditroff and their variant of dpost
to quite a wide variety of users.  This was my situation because I had
chosen to buy a used AT&T 3B2.  Without that I'd have been without
ditroff -- I would have been very lucky if I had v7 troff binaries so
that I could use Chris' PSroff.

These days of course there's the full ditroff source release in the
Heirloom Documentation Tools collection.  I'd like to see it used to
replace Groff in some places, but so far I've been less than successful
-- that cart seems to have rolled off the road into the ditch, hopefully
without losing the horse though.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] man Macro Package and pdfmark

[Larry McVoy]

On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote:
> At the times I referred to the lack of freely available AT&T source code
> was extremely limiting in how people viewed the availability of such
> "add-on" tools for Unix -- including the C compiler!  

This wasn't just an AT&T thing, Sun and SGI and everyone charged for their
C compiler.  I sort of get it, writing a good compiler is up there with 
writing a good kernel in effort, not quite the same, but probably the 
2nd hardest thing to do.  So the compiler people cost a lot, companies
wanted to get that cost back.

It was stupid.  Having a free compiler meant that more people would 
write apps for your platform.   It should have been a loss leader.

> > For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and the
> > like, it is possible it was different.
> 
> It was _very_ different.
> 
> If you weren't out in the trenches of end-user Unix-based systems at the
> time it may not have been as obvious as to just how restrictive it was
> to have proprietary fee-based licensing of such add-on software.  Most
> end-users couldn't even pay their vendors for ditroff -- their vendors
> didn't want to have to license it from AT&T, even when they had
> advocates inside the companies (e.g. I did some work supporting software
> for a couple such vendors and was never able to convince them).  Some,
> as you mention, were all-in, but it wasn't until UNIX System V Release 4
> became more widely available that systems based on it were more likely
> to have ditroff, and sometimes (though much more rarely) the "new" dpost
> post-processor was also included.  I don't know if there were different
> licensing terms for SysVr4 or not.  Don't get me started on how hard it
> also was to get some end users to buy a C compiler too.

Yep, lived through this as well.  I fought with Sun to make more stuff
free for developers, it just didn't make sense to not do that but the
powers that were didn't get it.

One thing that Sun did do, probably in spite of itself, was fund 
Michael Tiemann's work on C++.  He worked out some deal that that
work would be open source and he pretty much made GNU C++ work
for some definition of work (C++ is a mess).

Re: [TUHS] man Macro Package and pdfmark

[Earl Baugh]

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

What was more frustrating to Sun users was that there WAS a compiler
included in Sun OS,
but it went away with Solaris.  I saw a noticeable change in code available
in binary form only after that.
At least until the GNU stuff got stable enough to use...

(I was a customer of MIke's when he first start Cygnus for support of the
GNU compilers...
I was working in a secured facility and multiple times I spoke with him on
the phone typing in patches
by hand -- as he relayed them -- because of the time and hassle it took to
get a tape in with the patch...)

Earl


On Tue, Feb 18, 2020 at 11:45 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote:
> > At the times I referred to the lack of freely available AT&T source code
> > was extremely limiting in how people viewed the availability of such
> > "add-on" tools for Unix -- including the C compiler!
>
> This wasn't just an AT&T thing, Sun and SGI and everyone charged for their
> C compiler.  I sort of get it, writing a good compiler is up there with
> writing a good kernel in effort, not quite the same, but probably the
> 2nd hardest thing to do.  So the compiler people cost a lot, companies
> wanted to get that cost back.
>
> It was stupid.  Having a free compiler meant that more people would
> write apps for your platform.   It should have been a loss leader.
>
> > > For folks running binary only systems from Masscomp/Sun/DEC/HP/IBM and
> the
> > > like, it is possible it was different.
> >
> > It was _very_ different.
> >
> > If you weren't out in the trenches of end-user Unix-based systems at the
> > time it may not have been as obvious as to just how restrictive it was
> > to have proprietary fee-based licensing of such add-on software.  Most
> > end-users couldn't even pay their vendors for ditroff -- their vendors
> > didn't want to have to license it from AT&T, even when they had
> > advocates inside the companies (e.g. I did some work supporting software
> > for a couple such vendors and was never able to convince them).  Some,
> > as you mention, were all-in, but it wasn't until UNIX System V Release 4
> > became more widely available that systems based on it were more likely
> > to have ditroff, and sometimes (though much more rarely) the "new" dpost
> > post-processor was also included.  I don't know if there were different
> > licensing terms for SysVr4 or not.  Don't get me started on how hard it
> > also was to get some end users to buy a C compiler too.
>
> Yep, lived through this as well.  I fought with Sun to make more stuff
> free for developers, it just didn't make sense to not do that but the
> powers that were didn't get it.
>
> One thing that Sun did do, probably in spite of itself, was fund
> Michael Tiemann's work on C++.  He worked out some deal that that
> work would be open source and he pretty much made GNU C++ work
> for some definition of work (C++ is a mess).
>
>

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

Re: [TUHS] man Macro Package and pdfmark

[Emile Bye]

[-- Attachment #1: Type: text/html, Size: 6325 bytes --]

Re: [TUHS] man Macro Package and pdfmark

[Michael Huff]

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

I've only tried it in virtual machines. It feels slower and more 
sluggish than OpenIndiana (which is based on Illumos, which is the 
post-Oracle open solaris) -but I don't use OI a whole lot either.

Since there's an opening I'm curious about something mentioned earlier 
in the thread, so I'll ask.

It was said earlier that SunOS included a compiler, but it was dropped 
in Solaris. Was it possible for people to carry over the old SunOS 
compiler and use it on Solaris? Did people do that, or did they just 
have their companies spring for the actual Solaris compiler?


On 2/19/2020 9:12 AM, Emile Bye wrote:
> Hello all,
>
>
> I'm a new member of the list and have been reading quietly in the 
> background.
>
>
> Changing the subject slightly (it's kind of relevant)... Has anyone 
> had a look at the new Solaris?  Apart from it using the Gnome 3 DE 
> which is very sluggish, it's awful!
>
> 11.3 is the last version I'm going to install on anything I've got!  
> (My Sun Blade 2500 will have Solaris 10 though... much better...)
>
> Rant over...
>
> Apologies for being a little off-topic,
>
>
>
> Emile
>> On 19 February 2020 at 18:01 Earl Baugh <earl.baugh@gmail.com> wrote:
>>
>> What was more frustrating to Sun users was that there WAS a compiler 
>> included in Sun OS,
>> but it went away with Solaris.  I saw a noticeable change in code 
>> available in binary form only after that.
>> At least until the GNU stuff got stable enough to use...
>>
>> (I was a customer of MIke's when he first start Cygnus for support of 
>> the GNU compilers...
>> I was working in a secured facility and multiple times I spoke with 
>> him on the phone typing in patches
>> by hand -- as he relayed them -- because of the time and hassle it 
>> took to get a tape in with the patch...)
>>
>> Earl
>>
>>
>> On Tue, Feb 18, 2020 at 11:45 PM Larry McVoy < lm@mcvoy.com 
>> <mailto:lm@mcvoy.com>> wrote:
>>
>>     On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote:
>>     > At the times I referred to the lack of freely available AT&T
>>     source code
>>     > was extremely limiting in how people viewed the availability of
>>     such
>>     > "add-on" tools for Unix -- including the C compiler!
>>
>>     This wasn't just an AT&T thing, Sun and SGI and everyone charged
>>     for their
>>     C compiler.  I sort of get it, writing a good compiler is up
>>     there with
>>     writing a good kernel in effort, not quite the same, but probably
>>     the
>>     2nd hardest thing to do.  So the compiler people cost a lot,
>>     companies
>>     wanted to get that cost back.
>>
>>     It was stupid.  Having a free compiler meant that more people would
>>     write apps for your platform.   It should have been a loss leader.
>>
>>     > > For folks running binary only systems from
>>     Masscomp/Sun/DEC/HP/IBM and the
>>     > > like, it is possible it was different.
>>     >
>>     > It was _very_ different.
>>     >
>>     > If you weren't out in the trenches of end-user Unix-based
>>     systems at the
>>     > time it may not have been as obvious as to just how restrictive
>>     it was
>>     > to have proprietary fee-based licensing of such add-on
>>     software.  Most
>>     > end-users couldn't even pay their vendors for ditroff -- their
>>     vendors
>>     > didn't want to have to license it from AT&T, even when they had
>>     > advocates inside the companies (e.g. I did some work supporting
>>     software
>>     > for a couple such vendors and was never able to convince
>>     them).  Some,
>>     > as you mention, were all-in, but it wasn't until UNIX System V
>>     Release 4
>>     > became more widely available that systems based on it were more
>>     likely
>>     > to have ditroff, and sometimes (though much more rarely) the
>>     "new" dpost
>>     > post-processor was also included.  I don't know if there were
>>     different
>>     > licensing terms for SysVr4 or not.  Don't get me started on how
>>     hard it
>>     > also was to get some end users to buy a C compiler too.
>>
>>     Yep, lived through this as well.  I fought with Sun to make more
>>     stuff
>>     free for developers, it just didn't make sense to not do that but
>>     the
>>     powers that were didn't get it.
>>
>>     One thing that Sun did do, probably in spite of itself, was fund
>>     Michael Tiemann's work on C++.  He worked out some deal that that
>>     work would be open source and he pretty much made GNU C++ work
>>     for some definition of work (C++ is a mess).
>>
>

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

Re: [TUHS] man Macro Package and pdfmark

[Jon Steinhart]

Michael Huff writes:
> It was said earlier that SunOS included a compiler, but it was dropped 
> in Solaris. Was it possible for people to carry over the old SunOS 
> compiler and use it on Solaris? Did people do that, or did they just 
> have their companies spring for the actual Solaris compiler?

I don't think so.  I ended up springing for the compiler when I purchased
my Ultra-60.  But, it was extraordinarily clunky and unreliable because of
their licensing scheme.  It commonly refused to work thinking that there
were too many instances runnining or something like that.  It was a big
relief when the GNU compiler because available and I never touched the Sun
compiler again.

Jon

Re: [TUHS] man Macro Package and pdfmark

[Henry Bent]

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

On Wed, 19 Feb 2020 at 15:20, Michael Huff <mphuff@gmail.com> wrote:

> I've only tried it in virtual machines. It feels slower and more sluggish
> than OpenIndiana (which is based on Illumos, which is the post-Oracle open
> solaris) -but I don't use OI a whole lot either.
>
> Since there's an opening I'm curious about something mentioned earlier in
> the thread, so I'll ask.
>
> It was said earlier that SunOS included a compiler, but it was dropped in
> Solaris. Was it possible for people to carry over the old SunOS compiler
> and use it on Solaris? Did people do that, or did they just have their
> companies spring for the actual Solaris compiler?
>
In short: no. SunOS binaries would usually run on Solaris if you had all of
the right libraries, etc. but the compilers created totally different
code.  SunOS was a.out and Solaris was ELF; SunOS was BSD and Solaris was
SYSV.  Solaris was a huge shift away from SunOS; they were effectively
entirely different operating systems for the same hardware.  I don't know
if there was some sort of trade-in discount for the old compiler when you
upgraded to Solaris, there might have been.  SunOS continued to be patched
and supported long after Solaris was released.  There were many reasons for
this, but the short summary is that many people didn't want to have to move
to an entirely new OS, or for some reason couldn't.  The analogy that comes
to mind is the shift from the classic Mac OS to OS X: your old programs
would probably run if they weren't too concerned about the internals of the
OS, but it was a big upheaval and most everything had to be rewritten to
some degree.

-Henry

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

Re: [TUHS] man Macro Package and pdfmark

[arnold]

Michael Huff <mphuff@gmail.com> wrote:

> It was said earlier that SunOS included a compiler, but it was dropped 
> in Solaris. Was it possible for people to carry over the old SunOS 
> compiler and use it on Solaris? Did people do that, or did they just 
> have their companies spring for the actual Solaris compiler?

Early Solaris would not run SunOS binaries; that was fixed later
on. People could then move the SunOS compiler over to Solaris. That was
less helpful that it might seem, as it was a K&R compiler. But it could
be used to bootstrap GCC and then one could go on from there.

As Larry and others have pointed out, the unbundling of various components
was a big mistake by the vendors.  It just made users angry and motivated
them to switch to other Unix systems.

Also, early Solaris was a dog. Performance was poor. It improved over
time, but it wasn't until around Solaris 2.4 or 2.5 that running it
wasn't painful.

Arnold

Re: [TUHS] man Macro Package and pdfmark

[Rich Morin]

I looked at Solaris very briefly and decided that it wasn't my idea
of a proper (read, BSD) Unix system.  So, I kept my Sun running SunOS
until I finally replaced it with a FreeBSD box.

-r

> On Feb 19, 2020, at 23:27, arnold@skeeve.com wrote:
> 
> Also, early Solaris was a dog. Performance was poor. It improved over
> time, but it wasn't until around Solaris 2.4 or 2.5 that running it
> wasn't painful.

Re: [TUHS] man Macro Package and pdfmark

[Dan Cross]

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

On Thu, Feb 20, 2020 at 2:44 AM Rich Morin <rdm@cfcl.com> wrote:

> I looked at Solaris very briefly and decided that it wasn't my idea
> of a proper (read, BSD) Unix system.  So, I kept my Sun running SunOS
> until I finally replaced it with a FreeBSD box.
>

I got the Unix-on-PCs religion sometime in the mid-'90s after Sun's shift
to Solaris and SVR4 and FreeBSD was my ecclesiastic weapon of choice after
a brief flirtation with Linux. I will admit, with a small amount of shame,
that I still carry around a bit of that chauvinism, though now driven
primarily by nostalgia instead of belief in technical superiority.

When I was in high school, the folks I looked up to told me, "BSD is the
stuff; SysV is garbage" and not knowing anything, I adopted that as a sort
of "four legs good, two legs bad" kinda mantra. I liked Sun machines
because they were what the cool people were using, but the move to Solaris
felt like a betrayal and I started looking for alternatives. The Alpha was
promising, but didn't make a lot of local headway. SGIs were neat but felt
like high-end toys for graphics weenies and Irix was too weird for my
taste. PCs were getting fast, though, and within a couple of years we went
from my 486DX/33 to 200 MHz Pentiums and FreeBSD was real, so that seemed
like the way forward. It amazed me how everyone around me kind of rolled
over, threw their hands up and said, "Oh well, I guess we all have to run
Solaris now...."

Wait, what? Why? I remember being dismayed that no one else saw the
potential for running essentially gratis software on cheap, fast hardware,
and that the same people who gladly put down multiple hundreds of thousands
of dollars for a VAX a decade prior, but then threw away the
vendor-supplied OS and installed 4.3BSD now were so concerned about things
like, "vendor support" that they couldn't see to doing essentially the same
thing, but at much lower overall cost.

What a time....

        - Dan C.

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

Re: [TUHS] man Macro Package and pdfmark

[Larry McVoy]

On Thu, Feb 20, 2020 at 12:27:15AM -0700, arnold@skeeve.com wrote:
> Michael Huff <mphuff@gmail.com> wrote:
> As Larry and others have pointed out, the unbundling of various components
> was a big mistake by the vendors.  It just made users angry and motivated
> them to switch to other Unix systems.

I really fault Sun for that one.  There was a time when every open source
package "just worked (TM)" if you built it on a Sun.  All the other platforms
were fiddly (leading to that monstrosity called autoconf), Sun just worked.
So developers fought hard to get a Sun over the other platforms.

When you have that lead and you screw over the people who gave you that 
lead, yeah, shame on you, Sun.

> Also, early Solaris was a dog. Performance was poor. It improved over
> time, but it wasn't until around Solaris 2.4 or 2.5 that running it
> wasn't painful.

Early Solaris was awful, just awful.  They pulled out sockets and replaced
them with Lachman's STREAMS based TCP/IP stack (really convergent's stack,
I believe Lachman bought it from them).  Performance was horrible, they
brought in Mentat's stack and had to work on that, and eventually they
brought back sockets.  I dunno if there is any STREAMS stuff left, that
was a horrible idea.

Another idea, not sure if this shipped or not, was to use a thread for
each 8K block headed to disk.  The kernel stack was 24K (which is nuts
but that's another story).  So think about what a dd if=/dev/zero of=XXX
does to your system.  Each I/O costs you 8K (data) + 24K (stack) not to
mention the other overhead for a thread.  It means you only get to use
25% of ram for dirty pages. 

Bat shit crazy, right?  I pointed all that out to the VM / FS people
and they did it anyway, they were in love with threads.  It was just
as awful as I predicted and they ripped it all out and started over.

To this day, I'm baffled that I could see that that was a horrible idea
and really smart people did not.  Lots of those people were smarter
than me.  It speaks to why you shouldn't push your shiny new feature
too hard.  And it lead to these in http://www.mcvoy.com/lm/quotes.html

    Think of it this way: threads are like salt, not like pasta. You
    like salt, I like salt, we all like salt. But we eat more pasta.

    --me

    A computer is a state machine. Threads are for people who can't
    program state machines.

    --Alan Cox

Both very on point for the Sun people.

Re: [TUHS] man Macro Package and pdfmark

[Arthur Krewat]

On 2/20/2020 11:23 AM, Larry McVoy wrote:
>
> Early Solaris was awful, just awful.  They pulled out sockets and replaced
> them with Lachman's STREAMS based TCP/IP stack (really convergent's stack,
> I believe Lachman bought it from them).  Performance was horrible, they
> brought in Mentat's stack and had to work on that, and eventually they
> brought back sockets.  I dunno if there is any STREAMS stuff left, that
> was a horrible idea.
>

It's still there. Not sure if it's used for more than a console keyboard 
driver anymore, but from a Solaris 11.3 machine:

more /usr/include/sys/stream.h
/*
  * Copyright (c) 1988, 2016, Oracle and/or its affiliates. All rights 
reserved.
  */

#ifndef _SYS_STREAM_H
#define _SYS_STREAM_H

/*
  * For source compatibility
  */
#include <sys/isa_defs.h>
#ifdef _KERNEL
#include <sys/vnode.h>
#endif
#include <sys/poll.h>
#include <sys/strmdep.h>
#include <sys/cred.h>
#include <sys/t_lock.h>
#include <sys/model.h>

#ifdef  __cplusplus
extern "C" {
#endif

...

Re: [TUHS] man Macro Package and pdfmark

[Al Kossow]

On 2/20/20 8:23 AM, Larry McVoy wrote:

>     A computer is a state machine. Threads are for people who can't
>     program state machines.

And now the world runs on threads and (current fashonable OOPL)
It makes my brain hurt.

Re: [TUHS] man Macro Package and pdfmark

[Bakul Shah]

On Thu, 20 Feb 2020 08:23:08 -0800 Larry McVoy <lm@mcvoy.com> wrote:
>
>     Think of it this way: threads are like salt, not like pasta. You
>     like salt, I like salt, we all like salt. But we eat more pasta.

Go is quite salty! Erlang even more so.

>     A computer is a state machine. Threads are for people who can't
>     program state machines.

I have written both event based (state machine) and thread
based programs.  Each style has its pros and cons. Control
flow is cleaner in threads but managing shared state is
trickier.  In state machines managing state is easier but
control flow is a pain.  Not to mention state machine don't
benefit from multiple h/w threads.

Re: [TUHS] man Macro Package and pdfmark

[Rich Morin]

FWIW, I've been enjoying Elixir a lot for the past few years.  It's an Actor-based, dynamically typed, FP language that runs on the Erlang VM.  It has Rubyish syntax, pattern matching, syntactic macros, lightweight processes, a message-passing framework, supervision trees, and other cool stuff.

I will note, however, that Elixir programming tends to be rather different from the stuff I've been doing for the past 50 years.  For example, processing pipelines tend to replace sets of nested loops...

-r

> On Feb 20, 2020, at 09:24, Bakul Shah <bakul@bitblocks.com> wrote:
> 
> On Thu, 20 Feb 2020 08:23:08 -0800 Larry McVoy <lm@mcvoy.com> wrote:
>> 
>>    Think of it this way: threads are like salt, not like pasta. You
>>    like salt, I like salt, we all like salt. But we eat more pasta.
> 
> Go is quite salty! Erlang even more so.
> 
>>    A computer is a state machine. Threads are for people who can't
>>    program state machines.
> 
> I have written both event based (state machine) and thread
> based programs.  Each style has its pros and cons. Control
> flow is cleaner in threads but managing shared state is
> trickier.  In state machines managing state is easier but
> control flow is a pain.  Not to mention state machine don't
> benefit from multiple h/w threads.

Re: [TUHS] man Macro Package and pdfmark

[Bakul Shah]

On Thu, 20 Feb 2020 09:48:58 -0800 Rich Morin <rdm@cfcl.com> wrote:
> FWIW, I've been enjoying Elixir a lot for the past few years.  It's an
> Actor-based, dynamically typed, FP language that runs on the Erlang VM.
> It has Rubyish syntax, pattern matching, syntactic macros, lightweight
> processes, a message-passing framework, supervision trees, and other
> cool stuff.

I haven't gotten around to playing with Elixir yet....

Nit: I thought Erlang designers weren't aware of Hewitt's
Actor model before they designed the language; it just
happened to map to the Actor model very well.

> I will note, however, that Elixir programming tends to be rather
> different from the stuff I've been doing for the past 50 years.  For
> example, processing pipelines tend to replace sets of nested loops...

No Stinking Loops! I am familiar with that from the
perspective of array programming languages. Arrays and streams
have quite a bit in common. [At times I have wanted a more
powerful APL like shell, where things like wc, grep, sort,
group, join etc. are builtins.]

Re: [TUHS] man Macro Package and pdfmark

[Rich Morin]

> On Feb 20, 2020, at 12:10, Bakul Shah <bakul@bitblocks.com> wrote:
> 
> Nit: I thought Erlang designers weren't aware of Hewitt's
> Actor model before they designed the language; it just
> happened to map to the Actor model very well.

True, but after the fact everyone decided that Erlang was really doing Actors.
FWIW, here's an interesting session on that sort of thing:

https://www.youtube.com/watch?v=37wFVVVZlVU
Let's #TalkConcurrency
Panel Discussion with Sir Tony Hoare, Joe Armstrong, and Carl Hewitt
  with host Francesco Cesarini. 

When considering the panel to discuss concurrency, you’d be pushed to find a higher calibre than Sir Tony Hoare, Joe Armstrong, and Carl Hewitt. All greats within the industry and beyond, they give an amazing insight into the lifeline of concurrency and actor models over the past few decades, their bountiful experiences within the concurrency field, and where they see concurrency heading in the future.

-r

Re: [TUHS] man Macro Package and pdfmark

[Nemo]

On 20/02/2020, arnold@skeeve.com <arnold@skeeve.com> wrote (in part):
> Also, early Solaris was a dog. Performance was poor. It improved over
> time, but it wasn't until around Solaris 2.4 or 2.5 that running it wasn't painful.

I recall that Sun salesfolk came in to sell us something-or-other and
freely admitted that Slowlaris did not improve until dtrace came
along, at which point Sun dived into system calls.

N.

Re: [TUHS] man Macro Package and pdfmark

[Larry McVoy]

On Thu, Feb 20, 2020 at 11:48:03AM -0500, Nemo wrote:
> On 20/02/2020, arnold@skeeve.com <arnold@skeeve.com> wrote (in part):
> > Also, early Solaris was a dog. Performance was poor. It improved over
> > time, but it wasn't until around Solaris 2.4 or 2.5 that running it wasn't painful.
> 
> I recall that Sun salesfolk came in to sell us something-or-other and
> freely admitted that Slowlaris did not improve until dtrace came
> along, at which point Sun dived into system calls.

I was the lead guy on Sun's first cluster product, I developed it on
SunOS 4.x but Scott wouldn't let me ship that, it had to be Solaris.
Which screwed performance, it was an NFS server so all that traffic was
going through STREAMS, it was awful.

I gave a pitch for that product at the Moscone center and had to endure
heckle after heckle about 5.x vs 4.x.  I toed the party line for as long
as I could and finally I had enough and said something like "I know.
5.x sucks, it just does, but that's what I have to ship with."

It was taped.

Ken Okin, my boss and senior VP of all server hardware, heard the tape,
came to me and said "Find and destroy all copies of that tape.  Now!"

It was not a fun time.

Re: [TUHS] man Macro Package and pdfmark

[Dave Horsfall]

On Thu, 20 Feb 2020, arnold@skeeve.com wrote:

[ ... ]

> Also, early Solaris was a dog. Performance was poor. It improved over 
> time, but it wasn't until around Solaris 2.4 or 2.5 that running it 
> wasn't painful.

That's why we called it Slowaris...

-- Dave

Re: [TUHS] man Macro Package and pdfmark

[Doug McIntyre]

On Wed, Feb 19, 2020 at 11:18:53AM -0900, Michael Huff wrote:
> It was said earlier that SunOS included a compiler, but it was dropped 
> in Solaris. Was it possible for people to carry over the old SunOS 
> compiler and use it on Solaris? Did people do that, or did they just 
> have their companies spring for the actual Solaris compiler?

SunOS's compiler that shipped with it wasn't that usable. It didn't fully support
the C standards at the time. 

It was used primarily for two things.

*) To compile the few kernel objects that were shipped as source & to 
link in all the binary objects into one new kernel for patching/tuning. 

*) To bootstrap GCC so one had a usable compiler to build packages. GCC
had special code used for the bootstrap process specificly at the time
on SunOS, written in a level that the SunOS compiler could deal with. 

Otherwise, it could only be used for simple projects. 

As others stated, the output of the compiler would have been a.out, and
not ELF like Solaris 2.x would have needed.

Some people equate SunOS from a time when all Unices still had (usable) compilers,
but that was actually an earlier time frame. Sun was selling its
standards compliant compilers for SunOS before Solaris 2.x was around.

Re: [TUHS] man Macro Package and pdfmark

[Warner Losh]

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

On Thu, Feb 20, 2020, 4:51 PM Doug McIntyre <merlyn@geeks.org> wrote:

> On Wed, Feb 19, 2020 at 11:18:53AM -0900, Michael Huff wrote:
> > It was said earlier that SunOS included a compiler, but it was dropped
> > in Solaris. Was it possible for people to carry over the old SunOS
> > compiler and use it on Solaris? Did people do that, or did they just
> > have their companies spring for the actual Solaris compiler?
>
> SunOS's compiler that shipped with it wasn't that usable. It didn't fully
> support
> the C standards at the time.
>
> It was used primarily for two things.
>
> *) To compile the few kernel objects that were shipped as source & to
> link in all the binary objects into one new kernel for patching/tuning.
>
> *) To bootstrap GCC so one had a usable compiler to build packages. GCC
> had special code used for the bootstrap process specificly at the time
> on SunOS, written in a level that the SunOS compiler could deal with.
>
> Otherwise, it could only be used for simple projects.
>
> As others stated, the output of the compiler would have been a.out, and
> not ELF like Solaris 2.x would have needed.
>
> Some people equate SunOS from a time when all Unices still had (usable)
> compilers,
> but that was actually an earlier time frame. Sun was selling its
> standards compliant compilers for SunOS before Solaris 2.x was around.
>

IIRC, The K&R compiler was free. The ANSI 89 one cost $$$. It was this
change in policy that caused much consternation in the Sun users community.
It happened around 91 or 92.

Warner

>

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

Re: [TUHS] man Macro Package and pdfmark

[Nemo Nusquam]

On 02/20/20 19:18, Warner Losh wrote:
> IIRC, The K&R compiler was free. The ANSI 89 one cost $$$. It was this 
> change in policy that caused much consternation in the Sun users 
> community. It happened around 91 or 92.

For what it's worth, HP-UX (for PA-RISC, at least) shipped with a free 
K&R compiler that compiled a kernel specific to the box. However, I seem 
to recall that it could not compile GCC so no bootstrapping there.

N.

>
> Warner
>

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

[-- Attachment #1: Type: text/html, Size: 643 bytes --]

Re: [TUHS] man Macro Package and pdfmark

[Thomas Paulsen]

>SunOS's compiler that shipped with it wasn't that usable. It didn't fully support the C standards at the time. 
>It was used primarily for two things....
>*) To bootstrap GCC so one had a usable compiler to build packages. 
so this can only be true for later not to say final days of sun-o2, as gcc wasn't available before.
Was it Stephen's pcc or Dennis CC?

Re: [TUHS] man Macro Package and pdfmark

[arnold]

"Thomas Paulsen" <thomas.paulsen@firemail.de> wrote:

> >SunOS's compiler that shipped with it wasn't that usable. It didn't
> >fully support the C standards at the time. 
> >It was used primarily for two things....
> >*) To bootstrap GCC so one had a usable compiler to build packages. 
>
> so this can only be true for later not to say final days of sun-o2,
> as gcc wasn't available before.
>
> Was it Stephen's pcc or Dennis CC?

It was PCC based. Once PCC became available with V7, it was used
for porting pretty universally. The 'P' stood for "portable" after all;
it was explicitly designed for retargeting.

Arnold

Re: [TUHS] man Macro Package and pdfmark

[Ed Bradford]

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

I also worked with LSX - a stripped down version of Unix that required no
MMU. It worked on a PDP 11/03 and we delivered an LSX product to the
telco's based on LSX. My faulty memory tells me Mike Lesk created LSX. Is
that true?

Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC?

Ed Bradford, BTL 1976-1983
Columbus and Whippany

On Mon, Feb 17, 2020 at 9:22 AM Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>
> > one of the things I wanted to do in my retirement was convert
> > all the stuff that is in debian back from info to man(7)
>
> *all* the stuff? Please don't do that literally. The garrulity
> quotient of info pages dwarfs even that of the most excessive
> modern man pages. But I appplaud the intent to assure man
> pages are complete.
>
> Doug
>


-- 
Advice is judged by results, not by intentions.
  Cicero

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

Re: [TUHS] man Macro Package and pdfmark

[Heinz Lycklama]

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

Not true. LSX was developed by yours truly during the mid-70's
while I was at Bell Labs in Murray Hill. See BSTJ July/August 1978,
page 2087-2101. It was developed to support some real-time
features like contiguous files and asynchronous I/O. A number
of groups in Bell Labs used LSX and added device drivers to
support their dedicated applications.

Western Electric (WE) was responsible for licensing the UNIX system
at the time and only provided source code for the UNIX system for
the PDP11 computer with an MMU for $20K. LSX source code
was not included in this.

I also developed (actually modified and wrote device drivers for)
a version of the UNIX system that ran on the PDP11/10 computer,
which also did not have an MMU. It could support up to four users.
I believe that the source code for this system (Mini-UNIX) was
provided to some universities by the UNIX Support group at
Bell Labs. WE did not license this.

I do not believe that WE ever considered licensing a binary
version of LSX or the UNIX System to run on the IBM PC or
any other microcomputer. WE only offered binary licenses
later on, and then only for the PDP11 with an MMU first.
In hindsight, a missed opportunity, but that's another story.

Doug may be able to offer some insight into this as well.

Thanks for asking,

Heinz Lycklama

On 2/21/2020 2:37 AM, Ed Bradford wrote:
> I also worked with LSX - a stripped down version of Unix that required 
> no MMU. It worked on a PDP 11/03 and we delivered an LSX product to 
> the telco's based on LSX. My faulty memory tells me Mike Lesk created 
> LSX. Is that true?
>
> Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC?
>
> Ed Bradford, BTL 1976-1983
> Columbus and Whippany


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

Re: [TUHS] man Macro Package and pdfmark

[Warner Losh]

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

On Fri, Feb 21, 2020, 11:35 AM Heinz Lycklama <heinz@osta.com> wrote:

> Not true. LSX was developed by yours truly during the mid-70's
> while I was at Bell Labs in Murray Hill. See BSTJ July/August 1978,
> page 2087-2101. It was developed to support some real-time
> features like contiguous files and asynchronous I/O. A number
> of groups in Bell Labs used LSX and added device drivers to
> support their dedicated applications.
>
> Western Electric (WE) was responsible for licensing the UNIX system
> at the time and only provided source code for the UNIX system for
> the PDP11 computer with an MMU for $20K. LSX source code
> was not included in this.
>
> I also developed (actually modified and wrote device drivers for)
> a version of the UNIX system that ran on the PDP11/10 computer,
> which also did not have an MMU. It could support up to four users.
> I believe that the source code for this system (Mini-UNIX) was
> provided to some universities by the UNIX Support group at
> Bell Labs. WE did not license this.
>

The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc.
People offered copies to any Unix licensees. Most of these were
universities.

Warner

I do not believe that WE ever considered licensing a binary
> version of LSX or the UNIX System to run on the IBM PC or
> any other microcomputer. WE only offered binary licenses
> later on, and then only for the PDP11 with an MMU first.
> In hindsight, a missed opportunity, but that's another story.
>
> Doug may be able to offer some insight into this as well.
>
> Thanks for asking,
>
> Heinz Lycklama
>
> On 2/21/2020 2:37 AM, Ed Bradford wrote:
>
> I also worked with LSX - a stripped down version of Unix that required no
> MMU. It worked on a PDP 11/03 and we delivered an LSX product to the
> telco's based on LSX. My faulty memory tells me Mike Lesk created LSX. Is
> that true?
>
> Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC?
>
> Ed Bradford, BTL 1976-1983
> Columbus and Whippany
>
>
>

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

Re: [TUHS] man Macro Package and pdfmark

[Dave Horsfall]

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

On Fri, 21 Feb 2020, Warner Losh wrote:

> The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc. 
> People offered copies to any Unix licensees. Most of these were 
> universities. 

It was fun to play with, but as the name implies it was pretty limited.

I recall I got it working on one of those DEC PDT things, with 8" 
floppies; you had to turn off "/etc/update" otherwise it wore a groove 
where inode 1 was, or was it /dev/tty8?  Something like that...

-- Dave

Re: [TUHS] man Macro Package and pdfmark

[David Barto]

It was /etc/update. I used one of these in the Psych department at UCSD. When it started going weird I shut it down and removed the floppy. As you mentioned, the tracks at the start of the disk were worn smooth.

	David

> On Feb 21, 2020, at 1:10 PM, Dave Horsfall <dave@horsfall.org> wrote:
> 
> On Fri, 21 Feb 2020, Warner Losh wrote:
> 
>> The Auug newsletters talk a lot about miniunix, fixes to miniunix, etc. People offered copies to any Unix licensees. Most of these were universities. 
> 
> It was fun to play with, but as the name implies it was pretty limited.
> 
> I recall I got it working on one of those DEC PDT things, with 8" floppies; you had to turn off "/etc/update" otherwise it wore a groove where inode 1 was, or was it /dev/tty8?  Something like that...
> 
> -- Dave

Re: [TUHS] man Macro Package and pdfmark

[Ed Bradford]

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

Thank you Heinz for correcting my poor memory. I don't think we ever met.
Using LSX was a fun project.

LSX was before DOS and far better than any DOS in my view.

Thank you for responding.
Ed

On Fri, Feb 21, 2020 at 12:35 PM Heinz Lycklama <heinz@osta.com> wrote:

> Not true. LSX was developed by yours truly during the mid-70's
> while I was at Bell Labs in Murray Hill. See BSTJ July/August 1978,
> page 2087-2101. It was developed to support some real-time
> features like contiguous files and asynchronous I/O. A number
> of groups in Bell Labs used LSX and added device drivers to
> support their dedicated applications.
>
> Western Electric (WE) was responsible for licensing the UNIX system
> at the time and only provided source code for the UNIX system for
> the PDP11 computer with an MMU for $20K. LSX source code
> was not included in this.
>
> I also developed (actually modified and wrote device drivers for)
> a version of the UNIX system that ran on the PDP11/10 computer,
> which also did not have an MMU. It could support up to four users.
> I believe that the source code for this system (Mini-UNIX) was
> provided to some universities by the UNIX Support group at
> Bell Labs. WE did not license this.
>
> I do not believe that WE ever considered licensing a binary
> version of LSX or the UNIX System to run on the IBM PC or
> any other microcomputer. WE only offered binary licenses
> later on, and then only for the PDP11 with an MMU first.
> In hindsight, a missed opportunity, but that's another story.
>
> Doug may be able to offer some insight into this as well.
>
> Thanks for asking,
>
> Heinz Lycklama
>
> On 2/21/2020 2:37 AM, Ed Bradford wrote:
>
> I also worked with LSX - a stripped down version of Unix that required no
> MMU. It worked on a PDP 11/03 and we delivered an LSX product to the
> telco's based on LSX. My faulty memory tells me Mike Lesk created LSX. Is
> that true?
>
> Did BTL/AT&T ever try to sell LSX to IBM for its 1981 intro of the IBM PC?
>
> Ed Bradford, BTL 1976-1983
> Columbus and Whippany
>
>
>

-- 
Advice is judged by results, not by intentions.
  Cicero

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

Re: [TUHS] man Macro Package and pdfmark

[Al Kossow]

On 2/21/20 10:34 AM, Heinz Lycklama wrote:

> I believe that the source code for this system (Mini-UNIX) was
> provided to some universities by the UNIX Support group at
> Bell Labs. WE did not license this.

tape image at
http://bitsavers.org/bits/ATT/mini-unix_120679.zip

Re: [TUHS] man Macro Package and pdfmark

[Ed Bradford]

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

What is the legal status of such old, no longer useful source code?


On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org> wrote:

> On 2/21/20 10:34 AM, Heinz Lycklama wrote:
>
> > I believe that the source code for this system (Mini-UNIX) was
> > provided to some universities by the UNIX Support group at
> > Bell Labs. WE did not license this.
>
> tape image at
> http://bitsavers.org/bits/ATT/mini-unix_120679.zip
>
>
>

-- 
Advice is judged by results, not by intentions.
  Cicero

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

Re: [TUHS] man Macro Package and pdfmark

[Warner Losh]

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

This should be covered by the ancient Unix license since it is derived from
V6.

Warner

On Sat, Feb 22, 2020, 4:02 AM Ed Bradford <egbegb2@gmail.com> wrote:

> What is the legal status of such old, no longer useful source code?
>
>
> On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org> wrote:
>
>> On 2/21/20 10:34 AM, Heinz Lycklama wrote:
>>
>> > I believe that the source code for this system (Mini-UNIX) was
>> > provided to some universities by the UNIX Support group at
>> > Bell Labs. WE did not license this.
>>
>> tape image at
>> http://bitsavers.org/bits/ATT/mini-unix_120679.zip
>>
>>
>>
>
> --
> Advice is judged by results, not by intentions.
>   Cicero
>
>

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

Re: [TUHS] man Macro Package and pdfmark

[arnold]

Warren, do you want to grab this for the archive also?

Thanks,

Arnold

Warner Losh <imp@bsdimp.com> wrote:

> This should be covered by the ancient Unix license since it is derived from
> V6.
>
> Warner
>
> On Sat, Feb 22, 2020, 4:02 AM Ed Bradford <egbegb2@gmail.com> wrote:
>
> > What is the legal status of such old, no longer useful source code?
> >
> >
> > On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org> wrote:
> >
> >> On 2/21/20 10:34 AM, Heinz Lycklama wrote:
> >>
> >> > I believe that the source code for this system (Mini-UNIX) was
> >> > provided to some universities by the UNIX Support group at
> >> > Bell Labs. WE did not license this.
> >>
> >> tape image at
> >> http://bitsavers.org/bits/ATT/mini-unix_120679.zip
> >>
> >>
> >>
> >
> > --
> > Advice is judged by results, not by intentions.
> >   Cicero
> >
> >

Re: [TUHS] man Macro Package and pdfmark

[Ed Bradford]

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

How do I open a .tap file in the .zip file for mini-unix?
Also, do you have a date for this snapshot. A date would be
very useful for "product comparisons" at that date.

Ed


On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org> wrote:

> On 2/21/20 10:34 AM, Heinz Lycklama wrote:
>
> > I believe that the source code for this system (Mini-UNIX) was
> > provided to some universities by the UNIX Support group at
> > Bell Labs. WE did not license this.
>
> tape image at
> http://bitsavers.org/bits/ATT/mini-unix_120679.zip
>
>
>

-- 
Advice is judged by results, not by intentions.
  Cicero

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

Re: [TUHS] man Macro Package and pdfmark

[Warner Losh]

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

On Sat, Feb 22, 2020, 4:08 AM Ed Bradford <egbegb2@gmail.com> wrote:

> How do I open a .tap file in the .zip file for mini-unix?
> Also, do you have a date for this snapshot. A date would be
> very useful for "product comparisons" at that date.
>

The file name suggests Dec 6, 1979, though that's us centric and it could
be June 12, 79 as well...

Warner

Ed
>
>
> On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org> wrote:
>
>> On 2/21/20 10:34 AM, Heinz Lycklama wrote:
>>
>> > I believe that the source code for this system (Mini-UNIX) was
>> > provided to some universities by the UNIX Support group at
>> > Bell Labs. WE did not license this.
>>
>> tape image at
>> http://bitsavers.org/bits/ATT/mini-unix_120679.zip
>>
>>
>>
>
> --
> Advice is judged by results, not by intentions.
>   Cicero
>
>

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

Re: [TUHS] man Macro Package and pdfmark

[Clem Cole]

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

.tap files are simh <https://github.com/simh/simh> format files  and 'look
like a mag-tape' to the simulated tape hardware.
There are tools that will convert to/from Bob's Simulator format as needed.

On Sat, Feb 22, 2020 at 6:08 AM Ed Bradford <egbegb2@gmail.com> wrote:

> How do I open a .tap file in the .zip file for mini-unix?
> Also, do you have a date for this snapshot. A date would be
> very useful for "product comparisons" at that date.
>
> Ed
>
>
> On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org> wrote:
>
>> On 2/21/20 10:34 AM, Heinz Lycklama wrote:
>>
>> > I believe that the source code for this system (Mini-UNIX) was
>> > provided to some universities by the UNIX Support group at
>> > Bell Labs. WE did not license this.
>>
>> tape image at
>> http://bitsavers.org/bits/ATT/mini-unix_120679.zip
>>
>>
>>
>
> --
> Advice is judged by results, not by intentions.
>   Cicero
>
>

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

Re: [TUHS] man Macro Package and pdfmark

[Heinz Lycklama]

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

OK, that does look like the official Mini-UNIX release from
Bell Labs in 1979. I'd have to look at the files in the .tap file
to verify this.

Note the name Mini-UNIX was also used by Andrew Tanenbaum
for the system he developed at Vrije Universiteit in Amsterdam
much later in 1987 independent of the Mini-UNIX that I developed
at Bell Labs in the mid 1970's. See here:
https://en.wikipedia.org/wiki/MINIX

Heinz

On 2/22/2020 8:46 AM, Clem Cole wrote:
> .tap files are simh <https://github.com/simh/simh> format files  and 
> 'look like a mag-tape' to the simulated tape hardware.
> There are tools that will convert to/from Bob's Simulator format as 
> needed.
>
> On Sat, Feb 22, 2020 at 6:08 AM Ed Bradford <egbegb2@gmail.com 
> <mailto:egbegb2@gmail.com>> wrote:
>
>     How do I open a .tap file in the .zip file for mini-unix?
>     Also, do you have a date for this snapshot. A date would be
>     very useful for "product comparisons" at that date.
>
>     Ed
>
>
>     On Sat, Feb 22, 2020 at 4:43 AM Al Kossow <aek@bitsavers.org
>     <mailto:aek@bitsavers.org>> wrote:
>
>         On 2/21/20 10:34 AM, Heinz Lycklama wrote:
>
>         > I believe that the source code for this system (Mini-UNIX) was
>         > provided to some universities by the UNIX Support group at
>         > Bell Labs. WE did not license this.
>
>         tape image at
>         http://bitsavers.org/bits/ATT/mini-unix_120679.zip
>
>
>
>
>     -- 
>     Advice is judged by results, not by intentions.
>       Cicero
>


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