Comment by rbanffy
4 hours ago
I think the most important thing Sun got wrong was having no credible onboarding path for new clients. Why would someone invest in SPARC and Solaris when a generic x86 with Linux would do 99% of what the SPARC box would do, for far less? Why would someone who is developing their software on an x86 box with Linux care about deploying it to SPARC+Solaris? Or SPARC+Linux? Or x86+Solaris? There is a huge advantage in deploying to the same platform you develop for, which means, not having a credible desktop will hurt you in the long run.
The same applies to IBM's POWER and Z - how many green field projects are being built for them? Apart from weirdos (such as myself) who is even interested in that? And even then, I will not suggest building anything new on AIX or z/OS, or Linux on either, unless there is a really compelling (such as "we got the hardware for free", or "we really need instruction-cycle latencies to run inference and we can't match that with any other NPU") reason.
Don't get me wrong - I love using uncommon hardware with uncommon OSs (which expose bugs that are affected by endianness, or Linuxisms, or blindly assuming a string is ASCII, or that a file stays put while you use it).
> Why would someone who is developing their software on an x86 box with Linux care about ... Solaris?
There was a time when ZFS would have been a good answer for this. Of course, now it's available on FreeBSD and Linux.
At one point also there was zones, but again, containerization is pretty standard elsewhere now.
I guess also if you go further back, like the Linux 2.6 era, which is close to when Solaris was open sourced ... the 2.6 release involved a concerted effort to improve SMP support. So maybe you'd be interested more in commercial Unix in the 2.4 era, for better SMP. But again, Linux surpassed this ~20 years ago.
And not overcommitting memory.
But Illumos is a real modern viable option over Linux (and *racle Solaris) for server hardware.
I’m interested in oxide, but I feel like you could level the same criticism. The startup cost of using azure or aws is almost nothing. The cost to use oxide is 6 figures?
I feel like they need to run a public cloud just to let people tinker with lightweight stuff and scale up to owning the thing.
That said, I’m also a moron about certain things, and this might be a moronic take.
> but I feel like you could level the same criticism.
Exactly. Oxide builds machines for the few companies that won't go with Azure or AWS, or that got so big Azure and AWS are no longer competitive (and it takes A LOT to be in that space, because pricing is ridiculously flexible). This is a niche market.
The question I always ask is "why would I deploy my software on your platform?". The answer is, most of the time, I wouldn't. I don't want to play platform bingo with company money.
I mean, flashback to 2010 ... zones, dtrace, smf, iscsi and zfs were very well integrated together and lightyears beyond what was available in the Linux space at the time.
Zones were lightweight, more akin to the Linux vserver project or lxc. You could make a zone on its own zfs filesystem, clone the zone (which creates a zfs clone), launch the clone, run a throw-away task, tear the zone down which also discards the zfs snapshot+clone. It was quick and cheap but also half a decade before Docker was released or popularized.
zfs integrated into other parts of the system just as well. eg: iSCSI volumes backed by a zpool and export properties configured in zfs. All of these technologies were built with the idea of being "self-healing." Meanwhile, Linux has a disparate iSCSI daemon, lvm+ext4/reiserfs, initd, and probably 20 different tools to learn if you want to grab metrics across the stack like dtrace on Solaris was capable of.
The out of band management was amazing too. Yes, some x86 hardware had ilom but like everything else in the space, it's bolted on and not truly integrated.
Sun made really nice stuff that outpaced Linux in a lot of ways. The ecosystem came from a time of competing BSDs and looked for paying customers for the engineering marvel they had created. They were used to customers figuring out how to use Unix, and the Linux crowd at the time still fit that rubric. The OS was not optimized for low-latency terminal interaction and thus "felt slow" (aka: Slowaris) but a well tuned DB on Sparc really cooked.
Finally, I went to a few Sun events and had Sun reps come and look at what we were doing. They were definitely happy to help with any kind of outreach/onboarding we needed. The issue was none of "onboarding" but was a lot of "Linux is a movement." In early times, Linux was an anti-corporate movement and some of that energy carried through to the 2010s. It's sadly ironic because Sun itself has roots in open standards and an anti-establishment mentality.
> zones, dtrace, smf, iscsi and zfs were very well integrated together and lightyears beyond what was available in the Linux space at the time.
True, but did you need that? These are all high-end (therefore low-volume) server stuff. I loved that, and their high-end systems with dozens of SPARCs, but I had one customer who had one, and everyone in my company knew they made a terrible decision - they needed a web server, and you could do more with a rack of Dell boxes for a fraction of the Ultra Enterprise [very large number] price tag. They also decided they should run an enterprise application server (they went with Dynamo) instead of Tomcat, so, again, they made a stack (maybe a directed acyclic graph) of bad decisions. I think I facepalmed so much that is the point my hair started falling.
I think you have to keep in mind how IT contracts and purchase decisions are made in large enterprises. You will almost never have an on-the-ground engineer making those decisions. CTOs collect requirements from other high-level managers who collect requirements from other managers and eventually a final list of checkboxes bubble up to the CTO. The CTO evaluates the asks and comes up with their own checklist of features they are looking for then go shopping.
Solution providers then try to check as many boxes as they can on the list. It doesn't have to make sense; you just want to check the box. When a decision is made, the chosen solution gets to the individual engineers to "figure it out". There is also a considerable amount of CYA in all of these decisions. You never want a project to get delayed of not implemented because you as a CTO forgot to check a box. The engineers using a product could decide that the box check doesn't work for them and they can then workaround it, but management (and the solution provider) get to CYA based on whether a box is checked or not.
My favorite flavor of this is when things are lost in translation, and a box gets accidently checked without understanding the actual requirement. Then it suddenly becomes a de-facto feature request because "the box was already checked".
We used it all to great success ... along with our Linux hosts. We had a stack of T1's and eventually a few thumpers (x4500's) which we ended up running a variant of OpenSolaris on. There was also some bigger iron that was humming along on Solaris 8 which provided a very stable environment (until I fat-fingered a command one day.)
Later on, we even ran an ipfilter based router from a T1 on OpenSolaris for decent IPv6 connectivity with link-aggregation+vlans when our Cisco 6509 setup was found to be inadequate for the task.
This. Sun behaved like it had vendor lock-in. Who wants a vendor like that?!
Solaris x86 launched in 1993. I had one on my desk at work in early 1997, running Common Desktop Environment.
Even back then, the CTO of our startup said Sun had missed the boat on dominating x86 Unix. They could have had a larger role in x86 Unix world if they had wanted to. It was definitely a misstep for Sun.
Having said that, throughout the 1990s Sun was amazing. They were even good right up to the Oracle purchase, although by that time RHEL on HP (or Dell) servers was eating their lunch.