[TUHS] Happy birthday, Dennis Ritchie!

[TUHS] Happy birthday, Dennis Ritchie!

[Dave Horsfall]

Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just 
think, if it wasn't for him and Ken, we'd all be running Windoze, and 
thinking it's wonderful.

A Unix bigot through and through, I remain,

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie!

[Noel Chiappa]

    > From: Dave Horsfall <dave at horsfall.org>

    > Just think, if it wasn't for him and Ken, we'd all be running Windoze,
    > and thinking it's wonderful.

It's actually worse than that.

We'd be running a Windows even worse than current Windows (which has managed
to pick up a few decent ideas from places like Unix).

	Noel

[TUHS] Happy birthday, Dennis Ritchie!

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> We'd be running a Windows even worse than current Windows (which has managed
> to pick up a few decent ideas from places like Unix).

Like directories, and free-form files (collections of bytes as opposed
to collections of records)?

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Happy birthday, Dennis Ritchie!

[Wesley Parish]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

'fraid so. The Unix directory structure and the correlating free-form file competed with the file-as-
record-structure and directory-as-record-structure in the seventies and eighties. The competition had 
finished by the nineties, and hardly anybody remembers it now.

Seriously, how many grandmothers can you think of who would know how to allocate disk space for a 
photo of their grandkids? Who would be able to guess how many bytes a letter might take up?

Free-form files and directory nodes (with the corresponding requirement that the OS know how to 
allocate and reallocate disk space) helped democratize computing.

Just my 0.02c :)

Wesley Parish

Quoting Michael Kjörling <michael at kjorling.se>:

> On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel Chiappa):
> > We'd be running a Windows even worse than current Windows (which has
> managed
> > to pick up a few decent ideas from places like Unix).
> 
> Like directories, and free-form files (collections of bytes as opposed
> to collections of records)?
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se •
> michael at kjorling.se
>  “People who think they know everything really annoy
>  those of us who know we don’t.” (Bjarne Stroustrup)
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)

[Greg 'groggy' Lehey]

On Saturday,  9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
> 'fraid so. The Unix directory structure and the correlating
> free-form file competed with the file-as- record-structure and
> directory-as-record-structure in the seventies and eighties. The
> competition had finished by the nineties, and hardly anybody
> remembers it now.

Sorry, I don't understand this.  Can you give an example of
file-as-record and directory-as-record?  Some of it suggests MVS, but
not quite.

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/b9b9966f/attachment.sig>

[TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)

[Warner Losh]

On Fri, Sep 8, 2017 at 7:30 PM, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> On Saturday,  9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
> > 'fraid so. The Unix directory structure and the correlating
> > free-form file competed with the file-as- record-structure and
> > directory-as-record-structure in the seventies and eighties. The
> > competition had finished by the nineties, and hardly anybody
> > remembers it now.
>
> Sorry, I don't understand this.  Can you give an example of
> file-as-record and directory-as-record?  Some of it suggests MVS, but
> not quite.
>

See VMS's RMS: https://en.wikipedia.org/wiki/Record_Management_Services for
a representative competitor.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/c6b85a0a/attachment.html>

[TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)

[Wesley Parish]

I picked up a book in the early nineties called File Structures or File Systems: I've forgotten which, 
because I didn't read it as much as I had intended. It covered the IBM MVS mainframe dataset file and 
directory structure and the Unix file and directory structure. And yes, I was referring to the MVS dataset, 
as much of it as I can remember from that book. (I sorry I can't recall the exact title: the book is 
somewhere at the bottom of a pile of other books from my last move several years ago.)

Wesley Parish

Quoting Greg 'groggy' Lehey <grog at lemis.com>:

> On Saturday, 9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
> > 'fraid so. The Unix directory structure and the correlating
> > free-form file competed with the file-as- record-structure and
> > directory-as-record-structure in the seventies and eighties. The
> > competition had finished by the nineties, and hardly anybody
> > remembers it now.
> 
> Sorry, I don't understand this. Can you give an example of
> file-as-record and directory-as-record? Some of it suggests MVS, but
> not quite.
> 
> Greg
> --
> Sent from my desktop computer.
> Finger grog at lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed. If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] File-as-record

[Arthur Krewat]

Not sure I quite get this "file as record" thing.

On TOPS-10, you create a file, edit a file, you don't have to allocate 
space for it before you use it.

Sure, it's made up of "blocks" - and writing to the file requires you to 
do it in blocks. But allocating those blocks was done on as the fly as 
you wrote to it.

Also, the first thing I did was to make my own routines that would allow 
the program to read/write in random-size chunks, blocking as it needs to.

Is the distrinction that the operating system (libraries) allowed you to 
read/write random size chunks? If so, the underlying structure of a UNIX 
filesystem still required block I/O. It was just hidden from the 
programmer.

But for peak performance, you still needed to do things in big enough 
chunks (blocks).

If I had known that random-size chunk read/writes were a "thing" I would 
have added it to the TOPS-10 monitor sources and submitted it back to DEC :)

AAK

PS: First TOPS-10 monitor was 1964

[TUHS] File-as-record (was: Happy birthday, Dennis Ritchie!)

[Paul Winalski]

On 9/8/17, Greg 'groggy' Lehey <grog at lemis.com> wrote:
> On Saturday,  9 September 2017 at 13:16:30 +1200, Wesley Parish wrote:
>> 'fraid so. The Unix directory structure and the correlating
>> free-form file competed with the file-as- record-structure and
>> directory-as-record-structure in the seventies and eighties. The
>> competition had finished by the nineties, and hardly anybody
>> remembers it now.
>
> Sorry, I don't understand this.  Can you give an example of
> file-as-record and directory-as-record?  Some of it suggests MVS, but
> not quite.

At least in the IBM world, disk drives originally didn't have their
tracks formatted into fixed-length sectors as they are today.  Early
on in the business world, everything was record-oriented.  Except for
the very largest ones, computers didn't have the either the speed or
the memory to do database processing as we now know it.  For most
business shops, there was sequential file processing, random access
(where you had to know the cylinder and head position of the record
you wanted), and indexed sequential access (by the value of a key
field in the record).

Disks in those days (pre-mid 70s) were not formatted in fixed-length
sectors as they are today.  Instead, records could be arbitrary length
(limited by the capacity of a single disk track, of course) and had
three fields:  a count field containing the number of bytes in the
record, a key field for indexed access, and a data field.  This format
was called CKD (count/key/data).  On IBM disks, records were addressed
by a number of the form CCCHHRR, where CCC is the cylinder, HH the
head, and RR the record on the track (for the data cell drive, there
was also a two digit bin number).  The disk controller could also do a
"seek by key" operation.  This would scan the track for a record whose
key field matched the given key.  It was used to implement indexed
sequential access.

For System/360/370, the OSes for the smaller, slower systems, such as
Basic Operating System (BOS) and Disk Operating System (DOS and
DOS/VS) did not have an on-disk file system at all.  You had to
manually allocate the files on the disk and you used directives in job
control language (JCL) to tell the OS where your file was and to
assign it a logical unit number for the program to use (FORTRAN's I/O
reflects this).  The OSes for larger systems such as OS/MVS (and
perhaps its predecessor, OS/MVT?) had a catalog file that could
automate the process of assigning files to locations on disk.  This
was the closest these OSes came to a modern directory-oriented file
system.

In the business world this is not as grim as it might seem.  Most
businesses had a small number of files that didn't change very often.
For example, a college has accounts payable/receivable, student
academic records, alumni/charitable giving, and payroll and personnel.
These get allocated once and, provided the initial disk allocation is
sufficient, don't have to move.

On the programming side, there wasn't either the memory capacity or
processing power to implement a modern disk file system.  One of the
first computers I worked with was a System/360 model 25 running
DOS/360.  The machine had 48K of core memory, 12K of which was for the
OS, leaving 36K for programs.  No virtual memory.  The OS had an 8K
resident kernel and two 2K overlay areas:  the physical transient area
(for controlling hardware; the forerunners of what we now call device
drivers) and the logical transient area (for the parts of program I/O
that had to operate in privileged mode, and for most OS system service
functions).  For I/O, each program contained library routines called
"access methods", which took logical file I/O operations (open, close,
read, write, seek, etc.), built the appropriate I/O channel programs,
and executed the EXCP (execute channel program) OS primitive.  The
access methods operated on logical I/O unit numbers, which as
previously noted were associated with places on-disk via JCL
statements before the program started execution.  The access methods
were SAM (Sequential Access Method; records read/written in on-disk
order), DAM (Direct Access Method; allowed seeking to an arbitrary
record using CCCHHRR address), and ISAM (Indexed Sequential Access
Method; allowed seeking to a record by key, and then reading/writing
sequentially from there).

The access methods and their capabilities mirrored the CKD disk format
of the time.  As disk hardware became denser and faster, and computers
got more memory, it became more efficient to format the disk as a set
of fixed-length sectors, which could be packed more densely and
accessed faster than CKD records.  Record blocking and unblocking was
moved to the OS or application.  Indexed access could be accomplished
a lot faster using B-trees in the file.

UNIX took the final step in this evolution by providing exclusively
byte-stream I/O in the OS, and leaving record processing up to the
application.  Those of us from the record-oriented world found this a
pain in the butt at first (application programmers were forced to roll
their own record processing, something that the access methods did for
you in the OS/360 world).  But by 1990 it was generally recognized
that stream I/O is the more appropriate OS primitive.

-Paul W.

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]


I'm not sure that the file and directory structure was all that
innovative (after all, the biologists had been doing that kind of
thing forever...).  But the file as a lightweight
flick-of-the-wrist-create-able entity was mind blowing.  At the time,
the IBM 360 required that you run a special job step to create a file
(we're talking punched cards here).  And then you had to pull that
job step out of the deck because trying to create a file that already
existed was an error.   In the GE/Honeywell time sharing system, you
had to invoke a subsystem that asked you 8 or 10 questions (name, what
device was it on, how big is upon creation, how big could it grow to,
what was its record size, etc.).   It stored up your answers and then
handed them to the OS.  It was easy to get a question wrong, in which
case it sent you back to the beginning to do the dance again.  Most
telling, when the file was finally created the subsystem exited with
the happy message "Successful!"

For people used to that world, "echo hello >hi" was literally jaw
dropping.  Many people had to have it explained twice, because they
literally could not conceive of a file being created so easily.  I
had worked in the computing center for a couple of years, and probably
gave more than my share of demos to mainframe users...

Steve

PS:  It was about this time that a survey of the mainframe computer
centers found that over 50% of the (costly, limited) disc space
consisted of trailing blanks of 80-column card images stored on
disc. 

----- Original Message -----
From: "Wesley Parish" <wes.parish@paradise.net.nz>
To:<tuhs at minnie.tuhs.org>
Cc:
Sent:Sat, 09 Sep 2017 13:16:30 +1200 (NZST)
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie!

 'fraid so. The Unix directory structure and the correlating free-form
file competed with the file-as-
 record-structure and directory-as-record-structure in the seventies
and eighties. The competition had 
 finished by the nineties, and hardly anybody remembers it now.

 Seriously, how many grandmothers can you think of who would know how
to allocate disk space for a 
 photo of their grandkids? Who would be able to guess how many bytes a
letter might take up?

 Free-form files and directory nodes (with the corresponding
requirement that the OS know how to 
 allocate and reallocate disk space) helped democratize computing.

 Just my 0.02c :)

 Wesley Parish

 Quoting Michael Kjörling <michael at kjorling.se>:

 > On 8 Sep 2017 17:04 -0400, from jnc at mercury.lcs.mit.edu (Noel
Chiappa):
 > > We'd be running a Windows even worse than current Windows (which
has
 > managed
 > > to pick up a few decent ideas from places like Unix).
 > 
 > Like directories, and free-form files (collections of bytes as
opposed
 > to collections of records)?
 > 
 > -- 
 > Michael Kjörling ⢠https://michael.kjorling.se â¢
 > michael at kjorling.se
 > âPeople who think they know everything really annoy
 > those of us who know we donât.â (Bjarne Stroustrup)
 > 

 "I have supposed that he who buys a Method means to learn it." -
Ferdinand Sor,
 Method for Guitar

 "A verbal contract isn't worth the paper it's written on." -- Samuel
Goldwyn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/740587fc/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[William Cheswick]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

Amen.  There were a number of things that really sucked at the time.  
My least favorite: time sharing systems that didn’t allow type-ahead.

Kids these days...

> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com> wrote:
> 
> For people used to that world, "echo hello >hi" was literally jaw dropping.  Many people had to have it explained twice, because they literally could not conceive of a file being created so easily.  I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users...
> 
> Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/ea7e6843/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

On Sat, 9 Sep 2017, William Cheswick wrote:

> Amen.  There were a number of things that really sucked at the time.
> My least favorite: time sharing systems that didn’t allow type-ahead.
>
> Kids these days...

Oh geez. That sounds pants-on-head special.

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]

TOPS-10 allowed type-ahead, with the caveat that if a program exited 
with an error, it would intentionally clear the TTY buffer. Something I 
actually sorely miss.

IIRC, the type-ahead buffer was only around 80 characters. If you 
exceeded it, it beeped at you ;)



On 9/9/2017 9:04 AM, William Cheswick wrote:
> Amen.  There were a number of things that really sucked at the time.
> My least favorite: time sharing systems that didn’t allow type-ahead.
>
> Kids these days...
>
>> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com 
>> <mailto:scj at yaccman.com>> wrote:
>>
>> For people used to that world, "echo hello >hi" was literally jaw 
>> dropping.  Many people had to have it explained twice, because they 
>> literally could not conceive of a file being created so easily.  I 
>> had worked in the computing center for a couple of years, and 
>> probably gave more than my share of demos to mainframe users...
>>
>> Steve
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/a4869f25/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

On Sat, 9 Sep 2017, Arthur Krewat wrote:

> TOPS-10 allowed type-ahead, with the caveat that if a program exited with an 
> error, it would intentionally clear the TTY buffer. Something I actually 
> sorely miss.

That's actually a nice-ish feature.

> IIRC, the type-ahead buffer was only around 80 characters. If you exceeded 
> it, it beeped at you ;)

Reminds me of the 15-key buffer in the PC BIOS, which also beeps if you 
run out.

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

What, you didn’t like IBM 2741 terminals that mechanically locked the keyboard?

> On 2017, Sep 9, at 9:04 AM, William Cheswick <ches at cheswick.com> wrote:
> 
> Amen.  There were a number of things that really sucked at the time.  
> My least favorite: time sharing systems that didn’t allow type-ahead.
> 
> Kids these days...
> 
>> On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com <mailto:scj at yaccman.com>> wrote:
>> 
>> For people used to that world, "echo hello >hi" was literally jaw dropping.  Many people had to have it explained twice, because they literally could not conceive of a file being created so easily.  I had worked in the computing center for a couple of years, and probably gave more than my share of demos to mainframe users...
>> 
>> Steve
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/3f96ceb6/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2793 bytes --]

Part of that problem was probably electronic, not software.   Many
of the early terminals were half-duplex.  The normal mode was that
the terminal typed what came over the line, and the keyboard was
locked.  If you wanted to let the terminal send data, you needed to
send a control character to unlock the keyboard, and then another one
to lock it when you wanted to send data again.

As you may know, the first PDP-11 at Bell Labs was financed by the
patent department because there were very draconian rules about
submitting patents (every page had to have exactly 50 numbered lines,
lines could not be blank, numbers must be in order, etc.)   A change
on page 3 of a 25-page patent application could mean that the whole
thing had to be retyped (yes, manually...).   That need drove a lot
of the early nroff work.  And, when upper/lower case terminals became
common, many still had half duplex interfaces.    When the Unix
software got good enough, it started to get used by real typists, who
were used to electric typewriters.  There was bitter complaint about
the half duplex (keyboard lock) mode -- the typists were so fast that
when the keyboard locked they could break their fingernails!  Full
duplex pretty much solved that problem, and Unix, as far as I
remember, embraced it earlier than most other systems.

Steve

PS:  The Usenix publication ";login:" got its name because that's
what a half-duplex system wrote for the login message when viewed on a
full duplex terminal.  The ; and : were actually control
characters...

----- Original Message -----
From: "Lawrence Stewart" <stewart@serissa.com>
To:"William Cheswick" <ches at cheswick.com>
Cc:"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:Sat, 9 Sep 2017 16:33:54 -0400
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie!

 What, you didn’t like IBM 2741 terminals that mechanically locked
the keyboard?

On 2017, Sep 9, at 9:04 AM, William Cheswick <ches at cheswick.com [1]>
wrote:

Amen.  There were a number of things that really sucked at the time.
 
My least favorite: time sharing systems that didn’t allow
type-ahead.

Kids these days...

On 9Sep 2017, at 12:34 AM, Steve Johnson <scj at yaccman.com [2]> wrote:

For people used to that world, "echo hello >hi" was literally jaw
dropping.  Many people had to have it explained twice, because they
literally could not conceive of a file being created so easily.  I
had worked in the computing center for a couple of years, and probably
gave more than my share of demos to mainframe users...
Steve

 

Links:
------
[1] mailto:ches at cheswick.com
[2] mailto:scj at yaccman.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/1e8b75db/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]

On Sat, 9 Sep 2017, Steve Johnson wrote:

> Part of that problem was probably electronic, not software.   Many of 
> the early terminals were half-duplex.  The normal mode was that the 
> terminal typed what came over the line, and the keyboard was locked.  If 
> you wanted to let the terminal send data, you needed to send a control 
> character to unlock the keyboard, and then another one to lock it when 
> you wanted to send data again.

Aah, well I remember the times that I felt like leaning over to hit
the Big Switch on our 360/50, when the console jammed...

That was the Blue Button, of course, not the Red Switch (we weren't 
allowed to pull that).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie!

[Paul Winalski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On 9/9/17, Lawrence Stewart <stewart at serissa.com> wrote:
> What, you didn’t like IBM 2741 terminals that mechanically locked the
> keyboard?

In the business world, these terminals were typically half-duplex and
attached 4 or 8 (or more) to a control unit that communicated with the
computer using bisynch protocol.  It's like a telephone party
line--only one terminal can communicate with the computer at a time.
The remainder were locked out. [Note that Ethernet works pretty much
the same way.]  If you wanted to talk to the computer, you pressed the
"Request" key.  This caused the control unit to send an interrupt to
the computer, which in due course would then unlock your terminal and
talk to you.  This works out OK for transaction processing, but it's
not a good fit for interactive time-sharing.

-Paul W.

[TUHS] Happy birthday, Dennis Ritchie!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

below...

On Sat, Sep 9, 2017 at 12:34 AM, Steve Johnson <scj at yaccman.com> wrote:

>
> ​...​
>  At the time, the IBM 360 required that you run a special job step to
> create a file (we're talking punched cards here).  And then you had to pull
> that job step out of the deck because trying to create a file that already
> existed was an error.
>
​Point taken and sort of...TSS/360 and MTS was not (quite) as bad (although
it could be if you use the batch processing system), but Steve is right...
the idea of persistence was really not something people considered as
'easy' because it usually cost them money (real or allocated from the
computer center).

So I suspect part of it was the economics of storage at time.   On line
(magnetic) storage  was way more expensive than cards.   Its has been
pointed at the the original PDP-7 Ken used did not have a disk on it, it
was custom special DEC's CSS group had splicing a PDP-15 disk to it.  The
disk unit itself was manufactured by someone else (as were most/many of
DEC's disks for years).

Clay Christensen in "*The Innovator Dilemma" *has curves that actually
start a few years later when he studies the disk drive industry.   But its
the just part of the same effect he is talking about.

The key is the what UNIX was doing was not considered practical by the
mainframe folks, so people did not consider it.  It was a resources to be
protected (and to an extent, hoarded maybe).   Moore's Law, et al, was the
engine that allowed the UNIX innovation to really see light.  The way the
mainframes were doing things just did not make functional sense, but until
it was economical to do it otherwise - we were stuck.

As Steve says... it really was mind blowing for making things like this
easy.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170909/47feecf7/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

On Fri, 8 Sep 2017, Noel Chiappa wrote:

>    > From: Dave Horsfall <dave at horsfall.org>
>
>    > Just think, if it wasn't for him and Ken, we'd all be running Windoze,
>    > and thinking it's wonderful.
>
> It's actually worse than that.
>
> We'd be running a Windows even worse than current Windows (which has managed
> to pick up a few decent ideas from places like Unix).
>
> 	Noel
>

Heck, even MS-DOS 2 as we knew it would not have been what it was, were it 
not for Unix.

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 658 bytes --]

On 8 Sep 2017 18:28 -0400, from usotsuki at buric.co (Steve Nickolas):
> Heck, even MS-DOS 2 as we knew it would not have been what it was,
> were it not for Unix.

Wasn't it MS-DOS 2 that introduced such advanced features as
directories, pipes and general console I/O redirection?

Of course most software that ran on top of DOS broke much of the
redirection niceness by addressing the console directly via video
memory access...

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Sat, 9 Sep 2017, Michael Kjörling wrote:

> On 8 Sep 2017 18:28 -0400, from usotsuki at buric.co (Steve Nickolas):
>> Heck, even MS-DOS 2 as we knew it would not have been what it was,
>> were it not for Unix.
>
> Wasn't it MS-DOS 2 that introduced such advanced features as
> directories, pipes and general console I/O redirection?

For varying degrees of "pipes"; it implemented them with a temp file.  But 
yes, and that's exactly what I was referring to - it took those features 
from Xenix.  The API is pretty much as Unixlike as you could get on top of 
the INT21 interface and on a single-tasking system, I think.

> Of course most software that ran on top of DOS broke much of the
> redirection niceness by addressing the console directly via video
> memory access...

Of course.  But those kinds of programs often weren't the kind you'd want 
to redirect anyway.

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Arthur Krewat]

Seconded.

Who knows, may we wouldn't even have Windows.

On 9/8/2017 4:54 PM, Dave Horsfall wrote:
> Sadly no longer with us (he exited in 2011), he was forked in 1941. 
> Just think, if it wasn't for him and Ken, we'd all be running Windoze, 
> and thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>

[TUHS] Happy birthday, Dennis Ritchie!

[William Pechter]

If it wasn't for Unix, it possibly would have been VMS on Alpha... Or OS/2.  Early Windows 3.x wouldn't have cut it.

Perhaps without the Unix workstations DEC might have survived.

Interesting alternate history...

Bill


-----Original Message-----
From: Dave Horsfall <dave@horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Fri, 08 Sep 2017 16:56
Subject: [TUHS] Happy birthday, Dennis Ritchie!

Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just 
think, if it wasn't for him and Ken, we'd all be running Windoze, and 
thinking it's wonderful.

A Unix bigot through and through, I remain,

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie!

[Angus Robinson]

You also would have Mac OS, Linux,etc

On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter at gmail.com> wrote:

> If it wasn't for Unix, it possibly would have been VMS on Alpha... Or
> OS/2.  Early Windows 3.x wouldn't have cut it.
>
> Perhaps without the Unix workstations DEC might have survived.
>
> Interesting alternate history...
>
> Bill
>
>
> -----Original Message-----
> From: Dave Horsfall <dave at horsfall.org>
> To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Fri, 08 Sep 2017 16:56
> Subject: [TUHS] Happy birthday, Dennis Ritchie!
>
> Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just
> think, if it wasn't for him and Ken, we'd all be running Windoze, and
> thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170908/c69f8a31/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[William Pechter]

If no Unix... No Mac OSx or Linux or *BSD.

Linux came from the Posix spec.  OSx came from a Unix personality on Mach...

Perhaps the Prime OS or  perhaps Domain OS from Apollo would have been the workstation of the tech world. 

Apollo had a lead on Sun back in the day. 

Bill 
Bill

-----Original Message-----
From: Angus Robinson <angus@fairhaven.za.net>
To: William Pechter <pechter at gmail.com>, The Eunuchs Hysterical Society <tuhs at tuhs.org>, Dave Horsfall <dave at horsfall.org>
Sent: Fri, 08 Sep 2017 18:14
Subject: Re: [TUHS] Happy birthday, Dennis Ritchie!

You also would have Mac OS, Linux,etc

On Fri, Sep 8, 2017 at 5:14 PM William Pechter <pechter at gmail.com> wrote:

> If it wasn't for Unix, it possibly would have been VMS on Alpha... Or
> OS/2.  Early Windows 3.x wouldn't have cut it.
>
> Perhaps without the Unix workstations DEC might have survived.
>
> Interesting alternate history...
>
> Bill
>
>
> -----Original Message-----
> From: Dave Horsfall <dave at horsfall.org>
> To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
> Sent: Fri, 08 Sep 2017 16:56
> Subject: [TUHS] Happy birthday, Dennis Ritchie!
>
> Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just
> think, if it wasn't for him and Ken, we'd all be running Windoze, and
> thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>

[TUHS] Happy birthday, Dennis Ritchie!

[Dave Horsfall]

On Fri, 8 Sep 2017, William Pechter wrote:

> Perhaps the Prime OS or perhaps Domain OS from Apollo would have been 
> the workstation of the tech world.

I almost worked for Pr1me once (I worked next door to them in North 
Sydney); what stopped me was their notion that "1" was a prime number 
(yes, I'm a mathematician)...

> Apollo had a lead on Sun back in the day.

I used to work for Sun, and we hated Apollo :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie!

[Larry McVoy]

On Sat, Sep 09, 2017 at 03:13:30PM +1000, Dave Horsfall wrote:
> On Fri, 8 Sep 2017, William Pechter wrote:
> 
> >Perhaps the Prime OS or perhaps Domain OS from Apollo would have been the
> >workstation of the tech world.
> 
> I almost worked for Pr1me once (I worked next door to them in North Sydney);
> what stopped me was their notion that "1" was a prime number (yes, I'm a
> mathematician)...
> 
> >Apollo had a lead on Sun back in the day.
> 
> I used to work for Sun, and we hated Apollo :-)

Mr Yacc might like this story.

Before I worked for Sun I worked for Lachman (porting Unix to the ETA-10)
and the dev environment there was apollos served by a Sun 3/280 file
server.

I was fresh out of school, interviewed with Lachman for this job, they
sort of let me believe I'd be doing the VM system for this weird ass
machine that was basically a cluster with a huge (at the time) 2GB
"shared" memory that was bcopy only.  Seemed like a fun project.

I got there and they said "Um, you know, we have someone with more
than zero years of experience working on the VM system.  How about you
port all the commands?"  Crushed me was like "Really?" They said "Really".

Sigh, whatever.  So what I quickly learned was weird about this machine
was that native pointers pointed at bits.  The compiler writers were all
like "fuck that, we point at bytes" but they had to have a way to get to
real pointers so they decided that if you did 

	char	*p = &whatever;
	int	i = (int)p;

the assignment of a pointer into an int did the shift to point at the first
bit of that byte, and the other way shifted the other way.  Got it?  Ints
held "real" pointers and pointers held byte aligned pointers.  It was weird,
yes.

The unfortunate side effect is that 

	char	*p = malloc(10);

caused a shift if you didn't include malloc.h.  Because the compiler thought
malloc was returning a bit pointer so it "kindly" did the shift for us.

This quickly became a pattern.  Here is what I did:

First, and this is the apollo part, I ported the cross compiler from the
apollo environment to SunOS.  Because compiling on the file server was
faster in two ways: (a) local file system instead of NFS and (b) the Sun
was way way faster than those stupid apollo machines.  And the Sun was
real Unix.  The port caused all sorts of fuss because I wasn't part of
the compiler team, I had to write a tool that diffed the binaries produced
by the Sun with the ones produced by the apollos to show that the only
difference was in the a.out header that had a timestamp or something.

Second, and this is the part that Steve might like, I hacked lint suck
that when it complained about type mismatches it wandered around until
it got to the base types and printed out

	type mismatch: "INT" vs "POINTER"

which wasn't that easy, I didn't really understand the guts of lint.
I think those changes did wind their way back into Sys V lint somehow,
I had nothing to do with it, maybe someone from Lachman fed them back
or maybe the Sys V people redid them on their own.

OK, so now I lint all of /usr/src/cmd and I wrote an awk script (perl
wasn't around yet and awk worked fine) that looked for any int/pointer
mismatch, edited the file, and included every header I could think of
that declared some library function that returned a pointer, string.h,
malloc.h, etc.  I iterated a few times (this was an overnight thing,
I'd come in in the morning and see that I forgot some more, add them
to the list, restart the script).

Finally I get a clean lint run and I start up a compile run, fix up
a few remaining things (there were surprisingly few, it was an easy
port) and I've got a built /usr/src/cmd installed on piper1, my
test machine.  I go to my boss and say "I'm done".  Note that all of
this stuff, getting onboarded, porting the compiler, wacking lint,
linting, compiling, took about 3 weeks.  I was a busy little beaver :)

My boss goes "yeah, right.  Hey, Mike, go look at piper1 and see what
kind of a mess we have".  Mike goes off and comes back, gives me a
weird look, and says "He's right, he's done".  Sort of, we didn't have
tty's yet so vi didn't work, we didn't have a kmem driver so ps didn't
work (which was *really* annoying), etc.  But awk worked, find worked,
ls worked, all that stuff worked.

