Linked by Thom Holwerda on Mon 20th Jul 2009 19:16 UTC
Sun Solaris, OpenSolaris The Linux desktop has come a long way. It's a fully usable, stable, and secure operating system that can be used quite easily by the masses. Not too long ago, Sun figured they could do the same by starting Project Indiana, which is supposed to deliver a complete distribution of OpenSolaris in a manner similar to GNU/Linux. After using the latest version for a while, I'm wondering: why?
Thread beginning with comment 374491
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: personal impressions...
by kawazu on Tue 21st Jul 2009 18:26 UTC in reply to "RE: personal impressions..."
kawazu
Member since:
2005-12-11


...
This way you can have an environment for Eclipse java 1.5 in one BE in GRUB, another with Eclipse Java 1.6, Netbeans, etc etc etc.

This is not useful for desktops, you think??


Not sure, but at the very least for keeping different Java environments separated, I don't really need boot environments (although they are a nice feature, no doubt about that). Been working with OpenSolaris 2008.x for about two months in total in production work, trying to figure out whether this is what I want, and never found a real reason making me thing "wow, now _that_ is amazing a thing to have..." - on a notebook, not on the server.

Overally, stating this again, comparing the "experienced negatives" (overall performance, IPS issues, eventually lack of pre-compiled software) with the set of additional features of some use _to me_, I don't really see a reason to switch to OpenSolaris as my main OS. I'm still cautiously enthusiastic about OpenSolaris, both hoping for it to actually grow a real "community" (rather than just being a "public Sun code repository"), maybe for becoming the first operating system to be GPLv3 licensed (yes, this matters to me), maybe for coming to life in a more "lightweight" incarnation (StormOS with XFCE is pretty good about that actually) for desktop or notebook usage, but so far IMHO it is not yet there. YMMV of course.
K.

Reply Parent Score: 1

Kebabbert Member since:
2007-07-27

Ok, it is your choice, if you do not care about keeping your data safe (ZFS), or making your programming easier (DTrace).

But just one thing, please just skim this articles and see if you really really really do not think that OpenSolaris is totally awesome. Because, this stuff no other OS can do. This is totally unique for a developer. I can not really understand why you would think this stuff not the-coolest-thing-on-earth-right-now!


PHP development
http://blogs.sun.com/bmc/entry/dtrace_and_php_demonstrated


Rails
http://blogs.sun.com/bmc/entry/dtrace_on_rails


Java
http://blogs.sun.com/ahl/date/20050418#dtracing_java


Java Swing
http://blogs.sun.com/bmc/date/20050418#your_java_fell_into_my




And this is possible for other languages as well. DTrace helps Solaris kernel developer tremendously to iron out the bugs. People are in total awe of DTrace (and ZFS, Zones, etc etc). Maybe you non-solaris users fail to see why we are in total awe, or maybe we solaris users are very easily impressed:


"I looked at one customer's application that was absolutetly dependant of getting the best performance possible. Many people for many years had looked at the app using traditional tools. There was one particular function that was very "hot" - meaning that it was called several million times per second. Of course, everyone knew that being able to inline this function would help, but it was so complex that the compilers would refuse to inline.

Using DTrace, I instrumented every single assembly instruction in the function. What we found is that 5492 times to 1, there was a short circuit code path that was taken. We created a version of the function that had the short circuit case and then called the "real" function for other cases. This was completely inlinable and resulted in a 47 per cent performance gain.

Certainly, one could argue that if you used a debugger or analyzer you may have been able to come to the same conclusion in time. But who would want to sit and step through a function instruction by inctruction 5493 times? With DTrace, this took literally a ten second DTrace invocation, 2 minutes to craft the test case function, and 3 minutes to test. So in slightly over 5 minutes we had a 47 percent increase in performance.

