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

[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

[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!

[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!

[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!

[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 ]

[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 --> 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] 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] 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.