> The future of Oracle Solaris, perhaps the one true Solaris if you had to pick one, is murky at best.
I believe the article linked talking about "the death of Oracle Solaris" was shown to be FUD and over-zealous reporting, but ignoring that I don't see why you would think Oracle no-longer-open-Solaris would be the "one true Solaris if you had to pick one". illumos gained the majority of the development community from Oracle after the majority of the Solaris developers left, and most of the recent innovations in Solaris's core technologies (DTrace, ZFS, Zones, etc) have all happened in illumos.
I'm not terribly familiar with the ZFS/DTrace side of things but Solaris 11.2 added Kernel Zones [1] and Solaris 11.3 added more features [2].
We have Unified Archives as a way to create either a golden image of a system (all configuration and other host-specific data) or a "clone" image (the software payload minus host-specific data) which can be used to install metal, LDOMs, kernel zones, or branded zones and allow P2P, V2V, P2V, or V2P. [3]
We've had Boot Environments since 11.0 [4] which allows me infinite flexibility to upgrade or even try out random things. If things go south, I can roll back to a safe BE in 30 seconds with no issue.
Unified archives sound like an extension of flash archives, available since Solaris 9. Boot environments showed up in the post Solaris 10 open source effort, again, pre Oracle...
FWIW, I am a Solaris developer on the zones team and was part of the project team that implemented unified archives. I joined the Solaris org about a year before Solaris 11 shipped and was a Solaris admin for a long while before that. Here's my take.
Flash archives were available long before Solaris 9 - I think it was Solaris 7. In the Solaris 2.5.1 days I invented something similar for use in in the academic labs I managed. Boot environments were introduced with Live Upgrade which also was available at least as far back as Solaris 8. Lessons were learned.
With Live Upgrade, the admin had to plan ahead to ensure that spare disks or slices were available to create an alternate BE. Most admins didn't have the foresight. Then when it came time to patch or install/remove software, the pre/post install scripts often had broken logic that caused changes to happen in the wrong place (or not happen at all). Live Upgrade came long before zones and was an extremely poor fit. Live Upgrade came out of an org other than the Solaris org, and the lack of coordination was quite evident.
Flash archives seem to have a design point of installing one system to look exactly like others. Installing an Ultra 5 from a flash archive created from an Ultra 10 was considered going off the rails. In reality, this worked most of the time. When I used flash archives extensively, I would tend to create them on 15k or 25k domain and use them on all systems. Again, flash archives were conceived long before zones and integrated poorly with them.
The release of Solaris 11 integrated lots of stuff that was previously cobbled together. ZFS is the only supported root file system and zones also live on ZFS. Boot environments are required on the global zone and in zones. There were rules as to where the zonepath could be, making it possible to always come to a correct solution as to how to create a new zone boot environment that corresponds with the global zone boot environment. This foundation works nice with the packaging system, IPS. IPS determines whether you are changing files that will require a reboot. If so, it creates a new boot environment via zfs clones and updates the new boot environment. When you are ready, you can reboot into the new boot environment. By choosing defaults, you get the best practice. The system actively prevents you from doing things that will cause support to say "back up, repartition, and restore." That's a big improvement.
Unified archives build on lessons leared from flash archives. Flash archives were really only intended for system cloning, but the archive contained the configuration from the master system. Unconfiguration happened as part of deployment, not as part of archiving. Unified archives integrate with the packaging system to revert various amounts of configuration (in a temporary boot environment) so that the archive is optionally unconfigured and always ready to be moved to a new virtual or physical platform. Transforms between zones and global zones are explicitly supported. Want to convert your ldom/zone/kernel zone/whatever to a whatever/ldom/kernel zone/zone? That's supported.
Unified archives come in clone and recovery variants. A recovery archive is suitable for bare-metal restore and preserves all of the configuration (networking, name service config, etc.). A clone archive whacks all of that configuration and ensures that it is not part of the archive.
Unified archives allow multiple virtual systems to be included in one archive. This means that you can type "archiveadm create myarchive.uar" and it will create an archive that has the global zone and all other zones, each of which is individually installable from the archive.
Unified archives allow inclusion of multiple zpools in the archive. In contrast, flash archives only archived the root pool. The selection of which pools and/or datasets is possible via command line arguments.
I seem to recall that after I used a JumpStart server to put a flash archive on a system, I would do a "reconfiguration boot" to have the kernel probe all the devices again and rebuild the device tree. "touch /reconfigure && reboot" I think?
I would do this with similar but not exact systems, like you mentioned - the 5 and 10 were similar but not the same...
Jumpstart should have put the /reconfigure in place so you wouldn't need to. But that only adds new devices, it doesn't deal with old devices that have gone away. This can lead to things like a root disk being on c0 on one system and c1 on another, and similar confusing numbering for NICs. Experience tells me that this is less problematic than many inside the Solaris org have suggested.
The kvm support hasn't had much is any maintenance. It's very behind and lacking in a number of ways . Illumos should adopt bhyve and pester the shit out of plubirus to free the code for this .
Network virtualization was barely integrated before Indiana got cut off.. Only Oracle has the infrastructure and customers necessary to find and fix the less obvious bugs there.. But I wouldn't use code owned by Oracle.
Porting what is good into BSDs is really a better idea than trying to keep anything Solaris based going. There are people I respect that I wish would realize that, but I don't think it would be fruitful if they heard it from me..
Without confirming or denying anything, can you allude, vaguely, and super non-committally, that Oracle, who may or may not be your boss, cares about Solaris?
> and most of the recent innovations in Solaris's core technologies (DTrace, ZFS, Zones, etc) have all happened in illumos.
My use of "Solaris's core technologies" implies that I'm referring to technologies that already existed. Yes, I am aware that ZFS, DTrace and Zones all happened long before the Oracle acquisition.
Illumos is not "Oracle Solaris" though. It seems clear to me that the statement was about the commercial product, which while it's not going away, is clearly on a path to join AIX and HP-UX as fundamentally legacy products sold into shrinking markets.
As for illumos itself, meh. It's way behind even OpenBSD in adoption. Free software doesn't ever die, but I wouldn't expect it to carry much in the way of a Solaris torch.
Me too. It's easy to say "it doesn't have the numbers" but without sharing those actual numbers and showing what portion they account for in the total it always leaves me wondering if it's truly as low as implied.
That said, it seems perfectly reasonable to me that interest in Solaris releases is rather low and that maintaining support for it is probably costing them more than the returns.
Our numbers aren't comparable to MongoDB, but when we dropped support for Solaris in Virtualmin a few years ago, we had a couple dozen active Solaris installations left (and we had maybe 75,000 active installations on Linux at that time), only a couple of which were paying customers. At its peak, it was never more than a few thousand Solaris installations (and most of those were because Joyent installed Virtualmin GPL on their containers, and they also used it for shared hosting on Solaris before that, by default, but when they shifted their business model those disappeared).
I don't know anything about MongoDB usage, but I do know Solaris/Illumos is a tiny blip on the radar of usage in web dev and web hosting. We just don't hear about it at all. I think we still get Solaris bug reports and patches every now and then, like once or twice a year, for Webmin on Solaris (which is still supported in a "we won't intentionally break it" sort of way and Jamie still builds Solaris packages), but even that's very rare, and Webmin has a million or so installations.
The biggest factor for me wasn't the raw number, it was simply that usage was shrinking rapidly. You can't reasonably devote a bunch of effort to maintaining support for an OS that has a small number of users today and will have half as many in a year. Software is a bet on returns with interest; I'm betting that putting in weeks of effort to support a new OS (or Linux distro, or platform, or web server, or language, or whatever) will keep paying for months or years. There's no way to count Solaris usage that I'm aware of that doesn't show it being smaller next year.
That's unfortunate, perhaps; there's a lot of cool stuff in Solaris (and Illumos). But, market forces aren't sentimental and Linux is a juggernaut that rolls over everything in its path and consumes the best features (and some of the bad features too) of everything it touches. It's funny that the old wisdom of Microsoft being like the Borg and Linux being a scrappy upstart has kinda turned on its end. Linux now absorbs the best of other operating systems and just keeps multiplying and spreading into more and more markets from mobile to big iron.
I'll admit to running Solaris on my desktop many years ago when it was still under Sun's stewardship. It was the most accessible 'real' UNIX for most people (being that it was free and able to run on x86). I also once had a job working on an old Ada codebase that had us stuck on SPARC/Solaris 8 (in the late 2000s :O). It makes me sad to see what Oracle has done to it.
In any case, I suspect most users looking for a more 'authentic' UNIX flavor than Linux have shifted over to *BSD (My home file server runs FreeBSD -- mostly for the ZFS support -- hey, at least a file system from Solaris-land will live on).
I also ran FreeBSD for ZFS for a while. I ended switching and using ZFS on Linux and haven't had any issues, aside from a pool migration bug which the maintainers fixed very quickly: https://github.com/zfsonlinux/zfs
I have fond memories of Solaris, but I'm pretty much on OpenBSD for good these days. It's really head-and-shoulders above anything else available these days, IMO. The closest alternative that I'd find acceptable might be Arch, but gosh, systemd is one of those things that just make me hate running systems.
You should have a look at Void Linux[1] (if you ever wanted to give Linux another shot). It uses runit for init instead of systemd and offers musl as an actively supported alternative to glibc. Its package manager is similar to the one in Arch in that it provides both rolling-release binary packages as well as a ports-style build system. Void also incorporates OpenBSD's LibreSSL by default. Everything else is kept as minimal and simple as possible.
Very cool efforts. I will look into this as an alternative to some of our production systems where we've had to use Ubuntu instead of OpenBSD (for support of certain stacks).
One can also use the same toolset on FreeBSD/TrueOS. OpenBSD, alas, fails to provide some necessary functionality for everything to be similarly possible; but many of the tools can work there, and I use them on OpenBSD myself (alongside OpenBSD versions of the djbwares toolset).
I had no problems with sysv init since the 80s and SVR2. Did it exist before? I'm only drawing on personal experience.
I have failed to see any benefits of systemd and it has only caused me problems. Most in my circle agree with this, and I have never heard someone express gratitude that systemd exists. We feel it has been forced upon us, and we don't want to make a full time job out of maintaining our own platforms to be rid of it.
We are crotchety old men who have generated hundreds of millions of dollars (maybe more) for our employers and customers. We have never had a problem with init. Compared to ourselves, we think Lennart is a noob and examining his work leads us to conclude that he has no rational foundation of applied computing.
The software developers I've known in my career have all been professional and responsible. Our industry has zero tolerance for failures and hazards. During ten years I worked there, one place shipped one defect that I found out about, and the manager who signed off on it after incomplete testing lost his career. I deal with bad software every day and wish more of the industry had this focus on quality. I used to respect rhel because of their QA, now they hired this guy, did he even have a job before?
I wish Lennart the best in his quest to make a Windows out of what used to be Unix, with his audio mixer and cli version of 'services.exe.' Legions of misguided people who believe that Linux is the golden desktop OS for laypeople will certainly appreciate this. However I hope I never meet him because I do not want to pay his hospital costs.
My biggest problem with systemd is that it adds a new and completely unnecessary giant wall of incompatibility/incongruity between Linux and the rest of the *nix universe.
It was and is absolutely asinine and I can't believe all of the major linux distros went along with it.
What happens when security vulnerabilities are patched in a supported version of MongoDB? Will Solaris users simply never get those patches? The blog doesn't say that I could see.
> Existing release artifacts for Solaris will continue to be made available, but no new releases will be issued, barring a critical issue raised under an existing support contract covering MongoDB versions 3.0 through 3.4 running on Solaris.
Sounds like those with a support contract can get a patch/update. I suppose everyone else is SOL.
It's ironic that ecosystem fragmentation is now a legitimate reason to drop Solaris when fragmentation had for a long time been a major concern for supporting Linux.
I have a lot of nostalgia for Solaris and Irix circa 2000. They had their uses and places, especially when coupled with SGI and Sun hardware. I think mostly the reason its nostalgic is that it reminds me of a "golden age" (late 1970's to mid-1990's?) of accessible computing when computers were still the domain of nerds.
I'm one of the Product Managers at MongoDB and I was a part of making this decision. It seems like there are two main areas where people are asking for more information: 1) exactly what are the numbers of Solaris downloads and 2) what about security patches of existing versions? I'm happy to clarify those points here and we will be posting an update to the blog to include this information.
Based on the data we have, about 0.06% (and decreasing) of MongoDB users are running on Solaris. In addition, as Andrew mentioned in the blog, all of our customers have either deprecated Solaris or have told us they plan to deprecate it.
In regards to security patches on Solaris, we will continue to fix critical flaws for the community, regardless of where found or how reported. Anyone can report a security vulnerability by using our Security project (https://jira.mongodb.org/browse/SECURITY) to create an account then a ticket describing the vulnerability.
It was the right decision, @alyson-cabral. The major market is linux-based, correct? There are better uses of company assets, than trying to chase the less-than-0.06% of holdouts that operate Solaris.
As a person of science, I've used both Sun Solaris and SGI Irix.... time to let go of that past and pivot to the future!
Not sure why my relating my direct experience, respectfully... got me modded down. There are some really strange people with high karma scores. LOL What a joke.
Interesting that one of the reasons for their dropping Solaris support is "Operational difficulties." The same would also be valid reason for saying "Farewell" to Mongodb.
Anyone that's had to manage a MongoDB database could tell you about regularly having to manually re-synch their secondaries, manually having to run compactions to manage disk space(the power of 2 allocator), the automatic "balancer" process that sends I/O the roof, the rollback files etc. I think MongoDB being so operationally difficult is the prime reason that MongoDB offers a managed MongoDB PaaS offering.
Meanwhile in the comment section of this: https://news.ycombinator.com/item?id=15124306 HackerNews MongoDB article basically everyone (who speaks up at least) seems to agree that the drawbacks of NoSQL outweigh the benefits.
Unsurprising. As far as I can see Solaris is pretty much retreating into being in the same position as zOS (MVS): something Oracle ship with the integrated hardware stacks.
Solaris has, historically, been my favorite operating system. I started using it when Sun made Solaris 7 available for free to anyone who requested it when I was in college. I still remember receiving a package in the mail with a nice set of packaged CDs and documentation! My college had standardized on Unix for development for homework assignments, and Linux at the time still seemed "immature" to me. I loved the stability and sanity I found with Solaris, and even saved up money to beef up my home PC so that it could run better (SCSI hard drives, more RAM, etc.) I used it up through version 10, but once Oracle took control and de-open-sourced it, I knew that was the beginning of the end.
59 comments
[ 2.9 ms ] story [ 145 ms ] threadI believe the article linked talking about "the death of Oracle Solaris" was shown to be FUD and over-zealous reporting, but ignoring that I don't see why you would think Oracle no-longer-open-Solaris would be the "one true Solaris if you had to pick one". illumos gained the majority of the development community from Oracle after the majority of the Solaris developers left, and most of the recent innovations in Solaris's core technologies (DTrace, ZFS, Zones, etc) have all happened in illumos.
As a core Solaris dev at Oracle, I can tell you that's not true. I just can't prove it to you. :-(
We have Unified Archives as a way to create either a golden image of a system (all configuration and other host-specific data) or a "clone" image (the software payload minus host-specific data) which can be used to install metal, LDOMs, kernel zones, or branded zones and allow P2P, V2V, P2V, or V2P. [3]
We've had Boot Environments since 11.0 [4] which allows me infinite flexibility to upgrade or even try out random things. If things go south, I can roll back to a safe BE in 30 seconds with no issue.
[1] http://docs.oracle.com/cd/E36784_01/html/E37629/gnzfn.html
[2] http://docs.oracle.com/cd/E53394_01/html/E54847/virt.html#sc...
[3] https://docs.oracle.com/cd/E36784_01/html/E38524/index.html
[4] https://docs.oracle.com/cd/E23824_01/html/E21801/index.html
Flash archives were available long before Solaris 9 - I think it was Solaris 7. In the Solaris 2.5.1 days I invented something similar for use in in the academic labs I managed. Boot environments were introduced with Live Upgrade which also was available at least as far back as Solaris 8. Lessons were learned.
With Live Upgrade, the admin had to plan ahead to ensure that spare disks or slices were available to create an alternate BE. Most admins didn't have the foresight. Then when it came time to patch or install/remove software, the pre/post install scripts often had broken logic that caused changes to happen in the wrong place (or not happen at all). Live Upgrade came long before zones and was an extremely poor fit. Live Upgrade came out of an org other than the Solaris org, and the lack of coordination was quite evident.
Flash archives seem to have a design point of installing one system to look exactly like others. Installing an Ultra 5 from a flash archive created from an Ultra 10 was considered going off the rails. In reality, this worked most of the time. When I used flash archives extensively, I would tend to create them on 15k or 25k domain and use them on all systems. Again, flash archives were conceived long before zones and integrated poorly with them.
The release of Solaris 11 integrated lots of stuff that was previously cobbled together. ZFS is the only supported root file system and zones also live on ZFS. Boot environments are required on the global zone and in zones. There were rules as to where the zonepath could be, making it possible to always come to a correct solution as to how to create a new zone boot environment that corresponds with the global zone boot environment. This foundation works nice with the packaging system, IPS. IPS determines whether you are changing files that will require a reboot. If so, it creates a new boot environment via zfs clones and updates the new boot environment. When you are ready, you can reboot into the new boot environment. By choosing defaults, you get the best practice. The system actively prevents you from doing things that will cause support to say "back up, repartition, and restore." That's a big improvement.
Unified archives build on lessons leared from flash archives. Flash archives were really only intended for system cloning, but the archive contained the configuration from the master system. Unconfiguration happened as part of deployment, not as part of archiving. Unified archives integrate with the packaging system to revert various amounts of configuration (in a temporary boot environment) so that the archive is optionally unconfigured and always ready to be moved to a new virtual or physical platform. Transforms between zones and global zones are explicitly supported. Want to convert your ldom/zone/kernel zone/whatever to a whatever/ldom/kernel zone/zone? That's supported.
Unified archives come in clone and recovery variants. A recovery archive is suitable for bare-metal restore and preserves all of the configuration (networking, name service config, etc.). A clone archive whacks all of that configuration and ensures that it is not part of the archive.
Unified archives allow multiple virtual systems to be included in one archive. This means that you can type "archiveadm create myarchive.uar" and it will create an archive that has the global zone and all other zones, each of which is individually installable from the archive.
Unified archives allow inclusion of multiple zpools in the archive. In contrast, flash archives only archived the root pool. The selection of which pools and/or datasets is possible via command line arguments.
I've blogged about a bunch of thi...
I seem to recall that after I used a JumpStart server to put a flash archive on a system, I would do a "reconfiguration boot" to have the kernel probe all the devices again and rebuild the device tree. "touch /reconfigure && reboot" I think?
I would do this with similar but not exact systems, like you mentioned - the 5 and 10 were similar but not the same...
Illumos/SmartOS has had KVM support since 2011; Oracle Solaris 11.2 is from 2014.
Edit: forgive the terse reply - on mobile
Porting what is good into BSDs is really a better idea than trying to keep anything Solaris based going. There are people I respect that I wish would realize that, but I don't think it would be fruitful if they heard it from me..
Maybe.
:-|
My use of "Solaris's core technologies" implies that I'm referring to technologies that already existed. Yes, I am aware that ZFS, DTrace and Zones all happened long before the Oracle acquisition.
As for illumos itself, meh. It's way behind even OpenBSD in adoption. Free software doesn't ever die, but I wouldn't expect it to carry much in the way of a Solaris torch.
That said, it seems perfectly reasonable to me that interest in Solaris releases is rather low and that maintaining support for it is probably costing them more than the returns.
I don't know anything about MongoDB usage, but I do know Solaris/Illumos is a tiny blip on the radar of usage in web dev and web hosting. We just don't hear about it at all. I think we still get Solaris bug reports and patches every now and then, like once or twice a year, for Webmin on Solaris (which is still supported in a "we won't intentionally break it" sort of way and Jamie still builds Solaris packages), but even that's very rare, and Webmin has a million or so installations.
The biggest factor for me wasn't the raw number, it was simply that usage was shrinking rapidly. You can't reasonably devote a bunch of effort to maintaining support for an OS that has a small number of users today and will have half as many in a year. Software is a bet on returns with interest; I'm betting that putting in weeks of effort to support a new OS (or Linux distro, or platform, or web server, or language, or whatever) will keep paying for months or years. There's no way to count Solaris usage that I'm aware of that doesn't show it being smaller next year.
That's unfortunate, perhaps; there's a lot of cool stuff in Solaris (and Illumos). But, market forces aren't sentimental and Linux is a juggernaut that rolls over everything in its path and consumes the best features (and some of the bad features too) of everything it touches. It's funny that the old wisdom of Microsoft being like the Borg and Linux being a scrappy upstart has kinda turned on its end. Linux now absorbs the best of other operating systems and just keeps multiplying and spreading into more and more markets from mobile to big iron.
In any case, I suspect most users looking for a more 'authentic' UNIX flavor than Linux have shifted over to *BSD (My home file server runs FreeBSD -- mostly for the ZFS support -- hey, at least a file system from Solaris-land will live on).
1) https://www.voidlinux.eu/
* https://framagit.org/taca/archnosh
One can also use the same toolset on FreeBSD/TrueOS. OpenBSD, alas, fails to provide some necessary functionality for everything to be similarly possible; but many of the tools can work there, and I use them on OpenBSD myself (alongside OpenBSD versions of the djbwares toolset).
* http://jdebp.eu./Softwares/nosh/openbsd-binary-packages.html...
* http://jdebp.eu./Softwares/djbwares/
It has a shim svcadm command. (-:
* http://jdebp.info./Softwares/nosh/guide/svcadm.html
I had no problems with sysv init since the 80s and SVR2. Did it exist before? I'm only drawing on personal experience.
I have failed to see any benefits of systemd and it has only caused me problems. Most in my circle agree with this, and I have never heard someone express gratitude that systemd exists. We feel it has been forced upon us, and we don't want to make a full time job out of maintaining our own platforms to be rid of it.
We are crotchety old men who have generated hundreds of millions of dollars (maybe more) for our employers and customers. We have never had a problem with init. Compared to ourselves, we think Lennart is a noob and examining his work leads us to conclude that he has no rational foundation of applied computing.
The software developers I've known in my career have all been professional and responsible. Our industry has zero tolerance for failures and hazards. During ten years I worked there, one place shipped one defect that I found out about, and the manager who signed off on it after incomplete testing lost his career. I deal with bad software every day and wish more of the industry had this focus on quality. I used to respect rhel because of their QA, now they hired this guy, did he even have a job before?
I wish Lennart the best in his quest to make a Windows out of what used to be Unix, with his audio mixer and cli version of 'services.exe.' Legions of misguided people who believe that Linux is the golden desktop OS for laypeople will certainly appreciate this. However I hope I never meet him because I do not want to pay his hospital costs.
It was and is absolutely asinine and I can't believe all of the major linux distros went along with it.
RedHat and/or Canonical largely determine which way the wind is blowing in the Linux community, for good and bad.
Wasn't it the market that did that? What could Oracle have done to make Solaris popular? AIX and HP-UX aren't doing so well, either.
Sounds like those with a support contract can get a patch/update. I suppose everyone else is SOL.
Based on the data we have, about 0.06% (and decreasing) of MongoDB users are running on Solaris. In addition, as Andrew mentioned in the blog, all of our customers have either deprecated Solaris or have told us they plan to deprecate it.
In regards to security patches on Solaris, we will continue to fix critical flaws for the community, regardless of where found or how reported. Anyone can report a security vulnerability by using our Security project (https://jira.mongodb.org/browse/SECURITY) to create an account then a ticket describing the vulnerability.
As a person of science, I've used both Sun Solaris and SGI Irix.... time to let go of that past and pivot to the future!
Anyone that's had to manage a MongoDB database could tell you about regularly having to manually re-synch their secondaries, manually having to run compactions to manage disk space(the power of 2 allocator), the automatic "balancer" process that sends I/O the roof, the rollback files etc. I think MongoDB being so operationally difficult is the prime reason that MongoDB offers a managed MongoDB PaaS offering.