Solaris died a long time ago, regardless of what roadmaps say. It died the day Oracle acquired it. Even if Oracle invested heavily in Solaris, it's hard to imagine how they could match Linux long term.
Solaris had opportunity to compete with Linux, by becoming a real open source project. Not in the Android sense ("we let you see and modify it, but we don't let you participate in the development), but in the Linux sense. Do all your development in the open, kill the bureaucracy, make other companies trust that they aren't being taken advantage of if they contribute to it. Sun attempted to go in this direction, but Oracle killed it.
The SmartOS / Illumos community is pretty vibrant and active! Also the OpenZFS community is also very much alive. Yeah Solaris could have been bigger if they hadnt killed Opensolaris but I think things turned out pretty well actually!
The Omni folks got this working for OmniOS[1]; we would love SmartOS support on AWS, but (as one might imagine) we at Joyent don't have an immediate commercial interest in it. That said, we do have a clear indirect commercial interest in it, and we would happily engage/encourage any effort for SmartOS on AWS. Given that it's been done for OmniOS, it shouldn't be difficult...
Microsoft supports Windows on multiple cloud providers, while competing vigorously to be the "best cloud" for running Windows.
Joyent's business team surely knows the difference between demand generation for SmartOS (anywhere) and a marketing pitch for Joyent as the "best cloud for running SmartOS at scale".
There is nothing indirect about a marketing funnel that makes it easy for the largest developer community to evaluate your operating system.
The details below may be useful for whoever wants to get the latest images running on EC2 again. Unfortunately, I don't have time to tinker with this stuff after-hours anymore:
Required patches from Delphix illumos tree (at the time):
58b782ef6ec93fef26ab349aff81e8748f673b24 32722 Xen PV disks don't have properties set
09846dfe2cfc30fe54d80637aea0aa38b64127ed 33942 Creating xdf.conf file causes the kernel to panic on boot
2c4f787714ba44c84b8ed4dfb7ad05288c942a0e 34224 Xen HVM VM with 32 VCPUs hangs on boot
1fc3b35c42d5aeadb1e9c8b7308f3c33cfba00ac 34424 Some PV devices should not be configured in HVM mode
91f305d4c307729116dfa89022334083bf817058 34508 Expose xdf minor nodes when in PV-HVM mode
718bba6535f2a3423643aede0067775730a15a23 35310 Fix iostat on the EC2 instances
Files that had to be updated in the the vanilla SmartOS image after building the smartos-live tree:
The version I am running doesn't work with more than one CPU (SmartOS Live Image v0.147+ build: 20160622T220759Z), and I think the network interface defaults to using the realtek 8139 driver.
This was enough for my situation, but not optimal for heavy use.
Solaris had a lot of useful and unique features, and was backed with a substantial support apparatus. If you developed a feature for Solaris that got in, it'd be documented and supported to quite a high degree.
If you wanted support from the primary vendor of your OS, and wanted a pretty high-quality Unix, Solaris would fill that niche for you. There's definitely a market for that, but not nearly enough to keep Sun or Solaris alive.
No, the ability for the machine to not crash or need to be rebooted for long periods of time. Linux has gone completely downhill in this respect for the past few years. Switching to Solaris on my main Unix workstation has been a breath of fresh air compared to the constant naggering from Linux systems for updates, but I like old school...because it seems to 'just work'.
ZFS storage layers built on OmniOS/OpenSolaris/Illumos enjoy more years of maturity (and thus demonstrated stability) than upcoming versions for Linux/Ubuntu. If you have to build large storage in-house, stability is a high priority.
That's the thing when you look at it from today's standpoint and you are correct there. But jump back to January 2005. You got DTrace and ZFS and branded Zones. Way ahead of the curve. Just look at that release. But sadly it all got overshadowed by Oracle.
One of the things that stands out to me personally is that Illumos/ Solaris values debugging (both in-situ and postmortem) far more than other platforms. Both ZFS and dtrace are brilliant examples of this as well as mdb but I'm much less well versed in the later. If you're interested I'd recommend browsing through posts of perhaps to two largest Illumos deployments.
Exactly. You couldn't build OpenSolaris without proprietary blobs, the build process only worked correctly inside Sun's network, code contributions were not accepted. Under Sun the OpenSolaris project had already started to take technical decisions behind closed doors more and more (it was easy to confirm this from their bug tracking system that differentiated between public and private tickets). I dont understand why people think Sun was the open source god in the sky. Perhaps too much emotional attachment from the "good old days", but I can't relate.
6 or so years ago I thought Solaris would have a fighting chance. I was naive.
Back in the 90s Solaris ruled the world and you could be fired for bringing a Linux system into the building, everyone assumed open source was insecure in the 90s. It was immature so it was scary for the suits back then. Things have changed a lot lol.
That was a pretty sensible position in the 90s. Linux was in its infancy, and the commercial UNIX vendors all had very robust offerings (Solaris/Tru64/AIX/HP-UX/IRIX; all very good systems at the time).
I brought Slackware to my then boss @ Chevron in 1991 or so and showed him it booted fine from two floppies. He was like but every engineer already has a DECstation! What do we need that for?
This from a company that had UNIX on everything from a Cray down to a desktop. It wasn't obvious from early on that Linux would eventually spell doom for both desktop and servers but here we are.
It's incredible hard to figure out what Oracle is planning and they really need to make their intentions more clear. If they don't, Solaris and SPARC will just die off, and to be fair, that might be the plan.
Right now we don't know if Solaris 11.Next is a maintenance release or if they are just moving to something more akin to a rolling release, as some people have suggested. Unless all the question currently floating around are addressed by Oracle, no sane person would base new infrastructure on neither Solaris, nor SPARC.
Perhaps Oracle want to move all Solaris and SPARC deployments in-house, but what sense would that make?
AFAICT, Oracle bought Sun to get at their (really x86_64) hardware business, to compete with HP/IBM. One quick ref that kinda shows this angle: https://www.quora.com/Why-did-Oracle-buy-Sun
The rest of Sun was just extra. So Oracle's seeing if they can use them. If they find that they can't they'll just dump them. As they're doing now.
Sun's hardware business is mostly irrelivant, and both IBM and HP are in the process of switching away from providing hardware (Especially IBM). SPARC was already mostly dead by the time that Oracle bought Sun.
The prize Oracle was after is Java, and they have already begun the long process of squeezing large enterprises with Java "commerical" features flags.
My guess is Oracle bought Sun for control of Java and perhaps Solaris and server hardware design. Perhaps combining their database, Solaris and server hardware would give full control of the platform. But things have shifted and cloud computing is the new big thing so all that they acquired has less value to them.
Even if Oracle plans to reduce the scope of Solaris 12 or moving to a rolling release like Windows 10, they could have avoided this scrutiny by keeping the Solaris 12 name instead of inventing Solaris "11.next". Perhaps they thought existing Solaris 11.x customers would be more likely to upgrade to 11.next than 12.
It's reasonably safe to assume that 'next' is a placeholder for .4, .5, .6 and so on. This seems to me more like a project management issue than a technical issue. I.e. the scope of Solaris 12 was too ambitious and individual teams were finishing their work on different schedules. Rather than have everything sit idle, they are releasing it piecemeal under the Solaris 11.x umbrella.
To the extent that there are commercial ISVs supporting Solaris it also makes their jobs a little easier since they can deal with change in smaller increments.
We actually used to run OpenSolaris in production for quite a while. It took some time, but it's safe to say that FreeBSD has properly come forward and filled in those shoes quite readily.
I doubt they exist, but if there are any Solaris fans that haven't tried FreeBSD yet, you really should.
Oh, there is one thing I _do_ miss: Solaris was ABI compatible between the x86 and x86_64 kernels. You could run code (or kernel modules, even) compiled for one platform against the other. FreeBSD is not yet ABI-compatible between the two; it's been a todo list item going back to FreeBSD 8 or 9, I think.
I can think of four reasons for Oracle staying at Solaris 11.x instead of planning a new Solaris 12 release:
1. Some enterprises have a general policy of only running versions N and N-1 of software. The release of Solaris 12 would trigger a review of Solaris 10 in those environments, which would accelerate the trend away from Solaris. (The Solaris 10 to Solaris 11 upgrade is particularly disruptive due to the switch to IPS packaging and the networking changes, so migration to Linux is of comparable complexity.) Immediate loss of legacy support revenue for both Solaris and SPARC hardware.
2. Solaris 11 support is promised until at least 2031, or 2034 if customers pay for extended support [1]. A new release would just add another stream to support with at least 15 years of overlap.
3. The old SVR4 packaging was so slow and Live Upgrade so unreliable that new releases were required to stop patch bundles from getting too unwieldy. IPS is much faster and safer so it is more technically feasible to stick with the same major release.
4. I'd tend to agree with Adrian Cockcroft that the interesting things are happening elsewhere now [2]. There may not be enough reason for customers to upgrade. Oracle can avoid the story of a failed release by not doing the release in the first place.
39 comments
[ 2.7 ms ] story [ 94.7 ms ] thread[0] https://news.ycombinator.com/item?id=13079370
[1] https://www.thelayoff.com/t/KTCW4qz
However, thanks for the link.
Solaris had opportunity to compete with Linux, by becoming a real open source project. Not in the Android sense ("we let you see and modify it, but we don't let you participate in the development), but in the Linux sense. Do all your development in the open, kill the bureaucracy, make other companies trust that they aren't being taken advantage of if they contribute to it. Sun attempted to go in this direction, but Oracle killed it.
See OmniOS[2] - an Illumos distro that provides AMIs [3].
BTW, SmartOS and OmniOS both have support for Linux binaries within Zones, a superior Container technology.
[1] http://www.dilos.org
[2] https://omnios.omniti.com
[3] https://omnios.omniti.com/wiki.php/Installation
[1] https://omnios.omniti.com/wiki.php/Ec2Ami
Joyent's business team surely knows the difference between demand generation for SmartOS (anywhere) and a marketing pitch for Joyent as the "best cloud for running SmartOS at scale".
There is nothing indirect about a marketing funnel that makes it easy for the largest developer community to evaluate your operating system.
https://twitter.com/aszeszo/status/658115638683115521
The details below may be useful for whoever wants to get the latest images running on EC2 again. Unfortunately, I don't have time to tinker with this stuff after-hours anymore:
Required patches from Delphix illumos tree (at the time):
58b782ef6ec93fef26ab349aff81e8748f673b24 32722 Xen PV disks don't have properties set 09846dfe2cfc30fe54d80637aea0aa38b64127ed 33942 Creating xdf.conf file causes the kernel to panic on boot 2c4f787714ba44c84b8ed4dfb7ad05288c942a0e 34224 Xen HVM VM with 32 VCPUs hangs on boot 1fc3b35c42d5aeadb1e9c8b7308f3c33cfba00ac 34424 Some PV devices should not be configured in HVM mode 91f305d4c307729116dfa89022334083bf817058 34508 Expose xdf minor nodes when in PV-HVM mode 718bba6535f2a3423643aede0067775730a15a23 35310 Fix iostat on the EC2 instances
Files that had to be updated in the the vanilla SmartOS image after building the smartos-live tree:
platform/i86hvm/kernel/drv/amd64/cmdk platform/i86hvm/kernel/drv/amd64/rtls platform/i86hvm/kernel/drv/amd64/sd platform/i86hvm/kernel/drv/amd64/xdf platform/i86hvm/kernel/drv/amd64/xnf platform/i86hvm/kernel/drv/amd64/xpv platform/i86hvm/kernel/drv/amd64/xpvd platform/i86hvm/kernel/drv/xpvd.conf platform/i86hvm/kernel/misc/amd64/hvm_bootstrap platform/i86hvm/kernel/misc/amd64/hvm_cmdk platform/i86hvm/kernel/misc/amd64/hvm_sd
I would be cool to see official SmartOS images on EC2!
The version I am running doesn't work with more than one CPU (SmartOS Live Image v0.147+ build: 20160622T220759Z), and I think the network interface defaults to using the realtek 8139 driver.
This was enough for my situation, but not optimal for heavy use.
If you wanted support from the primary vendor of your OS, and wanted a pretty high-quality Unix, Solaris would fill that niche for you. There's definitely a market for that, but not nearly enough to keep Sun or Solaris alive.
https://www.joyent.com/blog
http://www.circonus.com/blog
6 or so years ago I thought Solaris would have a fighting chance. I was naive.
This from a company that had UNIX on everything from a Cray down to a desktop. It wasn't obvious from early on that Linux would eventually spell doom for both desktop and servers but here we are.
Right now we don't know if Solaris 11.Next is a maintenance release or if they are just moving to something more akin to a rolling release, as some people have suggested. Unless all the question currently floating around are addressed by Oracle, no sane person would base new infrastructure on neither Solaris, nor SPARC.
Perhaps Oracle want to move all Solaris and SPARC deployments in-house, but what sense would that make?
The rest of Sun was just extra. So Oracle's seeing if they can use them. If they find that they can't they'll just dump them. As they're doing now.
The prize Oracle was after is Java, and they have already begun the long process of squeezing large enterprises with Java "commerical" features flags.
To the extent that there are commercial ISVs supporting Solaris it also makes their jobs a little easier since they can deal with change in smaller increments.
I doubt they exist, but if there are any Solaris fans that haven't tried FreeBSD yet, you really should.
1. Some enterprises have a general policy of only running versions N and N-1 of software. The release of Solaris 12 would trigger a review of Solaris 10 in those environments, which would accelerate the trend away from Solaris. (The Solaris 10 to Solaris 11 upgrade is particularly disruptive due to the switch to IPS packaging and the networking changes, so migration to Linux is of comparable complexity.) Immediate loss of legacy support revenue for both Solaris and SPARC hardware.
2. Solaris 11 support is promised until at least 2031, or 2034 if customers pay for extended support [1]. A new release would just add another stream to support with at least 15 years of overlap.
3. The old SVR4 packaging was so slow and Live Upgrade so unreliable that new releases were required to stop patch bundles from getting too unwieldy. IPS is much faster and safer so it is more technically feasible to stick with the same major release.
4. I'd tend to agree with Adrian Cockcroft that the interesting things are happening elsewhere now [2]. There may not be enough reason for customers to upgrade. Oracle can avoid the story of a failed release by not doing the release in the first place.
[1] http://www.oracle.com/us/support/library/lifetime-support-ha...
[2] http://perfcap.blogspot.com.au/2010/08/open-letter-to-my-sun...