My boss says "get out of here, let me think about this".

I come back in the next day, go to my boss (Bob Palm if any of you
know him, great guy) and he says "You can go home, we'll just pay
you".  Turns out that Lachman had budgeted for 6 months to do the
/usr/src/cmd port and it didn't look good to have me sitting around
doing nothing.

I, being the nerd that I am, said "Do you mind if I stick around if
I'm doing work?"  Bob says "Go for it, you can do whatever you want
if you look busy".

And there began the most awesome 6 months of my life.  I wrote
my own version of ps and a /dev/ps driver that was a dumbed down
version of /dev/kmem, because I was too clueless to write a kmem
driver.  People used that ps for a long time until someone did a 
real kmem driver.

I wrote the Unix side of the disk driver, which sounds hard but 
wasn't, this thing had I/O channels that had their own processor
so it was more like writing a http client or something, just in 
the kernel.  The real driver was in the I/O channel, all I had to
do was learn how to talk to the I/O channel.  And it was a polling
driver, no interrupts, there was some hardware glitch with interrupts
or something, whatever the reason, I just polled so it was easy.
Shitty perf but easy.

I ported all of the Lachman STREAMS TCP stack.  If I recall correctly
shorts weren't shorts, they were u32.  So all the 

	unsigned short	port;

became

	unsigned short	port:16;

I remember the stack being the biggest job, there were some things
that turned out to be tricky, long forgotten.  Oh, I bet anything
a lot of it was the networking drivers.  I know some of it was 
me banging on stuff but I think there were some driver issues as
well, I didn't work on those, I'm not much of a device driver person.

After all this I got sent to Japan with 3 source tapes, the base system
that included all of /usr/src/cmd and everyone else's stuff that had 
sort of been approved for integration, a version of the tree with big
pages, and the version of the tree that had the networking stack in it.

I was sent to the Tokyo Institute of Technology (TIT) and I was the techy
guy, they sent me with another Sun 3/280 and two Sun 3/50 (screw that
apollo crud) and told me to set up a dev environment and merge those
source trees.  So of course the server was installed as "bigtit" and
the 3/50's as "lefttit" and "righttit" which lasted until the Japanese
folks figured out what those meant.

I was there for 3 months, doing the merge wasn't easy and then other
problems cropped, again with the drivers if I remember correctly.
So the folks back in St Paul were sending me stuff, I was merging it,
building, installing, testing, reporting back what didn't work, and
that went on for quite a while.  Eventually it worked and home I 
went.  Lost a bunch of weight because I didn't like sushi at the 
time and there weren't a lot of good alternatives that kept my
weight up.  Fun times.

[TUHS] Happy birthday, Dennis Ritchie!

[Dave Horsfall]

On Fri, 8 Sep 2017, William Pechter wrote:

> Perhaps without the Unix workstations DEC might have survived.

Sigh :-)  RSTS, RSX-11[MD], Pick, VMS, etc; they've all taken on Unix, and 
I've been privileged to see them all off :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie!

[Paul Winalski]

On 9/8/17, William Pechter <pechter at gmail.com> wrote:
> If it wasn't for Unix, it possibly would have been VMS on Alpha... Or OS/2.
> Early Windows 3.x wouldn't have cut it.
>
> Perhaps without the Unix workstations DEC might have survived.
>
> Interesting alternate history...

Clem Cole and I could go on for pages on why DEC went out of business.
But it's pretty much off-topic for this list.

SUN captured the workstation market from Apollo and DEC because they
managed to sell workstations cheaper than their competitors.  I don't
think that the OS being UNIX had very much to do with it.  But using
UNIX probably lowered SUN's software development costs, and no doubt
that contributed to their lower workstation cost.

What ultimately did in DEC was missing the PC wave.  PCs did the same
thing to the minicomputer and workstation companies that minicomputers
did to mainframes in the 1970s.  PCs offered equivalent (or better)
capabilities at much reduced cost.  First they ate the word processor
market (remember Wang?) and then minicomputers and workstations.  UNIX
workstation manufacturers such as SUN suffered the same fate as DEC at
the hands of the PC.  UNIX did not save them.

-Paul W.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[Jon Steinhart]

Paul Winalski writes:
> SUN captured the workstation market from Apollo and DEC because they
> managed to sell workstations cheaper than their competitors.  I don't
> think that the OS being UNIX had very much to do with it.  But using
> UNIX probably lowered SUN's software development costs, and no doubt
> that contributed to their lower workstation cost.

While the choice of UNIX may have played a small part, Sun really nailed
it with the SparcStation I.  Sure, they sold it for less than whatever
the DEC equivalent was at the time, but that's because their manufacturing
cost was way less.  The SparcStation I pioneered a lot of new manufacturing
technology; it was the first snap-together system.  I remember looking at
a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of
the parts of the equivalent DEC system.  Methinks that better engineering
won the day.

Jon

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[Paul Winalski]

On 9/11/17, Jon Steinhart <jon at fourwinds.com> wrote:
>
> While the choice of UNIX may have played a small part, Sun really nailed
> it with the SparcStation I.  Sure, they sold it for less than whatever
> the DEC equivalent was at the time, but that's because their manufacturing
> cost was way less.  The SparcStation I pioneered a lot of new manufacturing
> technology; it was the first snap-together system.  I remember looking at
> a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of
> the parts of the equivalent DEC system.  Methinks that better engineering
> won the day.

Absolutely.  I worked at DEC and had many engineer friends at Apollo,
and we were all shaking our heads wondering how Sun got their
manufacturing costs so low.  Scott McNealy's management style helped,
too.  Ken Olsen at DEC believed in consensus building; decisions
weren't final until everyone bought into them.  IMO this led to a lot
of (expensive) wrangling and slowed down corporate reaction to market
conditions.  Scott McNealy believed in the principle of a single
decision-maker:  "lead, follow, or get out of the way".  We at DEC
eventually moved to project management that involved a single lead
engineer who was responsible for the success of the project, and who
was empowered to make decisions when a consensus couldn't be found.
But that management style never really caught on, although in my
experience the most successful software projects were all organized
that way.

-Paul W.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[Larry McVoy]

On Mon, Sep 11, 2017 at 09:49:16AM -0700, Jon Steinhart wrote:
> Paul Winalski writes:
> > SUN captured the workstation market from Apollo and DEC because they
> > managed to sell workstations cheaper than their competitors.  I don't
> > think that the OS being UNIX had very much to do with it.  But using
> > UNIX probably lowered SUN's software development costs, and no doubt
> > that contributed to their lower workstation cost.
> 
> While the choice of UNIX may have played a small part, Sun really nailed
> it with the SparcStation I.  Sure, they sold it for less than whatever
> the DEC equivalent was at the time, but that's because their manufacturing
> cost was way less.  The SparcStation I pioneered a lot of new manufacturing
> technology; it was the first snap-together system.  I remember looking at
> a tear-down of the DEC and Sun offerings, and the Sun had less than 10% of
> the parts of the equivalent DEC system.  Methinks that better engineering
> won the day.

And don't underestimate the draw of a BSD that was "fixed", had mmap that
worked, unified page cache, VFS layer that was pleasant.  I worked for
Lachman before I worked for Sun, saw the guts of quite a few Unix OS's.
SunOS was by *far* the most pleasant and well thought out.  It was an
OS where you could predict what it would do based on the architecture
and sure enough, that's what it did.

I miss that source base.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[arnold]

Larry McVoy <lm at mcvoy.com> wrote:

> And don't underestimate the draw of a BSD that was "fixed", had mmap that
> worked, unified page cache, VFS layer that was pleasant.  I worked for
> Lachman before I worked for Sun, saw the guts of quite a few Unix OS's.
> SunOS was by *far* the most pleasant and well thought out.  It was an
> OS where you could predict what it would do based on the architecture
> and sure enough, that's what it did.

Thinking about it, particularly in light of the fact that Oracle has
finally killed Solaris, it seems to me that another reason that Sun
succeeded was that they were the ones who really innovated.

In particular, the creation of NFS and then the efforts to make it into
a de-facto standard (giving away the RPC and XDR code) was a HUGE thing.

They weren't afraid to swim upstream, either. Even though NeWS never took
off (even when combined with an X server), it was an interesting design,
ahead of its time even.

They were the first of the major Unix vendors to really dive into RISC, if
I recall correctly.  MIPS may have been the first Unix vendor based on
a RISC architecture, but they were a startup.

DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for
many years.

My two cents, as filtered through my aging memory, (:-)

Arnold

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[Ronald Natalie]

> 
> They weren't afraid to swim upstream, either. Even though NeWS never took
> off (even when combined with an X server), it was an interesting design,
> ahead of its time even.
> 
> 
NeWS had serious issues.   However, the same guy who was the NeWS proponent learned from mistakes and the result
was the must more successful Sun tehnology:   JAVA.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[Toby Thain]

On 2017-09-12 10:12 AM, Ronald Natalie wrote:
> 
>>
>> They weren't afraid to swim upstream, either. Even though NeWS never took
>> off (even when combined with an X server), it was an interesting design,
>> ahead of its time even.
>>
>>
> NeWS had serious issues.   However, the same guy who was the NeWS proponent learned from mistakes and the result
> was the must more successful Sun tehnology:   JAVA.
> 
> 

It would probably befit this list and posterity to go into detail about
what those issues were.

At the time, NeWS certainly seemed to have interesting ideas far ahead
of the popular window systems (and yes we could discuss those ideas as
well. Unfortunately my NeWS developer binder is in storage and my memory
isn't reliable at that range).

--T

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo ]

[arnold]

Ronald Natalie <ron at ronnatalie.com> wrote:

>
> > 
> > They weren't afraid to swim upstream, either. Even though NeWS never took
> > off (even when combined with an X server), it was an interesting design,
> > ahead of its time even.
> > 
> > 
> NeWS had serious issues.   However, the same guy who was the NeWS proponent learned from mistakes and the result
> was the must more successful Sun tehnology:   JAVA.
>

But you have strengthened my main point, which is that Sun *innovated*.
NFS, NeWS, Java - 2 out of 3 is pretty good. :-)

Thanks,

Arnold

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Jon Steinhart]

arnold at skeeve.com writes:
> 
> In particular, the creation of NFS and then the efforts to make it into
> a de-facto standard (giving away the RPC and XDR code) was a HUGE thing.
> 
> They weren't afraid to swim upstream, either. Even though NeWS never took
> off (even when combined with an X server), it was an interesting design,
> ahead of its time even.

It's interesting that you mention the two of these together.  It's my
opinion that the main reason that NeWS failed was because of the success
of NFS.

I recall that Apollo was really pissed off by NFS because they felt that
their token-ring network was better but lost because NFS was given away.
In hindsight, they were wrong; while the token-ring performed better in
large networks, the advent of switches made that moot.  In any case, when
NeWS was released nobody except Sun knew how to do the graphics (even
Adobe didn't know how to do it fast for display) and Apollo et. al. was
worried that Sun would give NeWS away and make it yet another de facto
standard a la NFS.  This led to the formation of the Hamilton Group which
was a thinly-disguised industry consortium that existed only for the
purpose of making sure that NeWS didn't succeed.

> DEC, IBM, and HP, all seemed to be playing follow the leader to Sun for
> many years.

I mentioned this to a lot of people after Sun died.  Few seem to realize
how much of what became PC manufacturing technology resulted from innovations
at Sun.

ron at ronnatalie.com writes:
>
> NeWS had serious issues.   However, the same guy who was the NeWS proponent
> learned from mistakes and the result was the must more successful Sun
> tehnology:   JAVA.

I'm going to take issue with the above.  NeWS had way fewer serious issues
than X.  It's main reason for failure was the coordinated effort to kill it
from others in the industry.  As the guy who single-handedly prevented X
from becoming an ANSI standard, I'd be happy to start another thread on
this topic if people are interested.  Part of the result of the Hamilton
Group effort was the misguided attempt to merge X and NeWS which was a
botched disaster.

Java is not the result of learning from mistakes in NeWS.  I have joked with
James that I feel that his legacy is being the person who first realizes that
technology is changing to the point where something can be done using an
interpreter.  If you look at his project history, he's done this many times.
I think that it's more accurate to say that Java is the result of a lifetime
of learning from interpreter projects.  I fully expect some new interpreter
to take over AWS sometime soon :-)

Jon

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 12, 2017 at 08:35:24AM -0700, Jon Steinhart wrote:
> arnold at skeeve.com writes:
> > 
> > In particular, the creation of NFS and then the efforts to make it into
> > a de-facto standard (giving away the RPC and XDR code) was a HUGE thing.
> > 
> > They weren't afraid to swim upstream, either. Even though NeWS never took
> > off (even when combined with an X server), it was an interesting design,
> > ahead of its time even.
> 
> It's interesting that you mention the two of these together.  It's my
> opinion that the main reason that NeWS failed was because of the success
> of NFS.
> 
> I recall that Apollo was really pissed off by NFS because they felt that
> their token-ring network was better but lost because NFS was given away.
> In hindsight, they were wrong; while the token-ring performed better in
> large networks, the advent of switches made that moot.  In any case, when
> NeWS was released nobody except Sun knew how to do the graphics (even
> Adobe didn't know how to do it fast for display) and Apollo et. al. was
> worried that Sun would give NeWS away and make it yet another de facto
> standard a la NFS.  This led to the formation of the Hamilton Group which
> was a thinly-disguised industry consortium that existed only for the
> purpose of making sure that NeWS didn't succeed.

It was more than NeWS, it was anything Sun.  Here's how 100Mbit ethernet
happened because of Sun (well, really me and Andy) in spite of the "anything
but Sun sentiment":

Some background to go with what Jon said.  I was at Sun during this
time, Sun was on a roll, they kept innovating and other people were
playing catchup, mmap, vm layer that worked, VFS interface that worked,
NFS, etc.  Sun really was innovating back then and it left other people
behind and pissed.  They were especially pissed when Sun stuff became
a standard and they had to match it.  So they formed a loose cabal that
had the sentiment of "No more Sun wins".

At the time I was arguing for 100Mbit ethernet with little success.  The
hardware guys hadn't twigged to the idea that one base packet format
over a bunch of different speed cables is better than multiple packet
types that you have to rewrite.  When I asked for 100mbit over copper
they said it couldn't be done.

I was a systems guy at the time, building a clustered NFS server code
named sunbox.  Venders were constantly coming to me to pitch their stuff
to be included in my system (we did use Kalpana switches so one of the
pitches worked).  One day some dude from Crescendo shows up with a pitch
for something they called CDDI.  It was FDDI over copper at 100mbit.
I said wait here, went down the hall to Andy Bechtolsheim's office (I
had the good fortune to have an office next door to him, a little brag,
but I was living the dream!) got Andy and dragged him back to the meeting.
Asked the dude to do it again.  We thanked him and went back to our offices
and I ask Andy "You thinking what I'm thinking" because he knew about my
100Mbit ethernet dreams.  "Yeah, but there is the cabal problem".  We
knew about the anti Sun sentiment, wasn't much we could do about it, it
was just a problem we had to route around.

So what we did is a little road show in the valley.  The Crescendo guys
hadn't made us sign an NDA, their stuff was for sale already.  So we 
went to every hardware company in the valley that made network cards
and said "Did you know these guys are signalling at 100Mbit over copper?
Wouldn't it be cool if you made an ethernet card that did that?".

That was all it took, someone had a card about 6 months later and the
rest is history.  I'm sure it would have happened by itself at some
point, but Sun made that stuff happen as well.

They really were on a roll back then and in the hardware side it was
all Andy.  He was in his sweet spot which is anything that he can keep
the whole picture, all the details, in his head.  He's fantastic at that.
There is a story, no idea if it is true but it sounds like Andy, that
someone interrupted a meeting to tell him that the serial chip was going
to be like a buck or so cheaper.  There is this brief pause and then Andy
says "Cool, we'll use it for more pigment in the feet, I was wondering
where that would come from."

Fun times for sure!  I'm super super lucky to have been there and been
a part of it.  It wasn't Bell Labs when Dennis and Ken and team were 
making Unix, I would have loved to have been there but wrong age.
Sun was the Bell Labs of their time.  I fought hard to get in there 
and once I was in it was awesome.  Yeah, there were politics and all
the usual stuff, but I knew I was at the place that was leading and
I got to be part of it.  Living the dream for sure.

--lm

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Arthur Krewat]

Oh, do, please go on ;)



On 9/12/2017 11:35 AM, Jon Steinhart wrote:
> As the guy who single-handedly prevented X
> from becoming an ANSI standard, I'd be happy to start another thread on
> this topic if people are interested.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

I'd like to hear that too.  I like X11, use it all the time, take advantage
of the remote display all the time, have done some sunview programming and
a little of just the base libraries.  I can imagine that standardizing all
that stuff would be more than a mouthful.  But what else ya got?

On Tue, Sep 12, 2017 at 01:04:30PM -0400, Arthur Krewat wrote:
> Oh, do, please go on ;)
> 
> 
> 
> On 9/12/2017 11:35 AM, Jon Steinhart wrote:
> >As the guy who single-handedly prevented X
> >from becoming an ANSI standard, I'd be happy to start another thread on
> >this topic if people are interested.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] X and NeWS history (long)

[Jon Steinhart]

> Jon Steinhart wrote:
> As the guy who single-handedly prevented X from becoming an ANSI standard,
> I'd be happy to start another thread on this topic if people are interested.

Arthur Krewat writes:
> Oh, do, please go on ;)

Larry McVoy writes:
> I'd like to hear that too.  I like X11, use it all the time, take advantage
> of the remote display all the time, have done some sunview programming and
> a little of just the base libraries.  I can imagine that standardizing all
> that stuff would be more than a mouthful.  But what else ya got?

OK, you asked for it.  I think that I need to ask the Thing King to zark in a
few crates of old memories...

I spent mt teenage years as a graphics person as a result of my summer job at
Murray Hill working on the Glance-G terminal project.  Side-tracked into test
and measurement after getting my EE degree and doing cool black magic
electronics at Tektronix.  Got back into graphics and software when Tek tried
to get into the UNIX workstation business.  Started working on window systems
at that time, and continued after I quit Tek and moved to the bay area to
play at the startup game.  Started consulting after the third startup failed
which I'm still doing today.

While at Tek one of my jobs was to come up with a C language binding for GKS,
the Graphical Kernel System standard.  That itself is a funny story which ties
into the earlier troff thread.  I designed a language binding and wrote it up.
My friend Ed, author of "Real Programmers Don't Use Pascal", worked down the
road at GSS (Graphics Software Systems).  He told me that "yours looks better
than ours, you should bring it to the standards committee".  Amazingly enough
my management bought off on it, I brought my draft to the Huntsville meeting,
and it was adopted as the draft standard.  Why?  Because we had troff and an
Imprint-10!  Those were the days when people equated typeset with professional.
I recall discussing the issues with the C binding at an ANSI C committee
meeting in San Franscisco; probably met some you there.

ANSI X3X3 formed a window management subcommittee X3H3.6 somewhere along the
line.  I moved over there as I was pretty much done with the GKS stuff and the
window management end of things was more interesting.  Life changed in that
committee when the X push happened.  But first, a bit on a parallel track.

I knew Keith Lantz at Stanford who, if I remember correctly, had a graduate
seminar and wanted to talk about window management systems.  I came in as a
guest lecturer.  Partly because of this I became aware of the origins of X as
those weren't the days when one could easily just get technical papers on line.

For those of you unfamiliar with this, Stanford had developed the V operating
system which featured very fast synchronous IPC.  I believe that this ran on
the original Stanford University Network (SUN) boards.  They also developed
the W window system which ran on top of V.

I'm a bit fuzzy on the continental shift, but I believe that W made the cross
country trip to MIT via some sort of DEC connection.  Maybe they had funded
some of the Stanford research.

Gosling and Rosenthal had been working on the Andrew window system at CMU.  I
don't remember whether or not this was UNIX-based, but one of their early
design decisions was to minimize round-trips because they didn't have fast
synchronous IPC.

Despite this prior art, Scheifler took the W code, ported it to UNIX, and
called it X.  As one would expect, the performance was terrible.  X got
stuck at this state, version 10, for a long time.  Sun announced NeWS during
this stagnant period.  Freaked out Apollo, DEC, HP, etc. who got together at
DEC's Hamilton Avenue building to plot the "anything but Sun" strategy.  They
were successful in holding off the adoption of NeWS until they could rewrite
X to eliminate many of the synchronous round trips from the protocol resulting
in X version 11 which was pretty much completely incompatible with version 10.

In many respects Sun botched NeWS politically.  Large numbers of businesses
relied on applications that ran on Sun's SunView window system which was
heavily hooked into the OS and not even remotely portable.  They couldn't
use NeWS instead of SunView because they were running real businesses.  There
was no way to run SunView and NeWS at the same time so businesses couldn't
run new NeWS-based applications and old SunView applications at the same time.

I'm a bit fuzzy here, but the decision to merge X and NeWS was a bad technical
solution to a political problem.  Sun wanted to be able to say "We have X too."
Unfortunately, folks at Sun agreed to do this project without knowing what they
were talking about; it got rough when they realized that the NeWS and X
graphics models were completely incompatible.

Oh, despite all of the hype, there was actually nothing useful that one could
do using X at the time.  Not being very well socially adjusted, I annoyed a
lot of people by going to show floors and looking at X running things like maze
and loudly proclaiming "Oh, that's exactly what I do for a living."

Somewhere along the line Sun also decided to produce a mostly automated system
to convert SunView programs to use X.  I think that this was called XView.  I
remember billing for many a late night to actually get the thing working.

One of my other clients at the time was AED (advanced electronic displays).
If you were lucky enough to have a color frame buffer in those days it was
likely one of theirs.  They had a project to build X accelerator boards that
plugged into Sun workstations.  I think that I got called in because it
wouldn't work on the 3/260 which I eventually tracked down to the behavior of
the cache that only the 260 had.

AED was trying to figure out what to do as the world had changed and frame
buffers couldn't compete with workstations.  I came up with the idea to make
an X server that would run in a SunView window so that companies that relied
on SunView applications could run X applications concurrently.  We called this
XTool in keeping with the SunView application naming scheme.  I think that I
still have a few "XTool - Safe X for Suns" tee shirts around somewhere.  This
project unfortunately failed because AED was bought by someone with a "ship it
now, that'll force folks to fix the bugs" attitude.  XTool was very small and
fast compared to the X sample server because I wrote the server from scratch.
I think that I'm the only person to write an X server outside of the X
Consortium.  One of the things that I learned by doing it was that the X
Consortium folks were wrong when they said that the documentation was the
standard, not the sample server.  There were significant differences between
the two.

We showed XTool off at some shows.  People would come by the booth and ask
"how did you get it to run so fast?"  Being me, I loudly answered "We cheated.
We designed ours first."  Turns out that one of these times Keith Packard and
Jim Gettys were walking by which resulted in some long-standing animosity.

Back to the standards track.  Any of you that have done ANSI work know that
CBEMA has a one organization, one vote policy.  When Scheifler showed up at
X3H3.6 all other work stopped and X became a draft standard.  Whenever there
was a vote everybody would look to see how Bob was voting and voted with him.
For political reasons, all of the voting members from X Consortium member
companies had been told that they couldn't vote against X for technical reasons.

You may also know that one has to pay to be on an ANSI committee.  I wrote the
ANSI Secretariet and told them that I felt that by having both the X Consortium
and their member companies voting violated the spirit of the one organization
one vote rule, and that I couldn't justify continuing to pay to be on the
committee with this behavior.  They took it under advisement.

Eventually, public review time came around.   I submitted a document containing
something on the order of 800 comments.  These were pretty repetitious because
I had to hit the document one request at a time, but the major themes were:

 o  The only really worthwhile thing about X was the distributed extension
    registration mechanism.  All of the input, graphics and other crap
    should be moved to extension #1.  That way, it won't be mandatory in
    conforming implementations once that stuff was obsolete.  As you probably
    know, that's where we are today; nobody uses that stuff but it's like the
    corner of an Intel chip that implements the original instruction set.  As
    an aside, I upset many when working on OpenDoc for Apple and saying the
    same thing there.

 o  The atom/property mechanism allows clients to allocate memory in the server
    that can never be freed.  Some way to free memory needs to be added.

 o  The bit encodings should be part of a separate language binding, not part
    of the functional description.

I received a reply from the committee that said "Thank you for you comments."
I wrote the ANSI Secretariet and asked "Don't the rules for milestone 9 say
that the technical committee must make all reasonable efforts to accomodate
public review comments?"  The Secretariet wrote the committee.  Everybody on
the committee from companies such as Sun who had bee prohibited from voting
no for technical reasons all jumped up and cried "procedural violation" and
voted against forwarding the standard.  Scheifler stormed out.

I heard later than Scheifler wrote an angry letter to the Secretariet saying
"how dare you listen to that one lone consultant when I have the backing of
all of these major companies?"  The response was "Didn't you read our rules
before joining?"

Of course, by the time all of this settled out X was entrenched setting back
the state of UNIX UI for a long time.  A couple of decades ago I bough a Sun
Ultra-60 and asked whether it was worth paying for the dual processor version.
The answer that I got was "Yes.  You need one processor to run X and another
for everything else."

Wrapping this up, I have a section in the book that I'm writing where I talk
about how to design a good API.  I pose the question of why none of the original
Apple Mac API published in 1985 taking about 1,200 pages is in use today
whereas almost all of the UNIX V6 API published in 1975 taking 321 pages is
still in use and has been copied by many other systems.  I'm sure that everyone
on this list knows the answer.

X suffers from the same problems as the original Mac API.  Scheifler et. al.
didn't really do any system level design and modelling.  I know this because
I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that
I have travelled to on business that had no redeeming qualities.  He said "I
don't believe in models because they predispose the implementation."

Had he done some real design work and looked at what others were doing he might
have realized that at its core, X was a distributed database system in which
operations on some of the databases have visual side-effects.  I forget the
exact number, but X includes around 20 different databases: atoms, properties,
contexts, selections, keymaps, etc. each with their own set of API calls.  As
a result, the X API is wide and shallow like the Mac, and full of interesting
race conditions to boot.  The whole thing could have been done with less than
a dozen API calls.

Wrapping this up on a happy note, some years ago I was hanging out yakking at
the Hacker's Conference when this guy I didn't recognize due to hair loss came
up to me and said "I'm not going to say that you weren't an asshole because
you were, but you were right."  It was Keith Packard who was trying to get X
running on the OLPC and had run into the issue of clients allocating server
memory that couldn't be freed.  Been good friends since.  Same with Gettys.

Well, that's the whole sordid take from my point of view.  Hope that you
enjoyed it.

Jon

[TUHS] X and NeWS history (long)

[Larry McVoy]

On Tue, Sep 12, 2017 at 03:11:03PM -0700, Jon Steinhart wrote:
> In many respects Sun botched NeWS politically.  Large numbers of businesses
> relied on applications that ran on Sun's SunView window system which was
> heavily hooked into the OS and not even remotely portable.  

The rest of your story is great, just one small correction.  SunView started
as something Sun specific but it pretty quickly became a library on top of
X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.

Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
This would have been around 1990, is that still X10 or X11?

> We showed XTool off at some shows.  People would come by the booth and ask
> "how did you get it to run so fast?"  Being me, I loudly answered "We cheated.
> We designed ours first."  Turns out that one of these times Keith Packard and
> Jim Gettys were walking by which resulted in some long-standing animosity.

Heh.  I can only imagine.  ROTFLMAF.

> Wrapping this up on a happy note, some years ago I was hanging out yakking at
> the Hacker's Conference when this guy I didn't recognize due to hair loss came
> up to me and said "I'm not going to say that you weren't an asshole because
> you were, but you were right."  It was Keith Packard who was trying to get X
> running on the OLPC and had run into the issue of clients allocating server
> memory that couldn't be freed.  Been good friends since.  Same with Gettys.

Awesome.

> Well, that's the whole sordid take from my point of view.  Hope that you
> enjoyed it.

I sure did, love to meet you some time, where are you?

--lm

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Larry McVoy writes:
> 
> The rest of your story is great, just one small correction.  SunView started
> as something Sun specific but it pretty quickly became a library on top of
> X11.  I'm not sure if it ever worked on X10, I think it did but I'm not sure.
> 
> Source: I've hacked up GUI interfaces for the SCM I did at Sun in Sunview.
> This would have been around 1990, is that still X10 or X11?

Well, just to nitpick, I remember that much of SunView was a library but it
relied on special device drivers with complicated ioctls and such.  I don't
recall that it be easily separated from the OS.

BTW, on a historically amusing note, I still have two old Sun machines in the
basement, a SparcStation 20 and an Ultra-60.  The 20 has whatever graphics card
supported double-buffering.  It has a modified kernel thanks to some unnamed
(and unremembered at this point) soul who provided source code.  I hacked it so
that SunView ran in one of the buffers and X ran in the other.  Moving the mouse
off of the edge of the screen switched which buffer was displayed.  My answer to
being able to run both SunView and X.

