29 May
2023
29 May
'23
7:28 a.m.
I was wondering if anyone close to Early Unix and Bell Labs would offer some comments on
the
evolution of Unix and the quality of decisions made by AT&T senior managers.
Tom Wolfe did an interesting piece on Fairchild / Silicon Valley,
where he highlights the difference between SV’s management style
and the “East Coast” Management style.
[ Around 2000, “Silicon Valley” changed from being ‘chips & hardware’ to ’software’
& systems ]
[ with chip making, every new generation / technology step resets competition, monopolies
can’t be maintained ]
[ Microsoft showed that Software is the opposite. Vendor Lock-in & monopolies are
common, even easy for aggressive players ]
Noyce & Moore ran Fairchild Semiconductor, but Fairchild Camera & Instrument was
‘East Coast’
or “Old School” - extracting maximum profit.
It seems to me, an outsider, that AT&T management saw how successful Unix was
and decided they could apply their size, “marketing knowhow” and client lists
to becoming a big player in Software & Hardware.
This appears to be the reason for the 1984 divestiture.
In another decade, they gave up and got out of Unix.
Another decade on, AT&T had one of the Baby Bells, SBC, buy it.
SBC had understood the future growth markets for telephony was “Mobile”
and instead of “Traditional” Telco pricing, “What the market will bear” p[lus requiring
Gross Margins over 90%,
SBC adopted more of a Silicon Valley pricing approach - modest Gross Margins
and high “pass through” rates - handing most/all cost reductions onto customers.
If you’re in a Commodity market, passing on cost savings to customers is “Profit
Maximising”.
It isn’t because Commodity markets are highly competitive, but Volumes drive profit,
and lower prices stimulate demand / Volumes. [ Price Elasticity of Demand ]
Kenneth Flamm has written a lot on “Pass Through” in Silicon Chip manufacture.
Just to close the loop, Bells Labs, around 1966, hired Fred Terman, ex-Dean of Stanford,
to write a proposal for “Silicon Valley East”.
The AT&T management were fully aware of California and perhaps it was a long term
threat.
How could they replicate in New Jersey the powerhouse of innovation that was happening in
California?
Many places in many countries looked at this and a few even tried.
Apparently South Korea is the only attempt that did reasonably.
I haven’t included links, but Gordon Bell, known for formulating a law of computer
‘classes’,
did forecast early that MOS/CMOS chips would overtake Bipolar - used by Mainframes - in
speed.
It gave a way to use all those transistors on a chip that Moore’s Law would provide,
and with CPU’s in a few, or one, chip, the price of systems would plummet.
He forecast the cutover in 1985 and was right.
The MIPS R2000 blazed past every other chip the year it was released.
And of course, the folk at MIPS understood that building their own O/S, tools, libraries
etc
was a fool’s errand - they had Unix experience and ported a version.
By 1991, IBM was almost the Last Man Standing of the original 1970’s “IBM & the
BUNCH”,
and their mainframe revenues collapsed. In 1991 and 1992, IBM racked up the largest
corporate losses in US history to the time, then managed to survive.
Linux has, in my mind, proven the original mid-1970’s position of CSRC/1127
that Software has to be ‘cheap’, even ‘free’
- because it’s a Commodity and can be ’substituted’ by others.
=================================
1956 - AT&T / IBM Consent decree: 'no computers, no software’
1974 - CACM article, CSRC/1127 in Software Research, no commercial Software allowed
1984 - AT&T divested, doing commercial Software & Computers
1994 - AT&T Sells Unix
1996 - “Tri-vestiture", Bell Labs sold to Lucent, some staff to AT&T Research.
2005 - SBC buys AT&T, long-lines + 4 baby bells
1985 - MIPS R2000, x2 throughput at same clock speed. Faster than bipolar, CMOS CPU's
soon overtook ECL
=================================
Code Critic
John Lions wrote the first, and perhaps only, literary criticism of Unix, sparking one of
open source's first legal battles.
Rachel Chalmers
November 30, 1999
https://www.salon.com/test2/1999/11/30/lions_2/
"By the time the seventh edition system came out, the company had begun to worry
more about the intellectual property issues and trade secrets and so forth," Ritchie
explains.
"There was somewhat of a struggle between us in the research group who saw the
benefit in having the system readily available,
and the Unix Support Group ...
Even though in the 1970s Unix was not a commercial proposition,
USG and the lawyers were cautious.
At any rate, we in research lost the argument."
This awkward situation lasted nearly 20 years.
Even as USG became Unix System Laboratories (USL) and was half divested to Novell,
which in turn sold it to the Santa Cruz Operation (SCO),
Ritchie never lost hope that the Lions books could see the light of day.
He leaned on company after company.
"This was, after all, 25-plus-year-old material, but when they would ask their
lawyers,
they would say that they couldnt see any harm at first glance,
but there was a sort of 'but you never know ...' attitude, and they never
got the courage to go ahead," he explains.
Finally, at SCO [ by July 1996 ], Ritchie hit paydirt.
He already knew Mike Tilson, an SCO executive.
With the help of his fellow Unix gurus Peter Salus and Berny Goodheart, Ritchie
brought pressure to bear.
"Mike himself drafted a 'grant of permission' letter," says
Ritchie,
"'to save the legal people from doing the work!'"
Research, at last, had won.
=================================
Tom Wolfe, Esquire, 1983, on Bob Noyce:
The Tinkerings of Robert Noyce | Esquire | DECEMBER 1983.webarchive
http://classic.esquire.com/the-tinkerings-of-robert-noyce/
=================================
Special Places
IEEE Spectrum Magazine
May 2000
Robert W. Lucky (Bob Lucky)
https://web.archive.org/web/20030308074213/http://www.boblucky.com/reflect/…
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=803583
Why does place matter? Why does it matter where we live and work today when the world is
so connected that we're never out of touch with people or information?
The problem is, even if they get da Vinci, it won't work.
There's just something special about Florence, and it doesn't travel.
Just as in this century many places have tried to build their own Silicon Valley.
While there have been some successes in
Boston,
Research Triangle Park, Austin, and
Cambridge in the U.K.,
to name a few significant places, most attempts have paled in comparison to the Bay Area
prototype.
In the mid-1960s New Jersey brought in Fred Terman, the Dean at Stanford and architect of
Silicon Valley, and commissioned him to start a Silicon Valley East.
[ Terman reited from Stanford in 1965 ]
=================================
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
5 Aug
5 Aug
3:35 a.m.
OK, you asked for it...
Let me first say that the management style in the Unix Research area was
pragmatic and, in many ways, ideal:
* We were told that the work we were doing this year would probably
take several years before it could be evaluated. This freed us to take
3 months on a project, and, even if the project itself failed it often
inspired other people to "do it right". The management structure was
very static -- organizations would remain unchanged in mission for
several years, with supportive managers up the line.
For example, the year I wrote Yacc (probably one of my most productive
years) I got a rather blah review from my manager (his exact words were
"Why would anyone want to do that?"). The next year I got a massive
raise, and the year after my Boss and I made multiple trips to "sell"
Unix to Bell Labs and AT&T organizations that could make use of it."
In the early 1980s, the V7 port of Unix, which I had been working on for
two years, was out and successful. A new language, C++, was being
developed and showed promise. The Portable C Compiler had been ported
to dozens of different machines, and front ends for FORTRAN and other
languages were becoming available. And AT&T decided to divest the
"thriving" computer company to go out and change the world. I could see
the technology development that was possible and had always enjoyed
delivering useful things to people who needed them. So I offered to
transfer to the Commercial arm as Department Head of a group of 30
people, growing over two years to nearly 60. My supervisors were a
great bunch, and when I told them that, I was sure I could do the job.
However, though, they needed to teach me what was most important and how
to do it right. They were a little surprised by this, but soon we were
technically in sync. The debugger was one piece of software that was a
kluge, and we redefined the formats to handle multiple languages and
delivered C, Fortran, Ada, and Pascal compilers.
However, the business was being run by people who had only worked for a
monopoly, and they did not understand the first thing about marketing.
They didn't know what the languages were, who used them, and what they
did, and, in particular, we had an urgent need for a FORTRAN optimizer
(because DEC's was excellent). My marketing support was one two-hour
meeting every other week. It was always the last person hired into the
marketing group and frequently had not even heard of the languages we
were delivering. So we would talk about what we were doing in places
like Usenix and Universities. After four years, we had built all the
promised languages except for the FORTRAN optimizer, which was written
and working but was held up for documentation. The word had come down
that all the documentation was to be written in a small office in a
small Southern state with no technical footprint whatsoever. The first
draft was worse than you could possibly imagine. Somehow, they had
gotten the idea that an optimizer was a piece of hardware! After quite
a bit of heated discussion, they set out to fix it. But I had had it.
I'd done the job I came to do, doubled the size of the department, and
much of the software from that time is still alive and well today. But
a California headhunter made me an offer I couldn't refuse, and I
didn't.
A couple of years in Silicon Valley taught me a lot about marketing -- I
worked with some superb folks and settled into my post-Bell career. I
also developed a deep interest in the craft of management and am
co-authoring a book on how you turn programmers, doctors, accountants,
etc. into managers. I have had many mistakes to learn from, as well as
many successes.
On 2023-05-29 00:28, steve jenkin wrote:
I was wondering if anyone close to Early Unix and Bell
Labs would
offer some comments on the
evolution of Unix and the quality of decisions made by AT&T senior
managers.
Tom Wolfe did an interesting piece on Fairchild / Silicon Valley,
where he highlights the difference between SV’s management style
and the “East Coast” Management style.
[ Around 2000, “Silicon Valley” changed from being ‘chips & hardware’
to ’software’ & systems ]
[ with chip making, every new generation / technology step resets
competition, monopolies can’t be maintained ]
[ Microsoft showed that Software is the opposite. Vendor Lock-in &
monopolies are common, even easy for aggressive players ]
Noyce & Moore ran Fairchild Semiconductor, but Fairchild Camera &
Instrument was ‘East Coast’
or “Old School” - extracting maximum profit.
It seems to me, an outsider, that AT&T management saw how successful
Unix was
and decided they could apply their size, “marketing knowhow” and client
lists
to becoming a big player in Software & Hardware.
This appears to be the reason for the 1984 divestiture.
In another decade, they gave up and got out of Unix.
Another decade on, AT&T had one of the Baby Bells, SBC, buy it.
SBC had understood the future growth markets for telephony was “Mobile”
and instead of “Traditional” Telco pricing, “What the market will
bear” p[lus requiring Gross Margins over 90%,
SBC adopted more of a Silicon Valley pricing approach - modest Gross
Margins
and high “pass through” rates - handing most/all cost reductions onto
customers.
If you’re in a Commodity market, passing on cost savings to customers
is “Profit Maximising”.
It isn’t because Commodity markets are highly competitive, but Volumes
drive profit,
and lower prices stimulate demand / Volumes. [ Price Elasticity of
Demand ]
Kenneth Flamm has written a lot on “Pass Through” in Silicon Chip
manufacture.
Just to close the loop, Bells Labs, around 1966, hired Fred Terman,
ex-Dean of Stanford,
to write a proposal for “Silicon Valley East”.
The AT&T management were fully aware of California and perhaps it was
a long term threat.
How could they replicate in New Jersey the powerhouse of innovation
that was happening in California?
Many places in many countries looked at this and a few even tried.
Apparently South Korea is the only attempt that did reasonably.
I haven’t included links, but Gordon Bell, known for formulating a law
of computer ‘classes’,
did forecast early that MOS/CMOS chips would overtake Bipolar - used
by Mainframes - in speed.
It gave a way to use all those transistors on a chip that Moore’s Law
would provide,
and with CPU’s in a few, or one, chip, the price of systems would
plummet.
He forecast the cutover in 1985 and was right.
The MIPS R2000 blazed past every other chip the year it was released.
And of course, the folk at MIPS understood that building their own
O/S, tools, libraries etc
was a fool’s errand - they had Unix experience and ported a version.
By 1991, IBM was almost the Last Man Standing of the original 1970’s
“IBM & the BUNCH”,
and their mainframe revenues collapsed. In 1991 and 1992, IBM racked
up the largest
corporate losses in US history to the time, then managed to survive.
Linux has, in my mind, proven the original mid-1970’s position of
CSRC/1127
that Software has to be ‘cheap’, even ‘free’
- because it’s a Commodity and can be ’substituted’ by others.
=================================
1956 - AT&T / IBM Consent decree: 'no computers, no software’
1974 - CACM article, CSRC/1127 in Software Research, no commercial
Software allowed
1984 - AT&T divested, doing commercial Software & Computers
1994 - AT&T Sells Unix
1996 - “Tri-vestiture", Bell Labs sold to Lucent, some staff to AT&T
Research.
2005 - SBC buys AT&T, long-lines + 4 baby bells
1985 - MIPS R2000, x2 throughput at same clock speed. Faster than
bipolar, CMOS CPU's soon overtook ECL
=================================
Code Critic
John Lions wrote the first, and perhaps only, literary criticism of
Unix, sparking one of open source's first legal battles.
Rachel Chalmers
November 30, 1999
https://www.salon.com/test2/1999/11/30/lions_2/
"By the time the seventh edition system came out, the company had
begun to worry more about the intellectual property issues and trade
secrets and so forth," Ritchie explains.
"There was somewhat of a struggle between us in the research group
who saw the benefit in having the system readily available,
and the Unix Support Group ...
Even though in the 1970s Unix was not a commercial proposition,
USG and the lawyers were cautious.
At any rate, we in research lost the argument."
This awkward situation lasted nearly 20 years.
Even as USG became Unix System Laboratories (USL) and was half
divested to Novell,
which in turn sold it to the Santa Cruz Operation (SCO),
Ritchie never lost hope that the Lions books could see the light of
day.
He leaned on company after company.
"This was, after all, 25-plus-year-old material, but when they
would ask their lawyers,
they would say that they couldnt see any harm at first glance,
but there was a sort of 'but you never know ...' attitude, and
they never got the courage to go ahead," he explains.
Finally, at SCO [ by July 1996 ], Ritchie hit paydirt.
He already knew Mike Tilson, an SCO executive.
With the help of his fellow Unix gurus Peter Salus and Berny
Goodheart, Ritchie brought pressure to bear.
"Mike himself drafted a 'grant of permission' letter," says
Ritchie,
"'to save the legal people from doing the work!'"
Research, at last, had won.
=================================
Tom Wolfe, Esquire, 1983, on Bob Noyce:
The Tinkerings of Robert Noyce | Esquire | DECEMBER 1983.webarchive
http://classic.esquire.com/the-tinkerings-of-robert-noyce/
=================================
Special Places
IEEE Spectrum Magazine
May 2000
Robert W. Lucky (Bob Lucky)
https://web.archive.org/web/20030308074213/http://www.boblucky.com/reflect/…
https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=803583
Why does place matter? Why does it matter where we live and work today
when the world is so connected that we're never out of touch with
people or information?
The problem is, even if they get da Vinci, it won't work.
There's just something special about Florence, and it doesn't travel.
Just as in this century many places have tried to build their own
Silicon Valley.
While there have been some successes in
Boston,
Research Triangle Park, Austin, and
Cambridge in the U.K.,
to name a few significant places, most attempts have paled in
comparison to the Bay Area prototype.
In the mid-1960s New Jersey brought in Fred Terman, the Dean at
Stanford and architect of Silicon Valley, and commissioned him to
start a Silicon Valley East.
[ Terman reited from Stanford in 1965 ]
=================================
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
13 Aug
13 Aug
12:16 a.m.
Steve,
thanks for the wonderful account of history.
you were at the heart of it all, very kind of you to answer my Q.
You exactly described the problem at the divested AT&T:
monopolists who didn’t understand ‘marketing’,
especially not of commodity goods,
where 90% gross margins kill sales volumes & profits.
===================
I know I've read a comment about BTL's CSRC being "collegiate" even
"collaborative”.
Was that your experience?
In 1971, Jerry Weinberg published a book with “Egoless Programming”.
I wouldn’t phrase his concept that way, perhaps
“Code Quality comes First”
not just “performant” but well designed, well coded, well documented and easily
maintained.
I wrote & discarded two additional responses, included ‘below the fold’ if anyone
wants to rip into them :)
cheers
steve
On 5 Aug 2023, at 13:35, scj(a)yaccman.com wrote:
OK, you asked for it...
Let me first say that the management style in the Unix Research area was pragmatic and,
in many ways, ideal:
* We were told that the work we were doing this year
would probably take several years before it could be evaluated.
This freed us to take 3 months on a project, and, even if the project itself failed it
often inspired other people to "do it right”.
The management structure was very static -- organizations would remain unchanged in
mission for several years, with supportive managers up the line.
For example, the year I wrote Yacc (probably one of my
most productive years)
I got a rather blah review from my manager (his exact words were "Why would anyone
want to do that?").
The next year I got a massive raise, and the year after my Boss and I made multiple trips
to "sell" Unix to Bell Labs and AT&T organizations that could make use of
it.”
In the early 1980s, the V7 port of Unix, which I had
been working on for two years, was out and successful.
A new language, C++, was being developed and showed promise.
The Portable C Compiler had been ported to dozens of
different machines, and front ends for FORTRAN and other languages were becoming
available.
And AT&T decided to divest the "thriving" computer company to go out and
change the world.
I could see the technology development that was
possible and had always enjoyed delivering useful things to people who needed them.
So I offered to transfer to the Commercial arm as Department Head of a group of 30
people, growing over two years to nearly 60.
My supervisors were a great bunch, and when I told
them that, I was sure I could do the job.
However, though, they needed to teach me what was most important and how to do it right.
They were a little surprised by this, but soon we were
technically in sync.
The debugger was one piece of software that was a kluge, and we redefined the formats to
handle multiple languages and delivered C, Fortran, Ada, and Pascal compilers.
However, the business was being run by people who had
only worked for a monopoly, and they did not understand the first thing about marketing.
They didn't know what the languages were, who used them, and what they did, and, in
particular, we had an urgent need for a FORTRAN optimizer (because DEC's was
excellent).
My marketing support was one two-hour meeting every
other week.
It was always the last person hired into the marketing group and frequently had not even
heard of the languages we were delivering.
So we would talk about what we were doing in places like Usenix and Universities.
After four years, we had built all the promised languages except for the FORTRAN
optimizer, which was written and working but was held up for documentation.
The word had come down that all the documentation was
to be written in a small office in a small Southern state with no technical footprint
whatsoever.
The first draft was worse than you could possibly imagine.
Somehow, they had gotten the idea that an optimizer was a piece of hardware!
After quite a bit of heated discussion, they set out
to fix it.
But I had had it.
I'd done the job I came to do, doubled the size of the department, and much of the
software from that time is still alive and well today.
But a California headhunter made me an offer I couldn't refuse, and I didn't.
A couple of years in Silicon Valley taught me a lot about marketing -- I worked with some
superb folks and settled into my post-Bell career.
I also developed a deep interest in the craft of management and am co-authoring a book on
how you turn programmers, doctors, accountants, etc. into managers.
I have had many mistakes to learn from, as well as many successes.
===================
Source Code, especially when Portable, puts power in the hands of users/ consumers, taking
it away from Vendors exploiting need:
- Can be no "Vendor Lock-In", used extensively to 'mine' user
bases for revenue.
Economics has the notions of goods being excludable (owners/vendors
control who uses a good)
and rivalrous (only one customer can consume the good, thus
preventing others).
Source Code is 'non-excludable' - if you've got all the
code for something, an 'owner' can't stop you running it.
Neither is it 'rivalrous' - my using the Code doesn't stop
anyone else using it vs I eat an Apple, you can't eat it.
- Users can't be coerced into 'upgrades' or 'orphaned'
when products are dropped or a company goes away.
Having the source means a vendor never has to say 'sorry'.
maybe.
With the invention of Portable Systems and Apps, a whole new layer of the Computing
Industry appeared:
ISV's like Oracle (Indep Software Vendors)
They got to exploit Customers (denying customers access to own data),
while hardware vendors lost "use us or else" control.
I think I've identified three things that Doug Mcilroy's group did / knew, apart
from his 4 part "Unix Philosophy"
(of building reusable Tools - allowing not-as-bright ppl like me to "Stand on
the Shoulders of Giants")
A: Artefacts: Code, distribution, self-hosting tools & 'toolchain',
basic Unix Userland tools & online documentation
B: Process: Collegiate, Collaborate, 2-way Sharing of ideas/code. "All of Us
is better than any one of Us"
C: Software Economics: a) Bill Gates Law, “it’s about volume”: selling
'000's of units, cost/unit is v. low, sell millions: invoicing costs more than
code.
b) Code developers need to invent
reasonable ways to get paid for their work.
Android is given away, but Google
make money on the "Play Store"
Sometimes, there's no obvious
substitute to "Pay for Support / License" :(
[ the Economics rules are the same for Moore's Law. ]
[ Sell lots, drop prices and High Elasticity of Consumer Products guarantees
higher profits ]
Points where GNU and Unix differ fundamentally:
- for Unix, it's all about working Code: 'show me yours, don't just
criticise', Clean, high quality, 'minimal' code was normalised + some doco
- BTL researchers, mostly, weren't inflating their ego or looking for power.
They collaborated and shared ideas, improved others work.
- BTL understood 'things cost money' and their work was intended to lead
to 'products'.
They didn't agree with the 'management' Business Model, but
weren't "Freedom!" Zealots... Cheap & 'everywhere' is good
:)
- BTL Research chose "Talent" very well, including
"self-starters": Curious intellects able to take Initiative & challenge
norms.
- BTL researchers had the luxury of "all the time you need" to do
'step-wise refinement', rewrites, explore multiple alternatives, profile &
'tune',
and modify core concepts / tools / languages. Iterating their way to great
software.
Deadlines and Deliverables are central to Business Projects - but anathema
to Research, where you don't know the Question even.
===================
Gordon Bell notes that:
in 1984 there were 91 computer manufacturers in the USA,
in 1990, just four of them were left: IBM, HP, DEC and Data General
Within a decade, only IBM & HP were left, with IBM having declared
‘largest losses in US Corporate history’, twice, 1991 & 1992.
The MOS / CMOS microprocessors were speeding up at 60%/year,
multiples faster than ECL & TTL improved.
Bell saw this early.
Presume one of the reasons he left DEC in 1983.
Gordon Moore and his team solved a Profit Maximisation problem
with “Moore’s Law”.
Old School AT&T management didn’t understand either:
- they were competing in Commodity markets for hardware & software
- their timing on hardware could not have been worse.
The Intel juggernaut & CMOS & RISC vendors
were about to over-run ’traditional’ firms
Unix, C and the new toolchains created an entirely new
class of Systems & Software:
Portable
Which created the ISV’s (Indep. Software Vendors).
Oracle and SAP have done very, very well off the back
of your invention :-/
Hardware and Software are Symbiotic:
neither thrives without the other.
Customers buy Software and what it can do for them.
But they have to run it on hardware.
Portable code allowed selection of “Best Option”.
The Open Systems and Portability revolution,
begun at Bell Labs, took this to a whole new level.
Customers wanted & needed zero barriers
to entry (and exit) - their data and systems
had to ‘just run’…
Which made 1980’s computing competitive in a way
it had never been for the previous two decades.
Vendors still sought ways to “Lock in” customers,
but it wasn’t hardware anymore.
The original AT&T management who thought
they’d all get rich of Unix in 1984 can’t be blamed
for missing this trend.
It was entirely outside their experience.
I wonder what the Shareholders thought?
===================
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
264
days inactive
340
days old
2 comments
3 participants
participants (3)
-
scj＠yaccman.com -
steve jenkin -
Steve Jenkin