[TUHS] tangential unix question: whatever happened to NeWS?
gingell at computer.org
Tue Jan 26 08:25:53 AEST 2021
On 1/25/2021 7:55 AM, Richard Salz wrote:
> ... It had no XDR because it was "reader makes it right" ...
Who made it wrong?
The issues addressed by a presentation layer are there whether you
explicitly make one (XDR) or embed it as a conditional (itself an
overhead.) But it's a tomayto tomahto thing in the end, just as it was
30 years ago, the same only different -- and both distinctions opaque to
who really mattered, the people spending money.
ONC and DCE RPC are both charmingly clear in comparison with the vogue
of protobufs and grpc. They're also both pervasive today well beyond the
platforms that birthed them.
A factor in the arc of NeWS' trajectory not thus far mentioned was its
acceptance by ISVs, though Clem's comment applies:
On Mon Jan 25 03:04:09 AEST 2021, Clem Cole wrote:
> As I have said in other replies: "simple economics always beats
> sophisticated architecture."
In these forums there is a lot of discussions about the technical merits
of this or that technology. It's perhaps unsatisfying to those of us
invested in those technologies but often those merits (or their lack)
don't determine what thrives and what doesn't.
I was a distant observer of, and occasional experimenter with, NeWS as a
technology. My recollections are of impressive capability and
performance (for the time) and elegance. (But then, my TECO skills were
still pretty high at the time so PostScript wasn't confronting in
comparison -- I'm sure I'd think differently coming at it cold now.)
But I was a much closer observer/participant with ISVs. The measure
which most highly correlated with Sun's ascent and success was the "thud
factor" of its applications catalog. When it was actually a printed
thing, at its height the Catalyst catalog had the throw weight of a
large metropolitan area phone book (hopefully not too dated an analogy.)
Few of Sun's customers bought Sun to have Sun, they were bought to run
applications that happened to run on Sun. We sold more Suns if we had
more ISVs on board. If you sold more you got more ISVs. And so it goes
-- the applications "virtuous cycle". When the feedback loop is
positive, it turns "selling" into "order taking" which is a pretty clear
indicator of marketing dollars having been well-spent.
In this relationship there is a tension between platform differentiation
attempts and keeping the flywheel effect of the virtuous cycle going. An
ISV is going to look at platform differentiation as either lubrication
or friction. They're going to resist friction and pursue lubrication. In
the end, NeWS caused too much friction. (A corollary is that an ISV
initially views any differentiation as friction, you need to prove it
can be lubrication, and the ISV's importance to the market determines
how much energy you put into that.)
There was attraction to NeWS because it was provocatively capable. A
number of ISVs, important ones, chose to adopt. But each release of
NeWS, while objectively better, was also sufficiently different that
what initially appeared to be an attractor was unsustainable for the
ISVs to keep up with, even in service of Sun as the then market leader.
Sun's volumes would allow us to get away with imposing a certain amount
of friction of variation with ISVs but there were always limits to it --
the ISVs are trying to run their own businesses with their own
differentiations and agendas to pursue.
For the ISVs, variations of any sort were not a one-time cost. They
repeated as qualification events when new software versions or new
systems were introduced. Just staying still on a platform and with a
vendor costs them. Making them re-do any portion of the initial effort
as well is a significant disincentive. You may not be able to introduce
your new product if they don't come along, they may not come along until
they're sure your new product will sell enough to make it worthwhile. So
successfully lubricating those costs as much as possible was for a lot
of us a primary reason for the Sun's growth. Differentiation "behind
interfaces" as we did in the operating system space helped lower that
cost. Binary compatibility was super important. Gratuitous improvements
that lacked opacity were avoided and we often made vanilla choices. Not
perfect certainly, but good enough.
NeWS stood out for not doing that, and that fact I think had far more to
do with its status today than whether or not the source was available.
Arguably NeWS never got far enough to have the availability conversation
but now I'm back to being too distant from it to really know.
The tensions being maintained in these market dynamics have multiple
factors. It's tempting but hard to pick the one true reason for any
outcome. But the virtuous cycle explains a lot of phenomena. It
certainly doesn't hurt to be excellent in what you do, but sadly, it's
not as determinative as we as practitioners might wish it to be. There's
a reason we can all find examples of technologically superior failures.
That said, I do think the NeWS experience was at least part of what
later informed Java's compatibility especially at the binary level, the
separation of the JVM from the language(s) hosted on it. Not the "one
true reason", but among the mix of considerations.
More information about the TUHS