> I sure did, love to meet you some time, where are you?

I live in Oregon, about 50 miles southwest of Portland.  I will probably be
in San Francisco the first full weekend of October for the Hardly Strictly
Bluegrass Festival if you're in the bay area.  Will be staying at Sun employee
#5's house.

Jon

[TUHS] X and NeWS history (long)

[Chris Torek]

>Well, just to nitpick, I remember that much of SunView was a library but it
>relied on special device drivers with complicated ioctls and such.  I don't
>recall that it be easily separated from the OS.

My (fuzzy) memory was that you called library routines to do
rasterops, and they consulted with the specific frame buffer
hardware in a way that, to (mis)quote Dennis Ritchie, had:

   unwarranted chumminess with the ... implementation

[see http://c-faq.com/struct/structhack.html for actual quote].

This meant if your rasterop was misbehaving, it could be a
bug in a driver, or in the hardware.

(I remember this from trying to chase down some weird rasterop
behavior, or some such.)

Chris

[TUHS] X and NeWS history (long)

[Adam Sampson]

Jon Steinhart <jon at fourwinds.com> writes:

> I think that I'm the only person to write an X server outside of the X
> Consortium.

When I was doing my PhD a few years ago, one of the case studies I used
was an X11 server that was written in occam 2 by Colin Willcock at the
University of Kent at Canterbury. I managed to recover Colin's source
code for the X server (in Transputer Development System format), which
is dated November 1988, from a very dusty machine backup...

I also found the sources for Colin's 1991 report to the funding body on
the completion of the project, and his 1992 PhD thesis which describes
the same work. I rebuilt these in 2010 using a modern version of TeX, so
the appearance is probably different from what Colin intended (and the
cover-page dates are definitely wrong), but they're quite readable:

https://stuff.offog.org/cw3-report-rebuilt.pdf
https://stuff.offog.org/cw3-thesis-rebuilt.pdf

Note in particular the motivation stated in the report: "The worst of
these problems was the MEiKO C compiler, which (by mid-1988) proved
incapable of making any significant headway when presented with the
public-domain X-sources. [...] After consultation with the project
monitoring officers at RAL, we took the decision to investigate the
prospects for a complete re-implementation of the X-server in occam 2,
making no use of the public domain C sources."

There have of course been other X server implementations more recently,
but they're less historically interesting!

-- 
Adam Sampson <ats at offog.org>                         <http://offog.org/>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Adam Sampson writes:
> Jon Steinhart <jon at fourwinds.com> writes:
> 
> > I think that I'm the only person to write an X server outside of the X
> > Consortium.
> 
> When I was doing my PhD a few years ago, one of the case studies I used
> was an X11 server that was written in occam 2 by Colin Willcock at the
> University of Kent at Canterbury. I managed to recover Colin's source
> code for the X server (in Transputer Development System format), which
> is dated November 1988, from a very dusty machine backup...
> 
> I also found the sources for Colin's 1991 report to the funding body on
> the completion of the project, and his 1992 PhD thesis which describes
> the same work. I rebuilt these in 2010 using a modern version of TeX, so
> the appearance is probably different from what Colin intended (and the
> cover-page dates are definitely wrong), but they're quite readable:
> 
> https://stuff.offog.org/cw3-report-rebuilt.pdf
> https://stuff.offog.org/cw3-thesis-rebuilt.pdf
> 
> Note in particular the motivation stated in the report: "The worst of
> these problems was the MEiKO C compiler, which (by mid-1988) proved
> incapable of making any significant headway when presented with the
> public-domain X-sources. [...] After consultation with the project
> monitoring officers at RAL, we took the decision to investigate the
> prospects for a complete re-implementation of the X-server in occam 2,
> making no use of the public domain C sources."
> 
> There have of course been other X server implementations more recently,
> but they're less historically interesting!

Cool, thanks for the info.  Based on the date, this was probably X10, not
X11.

[TUHS] old X versions (was:X and NeWS history)

[Christian Groessler]

On 09/13/17 02:14, Jon Steinhart wrote:
> Cool, thanks for the info.  Based on the date, this was probably X10, not
> X11.


Ever since I got in contact with X11 (around 92/93 with my first Linux 
and 386BSD installations), I was
wondering what happened to the previous versions.

You mention X10. Is there any documentation of source code of it available?

And what about X1 to X9?

regards,
chris

[TUHS] old X versions (was:X and NeWS history)

[Kurt H Maier]

On Wed, Sep 13, 2017 at 06:38:29PM +0200, Christian Groessler wrote:
> 
> You mention X10. Is there any documentation of source code of it available?

You can look at some X10 source here:
http://www.retro11.de/ouxr/43bsd/usr/src/new/X/

[TUHS] old X versions (was:X and NeWS history)

[Henry Bent]

On 13 September 2017 at 15:10, Kurt H Maier <khm at sciops.net> wrote:

> On Wed, Sep 13, 2017 at 06:38:29PM +0200, Christian Groessler wrote:
> >
> > You mention X10. Is there any documentation of source code of it
> available?
>
> You can look at some X10 source here:
> http://www.retro11.de/ouxr/43bsd/usr/src/new/X/
>
>
Full X10R3 and R4 source is still on x.org:

ftp://ftp.x.org/pub/X10R3/
ftp://ftp.x.org/pub/X10R4/

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/3c7b3752/attachment.html>

[TUHS] old X versions (was:X and NeWS history)

[Random832]

On Wed, Sep 13, 2017, at 12:38, Christian Groessler wrote:
> Ever since I got in contact with X11 (around 92/93 with my first Linux 
> and 386BSD installations), I was
> wondering what happened to the previous versions.
> 
> You mention X10. Is there any documentation of source code of it
> available?

X10R3 and R4 are available from xorg at https://www.x.org/releases/

[TUHS] old X versions (was:X and NeWS history)

[Nigel Williams]

Is the forerunner of X, I think called W? still around somewhere in source-form?

[TUHS] old X versions (was:X and NeWS history)

[Jon Steinhart]

Nigel Williams writes:
> Is the forerunner of X, I think called W? still around somewhere in source-form?

No clue.  Did a quick search and didn't find it.

[TUHS] old X versions (was:X and NeWS history)

[Gregg Levine]

Hello!
Wasn't the original project called "Athena", and wasn't it pursued by
one of the many Labs at MIT? I remember going over it in a big way
about the same time I started being an almost serious kernel hacker,
and that was while the kernel created by Linus was using BitKeeper as
its source control mechanism. This was around the turn of the century.

Oddly enough I also pursued and engaged a company who attempted to
combine an early X release with thier DOS based multitasking tool. The
discussion was rewarding, but it did not save the company.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart <jon at fourwinds.com> wrote:
> Nigel Williams writes:
>> Is the forerunner of X, I think called W? still around somewhere in source-form?
>
> No clue.  Did a quick search and didn't find it.

[TUHS] old X versions

[Chet Ramey]

On 9/19/17 11:16 AM, Gregg Levine wrote:
> Hello!
> Wasn't the original project called "Athena", and wasn't it pursued by
> one of the many Labs at MIT?

The athena project was indeed at MIT, and X was a part of that. This
would have been started and developed during the mid-1980s (1983, to be
exact).  X's predecessor was a window system named W, which was developed
at Stanford. Bob Scheifler used W as the basis for X.

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

[TUHS] old X versions

[Nemo]

On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
> On 9/19/17 11:16 AM, Gregg Levine wrote:
>> Hello!
>> Wasn't the original project called "Athena", and wasn't it pursued by
>> one of the many Labs at MIT?
>
> The athena project was indeed at MIT, and X was a part of that. This
> would have been started and developed during the mid-1980s (1983, to be
> exact).  X's predecessor was a window system named W, which was developed
> at Stanford. Bob Scheifler used W as the basis for X.

I vaguely recall (assuming no bit rot) that IBM was also involved and
they refused to release their portion under FRAND terms, leading Bob
to write X.

Anecodotes on W/X may be found in the delightful little book written
by Borenstein titled "Programming as if people mattered".

N.

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

[TUHS] old X versions

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Tue, Sep 19, 2017 at 2:23 PM, Nemo <cym224 at gmail.com> wrote:

>
> I vaguely recall (assuming no bit rot) that IBM was also involved and
> they refused to release their portion under FRAND terms, leading Bob
> to write X.


Right, I remember that was mixed up in it.   CMU (Andy "My hand is in your
pocket" Carnegie) was willing to abide by the IBM terms and MIT (Paul "You
gotta be kidding me" Gray) was not.   So IBM got the IP from Andrew, while
Athena was FOSS.​  IBM would eventually Open Source most of it.   But
originally, it was all private to them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/3788c1f5/attachment-0001.html>

[TUHS] old X versions

[Chet Ramey]

On 9/19/17 2:23 PM, Nemo wrote:
> On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
>> On 9/19/17 11:16 AM, Gregg Levine wrote:
>>> Hello!
>>> Wasn't the original project called "Athena", and wasn't it pursued by
>>> one of the many Labs at MIT?
>>
>> The athena project was indeed at MIT, and X was a part of that. This
>> would have been started and developed during the mid-1980s (1983, to be
>> exact).  X's predecessor was a window system named W, which was developed
>> at Stanford. Bob Scheifler used W as the basis for X.
> 
> I vaguely recall (assuming no bit rot) that IBM was also involved and
> they refused to release their portion under FRAND terms, leading Bob
> to write X.

As I understand it, Scheifler began with W, which Paul Asente and Chris
Kent had ported to Unix and given him a copy. He initially replaced its
synchronous protocol with an asynchronous one and went on from there.
I don't know whether IBM was involved with the V OS research, which was
where W came from, or resisted its public release, but Scheifler
certainly got a copy.

Jon Steinhart covered a little bit of this in a message to this list
last week.

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

[TUHS] old X versions

[Jon Steinhart]

Chet Ramey writes:
> On 9/19/17 2:23 PM, Nemo wrote:
> > On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
> >> On 9/19/17 11:16 AM, Gregg Levine wrote:
> >>> Hello!
> >>> Wasn't the original project called "Athena", and wasn't it pursued by
> >>> one of the many Labs at MIT?
> >>
> >> The athena project was indeed at MIT, and X was a part of that. This
> >> would have been started and developed during the mid-1980s (1983, to be
> >> exact).  X's predecessor was a window system named W, which was developed
> >> at Stanford. Bob Scheifler used W as the basis for X.
> > 
> > I vaguely recall (assuming no bit rot) that IBM was also involved and
> > they refused to release their portion under FRAND terms, leading Bob
> > to write X.
> 
> As I understand it, Scheifler began with W, which Paul Asente and Chris
> Kent had ported to Unix and given him a copy. He initially replaced its
> synchronous protocol with an asynchronous one and went on from there.
> I don't know whether IBM was involved with the V OS research, which was
> where W came from, or resisted its public release, but Scheifler
> certainly got a copy.
> 
> Jon Steinhart covered a little bit of this in a message to this list
> last week.

For what it's worth, I just looked in some old notebooks.  I have a number
of the V papers, and also some papers on VGTS which preceeded W.  I'm sure
that I have some of the W docs around somewhere but that'll take some more
hunting.

[TUHS] old X versions

[Chet Ramey]

On 9/19/17 2:32 PM, Chet Ramey wrote:
> On 9/19/17 2:23 PM, Nemo wrote:
>> On 19 September 2017 at 11:39, Chet Ramey <chet.ramey at case.edu> wrote:
>>> On 9/19/17 11:16 AM, Gregg Levine wrote:
>>>> Hello!
>>>> Wasn't the original project called "Athena", and wasn't it pursued by
>>>> one of the many Labs at MIT?
>>>
>>> The athena project was indeed at MIT, and X was a part of that. This
>>> would have been started and developed during the mid-1980s (1983, to be
>>> exact).  X's predecessor was a window system named W, which was developed
>>> at Stanford. Bob Scheifler used W as the basis for X.
>>
>> I vaguely recall (assuming no bit rot) that IBM was also involved and
>> they refused to release their portion under FRAND terms, leading Bob
>> to write X.
> 
> As I understand it, Scheifler began with W, which Paul Asente and Chris
> Kent had ported to Unix and given him a copy. He initially replaced its
> synchronous protocol with an asynchronous one and went on from there.

This is covered in one of the original Athena papers: The X Window System
by Scheifler and Gettys. I have the full set of "Project Athena: The First
Ten Years"; it's in volume 1. I think that paper was presented at a
couple of conferences, so there are probably copies floating around on the
net somewhere.

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

[TUHS] old X versions

[Stephen Kitt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 819 bytes --]

On Tue, 19 Sep 2017 14:43:59 -0400, Chet Ramey <chet.ramey at case.edu> wrote:
> On 9/19/17 2:32 PM, Chet Ramey wrote:
> > As I understand it, Scheifler began with W, which Paul Asente and Chris
> > Kent had ported to Unix and given him a copy. He initially replaced its
> > synchronous protocol with an asynchronous one and went on from there.  
> 
> This is covered in one of the original Athena papers: The X Window System
> by Scheifler and Gettys. I have the full set of "Project Athena: The First
> Ten Years"; it's in volume 1. I think that paper was presented at a
> couple of conferences, so there are probably copies floating around on the
> net somewhere.

E.g. in the ACM’s Digital Library: http://dl.acm.org/citation.cfm?id=24053
(from ACM Transactions on Graphics Volume 5 Issue 2).

Regards,

Stephen

[TUHS] old X versions (was:X and NeWS history)

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Tue, Sep 19, 2017 at 11:16 AM, Gregg Levine <gregg.drwho8 at gmail.com>
wrote:

>
> Wasn't the original project called "Athena", and wasn't it pursued by
> one of the many Labs at MIT?


​Greg - not quite right, although I can see how I might look that way from
the outside.   The Athena project was MIT's reaction to the CMU Andrew​
Project.  I'll not bring the somewhat humorous history but basic question
asked was simple... assume CMU succeeded in building the proposed 3M
'SPICE' system for Andrew.   MIT wanted to know: How would you deploy it?
Athena set out to figure that out...

It's interesting the two pieces of Athena that actually still live are X
and Kerberos where were developed as part of the Athena project.   I
understand why Kerberos and much of that tech was needed if you were going
to deploy hundreds of computers.   I don't remember the argument for
writing X - i.e. why it was needed, you'd have to ask Dan Geer (I've
forgotten).

FYI: In the case of Andrew, Mach and some of the AFS technology (and I've
heard some suggest it helped to move IBM into the doing RIOS which
eventually lead to Power/PC).

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/1a52929e/attachment-0001.html>

[TUHS] old X versions (was:X and NeWS history)

[Steve Nickolas]

On Tue, 19 Sep 2017, Gregg Levine wrote:

> Oddly enough I also pursued and engaged a company who attempted to
> combine an early X release with thier DOS based multitasking tool. The
> discussion was rewarding, but it did not save the company.

Sounds like DesQview/X?

-uso.

[TUHS] old X versions (was:X and NeWS history)

[Gregg Levine]

Hello!
Spot on. I've used it, and attempted to get it to work. Annoying thing
it is, is that it only sees Novell's IPX based networking.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 1:01 PM, Steve Nickolas <usotsuki at buric.co> wrote:
> On Tue, 19 Sep 2017, Gregg Levine wrote:
>
>> Oddly enough I also pursued and engaged a company who attempted to
>> combine an early X release with thier DOS based multitasking tool. The
>> discussion was rewarding, but it did not save the company.
>
>
> Sounds like DesQview/X?
>
> -uso.

[TUHS] old X versions (was:X and NeWS history)

[Derek Fawcus]

On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote:
> Hello!
> Spot on. I've used it, and attempted to get it to work. Annoying thing
> it is, is that it only sees Novell's IPX based networking.

That sounds... useless.

I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?).

Are you sure it isn't just ODI vs NDIS vs packet driver level stuff?

DF

[TUHS] old X versions

[Arthur Krewat]

On 9/19/2017 2:56 PM, Derek Fawcus wrote:
> On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote:
>> Hello!
>> Spot on. I've used it, and attempted to get it to work. Annoying thing
>> it is, is that it only sees Novell's IPX based networking.
> That sounds... useless.
>
> I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?).
>
> Are you sure it isn't just ODI vs NDIS vs packet driver level stuff?
>
> DF
>

http://www.cs.cmu.edu/afs/cs.cmu.edu/project/phrensy/pub/www/dvx/faq.txt

      To communicate with Unix machines, you must have a TCP/IP
      protocol stack that DESQview/X can communicate with. The
      following products are compatible:
           FTP's PCTCP
           HP/Lanman TCP/IP
           Novell's Lan Workplace for DOS
           PathWay Access (from The Wollongong Group Inc.)
           BW-TCP and BW-NFS (from Beame & Whiteside Software Ltd.)
           PC-NFS (from Sun Microsystems)

I remember playing around with it a long time ago - I think I used PC-NFS with it.

[TUHS] old X versions (was:X and NeWS history)

[Gregg Levine]

Hello!
Basically it was indeed looking for an ODI delivered stack for IPX, it
would further accept TCP/IP stacks, but it was an involved process.
Oddly enough its all freeware with one group claiming to have the
entire collection available free for download.

-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 2:56 PM, Derek Fawcus
<dfawcus+lists-tuhs at employees.org> wrote:
> On Tue, Sep 19, 2017 at 01:15:25PM -0400, Gregg Levine wrote:
>> Hello!
>> Spot on. I've used it, and attempted to get it to work. Annoying thing
>> it is, is that it only sees Novell's IPX based networking.
>
> That sounds... useless.
>
> I've got some vague memory of it being used on TCP/IP; and I wasn't even aware X ran over IPX (SPX?).
>
> Are you sure it isn't just ODI vs NDIS vs packet driver level stuff?
>
> DF

[TUHS] old X versions (was:X and NeWS history)

[Nemo]

On 19 September 2017 at 13:01, Steve Nickolas <usotsuki at buric.co> wrote:
> On Tue, 19 Sep 2017, Gregg Levine wrote:
>
>> Oddly enough I also pursued and engaged a company who attempted to
>> combine an early X release with thier DOS based multitasking tool. The
>> discussion was rewarding, but it did not save the company.
>
> Sounds like DesQview/X?

I used it but it still sat on top of DOS.  I downloaded their
GCC-based development tools and tried to build something  for X (from
X.org).  I invoked the makefile and then went to finish laying
subflooring in my living room, only to hear the PC rebooting in the
other room.  It turned out that many of the header-file names were
identical in the first 8 characters.  This led to recursive inclusion
until it blew.

N.


>
> -uso.

[TUHS] old X versions (was:X and NeWS history)

[Wesley Parish]

Quoting Gregg Levine <gregg.drwho8 at gmail.com>:

> Hello!
> Wasn't the original project called "Athena", and wasn't it pursued by
> one of the many Labs at MIT? I remember going over it in a big way
> about the same time I started being an almost serious kernel hacker,
> and that was while the kernel created by Linus was using BitKeeper as
> its source control mechanism. This was around the turn of the century.
> 
> Oddly enough I also pursued and engaged a company who attempted to
> combine an early X release with thier DOS based multitasking tool. The
> discussion was rewarding, but it did not save the company.

DeskView/X? I came across that in the early nineties and thought it sounded promising, but as I heard 
nothing more of it after a while I thought, they've gone under.

Wesley Parish

> -----
> Gregg C Levine gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
> 
> 
> On Tue, Sep 19, 2017 at 10:05 AM, Jon Steinhart <jon at fourwinds.com>
> wrote:
> > Nigel Williams writes:
> >> Is the forerunner of X, I think called W? still around somewhere in
> source-form?
> >
> > No clue. Did a quick search and didn't find it.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] old X versions

[Grant Taylor]

On 09/19/2017 05:40 PM, Wesley Parish wrote:
> DeskView/X? I came across that in the early nineties and thought as 
> I heard it sounded promising, but nothing more of it after a while
> I thought, they've gone under.

I ran across DeskView in the mid '90s too.  I occasionally thought about 
how it did graphics in MS-DOS but never really thought that much about it.

Since learning about DeskView's X11 (or 10?) server in the last few 
months, I'd like to get my hands on a copy to play with.  You know, for 
giggles.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/f85a5224/attachment-0001.bin>

[TUHS] old X versions

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

http://www.chsoft.com/dv.html

Or google it - it's all over the place.

On 9/19/2017 7:46 PM, Grant Taylor wrote:
> On 09/19/2017 05:40 PM, Wesley Parish wrote:
>> DeskView/X? I came across that in the early nineties and thought as I 
>> heard it sounded promising, but nothing more of it after a while
>> I thought, they've gone under.
>
> I ran across DeskView in the mid '90s too.  I occasionally thought 
> about how it did graphics in MS-DOS but never really thought that much 
> about it.
>
> Since learning about DeskView's X11 (or 10?) server in the last few 
> months, I'd like to get my hands on a copy to play with.  You know, 
> for giggles.
>
>
>

[TUHS] X and NeWS history (long)

[Bakul Shah]

> On Sep 12, 2017, at 3:11 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> 
> As
> a result, the X API is wide and shallow like the Mac, and full of interesting
> race conditions to boot.  The whole thing could have been done with less than
> a dozen API calls.


Unix still needs a decent graphics API (ideally one that can work over a network).
Any thoughts on that?

[TUHS] X and NeWS history (long)

[ron minnich]

On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote:

> Unix still needs a decent graphics API (ideally one that can work over a
> network).
>
>
does anyone know or care about network graphics any more? From what I can
tell, no.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/17a08332/attachment-0001.html>

[TUHS] X and NeWS history (long)

[Warner Losh]

On Tue, Sep 12, 2017 at 6:52 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com> wrote:
>
>> Unix still needs a decent graphics API (ideally one that can work over a
>> network).
>>
>>
> does anyone know or care about network graphics any more? From what I can
> tell, no.
>

I still use them all the time...  But maybe I'm a nobody...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/b3e4f3dd/attachment.html>

[TUHS] X and NeWS history (long)

[ron minnich]

On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> I still use them all the time...  But maybe I'm a nobody...
>
>
I know I am :-)

It's strange nowadays to try to explain network graphics to interns. I feel
like I'm giving them a tour of Jurassic Park. They like the idea once they
get it, but they have no particular use for it from what I can see. Why
does a phone need it? That's the determinant.

ron

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/c3212f7b/attachment.html>

[TUHS] X and NeWS history (long)

[Warner Losh]

On Tue, Sep 12, 2017 at 6:56 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Tue, Sep 12, 2017 at 5:54 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> I still use them all the time...  But maybe I'm a nobody...
>>
>>
> I know I am :-)
>
> It's strange nowadays to try to explain network graphics to interns. I
> feel like I'm giving them a tour of Jurassic Park. They like the idea once
> they get it, but they have no particular use for it from what I can see.
> Why does a phone need it? That's the determinant.
>

VNC to the phone is the best thing ever... But I like a real keyboard...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/c53d3688/attachment.html>

[TUHS] X and NeWS history (long)

[Kurt H Maier]

On Wed, Sep 13, 2017 at 12:56:26AM +0000, ron minnich wrote:
> Why does a phone need it? That's the determinant.
       
Apple and Google spend a hell of a lot of time syncing everyone's data
between phones, tablets, computers, surveillance platforms, and the
like.  Microsoft is making a lot of noise about jamming your phone into
your computer to do things in a consistent manner.  They call it
'convergence.'
       
In 2009 I could just ssh into my phone and launch its messaging program
from my desktop.  It worked the other way, too -- I could log into my
workstation from my phone.  We lost that when iOS and Android destroyed
all the competition.  
       
khm

[TUHS] X and NeWS history (long)

[ron minnich]

On Tue, Sep 12, 2017 at 7:06 PM Kurt H Maier <khm at sciops.net> wrote:

>
>
> In 2009 I could just ssh into my phone and launch its messaging program
> from my desktop.  It worked the other way, too -- I could log into my
> workstation from my phone.  We lost that when iOS and Android destroyed
> all the competition.
>


I don't disagree. I just think the knowledge of all that is lost, the same
way so much knowledge of unix is lost. That's why we have things like
systemd.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/50674af6/attachment.html>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

ron minnich writes:
> 
> I don't disagree. I just think the knowledge of all that is lost, the same
> way so much knowledge of unix is lost. That's why we have things like
> systemd.

It's amusing to me how many of the topics on this list I've included in
my book in process because I feel that they're important.

I look at the systemd problem slightly differently.  In short, I was
coming into work one night at BTL when Ken was heading out the door for
his sabbatical at UCB with a stack of mag tapes under his arm.  I see
that as a pivotal moment in computer history.  Students could learn from
an actual real computer system; they had source code access.  And, they
had the ability to modify and contribute to that code.  A lot of students
from that era went out to do great things.  Years later, the lower cost
of PCs resulted in students using them for their work.  Not only was MS-DOS
not as advanced a system as UNIX, but source code access was gone.  Students
had to learn from contrived projects, and didn't have the ability to play
with the guts of the operating system that they were using.  While there are
exceptions, I don't feel like students from the PC era are nearly as good.
While Linux has sort of brought us back to the golden age of source access
many of the people working on it are from the PC era and are trying to wedge
their Microsoft-nonsensibilities into Linux.  That's where things like
systemd come from.

Jon

[TUHS] X and NeWS history (long)

[Arthur Krewat]

On 9/12/2017 11:55 PM, Jon Steinhart wrote:
>
> I look at the systemd problem slightly differently.  In short, I was
> coming into work one night at BTL when Ken was heading out the door for
> his sabbatical at UCB with a stack of mag tapes under his arm.  I see
> that as a pivotal moment in computer history.  Students could learn from
> an actual real computer system; they had source code access.  And, they
> had the ability to modify and contribute to that code.  A lot of students
> from that era went out to do great things.  Years later, the lower cost
> of PCs resulted in students using them for their work.  Not only was MS-DOS
> not as advanced a system as UNIX, but source code access was gone.  Students
> had to learn from contrived projects, and didn't have the ability to play
> with the guts of the operating system that they were using.
Completely agree. To keep beating the dead horse, in high school we had 
access to a PDP-10, a KA10 running TOPS-10 5.06 - later they switched to 
4 KS10s running TOPS-10 6.03

I gained some notoriety as a hacker, and was tasked by the consulting 
firm that ran the things to build a "better" MIC (a batch scripting tool 
that allowed you to run things offline and go back later to look at the 
results). I had exploited the original DEC version to give me access to 
[1,2] ;)

Anyway, during that period, I was allowed to visit the installation, and 
if it was a weekend when students weren't on, to mount the "black" RP06 
pack that had all the TOPS-10 sources on it, and look at or print out 
anything I wanted (look or print, same thing, really, the access was via 
LA120). I learned a lot. Went on to work for the place for a few years.

Somewhere during that time, I was exposed to the IBM-PC and PCDOS. 
Except for my own projects in assembler, the IBM DOS and Technical 
Reference Manuals were all I had access to. HOWEVER - IBM in their 
infinite wisdom actually provided the sources to the BIOS in the manual. 
Still have that manual. That was awesome. I didn't have the DOS sources, 
but it wasn't hard to disassemble them with DEBUG and take a peak 
anyway. Back then, it was all written in assembler anyway, so it was 
only missing the symbols. Nothing was "out of reach".

Now, with C or C++, or worse, higher-level languages being the default 
choices, that optimize everything to death, it's hard to disassemble 
anything and really "see" what it's trying to accomplish, and how. Not 
impossible, I've done some reverse engineering of various OS's, but 
nothing spectacular.

For today's kids, well, it's a much different story. My son has a CS 
degree, but has almost no experience really peaking under the hood of 
any OS - some small ventures into kernels, but nothing huge like UNIX. 
Which brings me to another thing. Linux sources are freely available, 
and yet I don't see anyone really looking at them as an educational 
thing. I might be wrong, my experience in higher education is NONE.

[TUHS] X and NeWS history (long) [ really systemd, student access to real code ]

[Jon Steinhart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6000 bytes --]

Arthur Krewat writes:
> For today's kids, well, it's a much different story. My son has a CS 
> degree, but has almost no experience really peaking under the hood of 
> any OS - some small ventures into kernels, but nothing huge like UNIX. 
> Which brings me to another thing. Linux sources are freely available, 
> and yet I don't see anyone really looking at them as an educational 
> thing. I might be wrong, my experience in higher education is NONE.

I know kids who have poked at this stuff in college.  But, it opens a
whole 'nother can of worms.

UNIX was small.  One could actually understand it pretty easily.

Linux is huge.  I hate to say it, but it's gotten bloated.  And it
suffers from a problem with open source.  Don't get me wrong, I love
open source, but it's not perfect.

