Makeing "Gated"

[Root Boy Jim]

In <152790 at pyramid.pyramid.com> eric at pyramid.pyramid.com (Eric Bergan) writes:
?In article <129125 at uunet.UU.NET> rbj at uunet.UU.NET (Root Boy Jim) writes:
?>In <151920 at pyramid.pyramid.com> eric at pyramid.pyramid.com (Eric Bergan) writes:
?>?In article <128287 at uunet.UU.NET> rbj at uunet.UU.NET (Root Boy Jim) writes:
?>?> <151385 at pyramid.pyramid.com> eric at pyramid.pyramid.com (Eric Bergan) writes:

We really should start our own newsgroup :-)

?>It's very simple.
?>Start with the ucb universe and snarf anything you need from the att one. 
?>Resolve conflicts where they occur.
?
?	Would be nice if it were this simple. Unfortunately, the details
?get a little more complex.

Of course the details get hairy, but the basic idea is simple.
And you won't get anything done if you sit around lamenting
about how hard it is.

?Lets take signals, for example. Do you
?follow the bsd style and not have to reset the signal handler, or the
?"standard" att style (yes, I know variants have been introduced) and
?require resetting the handler after each signal? Can't have it both
?ways in the same API, and yet there are programs that expect each
?type of behavior.

You assume neither style and explicitly reset the signal handler
inside the handler itself. Portable to either environment.

I don't think any program insists that signals be unreliable
in the window between entering the handler and resetting the signal.

?	As for why someone would care - well, without getting philisophical,
?all I can say is that at least Oracle required zombies to be valid targets
?for signals.

Sending signals to zombies is clearly meaningless.
Some one should tell this to Oracle.
Fix the right piece of code.

? But so far, there hasn't been enough
?of a requirement from our customers to warrant a project being started.
?(While not rocket science, its not trivial, either. As with all projects,
?there would be a cost associated with doing it, and so far there haven't
?been enough requests to justify that cost.)

A very short sighted decision. That's why you're so far behind DEC and Sun.
You're going to have to do the work anyway, so you might as well
start doing it now.

?>You are wrong. Users do not want dual universes. They want
?>(with apologies to the Borg) The Best Of Both Worlds. 
?
?	I'll throw this one open to the general user community. Is this
?a hot requirement? If so, please let us know. We've not heard it in the
?past. Either post something here, let your favorite sales person
?know, or feed it back through the user group.

Unfortunately, "hot requirements" have little to do with The Right Thing.

?>Which problem is more interesting, the confusion of progress,
?>or the frustration of stagnation?
?
?	Well, we have significantly different views of the Pyramid
?customer base, but many of the customers that I talk to would actually
?like to see less "progress" in our operating systems. They feel that
?major new functionality even once a year is too frequent. Basically, they
?have production applications to run and maintain, and once these applications
?are deployed, they don't really need us to rock the boat with new enhancements.

OK. Once a year, you sync up with BSD, Sun, AT&T, and whoever else
you think is an industry leader. Take a year to port and release it.

You can't even keep to that schedule.

?	I don't want to take this argument too far, because clearly there
?are other customers (such as yourselves) that want to see us stay current
?with the very latest releases that come out. 

It's not how far you take the argument; the problem is that you're
going in the wrong direction. Yes, progress must be tempered.

?	Balancing between these extremes is difficult. We always
?encourage our customers to let us know what they would like to see us
?provide.

Of course, it is another thing to heed those words.

?(After all, you are our only source of revenue!)

Not any more.

?As I've
?mentioned, posting here, talking to our sales force, or working through
?the user group are all good ways of letting your views be known, and
?helping us judge exactly what you want.

We want what Berkeley had FIVE YEARS AGO!
HOW LOUD DO WE HAVE TO SAY THIS?

?>?But that would break some segment of working
?>?implementation issues. But that would break some segment of working
?>?programs, and I don't think the bulk of our customers would appreciate
?>?that.

You neglect to mention that AT&T regularly breaks code and has
its own share of gratuitous changes as well. First they rotated the
manual sections, then they made you buy the DWB to get online manuals.

Ln(1) is now broken. Consider: rm -f a b; touch a b; ln a b;
Historicly, the ln has always failed. Now it succeeds.

I am not aware of many other System V bugs because I rarely use it.

?>You've got All The Right Stuff, but you haven't got it all in one place.
?
?Some don't have SunOS or Ultrix code - they have stricly SVID compliant
?code, for instance. Or POSIX compliant. Also, I don't believe that SunOS
?and Ultrix are completely source compatible with each other, either.

No, but much closer than with Pyramid.
And you're not POSIX compliant now either.

?	Actually, a major segment of our customer base is att based.

Because you don't treat your Berkeley customers right.

?>[I deleted comments about your "joke" of SVR4 vs OSF universes]
?>
?>Some private mail with one of your coworkers indicated that
?>about half of your technical people would quit if y'all did that.
?
?	I'm among that number, by the way.
?
?>Anyway, I'm glad to see that you're moving towards one system.
?>Dual universes were once an intrigueing concept; now they are passe.
?
?	I don't know about passe,

You don't know about passe, but you'll quit if they do?
Make up your mind.
-- 
		[rbj at uunet 1] stty sane
		unknown mode: sane