Slashdot Mirror
Sun Says OpenSolaris Will Challenge Linux
E5Rebel writes "Sun Microsystems has ambitious plans for the commercial and open source versions of its Solaris operating system. The company hopes to achieve for Solaris the kind of widespread uptake already enjoyed by Java. This means challenging Linux. 'There's an enormous momentum building behind Solaris,' according to Ian Murdock, chief operating platforms officer at Sun, who was chief technology officer of the Linux Foundation and creator of the Debian Linux distribution. Isn't it all a bit late?"
Consider MS with IE and then Mozilla with Firefox.
MS Word vs WordPerfect 5.1
What about Linux, itself was probably considered "too late" or such at the time "Everything's been invented/done".
What about when Redhat was top dog - who'd have thought that Ubuntu would come along and change a lot of things.
The point is, it's [almost] never too late, just sometimes you have a harder job ahead of you.
(Just missed the FP, but still)
this chance was missed a few times. The last one was when Nexenta was treated like a mother-in-law.
If SUN wanted acceptance instead of l33t, GPL(v3) would have been the order of the day.
As long as they dangle about with CDDL, they might as well pass away. Don't get me wrong, CDDL ('cuddle') is quite a good FOSS licence. But it has its problems with a coexistence side-by-side to GPL. And GNU is, love it or hate it, thousands of great applications; and moreover a licence accepted by the majority of FOSS developers.
I hope(d) Ian would have the power to apt-ing Solaris, but he doesn't seem to. And when you read the OpenSolaris lists, you find as much ego-tripping as on OpenBSD or Mac. They rather sink with pkgadd.
And I cry for them, yes, because SunOS is the greatest kernel around, with limited hardware support. Back to licencing and square one.
Allow me to clarify. The JVM currently has a lot of clever optimizations like lock coarsening. It's proving it's pretty smart. Now, imagine if the JVM could detect a certain procedure is doing a LOT of user-kernel switches, and therefore can be moved to kernel space. When it needs to communicate memory back to userspace, it can be moved back in, ideally, only one switch. This is a pretty simple optimization which has a lot of room for improving performance. Some processes like servlet containers and their servlets could, in theory, be moved entirely into kernel land, without having to program any kernel code at all. I wonder if this is planned for any JVM?
Sam ty sig.
You've missed an important reality of FOSS development, which is that most projects have a core team (or, often, a Benevolent Dictator) which decides everything. No matter how much the users might want, that core team still decides what gets implemented and widely deployed. Look at Python vs Ruby - they're competing in a very similar space, and both growing in different directions, with uses for both of them. They simply cannot become one project without losing their individual advantages. But they can co-exist rather nicely, and cross-pollinate ideas that are compatible with both.
Linux has Linus as the benevolent dictator. Linux is freakin' awesome, but other projects do things differently, and can often justify them one way or another. If these projects are allowed to bring those ideas into reality, and demonstrate their value, Linux could copy the ideas.
Look at BSD's kqueue, spawned in FreeBSD. It's really good. Around the time it was spawned, Linux still had poll, and then later epoll, but epoll isn't that great. Now Linux is getting new event notification systems, of varying sanity, because kqueue has shown it can be done much better, even if the Linux guys don't quite agree with it in its entirety.
For all we know, Linux might end up re-architecturing to have natural SSI like DragonFly plans to have. DragonFly can be a great proof of concept. And if, a few years from now, the market situation is such that implementing drivers, software support, etc. is easy, the developer resources can focus on making a competitive, usable product instead of playing catchup with basic hardware support. We'll see an explosion of useful, interoperable operating systems, that would have otherwise died just trying to be runnable at all. *Especially* with virtualization platforms reducing the amount of code necessary to get a live kernel, and improving debuggability, deployment flexibility, etc. The mere anticipation floors me.
Sam ty sig.
If OpenSolaris sees adoption on low end machines, it would provide an incentive to enterprise level customers to go the whole hog and buy Sun hardware to run it on. What could be better from a corporate point of view than having a single vendor to go to for all your support and other issues, not to mention that my experience of Sun support is pretty damn good.
...After years of migrating most of our datacenter operations from Solaris & IRIX environment to Linux, we have pretty much migrated everything back to Solaris. Reasons? Cost - Solaris licenses are free. Support is good, and also relatively inexpensive. Cheaper than RedHat Enterprise. Stability - We're talking interface stability, backwards compatability, etc. Storage - Linux's storage subsystems are still a joke. A hodgepodge of filesystems, and don't even get started on enterprise storage technologies such as fibre channel & multipathing, where the linux solution requires a spool of duct tape, a pack of chewing gum, and some string. Compatibility - Solarisx86 has had no problems running on any enterprise-grade server hardware (Dell, IBM, Sun). Many complain about Solaris not having the "driver base" of Linux -- but the question is, would you really want to run that hardware in your enterprise?
1.) Ditch the inhouse CLI tools - they suck and will never catch up with GNU. Maintaining them is pointless. Use the full spectrum of GNU CLI tools.
2.) Use a pimped zshell as shell with a prime quality default setup and some good-looking, neat tutorials to get the Bash crowd in line for it.
3.) De-suckify the entire grafical desktop stack, unifing GTK and QT with the same, one and only default theme that looks good.
4.) Use APT as distribution system.
5.) GPL Solaris and remove the distinction between Solaris and OpenSolaris.
6.) Build a marketing army to push Solaris as "Mac OS X" for all non-Apple computers and 'the better open Unix variant / the better Linux' at the same time.
There's only one big problem in all this: Sun. They are a technology driven company. Gigs like Apple or Canonical (Ubuntu) are vision driven and have a single boss who's considered king. They have a vision and they convey it to any opinion leader in the industry they care about.
Suns staff wouldn't know a well designed desktop or a constently marketed brand if you showed it in their face. Just look at the video presentations from JavaOne. Anyone delivering such a presentation at Apples MacWorld would lose his job the next day. Sun is putting out CEO computable marketing babble and if at all they will only come through half way.
Mind you, Solaris overtaking Linux is possible. Theoretically. Solaris has the prime advantage of not having an image torn to tiny bits and pieces by a thousand distributions - if Sun would do all the things mentioned above they could seriously capitalize on this distinction to Linux. But as I mentioned allready, they lack the vision and conceptual consitency to really pull through with it. That's my experience anyway.
We suffer more in our imagination than in reality. - Seneca
As someone who has had to recover Solaris software raid out of f*** state on multiple occasions I can ensure you that it did not use to be any better. In fact it was worse. Booting, repopulating devices, devices missing, having your MBT f**** up. Yep. Been there seen that. An all of the great three - linux, bsd and solaris. All of them suck equally bad so I will not recommend a newbie doing any software raid in the first place. Disclaimer - I have not tried opensolaris for this though
I lost, completely lost, 320GB of data due to the piece of shit Truecrypt for Linux, supposedly "stable". If you have 320GB of data, if you are brave enough to play with LVM and software RAID and you also smack TrueCrypt on it. Well... You are expected to have enough clue to have backups... If you do not...
The great about solaris is that it WORKS. Right there and then: it just works. May I suggest that you run a couple of hundred of servers with it in an Internet facing environment first. I have suffered from it and I have seen the lot. F*** up filesystems, MBR cockups, software raid bloopers, applications managing to make the kernel through the Sparc equivalent of GPF from the depth of the scheduler (something linux has not done for a very long time), the lot. Granted it has been a while, and most of it was not under OpenSolaris which has supposedly been "improved". Though as people say, once you get burned you stay away from it.
the scheduler, while this isn't an issue on Solaris. Now do not get me started here either. Since the day of 2.5 every Solaris release has been released with a scheduler that has been heralded as the best and above the rest. In every f*** release the marketing droids has screamed that Solaris is right, everyone else is wrong everyone's else scheduler sucks and Solaris is the best. After that they accepted "everyone else" scheduler concepts in the next release. Sorry mate, people here have not forgotten the abomination of lightweight threads. People have not forgotten the screams of Solaris marketing droids about the greatness of the N:M model. There are also people who have had to program the actual scheduler internal priority tables and retune it for job loads different from default. All of this just to find out that the next release completely fucks it up to move to different semantics from the ground up. Rinse, repeat...
Do you like it or not scheduler is always a flamewar because every scheduler sucks. Just it sucks differently for different people so there will always be one to flame away (especially after failing a testcase miserably).
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/