I'm worried that I'm going to come across as flogging my in-process book
too much on this list.  Not my intent, it's just that I've already
written stuff that addresses this topic.  Here's what I have to say on
it (this part hasn't been attacked by my editor yet).

It's way cool to me that I can run it through nroff and have it work!


            A Young Programmer’s Computer Primer

Open Source Software
 Open  source software is widely successful despite alarmist propaganda
 by some established closed‐source companies.1 A main advantage of open
 source  software  is  that many more eyeballs are available to look at
 the code which translates into  benefits  such  as  greater  security.
 Even  if  you  used  a closed source computer system there is a pretty
 good chance that you’re still using some open source components.

 The development of open source software was greatly  enhanced  by  the
 Internet  and  ‘‘cloud’’  services.   It’s trivial to find open source
 projects and to start your own.  But, and  this  is  a  big  but,  the
 majority of open source projects out there are garbage.

 A  lot  of  open  source  software comes from student projects.  Since
 they’re often first projects, the authors haven’t yet mastered the art
 of writing good code.  And, much of this software is unfinished as the
 student finished their class or graduated  or  just  moved  on.   It’s
 often  easier  to  rewrite  something  than  it is to decipher someone
 else’s poorly written and documented code.  This is  a  viscous  cycle
 because  the rewrite often doesn’t get done so there are multiple ver‐
 sions which don’t work in different ways.2  It’s  often  difficult  to
 determine  whether or not there is a good working version of something
 because there is so much litter.

 There is a belief that one of the advantages of open  source  software
 is  that  you can fix bugs that you find.  Unfortunately, much of this
 software is so poorly written and completely undocumented  making  the
 amount of effort required too great for a casual user.

 Just  because  something is open source doesn’t mean that it’s a great
 example of the craft.  But, you can learn what not to do just as  well
 as you can learn what to do from looking at other’s code.

 There  are two indicators, one positive and one negative, that you can
 use to help determine the quality of a piece of code.

 The positive indicator is whether or not a  project  is  under  active
 development3 with more than one contributor.   It  often  helps  if  a
 project  is  supported  by  some organization.  Many of the major open
 source projects originated  at  companies4  who  still  support  their
 development.   Others  have  been  donated by companies to foundations
 that support their development.  This often yields a consistent vision
 which  keeps  the  project on track.  This indicator is not completely
 reliable5 so take it with a grain of salt.

 The  negative indicator is the type and quantity of dialog that you’ll
 see at various programmer ‘‘self‐help’’ web sites.  If you see lots of
 ‘‘I  can’t  figure out how to make this work?’’ and ‘‘Where do I start
 to make this change?’’ questions then it’s probably not a great  piece
 of code.  Furthermore, if the responses are mostly useless non‐answers
 or snarky and unhelpful then the project probably lacks good  develop‐
 ers.   Developers who blame the questioner for their own lack of qual‐
 ity work are not good role models.  Of course, it’s also a bad sign if
 there are no comments or questions as it means that the code is proba‐
 bly not used.

 Cautionary tales aside, open source is a great thing.  Make your  code
 open  source when it makes sense to do so.  But first, learn how to do
 a good job so that your code becomes a good example to others.

 __________________________
  1 For example, Microsoft claimed that ‘‘Open source is  an  intel‐
    lectual  property  destroyer.   I  can’t  imagine something that
    could be worse than this for the software business and  the  in‐
    tellectual‐property  business’’  despite the fact that they were
    secretly using open source tools in‐house.

  2 I recently needed to extract tags from mp3 files and  tried  six
    different open‐source programs each of which failed in a differ‐
    ent way.

  3 This  doesn’t apply to projects that have been around for a long
    time and are actually ‘‘done’’.

  4 One must be careful of open source projects created at companies
    who are later acquired by companies with different philosophies.
    For example, Sun Microsystems was a prodigious developer of open
    source  software  including  OpenOffice,  Java,  and VirtualBox.
    However, Sun was acquired by Oracle who ended support  for  some
    of these projects and tried to find ways to control and monetize
    others; see the Oracle versus Google lawsuit for details.

  5 For example, the code base for the  firefox  web  browser  is  a
    poorly documented complete mess.


 Copyright © 2001‐2017 Jonathan E. Steinhart.  All Rights Reserved - Page 2

[TUHS] X and NeWS history (long)

[Arthur Krewat]

Try installing Oracle products on UNIX/Linux without X. Better yet, try 
doing it on a remote machine on the other side of the world.

While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help 
a lot, it's nice to be able to "ssh -X" to a remote machine and run that 
installer back to my local VNC server.

If I had a decent X windows implementation locally, I'd use that instead 
of VNC.

X had it's issues. But it's still alive and well - maybe because of Java ;)



On 9/12/2017 8:52 PM, ron minnich wrote:
>
>
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com 
> <mailto:bakul at bitblocks.com>> wrote:
>
>     Unix still needs a decent graphics API (ideally one that can work
>     over a network).
>
>
> does anyone know or care about network graphics any more? From what I 
> can tell, no.
>
> ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/7f00c728/attachment-0001.html>

[TUHS] X and NeWS history (long)

[Grant Taylor]

On 09/12/2017 07:42 PM, Arthur Krewat wrote:
> Try installing Oracle products on UNIX/Linux without X. Better yet, try 
> doing it on a remote machine on the other side of the world.

Ouch!  Doing it half way across the US was bad enough.  I'd hate to 
experience half way around the world.

> While KVMs like a Dell DRAC or Sun LOM, and virtualization consoles help 
> a lot, it's nice to be able to "ssh -X" to a remote machine and run that 
> installer back to my local VNC server.

(Don't forget the -Y to forward authentication. ;-)

I completely agree.

Also, I believe that graphic console has a completely different security 
exposure compared to allowing someone to use X remotely.  (Via ssh 
forwarding or more traditionally across the network.)

> If I had a decent X windows implementation locally, I'd use that instead 
> of VNC.

I actually ended up going the other way.  X11 is nice when it works. 
However, I found that I spent a LOT of time waiting on X11 to chat back 
and forth.  Comparatively VNC is (IMHO) a lot better at lower bandwidth 
and / or higher latency.

Also, running Xvnc (server) on the remote system allows you to 
(dis)connect the VNC client at will.  Same advantages as screen / tmux, 
but for X11.

> X had it's issues. But it's still alive and well - maybe because of Java ;)

I personally look fondly on the days when you could set the DISPLAY 
variable and launch your GUI application.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/f0e379c5/attachment.bin>

[TUHS] X and NeWS history (long)

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]


> On 2017, Sep 12, at 8:52 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> 
> 
> On Tue, Sep 12, 2017 at 5:30 PM Bakul Shah <bakul at bitblocks.com <mailto:bakul at bitblocks.com>> wrote:
> Unix still needs a decent graphics API (ideally one that can work over a network).
> 
> 
> does anyone know or care about network graphics any more? From what I can tell, no.
> 
> ron 

Well I do.  I’ve been looking at gigantic simulator trace files recently, and the graphics is far smaller than the underlying data.


-L

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/263b125a/attachment.html>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Bakul Shah writes:
> 
> Unix still needs a decent graphics API (ideally one that can work over a network).
> Any thoughts on that?

Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
as to why you think that it's important for it to work over a network.

Before you bite my head off for that question, I'm not suggesting that there's
no value in taking data from somewhere on a network and using it on a local
machine.

Back in the darker ages of the Green Flash (Tektronix storage tubes like the
4014) it was common to display remote data on a local system.  The data in
those days arrived via RS-232.  Depending on the application, one could shovel
4014 commands over the wire or just raw data and use a local program to generate
drawing commands.

I've never been convinced that the way that X did it made sense.  Sure, you'd
here people say things like "your remote Cray can draw stuff on your local
screen."  But it wasn't just that; using X your Cray also had to draw and
manage your user interface: scroll bars, buttons, and so on unless you wanted
to create a separate protocol so that you could run your user interface
locally and have it communicate with the remote application.  Of course, X was
enough of a pig that maybe using a Cray to drive a scroll bar made sense :-)

So before getting off into graphics APIs I think that it would be interesting
to hash this out.

BTW, one of the best things about NeWS was the fact that with a reasonable set
of conventions the user interface personality could live in the server and be
applied to all applications.  Contrast that with X where each application links
in a UI library, and if your screen looks anything like mine there isn't a lot
of consistency because different applications use different libraries.

One of the problems with NeWS was that this was so much fun to play with that
the people doing the work kept on coming up with new ideas faster than they
could implement the old ones so there was difficulty completing toolkit
projects.

Jon

[TUHS] X and NeWS history (long)

[Bakul Shah]

> On Sep 12, 2017, at 5:56 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> Bakul Shah writes:
>> 
>> Unix still needs a decent graphics API (ideally one that can work over a network).
>> Any thoughts on that?
> 
> Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
> as to why you think that it's important for it to work over a network.

Heavy number crunching generating some data for display may be far
from the one displaying the data.

[sensor input | storage] => [computation} <=> [display/user input]

> Before you bite my head off for that question, I'm not suggesting that there's
> no value in taking data from somewhere on a network and using it on a local
> machine.
...
> So before getting off into graphics APIs I think that it would be interesting
> to hash this out.

Indeed. The question really is where in the pipeline from gobs 
of raw data to number crunching transformations to display
does the network split lie.  In a sense we already have a
split (GPU vs CPU) but it is highly specialized.
 
Camera, mouse, graphics tablet, keyboard, other sensor inputs 
will be (or should be) near the display but may be processed far
away in an application specific manner.
 
I suspect here too we may go through Sutherland's wheel of 
reincarnation.  We can offload more GUI processing in the
server but as GUI becomes more sophisticated (or complicated),
it will feel slow.
 
I can envision using a RaspberryPi as a "graphics processor"
but we still need a protocol between the 'Pi and the
"backend". If done right, I wouldn't want to touch the innards
of the s/w running on the 'Pi when writing a game or something
needing visualization.

> BTW, one of the best things about NeWS was the fact that with a reasonable set
> of conventions the user interface personality could live in the server and be
> applied to all applications.  Contrast that with X where each application links
> in a UI library, and if your screen looks anything like mine there isn't a lot
> of consistency because different applications use different libraries.

[TUHS] X and NeWS history (long)

[Grant Taylor]

On 09/12/2017 06:56 PM, Jon Steinhart wrote:
> Wow, big topic.  Rather than getting into it in detail at the moment I'm curious
> as to why you think that it's important for it to work over a network.

I personally really like the ability to SSH to a machine (*) using -XY 
and run Oracle's installer such that it's display shows up on my notebook.

I find that SO MUCH EASIER than trying to get the iDRAC / RSA / IMM / 
etc to work.  Usually they require multiple ports and protocols (often 
UDP, which is a pain through SSH).

For me, X11 forwarding just works.  -  Thank you to everyone that spent 
so much time and energy getting it to work.

> Before you bite my head off for that question, I'm not suggesting that there's
> no value in taking data from somewhere on a network and using it on a local
> machine.

I think there's a distinct and large difference in data and display I/O.

> Back in the darker ages of the Green Flash (Tektronix storage tubes like the
> 4014) it was common to display remote data on a local system.  The data in
> those days arrived via RS-232.  Depending on the application, one could shovel
> 4014 commands over the wire or just raw data and use a local program to generate
> drawing commands.

I've often contemplated SIXEL graphics in an error prompt from remote 
systems.  (This is a different topic, which itself relies on answer back.)

> I've never been convinced that the way that X did it made sense.  Sure, you'd
> here people say things like "your remote Cray can draw stuff on your local
> screen."  But it wasn't just that; using X your Cray also had to draw and
> manage your user interface: scroll bars, buttons, and so on unless you wanted
> to create a separate protocol so that you could run your user interface
> locally and have it communicate with the remote application.  Of course, X was
> enough of a pig that maybe using a Cray to drive a scroll bar made sense :-)

Maybe I'm a n00b and don't know better, but I'd think that would be a 
use case for nested X running on a local (closer than the Cray) machine. 
  So all the Cray needed to do was to send program I/O to the (nested) X 
server.  Then the (nested) X server could handle scroll bars and other 
local window manager eye candy.

I think the Cray would run something much like X does if you aren't 
running a window manager.  Simple, single application, no frills.

I think.

> So before getting off into graphics APIs I think that it would be interesting
> to hash this out.
> 
> BTW, one of the best things about NeWS was the fact that with a reasonable set
> of conventions the user interface personality could live in the server and be
> applied to all applications.  Contrast that with X where each application links
> in a UI library, and if your screen looks anything like mine there isn't a lot
> of consistency because different applications use different libraries.
> 
> One of the problems with NeWS was that this was so much fun to play with that
> the people doing the work kept on coming up with new ideas faster than they
> could implement the old ones so there was difficulty completing toolkit
> projects.

LOL

Feeping Creatureism?



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/2e26e6b3/attachment-0001.bin>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Grant Taylor writes:
> I personally really like the ability to SSH to a machine (*) using -XY 
> and run Oracle's installer such that it's display shows up on my notebook.

Well, I agree that this is one area in which X does OK.

Although, being a command line sort of guy, I'm happy to ssh into a machine
and run commands.  I try to avoid non-scriptable GUIs.

I don't administer headless machines, and stay very far away from Oracle.
I'm not sure what their installer does, but usually running X requires an
installed and running system.

So since a number of people have justified networked graphics we're back
to the question of what an API should look like.  At a very high level,
it needs to be modular because there is no one thing that gets done with
graphics, and there's no reason to carry a huge API around just because
you need a small part of it.  In particular, there is a distinction
between applications that spit out geometry and those that spit out mass
quantities of pixel/voxel data.

Also, because of the way that this discussion started, I'm not sure whether
or not resource management (windows, keyboard, etc.) falls under the
umbrella of graphics.

Jon

[TUHS] X and NeWS history (long)

[Grant Taylor]

On 09/12/2017 09:01 PM, Jon Steinhart wrote:
> Well, I agree that this is one area in which X does OK.

I also like how X will allow me to have windows from remote programs 
mixed with local programs and does not require a full desktop.  (A 
feature that RDP has gotten in the last 10 ? years.)

> Although, being a command line sort of guy, I'm happy to ssh into a machine 
> and run commands.  I try to avoid non-scriptable GUIs.

I completely agree.

> I don't administer headless machines, and stay very far away from Oracle. 
>  I'm not sure what their installer does, but usually running X requires an 
> installed and running system.

Sadly my use case what proving to a ... questionable DBA that things 
could work as directed, despite his objections the other way.

Since I was not familiar with Oracle RAC and Oracle DB, I needed to go 
the front door route, taking screen shots and documenting each and 
everything I did.  (Partially for political reasons.)

Yes, you do need an installed (base) OS with some dependencies. 
Thankfully you don't need a full window manager or the bloat that comes 
with things like Gnome / KDE.

> So since a number of people have justified networked graphics we're back 
> to the question of what an API should look like.  At a very high level, 
> it needs to be modular because there is no one thing that gets done with 
> graphics, and there's no reason to carry a huge API around just because 
> you need a small part of it.  In particular, there is a distinction 
> between applications that spit out geometry and those that spit out mass 
> quantities of pixel/voxel data.

"voxel"?  I'll have to look that up.

> Also, because of the way that this discussion started, I'm not sure whether 
> or not resource management (windows, keyboard, etc.) falls under the 
> umbrella of graphics.

I expect that they should be included in such discussions.  After all, 
they are intimately related.  GUI applications are of questionable value 
if you can't interact with them.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/01b07472/attachment.bin>

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Grant Taylor writes:
> "voxel"?  I'll have to look that up.

I'll save you the trouble.  3D.  Volume equivalent of a pixel.

[TUHS] X and NeWS history (long)

[Tony Finch]

A couple of NeWS-related links which I saved back in March:

A book / conference report surveying the state of Window Management in
1985, specifically the chapter on an early version of NeWS:

http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm

The amazing NeFS, the Network Extensible File System, which was supposed
to be version 3 of NFS, based on in-kernel PostScript.

Thankfully it died :-)

http://www.donhopkins.com/home/nfs3_0.pdf

Last year, an appreciation of NeWS written from a modern perspective,
including some comparisons with the JS / HTML / CSS / SVG web:

https://medium.com/@slavapestov/yesterdays-news-c52f2be95205

Finally, a question: is there a good comparison of NeWS vs NeXT Display
Postscript anywhere?

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Dogger: North or northwest 6 to gale 8, increasing severe gale 9 or storm 10
at first. Moderate or rough, occasionally very rough at first. Rain or
thundery showers. Good, occasionally poor.

[TUHS] X and NeWS history (long)

[Jon Steinhart]

Tony Finch writes:
> Finally, a question: is there a good comparison of NeWS vs NeXT Display
> Postscript anywhere?

Not that I'm aware of.  The main difference was in the name; Display
Postscipt just displayed Postscript; it's what NeXT used for higher
quality rendering.  NeWS was a window management system that included
Postscript graphics.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Dave Horsfall]

On Tue, 12 Sep 2017, Arthur Krewat wrote:

> Oh, do, please go on ;)
>
> On 9/12/2017 11:35 AM, Jon Steinhart wrote:
>> As the guy who single-handedly prevented X from becoming an ANSI 
>> standard, I'd be happy to start another thread on this topic if people 
>> are interested.

Seconded...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4979 bytes --]

Funny.  From the outside I had a rather different view of why Sun was
successful.

In 1986 I came to CA to work for what became Ardent/Stardent.  We
made the decision to go with Sun disc-less workstations.  They got us
more computing power, on paper, for less $$.

Roughly a quarter of the machines shipped to us were DOA.  When we
got them running, the OS had a memory leak and needed to be rebooted
several times a day.  The NFS server had the delightful property of
sometimes inserting 1024 zeros into a file it was writing or
serving.    (It was so bad that we hacked the OS to check every
executable for 0-blocks in the instruction space and refuse to run
it.  This was especially true for the MIPS cross compiler -- 0 was a
NOP on the MIPS, and encountering a block of zeros caused execution to
slide down a slippery slope of NOPs into the middle of some other
routine with a different stack layout, where it proceeded to do the
most mysterious things...)

We would go out to lunch every day and trash talk Sun up one side and
down the other.  And then we would go back to work and order more
Suns.  Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
GIVE IT TO US.  The other manufacturers were selling application
delivery vehicles rather than attempting to support software
development.  Eventually we ironed out many of the issues (often by
changing or hacking the code).  The only fly in the ointment was the
service department.  Dealing with Sun customer service was like
spitting into the wind.  We would report the same bug every week and
they swore the bug had not been reported before.  The memory leak
problem became so serious that we told them that we would only renew
the service agreement if they would put a date when that would be
fixed.  They refused to do so, and we canceled the service contract,
bought a couple of extra Suns for spares, and heaved a sigh of relief.

Steve

----- Original Message -----
From: "Jon Steinhart" <jon@fourwinds.com>
To:<tuhs at tuhs.org>
Cc:
Sent:Tue, 12 Sep 2017 08:35:24 -0700
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
dec/apollo --> X and NeWS ]

 arnold at skeeve.com writes:
 > 
 > In particular, the creation of NFS and then the efforts to make it
into
 > a de-facto standard (giving away the RPC and XDR code) was a HUGE
thing.
 > 
 > They weren't afraid to swim upstream, either. Even though NeWS
never took
 > off (even when combined with an X server), it was an interesting
design,
 > ahead of its time even.

 It's interesting that you mention the two of these together. It's my
 opinion that the main reason that NeWS failed was because of the
success
 of NFS.

 I recall that Apollo was really pissed off by NFS because they felt
that
 their token-ring network was better but lost because NFS was given
away.
 In hindsight, they were wrong; while the token-ring performed better
in
 large networks, the advent of switches made that moot. In any case,
when
 NeWS was released nobody except Sun knew how to do the graphics (even
 Adobe didn't know how to do it fast for display) and Apollo et. al.
was
 worried that Sun would give NeWS away and make it yet another de
facto
 standard a la NFS. This led to the formation of the Hamilton Group
which
 was a thinly-disguised industry consortium that existed only for the
 purpose of making sure that NeWS didn't succeed.

 > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun
for
 > many years.

 I mentioned this to a lot of people after Sun died. Few seem to
realize
 how much of what became PC manufacturing technology resulted from
innovations
 at Sun.

 ron at ronnatalie.com writes:
 >
 > NeWS had serious issues. However, the same guy who was the NeWS
proponent
 > learned from mistakes and the result was the must more successful
Sun
 > tehnology: JAVA.

 I'm going to take issue with the above. NeWS had way fewer serious
issues
 than X. It's main reason for failure was the coordinated effort to
kill it
 from others in the industry. As the guy who single-handedly prevented
X
 from becoming an ANSI standard, I'd be happy to start another thread
on
 this topic if people are interested. Part of the result of the
Hamilton
 Group effort was the misguided attempt to merge X and NeWS which was
a
 botched disaster.

 Java is not the result of learning from mistakes in NeWS. I have
joked with
 James that I feel that his legacy is being the person who first
realizes that
 technology is changing to the point where something can be done using
an
 interpreter. If you look at his project history, he's done this many
times.
 I think that it's more accurate to say that Java is the result of a
lifetime
 of learning from interpreter projects. I fully expect some new
interpreter
 to take over AWS sometime soon :-)

 Jon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170912/5d44e60c/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 12, 2017 at 01:15:43PM -0700, Steve Johnson wrote:
> We would go out to lunch every day and trash talk Sun up one side and
> down the other.?? And then we would go back to work and order more
> Suns.?? Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
> GIVE IT TO US.?? 

I love this.  I was one of those guys trying to give you what you wanted.
I did POSIX conformance in SunOS and as part of that I wrote lint
libraries for 4x BSD, SunOS, Sys V, etc.  I made it so you could use a
Sun machine as your dev environment but target other operating systems,
lint could tell you if you were using a Sun thing that didn't work on
$OS.

I had a huge blowup with Gingell (a high ranking Sun engineer, he had
some fancy title that made him like a VP) over this.  The libraries
added 40KB to the install image and he didn't like that.  I told him if
you don't ship this I quit.  He shipped it.

The details aside, that story supports your view that we wanted
to help you.  We were developers and we wanted to help developers.
And it worked.  Back at that time every open source (or closed source but
sent around) project had makefiles that "just worked" on Sun machines.
MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
It just worked.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Nemo]

On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> And it worked.  Back at that time every open source (or closed source but
> sent around) project had makefiles that "just worked" on Sun machines.
> MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> It just worked.

Oh, I nearly wept when I read this.  Building a typical project
nowadays is so painful -- the makefile works on one particular Linux
distro and woe betide the rest.

N.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Henry Bent]

On 13 September 2017 at 20:53, Nemo <cym224 at gmail.com> wrote:

> On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> > And it worked.  Back at that time every open source (or closed source but
> > sent around) project had makefiles that "just worked" on Sun machines.
> > MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> > It just worked.
>
> Oh, I nearly wept when I read this.  Building a typical project
> nowadays is so painful -- the makefile works on one particular Linux
> distro and woe betide the rest.
>
> N.
>

Henry Spencer's final commandment, as preserved at
https://www.lysator.liu.se/c/ten-commandments.html , seems particularly apt
here.

Even now, in the days of configure scripts and their ilk, if your code
blindly assumes that a "common" function will be present then it is
destined to fail somewhere.

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/6db1ff44/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Wed, Sep 13, 2017 at 08:53:07PM -0400, Nemo wrote:
> On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> > And it worked.  Back at that time every open source (or closed source but
> > sent around) project had makefiles that "just worked" on Sun machines.
> > MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> > It just worked.
> 
> Oh, I nearly wept when I read this.  Building a typical project
> nowadays is so painful -- the makefile works on one particular Linux
> distro and woe betide the rest.

I tend to just use Debian and Debian derived releases and stuff works for
me.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Rico Pajarola]

On Thu, Sep 14, 2017 at 2:53 AM, Nemo <cym224 at gmail.com> wrote:

> On 12/09/2017, Larry McVoy <lm at mcvoy.com> wrote (in part):
> > And it worked.  Back at that time every open source (or closed source but
> > sent around) project had makefiles that "just worked" on Sun machines.
> > MIPS?  Well that's IRIX, yeah, you need to do this or that.  On a Sun?
> > It just worked.
>
> Oh, I nearly wept when I read this.  Building a typical project
> nowadays is so painful -- the makefile works on one particular Linux
> distro and woe betide the rest.
>
I also wept a bit when reading this. I once built gnome from source (don't
ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned
how to use "autoconf" and "libtool" as swearwords...

But on modern Linux? That's not my experience. Maybe we just have different
standards for "just works", but a typical "modern" open source project
nowadays "just works" (for my definition of just works) on pretty much any
modern system including FreeBSD (type: ./configure; make && make install).


> N.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/69d2b950/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[arnold]

Rico Pajarola <rp at servium.ch> wrote:

> I also wept a bit when reading this. I once built gnome from source (don't
> ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned
> how to use "autoconf" and "libtool" as swearwords...

Libtool for sure. Autoconf is something you have to come to a negotiated
truce with and then it's OK. :-)

> But on modern Linux? That's not my experience. Maybe we just have different
> standards for "just works", but a typical "modern" open source project
> nowadays "just works" (for my definition of just works) on pretty much any
> modern system including FreeBSD (type: ./configure; make && make install).

Like anything else, it depends on the quality, knowledge, and experience
of the developers.  The problem isn't really the Autotools as much as
inexperienced developers who don't understand that all the world is not
Linux and who thus feel free to assume way too many things.

We just went through the exercise of building the latest libpcap for
Linux, Solaris, AIX and HP-UX.  Nightmarish, due to dependency upon
flex, which in turn took an act of Congress in order to get it to build,
particularly on AIX, but also not so easy on the others.

OTOH, the older GNU projects, with experienced developers (gawk, Bash)
don't exhibit such issues.

My two cents (as one of those battle-scarred developers :-)

Arnold

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Rico Pajarola]

On Thu, Sep 14, 2017 at 1:11 PM, <arnold at skeeve.com> wrote:

> Rico Pajarola <rp at servium.ch> wrote:
> > But on modern Linux? That's not my experience. Maybe we just have
> different
> > standards for "just works", but a typical "modern" open source project
> > nowadays "just works" (for my definition of just works) on pretty much
> any
> > modern system including FreeBSD (type: ./configure; make && make
> install).
>
> Like anything else, it depends on the quality, knowledge, and experience
> of the developers.  The problem isn't really the Autotools as much as
> inexperienced developers who don't understand that all the world is not
> Linux and who thus feel free to assume way too many things.
>
> We just went through the exercise of building the latest libpcap for
> Linux, Solaris, AIX and HP-UX.  Nightmarish, due to dependency upon
> flex, which in turn took an act of Congress in order to get it to build,
> particularly on AIX, but also not so easy on the others.
>
> OTOH, the older GNU projects, with experienced developers (gawk, Bash)
> don't exhibit such issues.
>
True, I'm amazed every time I try a really old version of some old GNU
software like bash 1.0 on a contemporary (but unusual) OS. No errors, no
warnings, nothing to fix-up manually. It just works.

My two cents (as one of those battle-scarred developers :-)
>
;)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/9f73e264/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Chet Ramey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On 9/14/17 8:13 AM, Rico Pajarola wrote:

> True, I'm amazed every time I try a really old version of some old GNU
> software like bash 1.0 on a contemporary (but unusual) OS. No errors, no
> warnings, nothing to fix-up manually. It just works.

If you have a version of bash-1.0, send it my way. We weren't quite as
careful with preserving milestone software versions in those days.

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

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Rico Pajarola]

On Thu, Sep 14, 2017 at 2:50 PM, Chet Ramey <chet.ramey at case.edu> wrote:

> On 9/14/17 8:13 AM, Rico Pajarola wrote:
>
> > True, I'm amazed every time I try a really old version of some old GNU
> > software like bash 1.0 on a contemporary (but unusual) OS. No errors, no
> > warnings, nothing to fix-up manually. It just works.
>
> If you have a version of bash-1.0, send it my way. We weren't quite as
> careful with preserving milestone software versions in those days.
>
it wasn't *exactly* 1.0

The oldest version I can find with by running "locate bash-1.0" on my
datagrave is version 1.05.

Do you keep an archive of old software somewhere? I spend a lot of time
hunting down old versions of 90'ies era software, but it's becoming
increasingly frustrating due to ftp services being turned down, especially
at universities.



> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~
> chet/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bec7c4a3/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Chet Ramey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

On 9/14/17 9:27 AM, Rico Pajarola wrote:

>     If you have a version of bash-1.0, send it my way. We weren't quite as
>     careful with preserving milestone software versions in those days.
> 
> it wasn't *exactly* 1.0 
> 
> The oldest version I can find with by running "locate bash-1.0" on my
> datagrave is version 1.05.

I have 1.05; it's the oldest version I have ever found.

> Do you keep an archive of old software somewhere? I spend a lot of time
> hunting down old versions of 90'ies era software, but it's becoming
> increasingly frustrating due to ftp services being turned down, especially
> at universities.

I'm only interested in old versions of bash, sorry. I don't really keep an
extensive collection of old software available (though I believe I have the
only ftp-available version of the original ash sources).

Chet

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

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steffen Nurpmeso]

