17 Feb
2020
17 Feb
'20
9:20 p.m.
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
17 Feb
17 Feb
10:47 p.m.
New subject: man Macro Package and pdfmark
On Mon, Feb 17, 2020 at 10:22 AM Doug McIlroy <doug(a)cs.dartmouth.edu> wrote:
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...
*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.
18 Feb
18 Feb
12:09 a.m.
New subject: man Macro Package and pdfmark
*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.
12:39 a.m.
New subject: man Macro Package and pdfmark
Thomas Paulsen writes:
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
*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.
3:16 a.m.
New subject: man Macro Package and pdfmark
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.
4:50 a.m.
New subject: man Macro Package and pdfmark
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.
5:22 a.m.
New subject: man Macro Package and pdfmark
On Mon, Feb 17, 2020 at 3:51 PM Thomas Paulsen <thomas.paulsen(a)firemail.de>
wrote:
I think this showed the wisdom of deleting binaries from /usr/bin when
there was no man page for them...
Warner
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.
6:56 a.m.
New subject: man Macro Package and pdfmark
On Mon, 17 Feb 2020 16:22:32 -0700 Warner Losh <imp(a)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 :-)
9:33 a.m.
New subject: man Macro Package and pdfmark
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
6:03 a.m.
New subject: man Macro Package and pdfmark
'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.
6:17 a.m.
New subject: man Macro Package and pdfmark
Richard Salz writes:
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:
'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. 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
6:54 a.m.
New subject: man Macro Package and pdfmark
On Mon, Feb 17, 2020 at 04:17:18PM -0800, Jon Steinhart wrote:
Richard Salz writes:
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.
'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. 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.
7:05 a.m.
New subject: man Macro Package and pdfmark
On Mon, 17 Feb 2020 16:17:18 -0800 Jon Steinhart <jon(a)fourwinds.com> wrote:
Richard Salz writes:
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.
'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. Noel Chiappa writes:
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.
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. 
1:40 p.m.
New subject: man Macro Package and pdfmark
At Mon, 17 Feb 2020 16:17:18 -0800, Jon Steinhart <jon(a)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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
1:45 p.m.
New subject: man Macro Package and pdfmark
"Greg A. Woods" <woods(a)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
19 Feb
19 Feb
2:24 a.m.
New subject: man Macro Package and pdfmark
At Tue, 18 Feb 2020 00:45:11 -0700, arnold(a)skeeve.com wrote:
Subject: Re: [TUHS] man Macro Package and pdfmark
"Greg A. Woods" <woods(a)robohack.ca> wrote:
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
Personally I still mostly use Lout these days. :-)
Wow. Is that still maintained? 
18 Feb
18 Feb
5:22 p.m.
New subject: man Macro Package and pdfmark
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
6:28 p.m.
New subject: man Macro Package and pdfmark
Rich Morin <rdm(a)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
6:49 p.m.
New subject: man Macro Package and pdfmark
On 18/02/2020 12:28, arnold(a)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-…
.
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
7:23 p.m.
New subject: man Macro Package and pdfmark
"U'll Be King of the Stars" <ullbeking(a)andrewnesbit.org> wrote:
Thanks!
On 18/02/2020 12:28, arnold(a)skeeve.com wrote:
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
(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. 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-…
.
I have that book.
There's also the LCC C compiler book which was done in a literate style.
Arnold
9:11 p.m.
New subject: man Macro Package and pdfmark
hrrmpt...
On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods <woods(a)robohack.ca> wrote:
At Mon, 17 Feb 2020 16:17:18 -0800, Jon Steinhart
<jon(a)fourwinds.com>
wrote:
Subject: Re: [TUHS] man Macro Package and pdfmark
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
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.
>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
9:28 p.m.
New subject: man Macro Package and pdfmark
Clem Cole <clemc(a)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
9:36 p.m.
New subject: man Macro Package and pdfmark
On Tue, Feb 18, 2020 at 08:28:50AM -0700, arnold(a)skeeve.com wrote:
Clem Cole <clemc(a)ccc.com> wrote:
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.
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. 
9:43 p.m.
New subject: man Macro Package and pdfmark
On Tue, 18 Feb 2020, arnold(a)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.
9:52 p.m.
New subject: man Macro Package and pdfmark
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(a)buric.co> wrote:
On Tue, 18 Feb 2020, arnold(a)skeeve.com wrote:
--
Sent from a handheld expect more typos than usual
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.
10:40 p.m.
New subject: man Macro Package and pdfmark
On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve Nickolas wrote:
On Tue, 18 Feb 2020, arnold(a)skeeve.com wrote:
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 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" ?
19 Feb
19 Feb
12:39 a.m.
New subject: man Macro Package and pdfmark
On Tue, 18 Feb 2020, Theodore Y. Ts'o wrote:
On Tue, Feb 18, 2020 at 10:43:06AM -0500, Steve
Nickolas wrote:
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.
On Tue, 18 Feb 2020, arnold(a)skeeve.com wrote:
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 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" ?
3:26 a.m.
New subject: man Macro Package and pdfmark
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
3:29 a.m.
New subject: man Macro Package and pdfmark
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(a)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:
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.
On Tue, 18 Feb 2020, arnold(a)skeeve.com wrote:
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 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" ?
10:52 a.m.
New subject: Open source or free software? (was: man Macro Package and pdfmark)
On Tuesday, 18 February 2020 at 13:39:22 -0500, Steve Nickolas wrote:
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).
I don't see those words as simpler. Ask any (wo)man in the street
what free software is, and they'll come up with a reasonable
approximation. As them what open source is and far fewer will know.
At the very best it's only intelligible in a limited environment.
And of course here in Australia, Open Sauce is a completely different
homonym. rms won't touch it either:
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20100916/small/rms-me…
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
18 Feb
18 Feb
9:48 p.m.
New subject: man Macro Package and pdfmark
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(a)skeeve.com> wrote:
Clem Cole <clemc(a)ccc.com> wrote:
--
Sent from a handheld expect more typos than usual
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
10:02 p.m.
New subject: man Macro Package and pdfmark
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(a)case.edu http://tiswww.cwru.edu/~chet/
10:28 p.m.
New subject: man Macro Package and pdfmark
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(a)case.edu> wrote:
On 2/18/20 10:48 AM, Clem Cole wrote:
--
Sent from a handheld expect more typos than usual
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(a)case.edu http://tiswww.cwru.edu/~chet/
19 Feb
19 Feb
3:46 a.m.
New subject: man Macro Package and pdfmark
On Feb 18, 2020, at 07:28, arnold(a)skeeve.com wrote:
Clem Cole <clemc(a)ccc.com> wrote:
"How I coined the term 'open source'", by Christine Peterson
https://opensource.com/article/18/2/coining-term-open-source-software
-r
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. 
18 Feb
18 Feb
10:47 p.m.
New subject: man Macro Package and pdfmark
On Tue, Feb 18, 2020, 10:13 Clem Cole <clemc(a)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
19 Feb
19 Feb
2:22 a.m.
New subject: man Macro Package and pdfmark
At Tue, 18 Feb 2020 10:11:45 -0500, Clem Cole <clemc(a)ccc.com> wrote:
Subject: Re: [TUHS] man Macro Package and pdfmark
On Tue, Feb 18, 2020 at 2:40 AM Greg A. Woods <woods(a)robohack.ca> wrote:
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.
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.
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
10:44 a.m.
New subject: man Macro Package and pdfmark
On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote:
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).
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. 
20 Feb
20 Feb
12:01 a.m.
New subject: man Macro Package and pdfmark
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(a)mcvoy.com> wrote:
On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A.
Woods wrote:
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).
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. 
2:18 a.m.
New subject: man Macro Package and pdfmark
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(a)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(a)mcvoy.com
<mailto:lm@mcvoy.com>> wrote:
On Tue, Feb 18, 2020 at 12:22:56PM -0800, Greg A. Woods wrote:
systems at the
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 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).
2:34 a.m.
New subject: man Macro Package and pdfmark
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
3:09 a.m.
New subject: man Macro Package and pdfmark
On Wed, 19 Feb 2020 at 15:20, Michael Huff <mphuff(a)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
1:27 p.m.
New subject: man Macro Package and pdfmark
Michael Huff <mphuff(a)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
1:43 p.m.
New subject: man Macro Package and pdfmark
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(a)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.
7:15 p.m.
New subject: man Macro Package and pdfmark
On Thu, Feb 20, 2020 at 2:44 AM Rich Morin <rdm(a)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.
10:23 p.m.
New subject: man Macro Package and pdfmark
On Thu, Feb 20, 2020 at 12:27:15AM -0700, arnold(a)skeeve.com wrote:
Michael Huff <mphuff(a)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.
10:34 p.m.
New subject: man Macro Package and pdfmark
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
...
11:24 p.m.
New subject: man Macro Package and pdfmark
On Thu, 20 Feb 2020 08:23:08 -0800 Larry McVoy <lm(a)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.
11:48 p.m.
New subject: man Macro Package and pdfmark
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(a)bitblocks.com> wrote:
On Thu, 20 Feb 2020 08:23:08 -0800 Larry McVoy <lm(a)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.
21 Feb
21 Feb
2:10 a.m.
New subject: man Macro Package and pdfmark
On Thu, 20 Feb 2020 09:48:58 -0800 Rich Morin <rdm(a)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.]
2:18 a.m.
New subject: man Macro Package and pdfmark
On Feb 20, 2020, at 12:10, Bakul Shah
<bakul(a)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
20 Feb
20 Feb
10:48 p.m.
New subject: man Macro Package and pdfmark
On 20/02/2020, arnold(a)skeeve.com <arnold(a)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.
11 p.m.
New subject: man Macro Package and pdfmark
On Thu, Feb 20, 2020 at 11:48:03AM -0500, Nemo wrote:
On 20/02/2020, arnold(a)skeeve.com
<arnold(a)skeeve.com> wrote (in part):
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.
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.
21 Feb
21 Feb
1:16 a.m.
New subject: man Macro Package and pdfmark
On Thu, 20 Feb 2020, arnold(a)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
5:45 a.m.
New subject: man Macro Package and pdfmark
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.
6:18 a.m.
New subject: man Macro Package and pdfmark
On Thu, Feb 20, 2020, 4:51 PM Doug McIntyre <merlyn(a)geeks.org> wrote:
On Wed, Feb 19, 2020 at 11:18:53AM -0900, Michael Huff
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.
Warner
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.
7:14 a.m.
New subject: man Macro Package and pdfmark
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
2:17 p.m.
New subject: man Macro Package and pdfmark
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?
4:17 p.m.
New subject: man Macro Package and pdfmark
"Thomas Paulsen" <thomas.paulsen(a)firemail.de> wrote:
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
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? 
4:37 p.m.
New subject: man Macro Package and pdfmark
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(a)cs.dartmouth.edu> wrote:
--
Advice is judged by results, not by intentions.
Cicero
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
22 Feb
22 Feb
12:34 a.m.
New subject: man Macro Package and pdfmark
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
12:59 a.m.
New subject: man Macro Package and pdfmark
On Fri, Feb 21, 2020, 11:35 AM Heinz Lycklama <heinz(a)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
3:10 a.m.
New subject: man Macro Package and pdfmark
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
3:46 a.m.
New subject: man Macro Package and pdfmark
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(a)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
12:48 p.m.
New subject: man Macro Package and pdfmark
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(a)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
4:42 p.m.
New subject: man Macro Package and pdfmark
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
5:01 p.m.
New subject: man Macro Package and pdfmark
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(a)bitsavers.org> wrote:
On 2/21/20 10:34 AM, Heinz Lycklama wrote:
--
Advice is judged by results, not by intentions.
Cicero
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
10:38 p.m.
New subject: man Macro Package and pdfmark
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(a)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(a)bitsavers.org> wrote:
On 2/21/20 10:34 AM, Heinz Lycklama wrote:
--
Advice is judged by results, not by intentions.
Cicero
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
23 Feb
23 Feb
12:11 a.m.
New subject: man Macro Package and pdfmark
Warren, do you want to grab this for the archive also?
Thanks,
Arnold
Warner Losh <imp(a)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(a)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(a)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
>
>
5:41 a.m.
New subject: Mini-UNIX
On Sat, Feb 22, 2020 at 11:11:28AM -0700, arnold(a)skeeve.com wrote:
Warren, do you want to grab this for the archive also?
Already there in
https://www.tuhs.org/Archive/Distributions/USDL/Mini-Unix/Kossow/
Thanks for the heads-up, though!
Cheers, Warren
22 Feb
22 Feb
5:08 p.m.
New subject: man Macro Package and pdfmark
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(a)bitsavers.org> wrote:
On 2/21/20 10:34 AM, Heinz Lycklama wrote:
--
Advice is judged by results, not by intentions.
Cicero
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
10:40 p.m.
New subject: man Macro Package and pdfmark
On Sat, Feb 22, 2020, 4:08 AM Ed Bradford <egbegb2(a)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(a)bitsavers.org> wrote:
On 2/21/20 10:34 AM, Heinz Lycklama wrote:
--
Advice is judged by results, not by intentions.
Cicero
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
10:46 p.m.
New subject: man Macro Package and pdfmark
.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(a)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(a)bitsavers.org> wrote:
On 2/21/20 10:34 AM, Heinz Lycklama wrote:
--
Advice is judged by results, not by intentions.
Cicero
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
11:51 p.m.
New subject: man Macro Package and pdfmark
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(a)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(a)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
1764
days inactive
1769
days old
77 comments
32 participants
participants (32)
-
Al Kossow -
arnold＠skeeve.com -
Arthur Krewat -
Bakul Shah -
Chet Ramey -
Clem Cole -
Dan Cross -
Dave Horsfall -
David Barto -
Doug McIlroy -
Doug McIntyre -
Earl Baugh -
Ed Bradford -
Emile Bye -
Greg 'groggy' Lehey -
Greg A. Woods -
Heinz Lycklama -
Henry Bent -
Jon Steinhart -
Larry McVoy -
Michael Huff -
Nemo -
Nemo Nusquam
-
Rich Morin -
Richard Salz -
Steve Nickolas -
Theodore Y. Ts'o -
Thomas Paulsen -
U'll Be King of the Stars -
Warner Losh -
Warren Toomey -
Wesley Parish