Perhaps this is a inane question, but why should we care about Solaris? What does it bring to the table over BSD or Linux? If it died tomorrow would your shop close up and everyone go home?
I know some of its features (DTrace and ZFS) are quite impressive but they are not really deal breakers. A kernel is great but it doesn't do much on its own. You still need applications and drivers to have a complete system.
OpenSolaris is the only platform that I'm aware of that supports ZFS and has stable, fast iSCSI Target support. (FreeBSD initiators don't even mount iSCSI LUNs on a reboot. I happen to like FreeBSD anyway, but it's not quite there for iSCSI.)
In plain english, OpenSolaris (the right version at least, avoid de-duplication) is the only free platform I'm aware of that will give you a fast, stable, iSCSI server with a file system that's basically impervious to corruption.
The only one. Seriously. COMSTAR and ZFS are that big of a deal. They aren't "nice to have"s. They're solutions that allow you to spend a couple grand on a box, put a lot of RAM in it, attach a JBOD, shove in a few SSDs for read-cache and write-logs and you can duplicate the performance million dollar storage systems on the cheap.
You can do this with very little effort on commodity hardware. You can start as small as you want and scale as large as you want. You get snapshots, clones and replication with barely any effort.
Sun's whole storage strategy (Sun Unified Storage) was built on nothing more than exactly this with a pretty Web interface sitting on top.
OpenSolaris is a real pain for a lot of things, but when it comes to storage nothing else comes close (that I'm aware of).
Don't be scared that you'll lose an alternative to Linux. OpenSolaris isn't any good as an application host if you're expecting anything close to modern GNU tools. Be scared that you'll lose an alternative to NetApp.
Data de-dupe is FUBAR. It's why snv_134, which was supposed to be final was scrapped.
I hadn't heard of a FreeBSD kernel issue, but if that's true, it might just be for the best for the next 6 months at least. de-dupe is kinda a useless feature if you're not a hosting company anyway. A hosting company could take advantage of storing tons of mostly-the-same VMs. It's not the few hundred GB in our dozens of base VM images that concerns me though. It's the terra-bytes of multimedia and databases.
Plus de-dupe takes a lot of RAM. A lot. There was a time where it would've been very nice, but as it stands, it's really a niche product to come up with a situation where it's RAM requirements, and it's rather small storage savings might make sense.
Lack of proper package management (you can't compare ports to yum or apt) is a dealbreaker for me. Ports is minimal and you can, conceivably, grow a real package management system out of it, but it's not one.
That's just silly. Having used pkg, pkgutil, pkg-get, apt-get, and ports near daily for awhile ports hands down beats anything on the *solaris platforms.
For one, you can find the libraries you want and they actually work.
Postgres 8.4 on FreeBSD? No problem. With plperl? No problem. OpenSolaris? Well, if you want to run 32bit Postgres on a system with 48GB of RAM sure. No 64bit for you though. And Oracle shutdown the Postgres build farm servers they were hosting.
Just because FreeBSD stores it's package information in makefiles and pkg stores it in a catalog doesn't change the end result. Ports are as easy to use (if you bother to read the very simple README), and offer far more robust support and packages than any flavor of Solaris I'm familiar with.
There was a time I'd have agreed about Ports, but 30 minutes later I had read the README and realized I was just being lazy. ;-)
No. Debian and Fedora have just fine package managers. What they can't do is boot from a ZFS file system. I am implying Solaris and FreeBSD (the other OSs that boot from ZFS, AFAIK) don't have a sane packaging system.
Source-based packaging is slower than binary packages. The binary package system, although it exists, is not as simple to use.
In Red Hat-ish distros, I can do "yum update". In Debian-ish distros, I can run "aptitude safe-upgrade". On Debian, I can even do a dist-upgrade and update the box to a new release without having to reinstall it (or boot into the installer). Everything is downloaded, installed and, if needed, restarted. Very close to zero downtime.
Why should we care about Linux when we have BSD, and vice versa? Competition and versatility of course, they encourage invention - Sun developed NIS, NIS+, NFS, VFS, ZFS and a bunch of other things in the UNIX world.
I guess it's a case of waiting for the announcement before passing comment - but if this is a new OpenSolaris distribution what does it matter when Oracle/Sun still employ 99% of all active developers?
People who quit Oracle are going to work for other proprietary software companies where they'll be working on something other than Solaris. I don't see any business model to pay people to work on an OpenSolaris fork.
Quite a few financial companies have mission critical apps running on solaris. If a large bunch of developers emerges who carry the solaris torch forward I think funding will not be a problem.
Since about 2005 most large banks have started deploying on Linux for most new projects. The place I'm at now, which is one of the most conservative environments - NIS, heaps of Sol 8 under Vintage support, 15 year old home grown perl scripts for config management, etc - has a minimal amount of Linux skills amongst the day to day support staff, just declared Solaris a non-strategic platform.
The question is how many banks do you need to subsidize the evolution of OpenSolaris/Illumos? Considering what a Sun/Oracle support contract costs, not many.
One of the incentives to use GPL-like licenses is that your competitors cannot take your contributions and run with them and, at the same time, have to make their contributions available to you.
This is the model that made Red Hat possible. It would not happen on top of BSD.
I'd distinguish between OpenSolaris the distribution and Solaris the kernel; and my interest in this lies in the server side of things, not UI. I'm currently using Nexenta, which uses the Solaris kernel with a server-oriented Debian userland. The things Solaris brings along, ZFS, dtrace, SMF etc. are not hugely relevant to the desktop.
Debian/Solaris is where things should be heading IMO. It gives the package management and up-to-date userland of Debian, while bringing most of Solaris' assets.
And it seems that Nexenta developers would like to make Debian/Solaris a reality:
Indeed I have not, in fact I usually disable file deletion confirmation prompts and also delayed deletion mechanisms like Windows' Recycle Bin. ZFS snapshots are more useful to me as a kind of system-wide version control; I don't use them often.
The few times I have deleted things accidentally - perhaps 3 times in the past 5 years - I've recovered in a few moments from backups. I've lost more data to hard drive failures with somewhat stale backups than accidental deletion. The redundancy of ZFS raidz / raidz2 / mirroring etc. is useful to reduce the risk disk failure, but of course offsite backup is the gold standard.
It they aren't done already, I suppose integrating these parts to newer versions of Gnome is, at least, in the pipeline for *BSD folks (and, once ported to current Gnome, they would be rather easy to adapt it to BtrFS, which is to be fully supported by canned linux distros by the end of the year).
Just now, OpenSolaris is a very cool server OS with a slightly old Gnome desktop on top of it.
It's approximately where RHEL5 (and maybe other enterprisey distros) is right now, which is an old version of gnome. I don't think that's a big problem to solve, provided they actually get more man-power.
Please. The version of GNOME you'll find in Sol 10 is way behind RHEL 5, the desktop / kernel integration is poor, and the amount of apps that actually make use of the desktop is minimal.
Then the better comparison is Fedora - while support contracts exist for OpenSolaris (whose last version was actually supposed to be 2010.03, but which was cancelled), very few people use them and Sun/Oracle will encourage you to use, and train for, Sol 10.
Perhaps theres a sizeable body of customers who have apps written and deployed for solaris. The cost of moving and certifying existing apps is often something enterprises like to avoid. Furthermore Oracle is expected to push to make the individual bits of Sun more profitable which means existing customers might feel squeezed in various ways. Combined both of the above facts mean that there is a sizeable body of customers willing to pay for solaris based support / products and who might be open to an alternative to the Oracle solaris distribution and support.
One last point - some companies with established products find linux to be a fast moving target and the relative stability of the solaris kernel interfaces is considered a good thing.
I've modded you back up as I have the same question, albeit I think some explanation would help: FreeBSD has the good bits of the Solaris kernel - ZFS and DTrace - and the common Solaris 10 userspace - toolchain, packaging, etc. - aren't particularly up to date.
FreeBSD supports ZFS v14, which lacks some of the features of ZFS on OpenSolaris, namely data deduplication. However, it is my understanding that porting later versions of ZFS to FreeBSD would require non trivial changes to the FreeBSD kernel, making it unlikely.
Add to this an idiotic attempt to replace SystemV startup scripts with some insanely non-obvious java-based (of course!) crap, badly ported in a great hurry outdated 32-bit userland (when at the same time x86_64 version of Fedora or FreeBSD-ports were several years old), some in-house designed and quite alien packaging system (pkg) and so on.
It is dead. As dead as Irix or Tru64 or even OpenVMS.
Solaris SMF is actually one of the best things about Solaris (IMO). Runit documentation as an init replacement are woefully out of date for most platforms, and Upstart seems like it's still beta at-best.
I'm not that savvy, but I know of nothing for Linux or FreeBSD that starts everything up, makes sure it gets restarted if it crashes, notifies you, has maintenance states, supports simple, robust dependencies (process or file-based). The SMF covers these bases very well.
Runit seems to come closest on the service side, but it's not nearly as well documented. Monit is almost a suitable substitute (even though that's not really it's goal), but robust dependency support is lacking last I checked.
XML isn't the best perhaps. But it's not a road-block either. New config files are always new.
And who cares what it's implemented in as long as it doesn't fall over? I mean, ideally sure. C FTW on resource utilization, but honestly, if the choice is between something that's a bit of a pig, eating up 100MB of RAM vs what...? Really simply put: There is no competition that checks the same boxes that I'm aware of.
I'd be genuinely grateful if you can show me an alternative, especially for GNU/Linux and FreeBSD, but most of the alternatives are new early-phase projects with grand goals that may never materialize, or unmaintained.
What is your argument exactly? Do you even understand what I said?
Here's the output of one of our services:
fmri svc:/application/harbor/unicorn:default
name Unicorn Rack Server
enabled true
state online
next_state none
state_time Sat Aug 07 12:52:45 2010
logfile /var/svc/log/application-harbor-unicorn:default.log
restarter svc:/system/svc/restarter:default
contract_id 18664
dependency require_all/none svc:/milestone/network:default (online)
dependency require_all/none svc:/system/filesystem/local:default (online)
dependency require_all/refresh file://localhost/var/harbor/unicorn.conf (online)
dependency require_all/refresh file://localhost/var/harbor/config.ru (online)
dependency require_all/refresh file://localhost/var/harbor/log (online)
See the dependencies? It took one of my guys all of a couple hours to grasp the documentation and set this up. Without ever having seen it before.
If you want the plain XML, just 'svccfg export unicorn'
You're a fool if you think a maintained, documented simple service like this has no value just because angle-brackets scare and confuse you.
If you had a more open mind, you might even ask yourself why it was done this way? Perhaps it's because with XML you can spend all of a few minutes in practically any programming language and have something that can manage the services?
And perhaps that might come in handy if you were managing a lot of servers, or building a cluster that you wanted to manage, install, and update services on?
Sure you could go the usual route of inventing your own syntax. tcl, lisp, or python compatible if you're lucky. Or you might just consider that maybe interoperability isn't the fall of Rome while you dismiss one of the most robust service management tools around just because you might have to write a bit of XML.
Unfortunately I didn't goto school. I did it the old fashioned way. I read people smarter than me. I'm glad I could do the same for you. :-)
Actually it is on occasion quite cool. For example, it will take a ZFS snapshot before doing package updates, so that if Bad Things (TM) happen you can simply reboot into the system snapshot taken before the update. And it's all copy-on-write, so you only use the disk space for what changed.
I know some of its features (DTrace and ZFS) are quite impressive but they are not really deal breakers. A kernel is great but it doesn't do much on its own. You still need applications and drivers to have a complete system.