arnold at skeeve.com wrote:
 |Rico Pajarola <rp at servium.ch> wrote:
 |
 |> I also wept a bit when reading this. I once built gnome from source (don't
 |> ask why), on Solaris, IRIX, and HP-UX. That was also the month I learned
 |> how to use "autoconf" and "libtool" as swearwords...
 |
 |Libtool for sure. Autoconf is something you have to come to a negotiated
 |truce with and then it's OK. :-)

I cannot seem to reach that state.  I see that the m4 directory of
gawk v4.1.4 contains no less than 46 files with a total of 312 KB.
On top of that the root directory contains some configure related
files which sum up to about 500 KB.
I do not know how much manual work was necessary for the files in
m4, as i never have used autotools (except for a week or so doing
something -- now obsolete -- for groff, there m4/groff.m4 is about
50 KB and handcraft).  And when i look into the missing_d of gawk
i cannot help to wonder what all that is for.

But of course, what is the alternative?  My MUA has a handcrafted
75 KB config shell script but the make system no longer could
install: on e.g. UnixWare v7.1.4 because of problems of the system
make last time i tried (we could outsource that as a shell script
and simply invoke that though), it does not work on the Solaris 9
i have access to (via OpenCSW.org) because we cannot work around
a SIZE_MAX iirc that is only defined but to nothing etc. etc. etc.

 |> But on modern Linux? That's not my experience. Maybe we just have \
 |> different
 |> standards for "just works", but a typical "modern" open source project
 |> nowadays "just works" (for my definition of just works) on pretty much any
 |> modern system including FreeBSD (type: ./configure; make && make install).
 |
 |Like anything else, it depends on the quality, knowledge, and experience
 |of the developers.  The problem isn't really the Autotools as much as
 |inexperienced developers who don't understand that all the world is not
 |Linux and who thus feel free to assume way too many things.
 |
 |We just went through the exercise of building the latest libpcap for
 |Linux, Solaris, AIX and HP-UX.  Nightmarish, due to dependency upon
 |flex, which in turn took an act of Congress in order to get it to build,
 |particularly on AIX, but also not so easy on the others.
 |
 |OTOH, the older GNU projects, with experienced developers (gawk, Bash)
 |don't exhibit such issues.

Plan9 shows an impressive beauty regarding this topic, but it, of
course, is exclusive to a current Plan9.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[arnold]

Definitely getting off-topic here ...

Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

>  |Libtool for sure. Autoconf is something you have to come to a negotiated
>  |truce with and then it's OK. :-)
>
> I cannot seem to reach that state.  I see that the m4 directory of
> gawk v4.1.4 contains no less than 46 files with a total of 312 KB.
> On top of that the root directory contains some configure related
> files which sum up to about 500 KB.

Gawk is light-weight compared to most projects that use gnulib (e.g,
grep).  Much of what you point out is boilerplate placed there by
the autotools.  The only file(s) I, as a developer, have to mess with
are the configure.ac files.

> I do not know how much manual work was necessary for the files in
> m4,

Once it's set up, you just ignore it, and update the files whenever
there's a new autoconf / automake / gettext / libtool release.

I've been using autoconf since 1.x days, so I'm very used to it.
I also find it to be much less aggravation than CMake-based projects,
where if something craps out during the cmake run, you essentially
must wipe out the directory and re-extract the tarball to start over.

>  And when i look into the missing_d of gawk
> i cannot help to wonder what all that is for.

Much of it is probably obsolete. Some things date back to the days
when some systems had strchr() and others had index()...

> But of course, what is the alternative?

I don't see one. CMake doesn't really cut it for me.  For make
problems, port GNU Make; it's very portable, since it's one of the
base items for many GNU projects.

I know it runs on Solaris 9.

> Plan9 shows an impressive beauty regarding this topic, but it, of
> course, is exclusive to a current Plan9.

No arguments there, but unfortunately, Plan 9 is a very self-contained
sandbox.  Few of us get to live there all the time.

Arnold

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Jon Steinhart]

OK, not gonna splice in all of the things to which I'm responding.

I don't have much love for the libtool/autoconf/automake/etc. system.
While it works, and is better than nothing, I have always felt that
it was the wrong approach.  I am fortunate that I know some of the
folks who worked on these tools because they're part of the too complex
for casual users thing that I mentioned in my earlier post about open
source.

I worked for a startup in 1985 that produced CAD tools that needed to
run on the various workstations of the era: Daisy, Apollo, Sun, etc.

When I started at the company, they would hire a new person to do a port
whenever we needed to support a new system.  I changed that so that it
took someone at most a few hours to do a port.

The way that I did this was to have a portability libarary and header file
for each target system.  We wrote our code for SunOS with the minor difference
that each library or system call had a p_ prefix, i.e., p_fopen and so on.
The portability library and header mapped each of these into the target
system facilities.  In most cases this was done by a macro in the header
file that just defined p_fopen to be fopen and so on.  In the harder cases
we had to write actual code to do some translation.  I have a faint memory
that Apollo had some different arguments to fopen, and at least one of the
systems either used carriage return as a line terminator or maybe used CF-LF.

There are two big advantages to handling portability this way.  First, the
source code is easier to read; it's not full of #ifdef this and #ifndef that.
Second, once the portability library existed it just worked and could be
reused.  With the GNU tools methodology, every time someone needed to do a
fopen on a machine where the target behaved differently, the alternate code
needed to be written.  There was no debugged library where this stuff only
had to be figured out once.

Just my $.02.

Jon

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Ron Natalie]

Autoconf didn't originate with Gnu.   It was around longer than that
(someone can probably remember, but I remember some of the netnews software
using it long before RMS or LINUX got going).
I always havd a lot of distatste for it.     I worked on portable software
as well, everything form Unipress EMACS to BRL CAD to my own software
products (we ran on, let me see if I can recall:   SUN both Solaris and the
old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various
levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the
80x86 in many flavors, Intergraph 32032, Intergraph Clipper...

We were always able to disttill the portability information into a single
set of include files, one conf.h and one included for each platform.    Most
of the grief came from people with various ideas on how to do 64 bit seeks
and of all things (thankfully we got away from this) stty/ioctl.

I never had to resort to a script to set things up.   Reading down through
conf.h told me what my options were and it didn't take long to set things
up.

I also ported/wrote X11 servers for four or five systems (including writing
my own CFB24 before MIT released theres).    iMake worked pretty well,
though since it relied on the C prepropcessor and the exacxt format of the C
preprocessor output really isn't defined for white space, it sometimes was a
problem.    Eventually, we picked up CMAKE though I don't particularly like
that one either.

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Chris Torek]

>Autoconf didn't originate with Gnu.   It was around longer than that
>(someone can probably remember, but I remember some of the netnews software
>using it long before RMS or LINUX got going).

It was not autoconf itself, but Larry Wall's configure scripts
were probably an (or "the") inspiration.

"Congratulations!  You're not running Eunice."

Chris

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Ron Natalie]

Years ago, I was building an RSX-11M system and it had a rather intricate
setup script.    At one point it announced:

"This will take a while.   Go have a cup of coffee."

And I useually did.   Then one day I was building a machine in another lab
and it said:

"This will take a while.   Go have a cup of tea."

OK, I had to dig into the script to figure it out.   Turns out the beverage
selection was dependent on  the configured line frequency.   The lab system
was built for European deployment (50HZ power).

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Grant Taylor]

On 09/14/2017 03:03 PM, Ron Natalie wrote:
> Years ago, I was building an RSX-11M system and it had a rather intricate
> setup script.    At one point it announced:
> 
> "This will take a while.   Go have a cup of coffee."
> 
> And I useually did.   Then one day I was building a machine in another lab
> and it said:
> 
> "This will take a while.   Go have a cup of tea."
> 
> OK, I had to dig into the script to figure it out.   Turns out the beverage
> selection was dependent on  the configured line frequency.   The lab system
> was built for European deployment (50HZ power).

LOL

I love the humor that I see in unix programs.

I still love to parrot "tar is cowardly refusing to create an empty 
archive" to people.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/6e123c79/attachment-0001.bin>

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Larry McVoy]

On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote:
> "Congratulations!  You're not running Eunice."

Heh, I remember that :)  And I ran on Eunice back in the day.

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Warner Losh]

On Fri, Sep 15, 2017 at 9:34 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Sep 14, 2017 at 02:00:05PM -0700, Chris Torek wrote:
> > "Congratulations!  You're not running Eunice."
>
> Heh, I remember that :)  And I ran on Eunice back in the day.
>

That was a complicated world with the whole TGV vs TWG dueling licenses for
TCP on VMS...

And despite all that, I never actually ran anything on Eunice...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/432c3ff2/attachment.html>

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Dave Horsfall]

On Fri, 15 Sep 2017, Larry McVoy wrote:

>> "Congratulations!  You're not running Eunice."
>
> Heh, I remember that :)  And I ran on Eunice back in the day.

I resemble that remark :-)  I used to tell a boss that Eunice made VMS 
look civilised, and he growled back "No, it makes it look like Unix."

But that's what I said :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Larry McVoy]

+1.  BitKeeper runs on a ton of platforms and we have no love nor no
need for autoconf.  

On Thu, Sep 14, 2017 at 04:32:41PM -0400, Ron Natalie wrote:
> Autoconf didn't originate with Gnu.   It was around longer than that
> (someone can probably remember, but I remember some of the netnews software
> using it long before RMS or LINUX got going).
> I always havd a lot of distatste for it.     I worked on portable software
> as well, everything form Unipress EMACS to BRL CAD to my own software
> products (we ran on, let me see if I can recall:   SUN both Solaris and the
> old SunOS4, Stellar, Ardent, HP (both architectures), Apollo, SGI (various
> levels), DEC MIPS, DEC ALPHA, RS6000, iTanium, i8t0 (several flavors), the
> 80x86 in many flavors, Intergraph 32032, Intergraph Clipper...
> 
> We were always able to disttill the portability information into a single
> set of include files, one conf.h and one included for each platform.    Most
> of the grief came from people with various ideas on how to do 64 bit seeks
> and of all things (thankfully we got away from this) stty/ioctl.
> 
> I never had to resort to a script to set things up.   Reading down through
> conf.h told me what my options were and it didn't take long to set things
> up.
> 
> I also ported/wrote X11 servers for four or five systems (including writing
> my own CFB24 before MIT released theres).    iMake worked pretty well,
> though since it relied on the C prepropcessor and the exacxt format of the C
> preprocessor output really isn't defined for white space, it sometimes was a
> problem.    Eventually, we picked up CMAKE though I don't particularly like
> that one either.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Bakul Shah]

On Sep 14, 2017, at 1:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> I don't have much love for the libtool/autoconf/automake/etc. system.
> While it works, and is better than nothing, I have always felt that
> it was the wrong approach.  I am fortunate that I know some of the
> folks who worked on these tools because they're part of the too complex
> for casual users thing that I mentioned in my earlier post about open
> source.

My days of wrestling with libtool/autoconf/automake/cmake are mostly
in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I
mainly use Go. Even cross compiled binaries just work. It has a very
well engineered ecosystem.

> There are two big advantages to handling portability this way.  First, the
> source code is easier to read; it's not full of #ifdef this and #ifndef that.
> Second, once the portability library existed it just worked and could be
> reused.  With the GNU tools methodology, every time someone needed to do a
> fopen on a machine where the target behaved differently, the alternate code
> needed to be written.  There was no debugged library where this stuff only
> had to be figured out once.

I agree with this. auto{conf,make}/configure is just the wrong approach.

At Real Networks our media server ran on 12 or so Unix platforms + windows +
macOS9 (at the time). I managed to corral machine dependent code in basically
a couple files for all but MacOS9. No #ifdefs in any other file. C++ also
helped to hide things like select(2) vs poll(2) from other code.

[TUHS] Tools and building: libtool, autoconf, etc. [ trying to have a relevant subject line ]

[Noel Hunt]

I'm surprised no-one has mentioned 'iffe', written by
Glenn Fowler and Phong Vo who were at AT&T. It is simply
a (large) shell script that runs 'feature' files. I have
had problems with it on 64-bit builds but I have had far
too many problems with 'configure' over the years.

'Iffe' deserves to be better known.

On Fri, Sep 15, 2017 at 6:41 AM, Bakul Shah <bakul at bitblocks.com> wrote:

> On Sep 14, 2017, at 1:22 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> >
> > I don't have much love for the libtool/autoconf/automake/etc. system.
> > While it works, and is better than nothing, I have always felt that
> > it was the wrong approach.  I am fortunate that I know some of the
> > folks who worked on these tools because they're part of the too complex
> > for casual users thing that I mentioned in my earlier post about open
> > source.
>
> My days of wrestling with libtool/autoconf/automake/cmake are mostly
> in the past. On FreeBSD/MacOS I use pkg/brew. For any new coding I
> mainly use Go. Even cross compiled binaries just work. It has a very
> well engineered ecosystem.
>
> > There are two big advantages to handling portability this way.  First,
> the
> > source code is easier to read; it's not full of #ifdef this and #ifndef
> that.
> > Second, once the portability library existed it just worked and could be
> > reused.  With the GNU tools methodology, every time someone needed to do
> a
> > fopen on a machine where the target behaved differently, the alternate
> code
> > needed to be written.  There was no debugged library where this stuff
> only
> > had to be figured out once.
>
> I agree with this. auto{conf,make}/configure is just the wrong approach.
>
> At Real Networks our media server ran on 12 or so Unix platforms + windows
> +
> macOS9 (at the time). I managed to corral machine dependent code in
> basically
> a couple files for all but MacOS9. No #ifdefs in any other file. C++ also
> helped to hide things like select(2) vs poll(2) from other code.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/da846e48/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steffen Nurpmeso]

arnold at skeeve.com wrote:
 |Definitely getting off-topic here ...

Do not think so, my i386 had a 20 MB hard disc...

 |Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
 |>|Libtool for sure. Autoconf is something you have to come to a negotiated
 |>|truce with and then it's OK. :-)
 |>
 |> I cannot seem to reach that state.  I see that the m4 directory of
 |> gawk v4.1.4 contains no less than 46 files with a total of 312 KB.
 |> On top of that the root directory contains some configure related
 |> files which sum up to about 500 KB.
 |
 |Gawk is light-weight compared to most projects that use gnulib (e.g,
 |grep).  Much of what you point out is boilerplate placed there by
 |the autotools.  The only file(s) I, as a developer, have to mess with
 |are the configure.ac files.
 |
 |> I do not know how much manual work was necessary for the files in
 |> m4,
 |
 |Once it's set up, you just ignore it, and update the files whenever

I only referred to its noise, not the comfort that it brings.

 |there's a new autoconf / automake / gettext / libtool release.

That update rate was quite high in the last years but seems to
have settled down again.  I became frustrated earlier, and stopped
to track many projects which no longer ship a pre-prepared
configure file via V-C-S, turning to tar bombs again.  That is
ugly, but having several versions of those tools around
concurrently to satisfy all those projects, no time.

 |I've been using autoconf since 1.x days, so I'm very used to it.
 |I also find it to be much less aggravation than CMake-based projects,
 |where if something craps out during the cmake run, you essentially
 |must wipe out the directory and re-extract the tarball to start over.

I do not know.  I once used perl for my configuration stuff, it
had to be available for OpenSSL anyway, and it was by default
installed on FreeBSD later on, anyway.  Also perl configures and
compiles out of the box on the Linux/BSD i had, and OpenSSL does
if there is perl.  So with vim which did not need anything i am
ready.

 |>  And when i look into the missing_d of gawk
 |> i cannot help to wonder what all that is for.
 |
 |Much of it is probably obsolete. Some things date back to the days
 |when some systems had strchr() and others had index()...

I hope it will be a fun project some day to port my stuff to elder
systems, before FreeBSD 4.7 / Solaris 9 / Linux 2.0.x.  Hopefully.
And i tend to write such simple functions my own anyway.  (I once
had the dream to end up with only me and the operating system, but
that is long gone.)

 |> But of course, what is the alternative?
 |
 |I don't see one. CMake doesn't really cut it for me.  For make
 |problems, port GNU Make; it's very portable, since it's one of the
 |base items for many GNU projects.
 |
 |I know it runs on Solaris 9.

Actually that made me kindly ignore the invalid definition of
UINTPTR_MAX and INTPTR_MAX on Solaris 5.9 and also replace a call
to iswblank(3) (i do not think it matters that much for now),
ending up with another credit of yours for the port to 5.9.
It was not about the make(1), actually, only /bin/sh we really
cannot afford but require /usr/xpg4/bin.  It was MAKEJOBS='-j X'
which resulted in -j being ignored and X standing alone and by
itself.  I never needed GNU make, the perl thing unrolled anything
and did not even use inference rules (in fact i did not understand
them back then.  And was not interested enough to learn!!
Terrible.)

 |> Plan9 shows an impressive beauty regarding this topic, but it, of
 |> course, is exclusive to a current Plan9.
 |
 |No arguments there, but unfortunately, Plan 9 is a very self-contained
 |sandbox.  Few of us get to live there all the time.

It is on a descending branch, so to say.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ian Zimmerman]

On 2017-09-14 15:21, Steffen Nurpmeso wrote:

> But of course, what is the alternative?

scons?  The main argument against it seems to be speed (or rather lack
of it).  The current version has a framework for build-time tests with
features quite similar to autotools.  Of course there are many fewer
pre-packaged tests, but in my experience the pre-packaged tests in
autotools are not all that useful, at least not for building on "modern"
systems; for the interesting platform differences one needs to write
custom auto* macros anyway.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Dave Horsfall]

On Wed, 13 Sep 2017, Nemo wrote:

> Oh, I nearly wept when I read this.  Building a typical project nowadays 
> is so painful -- the makefile works on one particular Linux distro and 
> woe betide the rest.

Ah, well I remember when "make" was first introduced (in PWB?); I thought
it was Christmas...

Now, even it has to be modified for various platforms.

Trivia: what does "make love" say on your system?  My Mac boringly says 
"make: *** No rule to make target `love'.  Stop." and the FreeBSD box 
isn't much better: "make: don't know how to make love. Stop".  I don't 
know what my Penguin laptop says because it's currently switched off.

Sigh...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Warner Losh]

On Thu, Sep 14, 2017 at 9:16 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 13 Sep 2017, Nemo wrote:
>
> Oh, I nearly wept when I read this.  Building a typical project nowadays
>> is so painful -- the makefile works on one particular Linux distro and woe
>> betide the rest.
>>
>
> Ah, well I remember when "make" was first introduced (in PWB?); I thought
> it was Christmas...
>
> Now, even it has to be modified for various platforms.
>
> Trivia: what does "make love" say on your system?  My Mac boringly says
> "make: *** No rule to make target `love'.  Stop." and the FreeBSD box isn't
> much better: "make: don't know how to make love. Stop".  I don't know what
> my Penguin laptop says because it's currently switched off.
>
> Sigh...


FreeBSD's make used to say 'not war' but when bmake was imported from
NetBSD, that went away and the maintainers aren't keen on brining back the
joke :( I added it years ago, but haven't missed it enough to fight the
political battle to get it back in...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bf9e3d31/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ron Natalie]

The command MAKE on TOPS10 was an interface to the editor (TECO).

 

. MAKE LOVE

NOT WAR?
[4K CORE]

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/49e94a3f/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Arthur Krewat]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On TOPS-10, "make love" says "Not WAR?" - but unlike UNIX make, it 
invokes TECO ;)

.MAKE LOVE
not WAR?

*ITHIS IS A TEST
$$
*HT$$
THIS IS A TEST
*



On 9/14/2017 11:16 PM, Dave Horsfall wrote:
> On Wed, 13 Sep 2017, Nemo wrote:
>
>> Oh, I nearly wept when I read this. Building a typical project 
>> nowadays is so painful -- the makefile works on one particular Linux 
>> distro and woe betide the rest.
>
> Ah, well I remember when "make" was first introduced (in PWB?); I thought
> it was Christmas...
>
> Now, even it has to be modified for various platforms.
>
> Trivia: what does "make love" say on your system?  My Mac boringly 
> says "make: *** No rule to make target `love'.  Stop." and the FreeBSD 
> box isn't much better: "make: don't know how to make love. Stop".  I 
> don't know what my Penguin laptop says because it's currently switched 
> off.
>
> Sigh...
>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> wrote:
 |On Wed, 13 Sep 2017, Nemo wrote:
 |> Oh, I nearly wept when I read this.  Building a typical project nowadays 
 |> is so painful -- the makefile works on one particular Linux distro and 
 |> woe betide the rest.
 |
 |Ah, well I remember when "make" was first introduced (in PWB?); I thought
 |it was Christmas...
 |
 |Now, even it has to be modified for various platforms.
 |
 |Trivia: what does "make love" say on your system?  My Mac boringly says 
 |"make: *** No rule to make target `love'.  Stop." and the FreeBSD box 
 |isn't much better: "make: don't know how to make love. Stop".  I don't 
 |know what my Penguin laptop says because it's currently switched off.
 |
 |Sigh...

Schily make is even melodramatic and/or digital:

  ?1[steffen at wales tmp]$ smake love
  smake: Can't find any source for 'love'.
  smake: Couldn't make 'love'.
  ?1[steffen at wales tmp]$ 

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Paul Winalski]

> Dave Horsfall <dave at horsfall.org> wrote:
>  |On Wed, 13 Sep 2017, Nemo wrote:
>  |
>  |Trivia: what does "make love" say on your system?

It says:

        Not war?

-Paul W.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[arnold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5367 bytes --]

And buried in this story is another reason Unix / BSD people went with
Sun --- (if you had the licenses) they would give you source! Even for
educational institutions, where I mostly worked, getting source out of
DEC / IBM / HP was essentially impossible.

Arnold

"Steve Johnson" <scj at yaccman.com> wrote:

> Funny.  From the outside I had a rather different view of why Sun was
> successful.
>
> In 1986 I came to CA to work for what became Ardent/Stardent.  We
> made the decision to go with Sun disc-less workstations.  They got us
> more computing power, on paper, for less $$.
>
> Roughly a quarter of the machines shipped to us were DOA.  When we
> got them running, the OS had a memory leak and needed to be rebooted
> several times a day.  The NFS server had the delightful property of
> sometimes inserting 1024 zeros into a file it was writing or
> serving.    (It was so bad that we hacked the OS to check every
> executable for 0-blocks in the instruction space and refuse to run
> it.  This was especially true for the MIPS cross compiler -- 0 was a
> NOP on the MIPS, and encountering a block of zeros caused execution to
> slide down a slippery slope of NOPs into the middle of some other
> routine with a different stack layout, where it proceeded to do the
> most mysterious things...)
>
> We would go out to lunch every day and trash talk Sun up one side and
> down the other.  And then we would go back to work and order more
> Suns.  Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
> GIVE IT TO US.  The other manufacturers were selling application
> delivery vehicles rather than attempting to support software
> development.  Eventually we ironed out many of the issues (often by
> changing or hacking the code).  The only fly in the ointment was the
> service department.  Dealing with Sun customer service was like
> spitting into the wind.  We would report the same bug every week and
> they swore the bug had not been reported before.  The memory leak
> problem became so serious that we told them that we would only renew
> the service agreement if they would put a date when that would be
> fixed.  They refused to do so, and we canceled the service contract,
> bought a couple of extra Suns for spares, and heaved a sigh of relief.
>
> Steve
>
> ----- Original Message -----
> From: "Jon Steinhart" <jon at fourwinds.com>
> To:<tuhs at tuhs.org>
> Cc:
> Sent:Tue, 12 Sep 2017 08:35:24 -0700
> Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
> dec/apollo --> X and NeWS ]
>
>  arnold at skeeve.com writes:
>  > 
>  > In particular, the creation of NFS and then the efforts to make it
> into
>  > a de-facto standard (giving away the RPC and XDR code) was a HUGE
> thing.
>  > 
>  > They weren't afraid to swim upstream, either. Even though NeWS
> never took
>  > off (even when combined with an X server), it was an interesting
> design,
>  > ahead of its time even.
>
>  It's interesting that you mention the two of these together. It's my
>  opinion that the main reason that NeWS failed was because of the
> success
>  of NFS.
>
>  I recall that Apollo was really pissed off by NFS because they felt
> that
>  their token-ring network was better but lost because NFS was given
> away.
>  In hindsight, they were wrong; while the token-ring performed better
> in
>  large networks, the advent of switches made that moot. In any case,
> when
>  NeWS was released nobody except Sun knew how to do the graphics (even
>  Adobe didn't know how to do it fast for display) and Apollo et. al.
> was
>  worried that Sun would give NeWS away and make it yet another de
> facto
>  standard a la NFS. This led to the formation of the Hamilton Group
> which
>  was a thinly-disguised industry consortium that existed only for the
>  purpose of making sure that NeWS didn't succeed.
>
>  > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun
> for
>  > many years.
>
>  I mentioned this to a lot of people after Sun died. Few seem to
> realize
>  how much of what became PC manufacturing technology resulted from
> innovations
>  at Sun.
>
>  ron at ronnatalie.com writes:
>  >
>  > NeWS had serious issues. However, the same guy who was the NeWS
> proponent
>  > learned from mistakes and the result was the must more successful
> Sun
>  > tehnology: JAVA.
>
>  I'm going to take issue with the above. NeWS had way fewer serious
> issues
>  than X. It's main reason for failure was the coordinated effort to
> kill it
>  from others in the industry. As the guy who single-handedly prevented
> X
>  from becoming an ANSI standard, I'd be happy to start another thread
> on
>  this topic if people are interested. Part of the result of the
> Hamilton
>  Group effort was the misguided attempt to merge X and NeWS which was
> a
>  botched disaster.
>
>  Java is not the result of learning from mistakes in NeWS. I have
> joked with
>  James that I feel that his legacy is being the person who first
> realizes that
>  technology is changing to the point where something can be done using
> an
>  interpreter. If you look at his project history, he's done this many
> times.
>  I think that it's more accurate to say that Java is the result of a
> lifetime
>  of learning from interpreter projects. I fully expect some new
> interpreter
>  to take over AWS sometime soon :-)
>
>  Jon
>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

Yeah but not the SCCS history.  And the source tapes went through
Bill Shannon who would grep the source for swear words and other
stuff before blessing it.  At least that's how it was when I was 
there.

On Wed, Sep 13, 2017 at 01:30:22AM -0600, arnold at skeeve.com wrote:
> And buried in this story is another reason Unix / BSD people went with
> Sun --- (if you had the licenses) they would give you source! Even for
> educational institutions, where I mostly worked, getting source out of
> DEC / IBM / HP was essentially impossible.
> 
> Arnold
> 
> "Steve Johnson" <scj at yaccman.com> wrote:
> 
> > Funny.? From the outside I had a rather different view of why Sun was
> > successful.
> >
> > In 1986 I came to CA to work for what became Ardent/Stardent.? We
> > made the decision to go with Sun disc-less workstations.? They got us
> > more computing power, on paper, for less $$.
> >
> > Roughly a quarter of the machines shipped to us were DOA.? When we
> > got them running, the OS had a memory leak and needed to be rebooted
> > several times a day.? The NFS server had the delightful property of
> > sometimes inserting 1024 zeros into a file it was writing or
> > serving.??? (It was so bad that we hacked the OS to check every
> > executable for 0-blocks in the instruction space and refuse to run
> > it.? This was especially true for the MIPS cross compiler -- 0 was a
> > NOP on the MIPS, and encountering a block of zeros caused execution to
> > slide down a slippery slope of NOPs into the middle of some other
> > routine with a different stack layout, where it proceeded to do the
> > most mysterious things...)
> >
> > We would go out to lunch every day and trash talk Sun up one side and
> > down the other.? And then we would go back to work and order more
> > Suns.? Because THEY UNDERSTOOD WHAT WE NEEDED, and were TRYING TO
> > GIVE IT TO US.? The other manufacturers were selling application
> > delivery vehicles rather than attempting to support software
> > development.? Eventually we ironed out many of the issues (often by
> > changing or hacking the code).? The only fly in the ointment was the
> > service department.? Dealing with Sun customer service was like
> > spitting into the wind.? We would report the same bug every week and
> > they swore the bug had not been reported before.? The memory leak
> > problem became so serious that we told them that we would only renew
> > the service agreement if they would put a date when that would be
> > fixed.? They refused to do so, and we canceled the service contract,
> > bought a couple of extra Suns for spares, and heaved a sigh of relief.
> >
> > Steve
> >
> > ----- Original Message -----
> > From: "Jon Steinhart" <jon at fourwinds.com>
> > To:<tuhs at tuhs.org>
> > Cc:
> > Sent:Tue, 12 Sep 2017 08:35:24 -0700
> > Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
> > dec/apollo --> X and NeWS ]
> >
> >  arnold at skeeve.com writes:
> >  > 
> >  > In particular, the creation of NFS and then the efforts to make it
> > into
> >  > a de-facto standard (giving away the RPC and XDR code) was a HUGE
> > thing.
> >  > 
> >  > They weren't afraid to swim upstream, either. Even though NeWS
> > never took
> >  > off (even when combined with an X server), it was an interesting
> > design,
> >  > ahead of its time even.
> >
> >  It's interesting that you mention the two of these together. It's my
> >  opinion that the main reason that NeWS failed was because of the
> > success
> >  of NFS.
> >
> >  I recall that Apollo was really pissed off by NFS because they felt
> > that
> >  their token-ring network was better but lost because NFS was given
> > away.
> >  In hindsight, they were wrong; while the token-ring performed better
> > in
> >  large networks, the advent of switches made that moot. In any case,
> > when
> >  NeWS was released nobody except Sun knew how to do the graphics (even
> >  Adobe didn't know how to do it fast for display) and Apollo et. al.
> > was
> >  worried that Sun would give NeWS away and make it yet another de
> > facto
> >  standard a la NFS. This led to the formation of the Hamilton Group
> > which
> >  was a thinly-disguised industry consortium that existed only for the
> >  purpose of making sure that NeWS didn't succeed.
> >
> >  > DEC, IBM, and HP, all seemed to be playing follow the leader to Sun
> > for
> >  > many years.
> >
> >  I mentioned this to a lot of people after Sun died. Few seem to
> > realize
> >  how much of what became PC manufacturing technology resulted from
> > innovations
> >  at Sun.
> >
> >  ron at ronnatalie.com writes:
> >  >
> >  > NeWS had serious issues. However, the same guy who was the NeWS
> > proponent
> >  > learned from mistakes and the result was the must more successful
> > Sun
> >  > tehnology: JAVA.
> >
> >  I'm going to take issue with the above. NeWS had way fewer serious
> > issues
> >  than X. It's main reason for failure was the coordinated effort to
> > kill it
> >  from others in the industry. As the guy who single-handedly prevented
> > X
> >  from becoming an ANSI standard, I'd be happy to start another thread
> > on
> >  this topic if people are interested. Part of the result of the
> > Hamilton
> >  Group effort was the misguided attempt to merge X and NeWS which was
> > a
> >  botched disaster.
> >
> >  Java is not the result of learning from mistakes in NeWS. I have
> > joked with
> >  James that I feel that his legacy is being the person who first
> > realizes that
> >  technology is changing to the point where something can be done using
> > an
> >  interpreter. If you look at his project history, he's done this many
> > times.
> >  I think that it's more accurate to say that Java is the result of a
> > lifetime
> >  of learning from interpreter projects. I fully expect some new
> > interpreter
> >  to take over AWS sometime soon :-)
> >
> >  Jon
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Dave Horsfall]

