> Sun had become bored with the mechanics of running a business.
I would contend that Sun was never interested in running a business. They always cared more about building amazing technology and suffered the sales to make money.
You can't deny that Sun hardware was top tier and always ahead of its time (until Oracle bought them).
Edit: I had on rose colored glasses. I was thinking of late 90s SUN. They did in fact start getting crushed in the early 2000s.
> You can't deny that Sun hardware was top tier and always ahead of its time (until Oracle bought them).
From Brian Cantrill's original HN comment in 2011(<a href="https://news.ycombinator.com/item?id=2287033">https://news.ycombinator.com/item?id=2287033): "I never hesitated to tell anyone that was listening that our x86 boxes were starting to smoke the hell out of UltraSPARC". SPARC stopped being ahead of its time way before being bought by Oracle.
>> You can't deny that Sun hardware was top tier and always ahead of its time (until Oracle bought them).
> SPARC stopped being ahead of its time way before being bought by Oracle.
You seem to be focusing strictly on performance, but there were other factors: e.g., remote management is still a bit of a mess with x86. With SPARC everything can be done on the CLI (serials consoles or SSH), with x86 quite often you're still clicking on "open KVM window" for so many things. And of course many/most vendors make you purchase an 'advanced license' to use the remote KVM functionality of the LOM system.
It's path dependence. If you built a Sun-syle x86 server with a serial console and inserted a random Linux installer CD, the installer would probably only output VGA and thus it wouldn't work.
> I would wager that almost no Linux installs are done by CD or displaying VGA anymore (maybe 0.01%).
When one of your Proxmox (or XCP-ng, or VMware/Nutanix/OpenStack) servers won't boot and you need go into single-user/rescue mode, then talk to me about the convenience or not of a remote KVM (versus having to drive to the DC and hook up the crash cart).
It's all very well if all you manage is VMs/instances, but some of us deal with the hardware that those VMs run on, and things break.
That 0.01% of servers is probably the layer that the other 99.99% run on (and yes, a lot of that 0.01% can also be automated, but if PXE isn't working (or you're getting strange CPU3VOLT or SLOT17ECC or BUS1RESET errors) then neither is re-imaging).
It's a very good habit to make your Proxmox hosts PXE-bootable to avoid this kind of situation. We're using this approach with Talos as Kubernetes host and it works very well.
Because pretty much every BMC out there in last decade is shipping AST2400/2500/2600 which include VGA and you want to deal with cases where people do not know how to navigate serial console, especially in case of windows servers
jedberg · · focus · HN ↗
I would contend that Sun was never interested in running a business. They always cared more about building amazing technology and suffered the sales to make money.
You can't deny that Sun hardware was top tier and always ahead of its time (until Oracle bought them).
Edit: I had on rose colored glasses. I was thinking of late 90s SUN. They did in fact start getting crushed in the early 2000s.
ragall · · focus · HN ↗
From Brian Cantrill's original HN comment in 2011(<a href="https://news.ycombinator.com/item?id=2287033">https://news.ycombinator.com/item?id=2287033): "I never hesitated to tell anyone that was listening that our x86 boxes were starting to smoke the hell out of UltraSPARC". SPARC stopped being ahead of its time way before being bought by Oracle.
throw0101a · · focus · HN ↗
> SPARC stopped being ahead of its time way before being bought by Oracle.
You seem to be focusing strictly on performance, but there were other factors: e.g., remote management is still a bit of a mess with x86. With SPARC everything can be done on the CLI (serials consoles or SSH), with x86 quite often you're still clicking on "open KVM window" for so many things. And of course many/most vendors make you purchase an 'advanced license' to use the remote KVM functionality of the LOM system.
frutiger · · focus · HN ↗
wmf · · focus · HN ↗
pamcake · · focus · HN ↗
frutiger · · focus · HN ↗
throw0101a · · focus · HN ↗
When one of your Proxmox (or XCP-ng, or VMware/Nutanix/OpenStack) servers won't boot and you need go into single-user/rescue mode, then talk to me about the convenience or not of a remote KVM (versus having to drive to the DC and hook up the crash cart).
It's all very well if all you manage is VMs/instances, but some of us deal with the hardware that those VMs run on, and things break.
That 0.01% of servers is probably the layer that the other 99.99% run on (and yes, a lot of that 0.01% can also be automated, but if PXE isn't working (or you're getting strange CPU3VOLT or SLOT17ECC or BUS1RESET errors) then neither is re-imaging).
wmf · · focus · HN ↗
ragall · · focus · HN ↗
wmf · · focus · HN ↗
p_l · · focus · HN ↗
wmf · · focus · HN ↗
p_l · · focus · HN ↗
p_l · · focus · HN ↗