Another case was one in which we were able to observe a high cross call rate as the result of running a particular application. Cross calls are essentially one CPU asking another to do something. They may or may not be an issue, but previously in was next to impossible (okay, really impossible) to determine their effecs with anything other than a debug version of the kernel. Being able to correlate the cross call directly to application was even more complex. If you had a room full of kernel engineers, each would have theories and plausible explanations, but no hard quantifiable data on what to do and what the impact to performance would be.

Enter DTrace.... With an exceedingly simple command line invocation of DTrace, we were able to quickly identify the line of code, the reason for the cross calls, and the impact on performance. The basic issue was that a very small region of a file was being mmap(2)'d, modified, msync(3C)'d, and then munmap(2)'d. This was basically being done to guarantee that the modified regoin was sync'd to disk.

The munmap(2) was the reason for the cross call and the application could get the same semantics by merely opening the file with O_DSYNC. This change was made and performance increased by almost double (not all from the cross calls, but they were the "footprint" that lead us down this path). So we went from an observable anomaly that previously had no means of analysis to a cause and remediation in less that 10 minutes."






EDIT: See DTrace in action on Linux (on top Solaris with Zones a.k.a BrandZ), where DTrace helps spotting less optimal behavior of "top" command:
http://blogs.sun.com/ahl/entry/dtrace_for_linux

Edited 2009-07-21 19:37 UTC

Reply Parent Score: 3

RE[4]: personal impressions...
by kawazu on Tue 21st Jul 2009 20:00 in reply to "RE[3]: personal impressions..."
kawazu Member since:
2005-12-11

Hi there;

well... you don't really have to kind of "evangelize" me regarding OpenSolaris... I spent most of my university life working with old Sun / Solaris workstations and for sure are affectionate towards Solaris and in some ways enthusiastic about the possibilities OpenSolaris does offer. And I have to admit that I am using Sun stuff (NetBeans, Glassfish, not talking about Java of course... :>) wherever possible. Personally, as well, I think many of the features provided by OpenSolaris generally are good, but then again, talking about an open source system, are they really tied to OpenSolaris? ZFS so far also does exist as a (fuse) port for GNU/Linux users. Maybe (not sure, though) DTrace also might be ported to GNU/Linux or other Unixoid systems - I'm not sure.

The only thing I know is, off-hand, that Sun in many respects failed about OpenSolaris. Why on earth that strange "Java Desktop System" (basically a modified GNU/Linux) a couple of years ago? Why does it take so long to make OpenSolaris stable? Why is there no "real" developer community around OpenSolaris so far, comparing to GNU/Linux or the *BSDs? Why, talking about DTrace in example, doesn't OpenSolaris come with a straightforward, powerful GUI tooling for these features to allow (desktop/developer) users to easily get started with these tools? Why, at the moment, is the set of hardware supported by OpenSolaris (being a company-backed operating system) still felt to be years behind what the Linux kernel provides here? Why, to get back to this example, does a system like Debian cleanly and quickly install packages within a couple of seconds or minutes where OpenSolaris IPS still takes rather long to install obscurely named packages to strange places like /opt/csw/ or /usr/gnu? I think that, given some more love years ago, OpenSolaris by now could be predominant. The way it is, right now it has to compete with GNU/Linux on the operating system, not even talking about Windows or MacOS X (which, as I disturbedly had to realize, seems to be the OS of choice amongst most of my Sun contacts... so much for that).

Asides this, just to add another example: When JavaFX was released, I just was into testing OpenSolaris, and I felt enthusiastic about JavaFX as well, just to figure out that - what? A technology released by Sun, in its initial release not supporting the operating system also released by Sun? That's simply dumb, from a marketing point of view, in my opinion...


So, overally: I hope the Sun/Oracle merger won't affect OpenSolaris all too much, or maybe a community will be capable of dropping in keeping OpenSolaris running even without Sun being there backing the project anymore. I still see work to be done, and I won't hesitate also testing out future releases. Let's see where it's heading...

Reply Parent Score: 1