On Wed, 13 Sep 2017, Larry McVoy wrote:

> Yeah but not the SCCS history.  And the source tapes went through Bill 
> Shannon who would grep the source for swear words and other stuff before 
> blessing it.  At least that's how it was when I was there.

I would love to see his list; I might learn a few new words :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Henry Bent]

Were there really that many comments that needed censoring?  It would be
nice to have the idealism to think of Sun as a freewheeling, uncensored
alternative to the corporate structure of DEC and IBM, but having seen the
"released" source for the early '90s Unix operating systems of all three I
never saw anything to indicate that there were censored inline curses
anywhere.  If anything, the DEC sources are now more informational by
virtue of still having a mostly complete changelog in the header.

-Henry

On 13 September 2017 at 19:55, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 13 Sep 2017, Larry McVoy wrote:
>
> Yeah but not the SCCS history.  And the source tapes went through Bill
>> Shannon who would grep the source for swear words and other stuff before
>> blessing it.  At least that's how it was when I was there.
>>
>
> I would love to see his list; I might learn a few new words :-)
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170913/750a93d2/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

I didn't see a lot but Shannon was very sensitive to appearing professional.

On Wed, Sep 13, 2017 at 08:18:06PM -0400, Henry Bent wrote:
> Were there really that many comments that needed censoring?  It would be
> nice to have the idealism to think of Sun as a freewheeling, uncensored
> alternative to the corporate structure of DEC and IBM, but having seen the
> "released" source for the early '90s Unix operating systems of all three I
> never saw anything to indicate that there were censored inline curses
> anywhere.  If anything, the DEC sources are now more informational by
> virtue of still having a mostly complete changelog in the header.
> 
> -Henry
> 
> On 13 September 2017 at 19:55, Dave Horsfall <dave at horsfall.org> wrote:
> 
> > On Wed, 13 Sep 2017, Larry McVoy wrote:
> >
> > Yeah but not the SCCS history.  And the source tapes went through Bill
> >> Shannon who would grep the source for swear words and other stuff before
> >> blessing it.  At least that's how it was when I was there.
> >>
> >
> > I would love to see his list; I might learn a few new words :-)
> >
> > --
> > Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> > suffer."
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2090 bytes --]

I'm not aware of any profanity per se in the early Unix sources, but
there certainly were some snarky error messages.   Like "eh?"   Or
"Very Funny".  I contributed a few: "gummy structure".

I've become truly PO'd at the state of error messages in today's
software.   Things like "file error" or "cannot open file" without
telling you what file was being opened.   And every encounter with
git gives me additional fodder.  The information in many of git's
error messages is roughly one bit, that is best translated with
profanity.

I wrote a paper on error messages at one point.  I had examples from
bad to best.  In a nutshell (worst to best):

	* <program aborts, leaving the world in an unknown state>
	* "internal error",  "beta table overflow", "operation failed"
	* "Writing the output file failed"
	* "File xxx could not be opened for writing."
	* "File xxx could not be opened for writing: check the file location
and permissions"

	* "Writing the output file xxx caused an error.  See <link> for
possible reasons and corrections" 

Most git messages fall between 2 and 3.  But there are occasional 4's
and 5's.

Steve

----- Original Message -----
From: "Henry Bent" <henry.r.bent@gmail.com>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Wed, 13 Sep 2017 20:18:06 -0400
Subject:Re: [TUHS] Happy birthday, Dennis Ritchie! [ really sun vs
dec/apollo --> X and NeWS ]

Were there really that many comments that needed censoring?  It would
be nice to have the idealism to think of Sun as a freewheeling,
uncensored alternative to the corporate structure of DEC and IBM, but
having seen the "released" source for the early '90s Unix operating
systems of all three I never saw anything to indicate that there were
censored inline curses anywhere.  If anything, the DEC sources are
now more informational by virtue of still having a mostly complete
changelog in the header.

-Henry


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/ffb78d69/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Thu, 14 Sep 2017, Steve Johnson wrote:

> I'm not aware of any profanity per se in the early Unix sources, but
> there certainly were some snarky error messages.   Like "eh?"   Or
> "Very Funny".  I contributed a few: "gummy structure".
>
> I've become truly PO'd at the state of error messages in today's
> software.   Things like "file error" or "cannot open file" without
> telling you what file was being opened.   And every encounter with
> git gives me additional fodder.  The information in many of git's
> error messages is roughly one bit, that is best translated with
> profanity.
>
> I wrote a paper on error messages at one point.  I had examples from
> bad to best.  In a nutshell (worst to best):
>
> 	* <program aborts, leaving the world in an unknown state>
> 	* "internal error",  "beta table overflow", "operation failed"
> 	* "Writing the output file failed"
> 	* "File xxx could not be opened for writing."
> 	* "File xxx could not be opened for writing: check the file location
> and permissions"
>
> 	* "Writing the output file xxx caused an error.  See <link> for
> possible reasons and corrections" 
>
> Most git messages fall between 2 and 3.  But there are occasional 4's
> and 5's.
>
> Steve

You got perror(), use it (not you)... >_>

All my code that outputs error messages for stuff in the C library uses 
perror(), so a typical error might be "foo: cannot open file bar: No such 
file or directory", with the last part coming from the C runtime itself.

-uso.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ian Zimmerman]

On 2017-09-14 15:54, Steve Nickolas wrote:

> You got perror(), use it (not you)... >_>
> 
> All my code that outputs error messages for stuff in the C library
> uses perror(), so a typical error might be "foo: cannot open file bar:
> No such file or directory", with the last part coming from the C
> runtime itself.

This only works if you call libc directly, or if the code you call
(including your own) reuses libc errno codes.  If you deal with libfoo,
libfoo has its own error codes, and has no perror-like function, you
must write your own :(

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ron Natalie]

The error codes perror relies on don't come from "libc."   They come from
the kernel.   The values only make sense if the error is the result of a
system call.

-----Original Message-----
 
This only works if you call libc directly, or if the code you call
(including your own) reuses libc errno codes.  If you deal with libfoo,
libfoo has its own error codes, and has no perror-like function, you must
write your own :(

 .

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

 

Ø  I'm not aware of any profanity per se in the early Unix sources, but there certainly were some snarky error messages.   Like "eh?"   Or "Very Funny".  I contributed a few: "gummy structure".




Of which “You’re not expected to understand this” is probably the most famous.     This so incensed my mentor Mike Muuss that he figured out what the code REALLY did and wrote several paragrahs after that starting with “You are expected to understand this:”

 

The worst error system I ever encountered was a summer job I had in college.   The system I was using had a package called “reptile” that’s sole diagnostic was “Snake bite at xxxx” where xxxx was the address that the error was detected.   I had a crib sheet of what errors corresponded to what addresses, but that was rendered incorrect when the program was relinked and evertying moved.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/fb405b91/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Jon Steinhart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

"Ron Natalie" writes:
> The worst error system I ever encountered was a summer job I had in college.  
> The system I was using had a package called “reptile” that’s sole diagnostic
> was “Snake bite at xxxx” where xxxx was the address that the error was
> detected.   I had a crib sheet of what errors corresponded to what addresses,
> but that was rendered incorrect when the program was relinked and evertying
> moved.

I suppose that I'm guilty of this at some level.  When I worked at Tektronix
there was a management edict that one had to check for error returns on all
system calls even if the only way in which the system call would fail was
because the system was in the process of crashing.  I don't remember the exact
specifics, but it annoyed me to be wasting valuable space doing this, and there
was some sort of ioctl on a tty that could not possibly fail on a healthy system
and wouldn't cause any damage even if the error was returned.  While nobody ever
saw it, I chose the error message "tough ttys".

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
> I wrote a paper on error messages at one point.  I had examples from
> bad to best.  In a nutshell (worst to best):
> 
> 	* <program aborts, leaving the world in an unknown state>
> 	* "internal error",  "beta table overflow", "operation failed"
> 	* "Writing the output file failed"
> 	* "File xxx could not be opened for writing."
> 	* "File xxx could not be opened for writing: check the file location
> and permissions"
> 
> 	* "Writing the output file xxx caused an error.  See <link> for
> possible reasons and corrections" 
> 
> Most git messages fall between 2 and 3.  But there are occasional 4's
> and 5's.

Just out of curiosity, where does perror(filename), quite possibly the
*most* common error message on Unix as a whole, fall on your scale? It
says which of the file location or permissions (or whatever else) it is,
but not whether it was attempting to open it for reading or writing.

(Of course, git sometimes has the problem that other cases of a 4 or 5
don't: needing to understand its internal structure to know why it wants
that file and how to fix it.)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
> > I wrote a paper on error messages at one point.?? I had examples from
> > bad to best.?? In a nutshell (worst to best):
> > 
> > 	* <program aborts, leaving the world in an unknown state>
> > 	* "internal error",?? "beta table overflow", "operation failed"
> > 	* "Writing the output file failed"
> > 	* "File xxx could not be opened for writing."
> > 	* "File xxx could not be opened for writing: check the file location
> > and permissions"
> > 
> > 	* "Writing the output file xxx caused an error.?? See <link> for
> > possible reasons and corrections" 
> > 
> > Most git messages fall between 2 and 3.?? But there are occasional 4's
> > and 5's.
> 
> Just out of curiosity, where does perror(filename), quite possibly the
> *most* common error message on Unix as a whole, fall on your scale? It
> says which of the file location or permissions (or whatever else) it is,
> but not whether it was attempting to open it for reading or writing.

So in the BitKeeper source, perror is redifined to my_perror which is
this:

void    
my_perror(char *file, int line, char *msg)
{
        char    *p = 0;
        int     save = errno;

        if (p = getenv("_BK_VERSION")) {
                if (strneq(p, "bk-", 3)) p += 3;
                fprintf(stderr, "%s:%d (%s): ", file, line, p);
        } else {
                fprintf(stderr, "%s:%d: ", file, line);
        }
        if (p = strerror(errno)) {
                fprintf(stderr, "%s: %s\n", msg, p);
        } else {
                fprintf(stderr, "%s: errno=%d\n", msg, errno);
        }
        errno = save;   
}

libc should do that.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Gregg Levine]

Hello!
Larry, back when I was a serious Kernel Hacker, I actually obtained
the appropriate release of Bitkeeper for grabbing the raw source code
for the kernel that Linus wrote.

I found it much easier to use then what is in use now. Its few errors
thrown in my direction were easier to understand then the many thrown
at me by the current tool. And here's a hint, even his Foundation and
my current distribution author, does not like it much.

And I remember meeting a DG system running a release of DG/UX, suffice
to say I wasn't happy. I found that the SUN systems running either
early Solaris or SUNos were easier to get along with. I can;t recall
outside of the VCF East event if I've seen a Tek graphics terminal
before........
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
>> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
>> > I wrote a paper on error messages at one point.?? I had examples from
>> > bad to best.?? In a nutshell (worst to best):
>> >
>> >     * <program aborts, leaving the world in an unknown state>
>> >     * "internal error",?? "beta table overflow", "operation failed"
>> >     * "Writing the output file failed"
>> >     * "File xxx could not be opened for writing."
>> >     * "File xxx could not be opened for writing: check the file location
>> > and permissions"
>> >
>> >     * "Writing the output file xxx caused an error.?? See <link> for
>> > possible reasons and corrections"
>> >
>> > Most git messages fall between 2 and 3.?? But there are occasional 4's
>> > and 5's.
>>
>> Just out of curiosity, where does perror(filename), quite possibly the
>> *most* common error message on Unix as a whole, fall on your scale? It
>> says which of the file location or permissions (or whatever else) it is,
>> but not whether it was attempting to open it for reading or writing.
>
> So in the BitKeeper source, perror is redifined to my_perror which is
> this:
>
> void
> my_perror(char *file, int line, char *msg)
> {
>         char    *p = 0;
>         int     save = errno;
>
>         if (p = getenv("_BK_VERSION")) {
>                 if (strneq(p, "bk-", 3)) p += 3;
>                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
>         } else {
>                 fprintf(stderr, "%s:%d: ", file, line);
>         }
>         if (p = strerror(errno)) {
>                 fprintf(stderr, "%s: %s\n", msg, p);
>         } else {
>                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
>         }
>         errno = save;
> }
>
> libc should do that.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Mon, Sep 18, 2017 at 10:56:51PM -0400, Gregg Levine wrote:
> Hello!
> Larry, back when I was a serious Kernel Hacker, I actually obtained
> the appropriate release of Bitkeeper for grabbing the raw source code
> for the kernel that Linus wrote.
> 
> I found it much easier to use then what is in use now. Its few errors
> thrown in my direction were easier to understand then the many thrown
> at me by the current tool. 

yeah, git suffers from the Not Unix problem that Linux has.  There is a
lot of value in the Unix approach which is, in my opinion, fairly terse.
Do a little but do it right.  Don't go crazy with every option that
every well intentioned person wants, do the subset that is what people
truly want even if they don't realize it.

I know it doesn't matter at this point, git won, but BitKeeper is open
source under the very liberal Apache license (and if you don't like
that one for a good reason I can rerelease under a different license)
and there is a ton of useful stuff in there that has nothing to do with
source management.  Most of perl/lisp is in there, cross platform stuff
that includes windows is in there, some pretty amazing stdio work that I
wish Chris Torek would suck back into NetBSD is in there, and BK itself
is pretty sweet.  I routinely do

	git -C git-repo fast-export master | bk fast-import bk-repo

so I can look at the source with BK tools.  BK differs from git in many
ways, but to you Unix people, BK has the inode concept.  There is a
thing that is a file, it doesn't care where it lives, the pathname is
an attribute of the file, just like the changes are.  Git doesn't have a
file concept, no inode for you.  So no create/unlink/rename, Git doesn't
have those, BitKeeper does.  In practice that hurts, sometimes a lot,
in a big repo git blame is useless because it is so slow, bk's blame
runs in milliseconds.

And can we talk about merges?  Git has one graph for the entire
repository.  BitKeeper has a graph for each inode.  So when Git goes
to merge it's going to use the GCA for the repository for everything.
BitKeeper uses the GCA for the file which is always a better choice.
And BK uses a ton more info, go read the code, it's cool, way better
than diff3.

I weep when I look at Git.  It's just crap yet that is what the world
uses.  It's exactly what I predicted when I was arguing with the FSF,
if you want everything to be free then what you will get is substandard
stuff.	Not all the time but most of the time.

Part of the reason I love this list is it is full of people who were
careful, they cared about the code (look at the good taste thread) and
they cared about regressions, they cared that people could understand
what they did.	(And, for the record, I just love love love the stories
about the history, Mr Yacc has some great ones, Clem has great ones,
all you guys rock when you are talking about how you made something work.)

While I use Linux, I yearn for the days where you guys and the SunOS
guys were carefully, very carefully, creating a decent system that had
an architecture that you could see if you looked hard enough.  Unix
had that, I'm not sure Linux and friends does.

--lm

If you want the BK source it's at bitkeeper.org

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Lars Brinkhoff]

Larry McVoy wrote:
> BitKeeper is open source under the very liberal Apache license [...]
> and there is a ton of useful stuff in there that has nothing to do
> with source management.  Most of perl/lisp is in there

Just curious, what Lisp is in there?

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ian Zimmerman]

On 2017-09-18 19:50, Larry McVoy wrote:

> So in the BitKeeper source, perror is redifined to my_perror which is
> this:
> 
> void    
> my_perror(char *file, int line, char *msg)

That is a different signature from perror, so I presume you mean you did
something along the lines of

#define perror(s) (my_perror(__FILE__, __LINE__, (s)))

Since this must obviously be a macro, I'm not sure I want it in libc;
macros are messy.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 19, 2017 at 12:22:14AM -0700, Ian Zimmerman wrote:
> On 2017-09-18 19:50, Larry McVoy wrote:
> 
> > So in the BitKeeper source, perror is redifined to my_perror which is
> > this:
> > 
> > void    
> > my_perror(char *file, int line, char *msg)
> 
> That is a different signature from perror, so I presume you mean you did
> something along the lines of
> 
> #define perror(s) (my_perror(__FILE__, __LINE__, (s)))

Yep.  It's much nicer knowing where in the source the error is coming
from.  Personally, I think this should be the libc version but I'm
weird :)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
 |> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
 |>> I wrote a paper on error messages at one point.?? I had examples from
 |>> bad to best.?? In a nutshell (worst to best):
 |>> 
 |>>  * <program aborts, leaving the world in an unknown state>
 |>>  * "internal error",?? "beta table overflow", "operation failed"
 |>>  * "Writing the output file failed"
 |>>  * "File xxx could not be opened for writing."
 |>>  * "File xxx could not be opened for writing: check the file location
 |>> and permissions"
 |>> 
 |>>  * "Writing the output file xxx caused an error.?? See <link> for
 |>> possible reasons and corrections" 
 |>> 
 |>> Most git messages fall between 2 and 3.?? But there are occasional 4's
 |>> and 5's.
 |> 
 |> Just out of curiosity, where does perror(filename), quite possibly the
 |> *most* common error message on Unix as a whole, fall on your scale? It
 |> says which of the file location or permissions (or whatever else) it is,
 |> but not whether it was attempting to open it for reading or writing.
 |
 |So in the BitKeeper source, perror is redifined to my_perror which is
 |this:
 |
 |void    
 |my_perror(char *file, int line, char *msg)
 |{
 |        char    *p = 0;
 |        int     save = errno;
 |
 |        if (p = getenv("_BK_VERSION")) {
 |                if (strneq(p, "bk-", 3)) p += 3;
 |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
 |} else {
 |                fprintf(stderr, "%s:%d: ", file, line);
 |}
 |        if (p = strerror(errno)) {
 |                fprintf(stderr, "%s: %s\n", msg, p);
 |} else {
 |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
 |}
 |        errno = save;   
 |}
 |
 |libc should do that.

That really made me wonder why "save" is not used, errno may
eventually change along the way.  Ok ok, but.. well.
I have had a Txt::FormatEncoder which was the sole implementation
of a format codec (plus FormatDecoder), which supported %m

  * "%m"
  * Print the description of the \SF Errno which was active at setup() time,
  * if it's value has an assigned description
  * (otherwise a message is printed which says that this value is unknown).
  * This always prints the original english string \ldots

mostly for debugging and developers thus, but why not, except for
inter-dependencies, thus optional at least, support of
a # modifier could have been added.
The encoder could be used for finite (CP::) as well as resizable
buffers (CString, ([Sys::]IO::TextWriter, etc.) as in

  static void _MyAddVFmt(
          CString                 &_str,
          const char              *_fmt,
          void                    *_valist)
  {
          ui32                    grow, olen;
          auto Txt::FormatEncoder fe;
          // use special case+update() for better code flow
          (void)fe.setup(NIL, 0, _fmt, _valist);
          for(grow=80-1;  ;  ) {
                  olen = _str.length();
                  (void)fe.update(_str.reserve(grow).data()+olen, grow)
                          .call();
                  // resize insufficient? nothing changed!
                  if(fe.isInsufficient()) {
                          (void)_str.truncate(olen);
                          grow <<= 1;
                  } else {
                          (void)_str.truncate(olen + fe.count());
                          if(fe.isFinished())
                                  break;
                          grow = 80-1;
                  }
          }
          return;
  }

Terrible: no overflow protection.  And camel case.
Plus a [Sys::]Log and [Sys::]Log::Domain with vWrite() and

  pub static void write(Priority _prio, const char *_fmt, ...);

That was for the builtin Domain only, which needs to be created
to overcome the no-op state, optionally SMP safe:

  pub static void createBuiltinDomain(IO::Device *_dev,
                    SMP::Mutex *_mtx=NIL);
  pub static Domain *getBuiltinDomain(void){ return(s_bdom); }

Optionally in [Sys::]POSIX there also was

  pub static Log::Domain *createSyslogDomain(
                            SyslogFacility _facility=user,
                            boolean _includepid=tru1,
                            const char *_intro=NIL,
                            boolean _enabled=tru1,
                            Log::Priority _prio=Log::debug);

but that cannot be used as the main log domain.  I have forgotten
why.  It also used a shared internal socket connection and mutex
for all domains created like that, but can (re)use
CP::fromVFormat() to actually prepare the written messages in
the 1 KB stack buffer for syslog purposes.  At least.  All this of
course very inconvenient in a main():

          Mem::Cache::enableStatistics();
          Mem::Cache::configure(Mem::Cache::conf_trash, tru1);
          Std::createChannels(tru1, tru1, tru1);
  No standard streams by default.
          Log::setEnabled(tru1);
          Log::setPriority(Log::debug);
          Log::createBuiltinDomain(Std::ferr);
  No logging by default.
          (void)Misc::NYD::setDumpChannel(Std::ferr);
  And NotYetDead chirps or profiling needs to be charged, too.

But despite all faulty design decisions, implementation
shortcomings, missing focus on security details, etc., at least
you can exactly specify what is going on.  And get that and
nothing else.

Unfortunately C++ has become overly huge, and i am not rich enough
to go for a C+ / C-- / C-w-C.  Well.  There is i think a German
who did something i think nice, Python style source code,
transformed to C which then is compilable as such.  But with
garbage collection and all that stuff that interpreted languages
ship, and inclusive a runtime.  Now called Nim, Nimrod no longer.
I have just looked, in the meantime also compiles to JavaScript.
Getting real grip it seems, on github etc.  Well.  Never used it,
but sounds very interesting to me.

The NetBSD getenv() uses a fast tree i think to speed up lookups.
I think especially in massive parallel object-based programs any
sort of perror() is likely overchallenged and needs to attach to
more context.  Then again i have no idea better than "CTX1: CTX2:
CTX3: message" either, and always get a headache when i see
OpenSSL error messages which exactly go this route.  So you need
two programs, one to do the work, and the other to interpret the
error messages of the first...

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
>  |On Mon, Sep 18, 2017 at 08:52:08PM -0400, Random832 wrote:
>  |> On Thu, Sep 14, 2017, at 15:37, Steve Johnson wrote:
>  |>> I wrote a paper on error messages at one point.?? I had examples from
>  |>> bad to best.?? In a nutshell (worst to best):
>  |>> 
>  |>>  * <program aborts, leaving the world in an unknown state>
>  |>>  * "internal error",?? "beta table overflow", "operation failed"
>  |>>  * "Writing the output file failed"
>  |>>  * "File xxx could not be opened for writing."
>  |>>  * "File xxx could not be opened for writing: check the file location
>  |>> and permissions"
>  |>> 
>  |>>  * "Writing the output file xxx caused an error.?? See <link> for
>  |>> possible reasons and corrections" 
>  |>> 
>  |>> Most git messages fall between 2 and 3.?? But there are occasional 4's
>  |>> and 5's.
>  |> 
>  |> Just out of curiosity, where does perror(filename), quite possibly the
>  |> *most* common error message on Unix as a whole, fall on your scale? It
>  |> says which of the file location or permissions (or whatever else) it is,
>  |> but not whether it was attempting to open it for reading or writing.
>  |
>  |So in the BitKeeper source, perror is redifined to my_perror which is
>  |this:
>  |
>  |void    
>  |my_perror(char *file, int line, char *msg)
>  |{
>  |        char    *p = 0;
>  |        int     save = errno;
>  |
>  |        if (p = getenv("_BK_VERSION")) {
>  |                if (strneq(p, "bk-", 3)) p += 3;
>  |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
>  |} else {
>  |                fprintf(stderr, "%s:%d: ", file, line);
>  |}
>  |        if (p = strerror(errno)) {
>  |                fprintf(stderr, "%s: %s\n", msg, p);
>  |} else {
>  |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
>  |}
>  |        errno = save;   
>  |}
>  |
>  |libc should do that.
> 
> That really made me wonder why "save" is not used, errno may
> eventually change along the way.  Ok ok, but.. well.

Huh?  save is set with errno and then errno is restored to save.   The 
point of save is to do the library calls (which do syscalls which 
could in theory change errno) and leave it the same as it was on
the way in.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Random832]

On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
> >  |void    
> >  |my_perror(char *file, int line, char *msg)
> >  |{
> >  |        char    *p = 0;
> >  |        int     save = errno;
> >  |
> >  |        if (p = getenv("_BK_VERSION")) {
> >  |                if (strneq(p, "bk-", 3)) p += 3;
> >  |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
> >  |} else {
> >  |                fprintf(stderr, "%s:%d: ", file, line);
> >  |}
> >  |        if (p = strerror(errno)) {
> >  |                fprintf(stderr, "%s: %s\n", msg, p);
> >  |} else {
> >  |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
> >  |}
> >  |        errno = save;   
> >  |}
> >  |
> >  |libc should do that.
> > 
> > That really made me wonder why "save" is not used, errno may
> > eventually change along the way.  Ok ok, but.. well.
> 
> Huh?  save is set with errno and then errno is restored to save.   The 
> point of save is to do the library calls (which do syscalls which 
> could in theory change errno) and leave it the same as it was on
> the way in.

I think his point was that you should be passing save (rather than
errno) to the strerror and the last printf, because the preceding
library calls may have changed errno.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Steffen Nurpmeso]

Random832 <random832 at fastmail.com> wrote:
 |On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
 |> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
 |>>|void    
 |>>|my_perror(char *file, int line, char *msg)
 |>>|{
 |>>|        char    *p = 0;
 |>>|        int     save = errno;
 |>>|
 |>>|        if (p = getenv("_BK_VERSION")) {
 |>>|                if (strneq(p, "bk-", 3)) p += 3;
 |>>|                fprintf(stderr, "%s:%d (%s): ", file, line, p);
 |>>|} else {
 |>>|                fprintf(stderr, "%s:%d: ", file, line);
 |>>|}
 |>>|        if (p = strerror(errno)) {
 |>>|                fprintf(stderr, "%s: %s\n", msg, p);
 |>>|} else {
 |>>|                fprintf(stderr, "%s: errno=%d\n", msg, errno);
 |>>|}
 |>>|        errno = save;   
 |>>|}
 |>>|
 |>>|libc should do that.
 |>> 
 |>> That really made me wonder why "save" is not used, errno may
 |>> eventually change along the way.  Ok ok, but.. well.
 |> 
 |> Huh?  save is set with errno and then errno is restored to save.   The 
 |> point of save is to do the library calls (which do syscalls which 
 |> could in theory change errno) and leave it the same as it was on
 |> the way in.
 |
 |I think his point was that you should be passing save (rather than
 |errno) to the strerror and the last printf, because the preceding
 |library calls may have changed errno.

