Well, the Alpha no longer exists because Intel bought it and stopped making it.
DEC's demise is a little more complicated, as DEC had been selling of parts trying to stay alive before what was left was acquired by Compaq.
Far that matter, DEC competitor Data General suffered a similar fate. They made the AViiON line, originally based on the Motorola 88000 RISC processor, and shifted to Intel when Motorola dropped the 88000.
DG was eventually purchased by storage vendor EMC, who bought them to get the CLARiiON storage system, and promptly stopped making the computer.
But yeah, it pays to be the 800lb gorilla. It's yet another acquisition made to buy and kill off a potential competitor.
Just by way of reminder, silicon photonics is very much an SOI-based technology. See http://www.advancedsubstratenews.com/tag/photonics/ for articles explaining the role of SOI in photonics by Intel, IBM, Luxtera, Sony and more.
I'm not disagreeing with your analysis, but the reason DEC no longer exists is that Intel bought it as part of the settlement of the patent lawsuit brought by DEC against Intel.
Intel had no reason to keep producing the Alpha or keep the DEC name past the agreed period. It pays to be the 880 lb. gorilla.
It might be more accurate to say the *market* gave up on SPARC.
SPARC is a RISC processor, and an outgrowth of rethinking the architecture of a CPU. Previous generations had all been CISC architectures, with huge instruction sets. But realization set in that most of those instructions weren't actually used because compilers didn't generate code that used them. Why not design a CPU with only the basic instructions from which others could be constructed, and concentrate on making them as fast as possible, then let compilers do the work?
Sun created the SPARC. HP had Precision Architecture. DEC created the Alpha. AMD had the 29000. But takeup was limited to server space, and steady improvements by Intel ate into any advantages RISC possessed. CISC was just as fast as RISC, and was *cheaper*.
Sun wasn't the only one who backed off. DEC no longer exists. HP moved away from PA to systems based on Intel architecture. AMD concentrated on being an alternate supplier of Intel architecture chips.
Backing away from SPARC didn't kill Sun. Being unable to compete did. You can make an argument that developing SPARC used resources Sun might have better applied elsewhere. If I'm a customer looking at Sun servers, and I see SPARC and Intel-architecture Opteron models, they can do the same things, and Opteron is cheaper, which way do I jump?
SPARC may well be technically superior, but customers aren't buying technical superiority - they're buying bang for the buck. If you offer a product that costs more, you better have something the *customer* will see as justification to pay the higher price. SPARC wasn't it.
Let's see Apple has it's own HW (silicon, boards, and I/O specs) and SW (OS, and applications). Sounds vertically integrated to me. Only thing missing is manufacturing but if foxcon has more problems, this many change.
Seems the pendulum has swung back the other way and the industry is still stuck in 'core competency' mode -- or rather chucking competency and innovation.
Apparently on the marketing front Arista supports the buzzwords of SDN and actually supports some version of OpenFlow.
But privately Andy believes OpenFlow is too limited, low level and incompatible with today's networks to gain traction.
He does believe there will be more mangeable, configurable nets using some form of SDN with each major company probably doing their own API thing for the next several years.
It appears that Andy can get headline articles written based just on his hallway uterings!
His comments on Sparc were referring to the vertical integration of silicon, system h/w and software. This is difficult for any company to keep delivering on. Being able to use the best of current breed of silicon and differentiating on the software is where the system companies are finding success.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.