Well, if _you_ see it the WallStreetFighter style then it needs to
be said that an overwhelming, deadly, rather exterminating number
of points have been made.  errno today is thread local storage, or
worse some pthread-specific macro expansion, i see multiple
call-ins to standard I/O which is potentially SMP-safe, stderr is
unbuffered, getenv() can end up doing a sequential walk on a flat
array with X number of strncmp() calls, in a context i assume the
variable itself is constant over the entire run of the software.
Also p=0 is C++ i think.  There are two value assignments inside
a conditional statement without parenthesis.  If the file
parameter comes from __FILE__ then that could and likely should be
constant string storage, msg looks likewise but possibly not as
bad.  This code would benefit from an iteration.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 19, 2017 at 08:31:52PM +0200, Steffen Nurpmeso wrote:
> Random832 <random832 at fastmail.com> wrote:
>  |On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
>  |> On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
>  |>>|void    
>  |>>|my_perror(char *file, int line, char *msg)
>  |>>|{
>  |>>|        char    *p = 0;
>  |>>|        int     save = errno;
>  |>>|
>  |>>|        if (p = getenv("_BK_VERSION")) {
>  |>>|                if (strneq(p, "bk-", 3)) p += 3;
>  |>>|                fprintf(stderr, "%s:%d (%s): ", file, line, p);
>  |>>|} else {
>  |>>|                fprintf(stderr, "%s:%d: ", file, line);
>  |>>|}
>  |>>|        if (p = strerror(errno)) {
>  |>>|                fprintf(stderr, "%s: %s\n", msg, p);
>  |>>|} else {
>  |>>|                fprintf(stderr, "%s: errno=%d\n", msg, errno);
>  |>>|}
>  |>>|        errno = save;   
>  |>>|}
>  |>>|
>  |>>|libc should do that.
>  |>> 
>  |>> That really made me wonder why "save" is not used, errno may
>  |>> eventually change along the way.  Ok ok, but.. well.
>  |> 
>  |> Huh?  save is set with errno and then errno is restored to save.   The 
>  |> point of save is to do the library calls (which do syscalls which 
>  |> could in theory change errno) and leave it the same as it was on
>  |> the way in.
>  |
>  |I think his point was that you should be passing save (rather than
>  |errno) to the strerror and the last printf, because the preceding
>  |library calls may have changed errno.
> 
> Well, if _you_ see it the WallStreetFighter style then it needs to
> be said that an overwhelming, deadly, rather exterminating number
> of points have been made.  errno today is thread local storage, or
> worse some pthread-specific macro expansion, i see multiple
> call-ins to standard I/O which is potentially SMP-safe, stderr is
> unbuffered, getenv() can end up doing a sequential walk on a flat
> array with X number of strncmp() calls, in a context i assume the
> variable itself is constant over the entire run of the software.
> Also p=0 is C++ i think.  There are two value assignments inside
> a conditional statement without parenthesis.  If the file
> parameter comes from __FILE__ then that could and likely should be
> constant string storage, msg looks likewise but possibly not as
> bad.  This code would benefit from an iteration.
> 
> --steffen

Feel free to send in a patch! 

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]

Being too lazy to type __FILE__ and __LINE__ all the time I tend to do this:

#define whereprintf(fmt, ...) printf("%s:%d: " fmt, __FILE__, __LINE__, ##__VA_ARGS__)

which works when fmt is a constant anyway.

My rant about error messages is that programmers too infrequently make them actionable.  

I group errors into 4 categories:

* Things the user can fix (file not found)
* Temporary resource constraints (destination unreachable, disk full)
* Things the admin can fix (library not found)
* Things the author of the program can fix (assertion failures)

In each case, the kind of information needed is different, and the level of noise and specificity may differ as well.  The user wants to know (a) how to fix it or (b) who to ask.

Finally, When faced with an unfamiliar error, the natural reaction of a 2017 user is to cut and past the error into a search engine.  Consequently I think often the right thing to do is to put a unique ID in the error message that will find it on the support website (or user forum, or …)

-L

PS Daughter is working on a master’s project to improve the quality of errors from the python interpreter/compiler.  Sorely needed.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 19, 2017 at 01:56:48PM -0400, Random832 wrote:
> On Tue, Sep 19, 2017, at 09:56, Larry McVoy wrote:
> > On Tue, Sep 19, 2017 at 03:53:59PM +0200, Steffen Nurpmeso wrote:
> > >  |void    
> > >  |my_perror(char *file, int line, char *msg)
> > >  |{
> > >  |        char    *p = 0;
> > >  |        int     save = errno;
> > >  |
> > >  |        if (p = getenv("_BK_VERSION")) {
> > >  |                if (strneq(p, "bk-", 3)) p += 3;
> > >  |                fprintf(stderr, "%s:%d (%s): ", file, line, p);
> > >  |} else {
> > >  |                fprintf(stderr, "%s:%d: ", file, line);
> > >  |}
> > >  |        if (p = strerror(errno)) {
> > >  |                fprintf(stderr, "%s: %s\n", msg, p);
> > >  |} else {
> > >  |                fprintf(stderr, "%s: errno=%d\n", msg, errno);
> > >  |}
> > >  |        errno = save;   
> > >  |}
> > >  |
> > >  |libc should do that.
> > > 
> > > That really made me wonder why "save" is not used, errno may
> > > eventually change along the way.  Ok ok, but.. well.
> > 
> > Huh?  save is set with errno and then errno is restored to save.   The 
> > point of save is to do the library calls (which do syscalls which 
> > could in theory change errno) and leave it the same as it was on
> > the way in.
> 
> I think his point was that you should be passing save (rather than
> errno) to the strerror and the last printf, because the preceding
> library calls may have changed errno.

Thanks for that insight.  That code has been working for decades but I
think the reason it works is if it works then errno doesn't change and
if it doesn't work then we're not going to see the output.  So passing
save is technically correct but not sure it is practically correct.

Anyone have an opinion?

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Ralph Corderoy]

Hi Larry,

> > > > > void    
> > > > > my_perror(char *file, int line, char *msg)
> > > > > {
> > > > >         char    *p = 0;
> > > > >         int     save = errno;
> > > > > 
> > > > >         if (p = getenv("_BK_VERSION")) {
> > > > >                 if (strneq(p, "bk-", 3)) p += 3;
> > > > >                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
> > > > >         } else {
> > > > >                 fprintf(stderr, "%s:%d: ", file, line);
> > > > >         }
> > > > >         if (p = strerror(errno)) {
> > > > >                 fprintf(stderr, "%s: %s\n", msg, p);
> > > > >         } else {
> > > > >                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
> > > > >         }
> > > > >         errno = save;   
> > > > > }
>
> I think the reason it works is if it works then errno doesn't change
> and if it doesn't work then we're not going to see the output.

Unless the failure under fprintf(3) is transient?

> So passing save is technically correct but not sure it is practically
> correct.

Passing `save' would also stop readers wondering why it's not being
passed.  :-)

Also, `p = strerror(errno)' is always going to be true;  strerror(3)
doesn't return NULL.  To check for strerror() errors one must errno=0
and then check errno afterwards;  strerror() can kick off LC_MESSAGES
stuff so errors are possible.  Yes, how does one then report that
error...

Another option when in dire straits, e.g. about to _exit() and trying
hard to get *something* to FD 2, is to writev(2) since the iov[] will be
a fixed size and the only formatting issue in the above code is the
`%d' and the space needed by its sprintf(3) can be found at compile
time.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote:

> So in the BitKeeper source, perror is redifined to my_perror which is
> this:
>
> void
> my_perror(char *file, int line, char *msg)
> {
>         char    *p = 0;
>         int     save = errno;
>
>         if (p = getenv("_BK_VERSION")) {
>                 if (strneq(p, "bk-", 3)) p += 3;
>                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
>         } else {
>                 fprintf(stderr, "%s:%d: ", file, line);
>         }
>         if (p = strerror(errno)) {
>                 fprintf(stderr, "%s: %s\n", msg, p);
>         } else {
>                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
>         }
>         errno = save;
> }
>
> libc should do that.


​+1,  indeed!​ - knowing where the the error came from (file and line) is
huge. Yeah it means putting it in the preprocessor, which has some issues;
but it comes back to a previous comment I have made -- I really believe a
serious production language needs a preprocessor that is carefully used
because there are places (like this one) that just makes the right things
happen.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/32420dee/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Larry McVoy]

On Tue, Sep 19, 2017 at 10:32:20AM -0400, Clem Cole wrote:
> On Mon, Sep 18, 2017 at 10:50 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> > So in the BitKeeper source, perror is redifined to my_perror which is
> > this:
> >
> > void
> > my_perror(char *file, int line, char *msg)
> > {
> >         char    *p = 0;
> >         int     save = errno;
> >
> >         if (p = getenv("_BK_VERSION")) {
> >                 if (strneq(p, "bk-", 3)) p += 3;
> >                 fprintf(stderr, "%s:%d (%s): ", file, line, p);
> >         } else {
> >                 fprintf(stderr, "%s:%d: ", file, line);
> >         }
> >         if (p = strerror(errno)) {
> >                 fprintf(stderr, "%s: %s\n", msg, p);
> >         } else {
> >                 fprintf(stderr, "%s: errno=%d\n", msg, errno);
> >         }
> >         errno = save;
> > }
> >
> > libc should do that.
> 
> 
> ???+1,  indeed!??? - knowing where the the error came from (file and line) is
> huge. Yeah it means putting it in the preprocessor, which has some issues;
> but it comes back to a previous comment I have made -- I really believe a
> serious production language needs a preprocessor that is carefully used
> because there are places (like this one) that just makes the right things
> happen.

Yep.  And the _BK_VERSION stuff is obviously BK specific, but if there was
a way to generalize that so you could have _APPLICATION_VERSION or something
and that got printed with the error then you get stuff like

slib.c:1653 (bk-7.3): open failed: permission denied

which is way way way more useful than just permission denied.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Tue, Sep 19, 2017 at 10:42 AM, Larry McVoy <lm at mcvoy.com> wrote:

> slib.c:1653 (bk-7.3): open failed: permission denied
>
> which is way way way more useful than just permission denied.

​And just as easy to use for the programmer... which is why it make so much
sense.​

​This ​
is an example of what I mean by "good taste."​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170919/d2bf1514/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Random832]

On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote:
> slib.c:1653 (bk-7.3): open failed: permission denied
> 
> which is way way way more useful than just permission denied.

Well. It's less useful in one way - it doesn't say what file it was
trying to open. You could pass the filename *instead* of "open failed",
but that still omits the issue I had pointed out: what were you trying
to open the file for (at the very least, were you trying to read, write,
or exec it). Ideally the function would have a format and arguments.

Another thing that's unfortunately not easy to solve is whether an error
accessing a file was due to a problem (permissions/nonexistence) with
the file itself, or one of the directories along the way. This
information isn't provided by the OS, either, so at best you can detect
an error and then check every component yourself.

[TUHS] Happy birthday, Dennis Ritchie!

[arnold]

Dave Horsfall <dave at horsfall.org> wrote:

> Sadly no longer with us (he exited in 2011), he was forked in 1941.  Just 
> think, if it wasn't for him and Ken, we'd all be running Windoze, and 
> thinking it's wonderful.
>
> A Unix bigot through and through, I remain,
>
> -- 
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

I just want to say that Dennis Ritchie was "a scholar and a gentleman".
He was always warm, polite, friendly, and down to earth, both in his
correspondance with me, and in direct conversation the few times I
talked to him in person at USENIX conferences.  He helped out A LOT
when I had Unix history questions for whatever books I happened to
be writing.

Not only to me, of course, but he was that way with everyone. He also
had a warm sense of humor, and was very active in the TUHS and Unix
history preservation.

He continues to be missed.

Arnold

[TUHS] Happy birthday, Dennis Ritchie!

[Dave Horsfall]

On Sun, 10 Sep 2017, arnold at skeeve.com wrote:

> I just want to say that Dennis Ritchie was "a scholar and a gentleman". 
> He was always warm, polite, friendly, and down to earth, both in his 
> correspondance with me, and in direct conversation the few times I 
> talked to him in person at USENIX conferences.  He helped out A LOT when 
> I had Unix history questions for whatever books I happened to be 
> writing.

He was at an AUUG conference in Sydney, and although I never got to shake 
hands with him (he had too many fans around him, and I had a home and a 
wife to go back to, not to mention two cats), he struck me as being the 
perfect gentleman.  Mr. and Mrs. Ritchie, you raised a damned good son...

> Not only to me, of course, but he was that way with everyone. He also 
> had a warm sense of humor, and was very active in the TUHS and Unix 
> history preservation.

Agreed.

> He continues to be missed.

And I just wish that the Penguin/OS community would realise this; if you 
believe those silly sods, you'd think that they invented Unix...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Dennis Ritchie!

[Ian Zimmerman]

On 2017-09-14 09:22, Dave Horsfall wrote:

> > He continues to be missed.
> 
> And I just wish that the Penguin/OS community would realise this; if
> you believe those silly sods, you'd think that they invented Unix...

Maybe some are deluded like that.  But the more typical case (and I saw
this personally not just on "the Internet") are those who actively and
consciously disdain Unix, and want Penguin kernel based systems to move
to a completely new and different userland, free from any links to Unix
history.

And we should stop assuming they're kidding when they say so openly.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

On Thu, 14 Sep 2017, Ian Zimmerman wrote:

> On 2017-09-14 09:22, Dave Horsfall wrote:
>
>>> He continues to be missed.
>>
>> And I just wish that the Penguin/OS community would realise this; if
>> you believe those silly sods, you'd think that they invented Unix...
>
> Maybe some are deluded like that.  But the more typical case (and I saw
> this personally not just on "the Internet") are those who actively and
> consciously disdain Unix, and want Penguin kernel based systems to move
> to a completely new and different userland, free from any links to Unix
> history.
>
> And we should stop assuming they're kidding when they say so openly.
>
>

Isn't that pretty much just Lennart Poettering and his fan club?

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Theodore Ts'o]

On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > Maybe some are deluded like that.  But the more typical case (and I saw
> > this personally not just on "the Internet") are those who actively and
> > consciously disdain Unix, and want Penguin kernel based systems to move
> > to a completely new and different userland, free from any links to Unix
> > history.
> > 
> > And we should stop assuming they're kidding when they say so openly.
> > 
> 
> Isn't that pretty much just Lennart Poettering and his fan club?

It's mostly Lennart Poettering and his fan club, but it's also
important to remember that Unix was not perfect.

For years, I've been ranting about the telldir/seekdir interface, for
which JFS has three b-trees that have to be updated for every
directory operation --- one of which was added *just* because of
telldir/seekdir.  Other file systems make other design choices or go
through other bits of hell just because of telldir/seekdir, but
assuming a 32-bit cookie which must survive potentially indefinitely,
with the readdir "will return file names exactly zero or one times"
guarantees required by POSIX, is rather hellish.

Or, say the atime update requirement, which can be a performance
killer, and for which the default on Linux violates Posix, and so I
suppose it technically isn't allowed to use the Unix trademark anyway.

I'm sure the Plan 9 folks could come up with other Unix shortcomings.  :-)

	   	       	     	     	    - Ted

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

On Thu, 14 Sep 2017, Theodore Ts'o wrote:

> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
>>> Maybe some are deluded like that.  But the more typical case (and I saw
>>> this personally not just on "the Internet") are those who actively and
>>> consciously disdain Unix, and want Penguin kernel based systems to move
>>> to a completely new and different userland, free from any links to Unix
>>> history.
>>>
>>> And we should stop assuming they're kidding when they say so openly.
>>>
>>
>> Isn't that pretty much just Lennart Poettering and his fan club?
>
> It's mostly Lennart Poettering and his fan club, but it's also
> important to remember that Unix was not perfect.
>
> For years, I've been ranting about the telldir/seekdir interface, for
> which JFS has three b-trees that have to be updated for every
> directory operation --- one of which was added *just* because of
> telldir/seekdir.  Other file systems make other design choices or go
> through other bits of hell just because of telldir/seekdir, but
> assuming a 32-bit cookie which must survive potentially indefinitely,
> with the readdir "will return file names exactly zero or one times"
> guarantees required by POSIX, is rather hellish.
>
> Or, say the atime update requirement, which can be a performance
> killer, and for which the default on Linux violates Posix, and so I
> suppose it technically isn't allowed to use the Unix trademark anyway.
>
> I'm sure the Plan 9 folks could come up with other Unix shortcomings.  :-)
>
> 	   	       	     	     	    - Ted
>

I never managed to pull it off, but I tried creating a full live Linux 
environment based on musl, clang, Heirloom Toolchest and OpenBSD/NetBSD 
sources.  The idea was that I wanted to make a "Real Unix" that happened 
to have Linux as its kernel.  (It also would have run the CDE as its 
default desktop.)

One thing I did come up with was, if I were to pull it off, it would be a 
Linux distribution that rightfully could NOT be called, by any means, 
"GNU/Linux" - and some heads would explode.

(I still want to do it, but I remain at a loss as to execution.)

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Christian Groessler]

On 09/14/17 21:52, Steve Nickolas wrote:

> I never managed to pull it off, but I tried creating a full live Linux 
> environment based on musl, clang, Heirloom Toolchest and 
> OpenBSD/NetBSD sources.  The idea was that I wanted to make a "Real 
> Unix" that happened to have Linux as its kernel.  (It also would have 
> run the CDE as its default desktop.)


I, too, was toying with the idea of creating a NetBSD distribution which 
uses the Linux kernel and NetBSD userland.
I very much like the concept of going to /usr/src and typing "make 
build" (or "make world" on FreeBSD) and have the
whole base system rebuilt.

I've played with Gentoo Linux which also builds from source, but I found 
it too complicated (for me, at least). On the
BSDs it's just Makefiles, and no strange python (or whatever) scripts to 
build the system.

Maybe when I'm retired and have plenty of time...

regards,
chris

[TUHS] Happy birthday, Dennis Ritchie!

[Erik Berls]

No, I am Spartacus!

I've toyed with this idea as well, mostly for getting a NetBSD environment
in a Docker container.

Maybe we should pool resources?

On Thu, Sep 14, 2017 at 15:04 Christian Groessler <chris at groessler.org>
wrote:

> On 09/14/17 21:52, Steve Nickolas wrote:
>
> > I never managed to pull it off, but I tried creating a full live Linux
> > environment based on musl, clang, Heirloom Toolchest and
> > OpenBSD/NetBSD sources.  The idea was that I wanted to make a "Real
> > Unix" that happened to have Linux as its kernel.  (It also would have
> > run the CDE as its default desktop.)
>
>
> I, too, was toying with the idea of creating a NetBSD distribution which
> uses the Linux kernel and NetBSD userland.
> I very much like the concept of going to /usr/src and typing "make
> build" (or "make world" on FreeBSD) and have the
> whole base system rebuilt.
>
> I've played with Gentoo Linux which also builds from source, but I found
> it too complicated (for me, at least). On the
> BSDs it's just Makefiles, and no strange python (or whatever) scripts to
> build the system.
>
> Maybe when I'm retired and have plenty of time...
>
> regards,
> chris
>
> --
-=erik.
--
Look, I lived through the Gray Davis years.  I *need* a UPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/bb82f173/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[ron minnich]

The u-root project (u-root.tk) is aimed at creating the *nix tools in Go.
The targets are firmware where linux and an initramfs are loaded; and root
file systems.

One goal was to get back to old school unix where the root always included
the source to create the commands. In the non-firmware mode all the sources
are there
and they are compiled on demand, save for the 4 go tooclhain binaries and
/init.

It takes about 15 seconds to compile all the tools at present.

We've got a demo OS for Chromebooks based on u-root called NiChrome
(NiChrome is an alloy of Chrome). This was a summer project for 2 interns
here. It helped show that the idea can work to support an OS distro.

We've also shown that linux and a u-root initramfs can replace most of UEFI
firmware on the Open Compute Platform nodes, reducing boot time from 8
minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta
start somewhere, and most of that time is beyond our control.

We can always use help if you're interested. I'm ok with C for kernels but
don't want to use it again in user mode, hence this project.

ron

On Thu, Sep 14, 2017 at 3:39 PM Erik Berls <erik at ono-sendai.com> wrote:

> No, I am Spartacus!
>
> I've toyed with this idea as well, mostly for getting a NetBSD environment
> in a Docker container.
>
> Maybe we should pool resources?
>
> On Thu, Sep 14, 2017 at 15:04 Christian Groessler <chris at groessler.org>
> wrote:
>
>> On 09/14/17 21:52, Steve Nickolas wrote:
>>
>> > I never managed to pull it off, but I tried creating a full live Linux
>> > environment based on musl, clang, Heirloom Toolchest and
>> > OpenBSD/NetBSD sources.  The idea was that I wanted to make a "Real
>> > Unix" that happened to have Linux as its kernel.  (It also would have
>> > run the CDE as its default desktop.)
>>
>>
>> I, too, was toying with the idea of creating a NetBSD distribution which
>> uses the Linux kernel and NetBSD userland.
>> I very much like the concept of going to /usr/src and typing "make
>> build" (or "make world" on FreeBSD) and have the
>> whole base system rebuilt.
>>
>> I've played with Gentoo Linux which also builds from source, but I found
>> it too complicated (for me, at least). On the
>> BSDs it's just Makefiles, and no strange python (or whatever) scripts to
>> build the system.
>>
>> Maybe when I'm retired and have plenty of time...
>>
>> regards,
>> chris
>>
>> --
> -=erik.
> --
> Look, I lived through the Gray Davis years.  I *need* a UPS.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/3e14649e/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Warner Losh]

First off, this sounds cool! One nit pick though...

On Thu, Sep 14, 2017 at 4:52 PM, ron minnich <rminnich at gmail.com> wrote:

> It takes about 15 seconds to compile all the tools at present.
>

If you want to replicate the old-school Unix experience, you'd need it to
take more like 15 hours to compile all the tools :)

My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the
bits of the v7 tree that build on it. I don't have the sources to Venix,
but a long-term project is to recreate them using the compiler supplied and
comparison to the binaries shipped...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170914/cbc9fa90/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Bakul Shah]

> On Sep 14, 2017, at 4:04 PM, Warner Losh <imp at bsdimp.com> wrote:
> 
> First off, this sounds cool! One nit pick though...
> 
> On Thu, Sep 14, 2017 at 4:52 PM, ron minnich <rminnich at gmail.com> wrote:
> It takes about 15 seconds to compile all the tools at present. 
> 
> If you want to replicate the old-school Unix experience, you'd need it to take more like 15 hours to compile all the tools :)
> 
> My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the bits of the v7 tree that build on it. I don't have the sources to Venix, but a long-term project is to recreate them using the compiler supplied and comparison to the binaries shipped...

You can do better than your old-school Unix experience with a pi and linux :-)
On the 1st gen RasPi the linux kernel took 10+ hours to build from scratch.
In contrast the plan9 kernel took one minute. The equivalent of FreeBSD's
"make world" for plan9 took 4 minutes. IIRC half of it was for ghostscript.

[TUHS] Happy birthday, Dennis Ritchie!

[Chris Torek]

>My DEC Rainbow running Venix (v7 port) takes about 15 hours to build the
>bits of the v7 tree that build on it.

In the spirit of complaining about compile times :-) ... I like to
build my freebsd ports tree from source.  Every time webkit2 needs
an update, my box (which I admit is no longer super-fast, but is
not exactly slow either) takes well over three hours to grind
through it, using all eight cores.  (I never timed it, I always
just left it to its own devices after a while.)

Much of this can be blamed on the complexity of compiling C++
in general (the "best type" matching rules are not simple).

Chris

[TUHS] Happy birthday, Dennis Ritchie!

[Lyndon Nerenberg]

> In the spirit of complaining about compile times :-) ... I like to
> build my freebsd ports tree from source.  Every time webkit2 needs
> an update, my box (which I admit is no longer super-fast, but is
> not exactly slow either) takes well over three hours to grind
> through it, using all eight cores.  (I never timed it, I always
> just left it to its own devices after a while.)

Forget ports!  /usr/src is bad enough.  Running buildworld, it takes 
longer to build the flippin' compilers (llvm) than it does to build the 
entire rest of the OS.  This is not progress.

--lyndon

[TUHS] Happy birthday, Dennis Ritchie!

[ron minnich]

huh. Time to build all of plan 9 -- libraries, commands, windowing system,
all kernels -- was always a few minutes. It was really annoying -- people
just assumed there
was not much capability there because it took less time to build than to
run an autoconf on GNU tools :-)

I wonder what Ken was doing wrong?

(fwiw, the Ken C compilers were a wonder -- they did not link against the C
library, they just made the system calls directly, malloc was defined to
brk(), and there was no free() -- and the code is tiny)

It's nice to see the kenc spirit still alive in the Go toolchain --
although that makes sense, since the up through 1.4 or so the go toolchain
was derived from ken c :-)

ron

On Fri, Sep 15, 2017 at 12:50 PM Lyndon Nerenberg <lyndon at orthanc.ca> wrote:

> > In the spirit of complaining about compile times :-) ... I like to
> > build my freebsd ports tree from source.  Every time webkit2 needs
> > an update, my box (which I admit is no longer super-fast, but is
> > not exactly slow either) takes well over three hours to grind
> > through it, using all eight cores.  (I never timed it, I always
> > just left it to its own devices after a while.)
>
> Forget ports!  /usr/src is bad enough.  Running buildworld, it takes
> longer to build the flippin' compilers (llvm) than it does to build the
> entire rest of the OS.  This is not progress.
>
> --lyndon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/76ca31b7/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Chris Torek]

>Forget ports!  /usr/src is bad enough.  Running buildworld, it takes 
>longer to build the flippin' compilers (llvm) than it does to build the 
>entire rest of the OS.  This is not progress.

Common thread: LLVM is written in C++.

(Also, at some point during compilation, at least some versions
grow quite big, using 20 GB of RAM or whatever.  And C++ is hard
on the linkers as well...)

Chris

[TUHS] Happy birthday, Dennis Ritchie!

[Bakul Shah]

> On Sep 14, 2017, at 3:52 PM, ron minnich <rminnich at gmail.com> wrote:
> 
> The u-root project (u-root.tk) is aimed at creating the *nix tools in Go. The targets are firmware where linux and an initramfs are loaded; and root file systems.
> 
> One goal was to get back to old school unix where the root always included the source to create the commands. In the non-firmware mode all the sources are there
> and they are compiled on demand, save for the 4 go tooclhain binaries and /init.
> 
> It takes about 15 seconds to compile all the tools at present. 
> 
> We've got a demo OS for Chromebooks based on u-root called NiChrome (NiChrome is an alloy of Chrome). This was a summer project for 2 interns here. It helped show that the idea can work to support an OS distro. 
> 
> We've also shown that linux and a u-root initramfs can replace most of UEFI firmware on the Open Compute Platform nodes, reducing boot time from 8 minutes to 17 seconds. Not as fast as the 3 seconds I'd like but you gotta start somewhere, and most of that time is beyond our control. 
> 
> We can always use help if you're interested. I'm ok with C for kernels but don't want to use it again in user mode, hence this 

Nice!

How hard would it be to replace linux with FreeBSD or plan9?
I guess linux->plan9 is progressively less and less h/w
support more and more fun to hack on the kernel! 

[TUHS] Happy birthday, Dennis Ritchie!

[ron minnich]

On Thu, Sep 14, 2017 at 4:06 PM Bakul Shah <bakul at bitblocks.com> wrote:

>
>
> How hard would it be to replace linux with FreeBSD or plan9?
> I guess linux->plan9 is progressively less and less h/w
> support more and more fun to hack on the kernel!


whatever go runs on, u-root will run on, but there are places we had to use
Linux-specific stuff (e.g. netlink) that you'd have to write code for or
you won't get thinks like the ip command or dhcp client, and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170915/6eeb3561/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Kurt H Maier]

On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> 
> Isn't that pretty much just Lennart Poettering and his fan club?
> 

It's right there in the name "GNU" as well.  There's a whole generation
of computer people out here for whom bash and gawk are fossilized in
their substrata, and they get mad when someone suggests maybe other
tools exist.

khm

[TUHS] Happy birthday, Dennis Ritchie! [ really Pottering vs UNIX ]

[Jon Steinhart]

Kurt H Maier writes:
> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > 
> > Isn't that pretty much just Lennart Poettering and his fan club?
> > 
> 
> It's right there in the name "GNU" as well.  There's a whole generation
> of computer people out here for whom bash and gawk are fossilized in
> their substrata, and they get mad when someone suggests maybe other
> tools exist.
> 
> khm

Well, I'd suggest that a lot of this has to do with people who have vision
and people who don't.  When you look at UNIX, you see something created by
a bunch of very talented people who had a reasonably shared vision of what
they were trying to achieve.

I happen to be good friends with John Gilmore, and early Sun employee and
one of the founders of Cygnus Solutions which one can argue did more for
the acceptance of open source than anything else.

Whenever we get into an argument (which is really easy to do with John) over
how to do something he falls back onto "When I was a Cygnus and wrote GNU
tar..."  I always point out that implementing something that was already
defined was way easier than defining something new, and a completely different
skill set.

So I would make the claim that Pottering et. al. are not good definers, and
their model for definition comes from Microsoft which is also not a good
definer.

Along these lines, I think that the demise of UNIX began with AT&T/USL for
the reasons above.  I would much rather use UNIX Version III than UNIX
System III.

Jon

[TUHS] Happy birthday, Dennis Ritchie!

[Theodore Ts'o]

On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote:
> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > 
> > Isn't that pretty much just Lennart Poettering and his fan club?
> > 
> 
> It's right there in the name "GNU" as well.  There's a whole generation
> of computer people out here for whom bash and gawk are fossilized in
> their substrata, and they get mad when someone suggests maybe other
> tools exist.

The use of "GNU" as in "GNU/Linux" is something that was pushed by
Stallman and the Free Software Foundation, and actively abosed, or
mostly ignored by the majority of the Linux community.  See [1] if you
want more details on that whole mess.  Of the distributions, I believe
only Debian has adopted the use of GNU/Linux in their official
documentation, but it's not used by most Debian users or developers
from my experience.

I'll also note that Debian has pushed to use /bin/dash, as their
default /bin/sh, and not /bin/bash, to try to make Debian's shell
scripts to be more portable.  (And for speed reasons, since dash is
faster than bash).

[1] https://en.wikipedia.org/wiki/GNU/Linux_naming_controversy

				- Ted

[TUHS] Happy birthday, Dennis Ritchie!

[Ron Natalie]

Frankly, I don't give a hoot about what the FSF or especially RMS cares
about.   RMS used to show up at my house on a regular basis, and I spent
time in the early FSF with some of the people I really respected other than
RMS (like Len Tower).   RMS while condemning everybody else, cares little
about other than himself and his sociopathically depraved views of the way
the world should be.    And as Forrest Gump would say "Tha'ts all I have to
say about that."

[TUHS] Happy birthday, Dennis Ritchie!

[Larry McVoy]

On Thu, Sep 14, 2017 at 09:40:27PM -0400, Ron Natalie wrote:
> 
> Frankly, I don't give a hoot about what the FSF or especially RMS cares
> about.   RMS used to show up at my house on a regular basis, and I spent
> time in the early FSF with some of the people I really respected other than
> RMS (like Len Tower).   RMS while condemning everybody else, cares little
> about other than himself and his sociopathically depraved views of the way
> the world should be.    And as Forrest Gump would say "Tha'ts all I have to
> say about that."

Amen.  Not a fan.

[TUHS] Happy birthday, Dennis Ritchie!

[Larry McVoy]

On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote:
> On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote:
> > On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
> > > 
> > > Isn't that pretty much just Lennart Poettering and his fan club?
> > > 
> > 
> > It's right there in the name "GNU" as well.  There's a whole generation
> > of computer people out here for whom bash and gawk are fossilized in
> > their substrata, and they get mad when someone suggests maybe other
> > tools exist.
> 
> The use of "GNU" as in "GNU/Linux" is something that was pushed by
> Stallman and the Free Software Foundation, and actively abosed, or
> mostly ignored by the majority of the Linux community.  

As well it should be.  My colors are showing here, but I'm really sick
of the FSF slapping their name on other people's work.  If Stallman
wants it to be called GNU/Linux let him write a kernel.  He didn't,
he can't, yet he wants credit.  I got pretty disgusted back in the day
when everything that was GPLed suddenly became a GNU project.  The GNU
guys have written very, very little code.

They are all about the license, which is fine, but I get off the bus
when they are claiming credit for work they did not do.

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Nickolas]

On Fri, 15 Sep 2017, Larry McVoy wrote:

> On Thu, Sep 14, 2017 at 05:35:35PM -0400, Theodore Ts'o wrote:
>> On Thu, Sep 14, 2017 at 12:39:05PM -0700, Kurt H Maier wrote:
>>> On Thu, Sep 14, 2017 at 12:15:32PM -0400, Steve Nickolas wrote:
>>>>
>>>> Isn't that pretty much just Lennart Poettering and his fan club?
>>>>
>>>
>>> It's right there in the name "GNU" as well.  There's a whole generation
>>> of computer people out here for whom bash and gawk are fossilized in
>>> their substrata, and they get mad when someone suggests maybe other
>>> tools exist.
>>
>> The use of "GNU" as in "GNU/Linux" is something that was pushed by
>> Stallman and the Free Software Foundation, and actively abosed, or
>> mostly ignored by the majority of the Linux community.
>
> As well it should be.  My colors are showing here, but I'm really sick
> of the FSF slapping their name on other people's work.  If Stallman
> wants it to be called GNU/Linux let him write a kernel.  He didn't,
> he can't, yet he wants credit.  I got pretty disgusted back in the day
> when everything that was GPLed suddenly became a GNU project.  The GNU
> guys have written very, very little code.
>
> They are all about the license, which is fine, but I get off the bus
> when they are claiming credit for work they did not do.
>

The GNU Project has a kernel, The HURD, but iirc, it's still as unusable 
now as it has been for decades.  Which is why Linux wound up being the 
de-facto kernel of the GNU system, even while The HURD is still their 
official kernel.

-uso.

[TUHS] Happy birthday, Dennis Ritchie!

[Ron Natalie]

RMS hates UNIX.   That was clear in the original manifesto.   But he's also
a megalomaniac and believes that if you even use a GNU tool your work
becomes his.

[TUHS] Happy birthday, Dennis Ritchie!

[Andy Kosela]

On Saturday, September 16, 2017, Ron Natalie <ron at ronnatalie.com> wrote:

> RMS hates UNIX.   That was clear in the original manifesto.


There can be some truth in it -- after all he came from MIT, which was
anti-unix as much as you can get.

When you say MIT you think about ITS and Lisp.  That is why emacs IMHO
was against UNIX ideals.  RMS was thinking in different terms than Bell
Labs hackers.

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170916/8ebb6252/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Chet Ramey]

On 9/16/17 8:59 AM, Ron Natalie wrote:
> RMS hates UNIX.   That was clear in the original manifesto.   But he's also
> a megalomaniac and believes that if you even use a GNU tool your work
> becomes his.

Nah, this is BS. Stallman might not like Unix, and he clearly has a very
large ego -- as do many of us here -- but that "belief" is just crap.  The
thing that comes closest to it is bison, and the output of bison is
explicitly excluded. There is the issue of GPL libraries (like readline),
and that's a pain for people who want to link with them, but that doesn't
count as "even use a GNU tool."

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

[TUHS] Happy birthday, Dennis Ritchie!

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

If imitation is the sincerest form of flattery,  I suppose those of
us who worked on Unix should be very flattered.  I just wish they had
imitated the programming style and sense of taste.  The gcc
 _manual_ is 500 pages -- bigger than the entire Unix distribution. 
The options alone are almost 100 pages.  The average line in the
source code is an ifdef of some machine you've never heard of.  If
you are doing anything the slightest bit unusual (e.g., increasing the
default stack size) you need a different option for each machine
target.  Hmm, I thought the point of C was to be portable...

I recently started using clang, and I'm never going back to gcc.  I
feel so much cleaner now...

Steve

----- Original Message -----
From:
 chet
.ramey
@case.edu

To:
"Ron Natalie" <ron
@ronnatalie
.com>, "Larry McVoy
" <lm
@mcvoy
.com>, "Theodore Ts'o
" <tytso
@mit
.edu
>
Cc:
<tuhs
@minnie
.tuhs
.org>
Sent:
Sun, 17 Sep
 2017 14:37:59 -0400
Subject:
Re: [TUHS
] Happy birthday, Dennis Ritchie
!

 On 9/16/17 8:59 AM, Ron Natalie wrote:
 > RMS
 hates UNIX. That was clear in the original manifesto. But he's also
 > a megalomaniac and believes that if you even use a GNU tool your
work
 > becomes his.

 Nah, this is BS. Stallman
 might not like Unix, and he clearly has a very
 large ego -- as do many of us here -- but that "belief" is just crap.
The
 thing that comes closest to it is bison, and the output of bison is
 explicitly excluded. There is the issue of GPL
 libraries (like readline
),
 and that's a pain for people who want to link with them, but that
doesn't
 count as "even use a GNU tool."

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170918/2f11b6f0/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie!

[arnold]

Larry McVoy <lm at mcvoy.com> wrote:

> The GNU guys have written very, very little code.

Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ...
Essentially everything that was used from the command line on a
standard Unix system. All reimplemented from scratch.

Many GNU maintainers are active (directly or indirectly) in the
POSIX standard efforts which influences all Unix implementations.

> They are all about the license, which is fine, but I get off the bus
> when they are claiming credit for work they did not do.

This not true of ALL the GNU project maintainers.  Don't tar everyone
with RMS's brush.

'nuff said,

And, IMHO, all this is WAY off topic and probably should be brought
to a close.

Arnold

[TUHS] Happy birthday, Dennis Ritchie!

[Larry McVoy]

I stand by my comment.  I'm friends with the Cygnus folks, they would
tend to agree with me I think.

All that stuff you listed, can you list the things that the GNU/FSF
people have funded?  Because I think there is close to nothing.  All of
that stuff is stuff that came under the GNU umbrella but they didn't do
the coding.

I give credit to RMS for the GPL, that was cool.  But claiming credit
for stuff that GNU/FSF didn't do was not cool.

On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > The GNU guys have written very, very little code.
> 
> Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ...
> Essentially everything that was used from the command line on a
> standard Unix system. All reimplemented from scratch.
> 
> Many GNU maintainers are active (directly or indirectly) in the
> POSIX standard efforts which influences all Unix implementations.
> 
> > They are all about the license, which is fine, but I get off the bus
> > when they are claiming credit for work they did not do.
> 
> This not true of ALL the GNU project maintainers.  Don't tar everyone
> with RMS's brush.
> 
> 'nuff said,
> 
> And, IMHO, all this is WAY off topic and probably should be brought
> to a close.
> 
> Arnold

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Happy birthday, Dennis Ritchie!

[Jon Steinhart]

On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
>
> This not true of ALL the GNU project maintainers.  Don't tar everyone
> with RMS's brush.

What are we supposed to to then?  cpio?

[TUHS] Happy birthday, Dennis Ritchie!

[Warner Losh]

On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> wrote:

> On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> >
> > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > with RMS's brush.
>
> What are we supposed to to then?  cpio?
>

I think libarchive has largely replaced all that and understands zip, lzh,
etc.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170916/6c729829/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Larry McVoy]

On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote:
> On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com> wrote:
> 
> > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> > >
> > > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > > with RMS's brush.
> >
> > What are we supposed to to then?  cpio?
> >
> 
> I think libarchive has largely replaced all that and understands zip, lzh,
> etc.

I think you missed Jon's joke.  If you want more of that, check out this
thread:

https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_cleese_writer_actor_and_tall_person_ama/

[TUHS] Happy birthday, Dennis Ritchie!

[Warner Losh]

On Sat, Sep 16, 2017 at 8:18 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Sat, Sep 16, 2017 at 08:14:47PM -0600, Warner Losh wrote:
> > On Sat, Sep 16, 2017 at 7:55 PM, Jon Steinhart <jon at fourwinds.com>
> wrote:
> >
> > > On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> > > >
> > > > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > > > with RMS's brush.
> > >
> > > What are we supposed to to then?  cpio?
> > >
> >
> > I think libarchive has largely replaced all that and understands zip,
> lzh,
> > etc.
>
> I think you missed Jon's joke.  If you want more of that, check out this
> thread:
>
> https://www.reddit.com/r/IAmA/comments/70arwl/i_am_john_
> cleese_writer_actor_and_tall_person_ama/
>

I think you missed my "Why can't we all get along" moment :)

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/9706f8fb/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Ian Zimmerman]

On 2017-09-16 18:55, Jon Steinhart wrote:

> > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > with RMS's brush.
> 
> What are we supposed to to then?  cpio?

pax posixana!

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] Happy birthday, Dennis Ritchie!

[arnold]

RMS wrote GCC initially.  And Emacs if that's what you use. And GDB
initially as well. RMS did Texinfo (even if you don't like it yourself,
it's a very nice markup language).

Bash, gawk, sed, grep, coreutils were (and still are) maintained by
unpaid volunteers, true, but they all were started for the GNU project.
(Bash in the early days may have been funded by the FSF.)

You're welcome to stand by your comment, but --- as a GNU maintainer for
close to 30 years --- I think you paint with too broad a brush.

More than enough said,

Arnold

Larry McVoy <lm at mcvoy.com> wrote:

> I stand by my comment.  I'm friends with the Cygnus folks, they would
> tend to agree with me I think.
>
> All that stuff you listed, can you list the things that the GNU/FSF
> people have funded?  Because I think there is close to nothing.  All of
> that stuff is stuff that came under the GNU umbrella but they didn't do
> the coding.
>
> I give credit to RMS for the GPL, that was cool.  But claiming credit
> for stuff that GNU/FSF didn't do was not cool.
>
> On Sat, Sep 16, 2017 at 01:20:00PM -0600, arnold at skeeve.com wrote:
> > Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > > The GNU guys have written very, very little code.
> > 
> > Um, let's see: Bash. gawk. sed. grep. coreutils. binutils. gcc. ...
> > Essentially everything that was used from the command line on a
> > standard Unix system. All reimplemented from scratch.
> > 
> > Many GNU maintainers are active (directly or indirectly) in the
> > POSIX standard efforts which influences all Unix implementations.
> > 
> > > They are all about the license, which is fine, but I get off the bus
> > > when they are claiming credit for work they did not do.
> > 
> > This not true of ALL the GNU project maintainers.  Don't tar everyone
> > with RMS's brush.
> > 
> > 'nuff said,
> > 
> > And, IMHO, all this is WAY off topic and probably should be brought
> > to a close.
> > 
> > Arnold
>
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Happy birthday, Dennis Ritchie!

[Chet Ramey]

On 9/17/17 1:19 AM, arnold at skeeve.com wrote:
> RMS wrote GCC initially.  And Emacs if that's what you use. And GDB
> initially as well. RMS did Texinfo (even if you don't like it yourself,
> it's a very nice markup language).
> 
> Bash, gawk, sed, grep, coreutils were (and still are) maintained by
> unpaid volunteers, true, but they all were started for the GNU project.
> (Bash in the early days may have been funded by the FSF.)

I remember multiple FSF efforts to solicit volunteers for named projects.
There were lots of people willing to donate their time and effort. And
at that time, there were very few non-FSF projects licensed under the GPL,
so the issue of "absorbtion" was minor to non-existent.

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

[TUHS] Happy birthday, Dennis Ritchie!

[Kurt H Maier]

On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote:
> 
> I remember multiple FSF efforts to solicit volunteers for named projects.
> There were lots of people willing to donate their time and effort. And
> at that time, there were very few non-FSF projects licensed under the GPL,
> so the issue of "absorbtion" was minor to non-existent.

But that time changed, and was replaced by a time where the FSF pushed
hard on copyright assignment to the FSF, and led to a time where we
wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us
in the present day, where half the tech organizations on earth are so
unwilling to step into the morass that BSD/MIT licenses are making a big
comeback.  

They've spent so much time trying to 'fix' international patent law by
clubbing people with copyright licenses that the company behind the most
popular linux distribution is working on a BSD-licensed kernel.

The history of UNIX and its ilk fascinates me, but only half of it is
technology.  The other half of it is a bizarre forty-year-long license
war, which the partisans refuse to stop fighting, even after they win.

khm

[TUHS] Happy birthday, Dennis Ritchie!

[Warner Losh]

On Sun, Sep 17, 2017 at 12:57 PM, Kurt H Maier <khm at sciops.net> wrote:

> On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote:
> >
> > I remember multiple FSF efforts to solicit volunteers for named projects.
> > There were lots of people willing to donate their time and effort. And
> > at that time, there were very few non-FSF projects licensed under the
> GPL,
> > so the issue of "absorbtion" was minor to non-existent.
>
> But that time changed, and was replaced by a time where the FSF pushed
> hard on copyright assignment to the FSF, and led to a time where we
> wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us
> in the present day, where half the tech organizations on earth are so
> unwilling to step into the morass that BSD/MIT licenses are making a big
> comeback.
>

FreeBSD started out life with lots of GNU/GPL software. After GPLv3 was
released, the project made a conscious effort to move away from all GPL'd
software in the tree. When FreeBSD 12 comes out next year, there's a really
good chance all the GPL'd code will be gone from the tree.


> They've spent so much time trying to 'fix' international patent law by
> clubbing people with copyright licenses that the company behind the most
> popular linux distribution is working on a BSD-licensed kernel.
>

Fun times, that....


> The history of UNIX and its ilk fascinates me, but only half of it is
> technology.  The other half of it is a bizarre forty-year-long license
> war, which the partisans refuse to stop fighting, even after they win.
>

Yea...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/5002e5bd/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Bakul Shah]

> The history of UNIX and its ilk fascinates me, but only half of it is
> technology.  The other half of it is a bizarre forty-year-long license
> war, which the partisans refuse to stop fighting, even after they win.
> 
> Yea...

Even discussions about GPL are viral!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/3a8175e1/attachment.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Chet Ramey]

On 9/17/17 2:57 PM, Kurt H Maier wrote:
> On Sun, Sep 17, 2017 at 02:49:16PM -0400, Chet Ramey wrote:
>>
>> I remember multiple FSF efforts to solicit volunteers for named projects.
>> There were lots of people willing to donate their time and effort. And
>> at that time, there were very few non-FSF projects licensed under the GPL,
>> so the issue of "absorbtion" was minor to non-existent.
> 
> But that time changed, and was replaced by a time where the FSF pushed
> hard on copyright assignment to the FSF, and led to a time where we
> wound up with GPL, GPL2, GPL3, AGPL, LGPL, ad infinitum, which landed us
> in the present day, where half the tech organizations on earth are so
> unwilling to step into the morass that BSD/MIT licenses are making a big
> comeback.

This is all true, though I would argue that the "copyright assignment to
the FSF" was there from the beginning, and concealed by the fact that
the early work was directly funded by the FSF before being handed off.
Certainly they asked me for a copyright assignment early on, and this is
almost 30 years ago. There just weren't that many objections.

I would also argue that the different versions of the license were the
result of people asking for exceptions or clarifiations, and the FSF
attempting to accommodate them.

There's no question that the GNU project is at least as much of a social
policy effort as a technology one. You can't leave either one out of any
history.

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

[TUHS] Happy birthday, Dennis Ritchie!

[Chet Ramey]

On 9/16/17 9:43 PM, Larry McVoy wrote:
> I stand by my comment.  I'm friends with the Cygnus folks, they would
> tend to agree with me I think.
> 
> All that stuff you listed, can you list the things that the GNU/FSF
> people have funded?  Because I think there is close to nothing.  All of
> that stuff is stuff that came under the GNU umbrella but they didn't do
> the coding.

Is that the only criterion? Whether or not someone got paid directly by
the FSF to do something?  Because there are lots of tools that were
originally written by people funded by the FSF and then handed off to
people like me: volunteers who donate our effort.

> 
> I give credit to RMS for the GPL, that was cool.  But claiming credit
> for stuff that GNU/FSF didn't do was not cool.

Denigrating the work of volunteers who explicitly donated their effort
and talent to the FSF is not cool.

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

[TUHS] Happy birthday, Dennis Ritchie!

[Larry McVoy]

On Sun, Sep 17, 2017 at 02:43:33PM -0400, Chet Ramey wrote:
> On 9/16/17 9:43 PM, Larry McVoy wrote:
> > I stand by my comment.  I'm friends with the Cygnus folks, they would
> > tend to agree with me I think.
> > 
> > All that stuff you listed, can you list the things that the GNU/FSF
> > people have funded?  Because I think there is close to nothing.  All of
> > that stuff is stuff that came under the GNU umbrella but they didn't do
> > the coding.
> 
> Is that the only criterion? Whether or not someone got paid directly by
> the FSF to do something?  Because there are lots of tools that were
> originally written by people funded by the FSF and then handed off to
> people like me: volunteers who donate our effort.
> 
> > 
> > I give credit to RMS for the GPL, that was cool.  But claiming credit
> > for stuff that GNU/FSF didn't do was not cool.
> 
> Denigrating the work of volunteers who explicitly donated their effort
> and talent to the FSF is not cool.

OK, let's hit the reset button on this one.  I'm happy that the GNU
project exists, I benefit from it every day.  I am explicitly stating
that I appreciate all of the work that people have done as volunteers,
I'm one of them.

What I'm not a fan of is Stallman getting people to put stuff under the
GPL and then acting like he/FSF wrote the code.  He still claims credit
for GCC to this day and the Stallman GCC was *nothing* like a Ken C
compiler, it was junk.  Tiemann at Sun and then Cygnus, did the real work
to make that thing actually be a reasonable program.  Don't believe me?
Go find a pre-Tiemann GCC and try and compile any reasonable program
with it.  As someone else pointed out, emacs wasn't RMS, it was Gosling.
RMS has a track record of starting stuff, hijacking stuff, and claiming
credit.  That is what I don't like.  I like the GNU project just fine,
I'm not a fan of people claiming credit for stuff they didn't do.

I really soured on on RMS when the FSF took my ls -h/du -h code and
"rewrote" it so they would not have to give me credit.  That's pretty
petty.  He did it because he hated me because BitKeeper wasn't open source
enough for him and the kernel was using it.  So he wanted to scrub the
GNU source base of any of my contributions.  So I stopped contributing.

I'll leave you with a story from the Cygnus days, I was friends with
all three founders.  I was having dinner with Gumby and Michael and
we were discussing RMS.  It was RMS this, RMS that.  Gumby's wife is
German and at one point she says "OMG, you mean RMS!".  We say "yeah?"
She says all this time I thought you were saying "Our mess".  We paused,
replayed the conversation, and were sort of stunned that every sentence
made sense with "our mess".

[TUHS] Happy birthday, Dennis Ritchie!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2095 bytes --]

On Sun, Sep 17, 2017 at 8:12 PM, Larry McVoy <lm at mcvoy.com> wrote:

>
> OK, let's hit the reset button on this one.

​I agree,   Warren said something similar...​




> I'm happy that the GNU
> ​ ​
> project exists, I benefit from it every day.

​ditto.​




> I am explicitly stating
> ​ ​
> that I appreciate all of the work that people have done as volunteers,
> I'm one of them.

​And I'll add, we as a community owe a huge thank you to all of them,
particularly many smaller less known folks that have helped out over the
years.  I wish I could thank them all specifically.

I'll give RMS, Len and original GNU team credit for one really important
thing that happened early on.   It really was the getting a C compiler out
that there that worked (sort of) for so many systems.  This was the key
enabler more than anything else.  The C compiler that anyone could get,
that was freely available, was the watershed moment for all us.  [
​
​And Larry's right, the
 fact the Tiemann mopped up an
​d​
really move
​d​
it from being a toy to being something that was pretty creditable, it what
made the project actually have a
​ long term​
life
​]​
.​
​   If we had not had the compiler, almost all other project would not have
happened.


By getting a compiler that covered the primary architectures being used and
was quickly moved to so many OS's and generated 'good enough' code for so
many folks - we have the options we have today.

The only other compiler at the time, that could have done the same things
was Andy's Amsterdam Compiler Kit (which when it came out, was considered a
"better" compiler)​, but it had a small pay wall.  And 'free' as in 'beer'
was the important difference when it all started.

Like many of other Christiansen style disruptions.... 'worse' technology
was valuable and got better.   And the GNU C disrupted the order in the
software industry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170917/bdd92b6e/attachment-0001.html>

[TUHS] Happy birthday, Dennis Ritchie!

[Chet Ramey]

On 9/15/17 11:40 PM, Larry McVoy wrote:

> As well it should be.  My colors are showing here, but I'm really sick
> of the FSF slapping their name on other people's work.  If Stallman
> wants it to be called GNU/Linux let him write a kernel.  He didn't,
> he can't, yet he wants credit.  I got pretty disgusted back in the day
> when everything that was GPLed suddenly became a GNU project.  The GNU
> guys have written very, very little code.
> 
> They are all about the license, which is fine, but I get off the bus
> when they are claiming credit for work they did not do.

You are associating not having a lot of paid employees with not having a
lot of people do work under the FSF banner. That's not close to true.

It's true that the FSF had few full-time employees. They worked off
grants.

It's not true that these folks didn't produce a lot of work: they did.

It's true that the volunteers who donated their work to the FSF did so
fully understanding what they were doing. Arnold and I have first-hand
experience here.

It's true that there were a number of projects that petitioned to come
under the FSF umbrella, and were accepted.

It's not true that everything released under the GPL became part of the
GNU project and was listed on www.gnu.org/software.

I get that you don't like the FSF model, but the organization and its
volunteers produced -- and continue to produce -- a significant body of
good work. Linux as people think of it today (no, it's not just a kernel)
really wouldn't exist without it.

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

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Norman Wilson]

Random832:

  Just out of curiosity, where does perror(filename), quite possibly the
  *most* common error message on Unix as a whole, fall on your scale? It
  says which of the file location or permissions (or whatever else) it is,
  but not whether it was attempting to open it for reading or writing.

=====

I never liked perror much.  It's a little too primitive:
you get exactly one non-formatted string; you get only
stderr, so if you're sending messages separately to a log
or writing them to a network connection or the like, you're
out of luck.

strerror(errno) hits the sweet spot for me.  Until it
appeared in the standard library (and until said standard
spread enough that one could reasonably expect to find it
anywhere) I kept writing more or less that function into
program after program.

I guess the problem with perror is that it isn't sufficiently
UNIX-like: it bundles three jobs that are really separate
(convert errno to string message, format an error message,
output the message) into one function, inseparably and
inflexibly.

Norman Wilson
Toronto ON

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Random832]

On Tue, Sep 19, 2017, at 08:24, Norman Wilson wrote:
> I guess the problem with perror is that it isn't sufficiently
> UNIX-like: it bundles three jobs that are really separate
> (convert errno to string message, format an error message,
> output the message) into one function, inseparably and
> inflexibly.

Yeah, but you have to do all of that (plus exit, if the error isn't
recoverable) after every single function that might fail.  If the
function didn't exist, you'd have to write your own, so you're not
really any worse off if it doesn't do quite what you want.

if(open one thing < 0) { perror...; exit...; }
if(open another thing < 0) { perror...; exit...; }
if(!malloc...) {perror... exit... }
etc, I'd be half tempted to write a function just for *that*.

BSD's err/warn family is a further refinement on this - it allows
format/arguments, as I complained about in another post, and lets you
specify what file to send output to, and the existence of err vs warn
lets you avoid having exit as a separate step.

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Chris Torek]

>BSD's err/warn family is a further refinement on this - it allows
>format/arguments, as I complained about in another post ...

Yes, which is why I pushed for having something like this.
The final implementation (err, errx, warn, warnx) is not
quite what I had suggested (I had an error-exit-code that,
if 0, meant this was a warning, i.e., don't exit) but the
essence is all there.

>and lets you specify what file to send output to,

It does now.  That was not in the original.  It's a good
idea though.

>and the existence of err vs warn lets you avoid having
>exit as a separate step.

I still like my "exit code" argument with zero for warn,
since it pushes one towards a nonzero exit for all errors.

Chris

[TUHS] Happy birthday, Dennis Ritchie! [ really sun vs dec/apollo --> X and NeWS ]

[Norman Wilson]

On Tue, Sep 19, 2017, at 10:42, Larry McVoy wrote:
> slib.c:1653 (bk-7.3): open failed: permission denied
> 
> which is way way way more useful than just permission denied.

Random832 replied:

  Well. It's less useful in one way - it doesn't say what file it was
  trying to open. You could pass the filename *instead* of "open failed",
  but that still omits the issue I had pointed out: what were you trying
  to open the file for (at the very least, were you trying to read, write,
  or exec it). Ideally the function would have a format and arguments.

====

Exactly.

The string interpretation of errno is just another
item of data that goes in an error message.  There is
no fixed place it belongs, and it doesn't always
belong there, because all that is error does not
fail from a syscall (or library routine).

I do often insert a function of the form

	void errmsg(char *, ...)

in my C programs.  It takes printf-like arguments.
Normally they just get passed to vfprintf(stderr, ...),
though sometimes there is something more esoteric,
and often fprintf(stderr, "%s: ", progname) ends up
in front.

But errmsg never knows anything about errno.  Why
should it?  It's supposed to send complaints to
a standard place; it's not supposed to invent the
complaints for itself!  If an errno is involved,
I write something like
	errmsg("%s: cannot open: %s", filename, strerror(errno));
(Oh, yes, errmsg appends a newline too.  The idea
is to avoid cluttering code with minutiae of how
errors are reported.)

I don't print the source code filename or line number
except for `this shouldn't have happened' errors.
For routine events like the user gave the wrong
filename or it had the wrong permissions or his
data are malformed, pointers to the source code are
just unhelpful clutter, like the complicated
%JARGON-OBSCURE-ABBREVIATION prefixes that accompanied
every official error message in VMS.

Of course, if the user's data are malformed, he
should be told which file has the problem and
where in the file.  But that's different from
telling him that line 193 of some file he doesn't
have and will probably never see contains the system
call that reported that he typed the wrong filename.

Norman Wilson
Toronto ON