Either way I regret that Sun didn't even talk to KDE (afaicr) to see if some collaboration could happen.

Yes, so you're supporting my point that while KDE people are actively supporting OpenSolaris, OpenSolaris does not care to support KDE on an equal footing with Gnome.

I installed nevada dev edition from the DVD kit. Gnome looks nice and the system performance is good. Unfortunately the GUI updater didn't connect at all. In addition running smpatch from the CLI gave me the message of register first via GUI.

Looking forward to the projects progress:-)

The C++ ABI is not standard and it is far from be stable (including between two versions of the same C++ compiler)..

...so, creating some library with SUNWpro C++ compiler will not be useful for an application written with g++.

...as far as I know, Qt does not support SUNWPro C++ compiler...

...Qt, the KDE base library, has a dual license: GPL for open source applications and a commercial license for proprietary applications...

I've seen this as well, even from Sun engineers. Seems their C++ compiler can't keep stable ABI either, at least not through a Solaris release cycle.

Extremely unlikely, unless Sun has a couple of totally different C++ compilers, because it supports the one from Sun we are using on Solaris/SPARC every day when doing nightly builds.

Licence royalties haven't kept them from shipping Motif and hasn't kept hunderts of companies from licencing Qt so far.

+ Solaris with apt-get!

2) GNOME has better licensing (for business purposes, no flame wars please)

No, it's actually the other way around. Sun's C++ ABI hasn't changed in many years. It's the gcc ABI that keeps changing.

Which is irrelevant because that's what the UNIX consortium started with.

However, Sun decided that wasn't an acceptable choice going forward and that is why they are phasing out CDE in favour of GNOME.

Writing "better licencing" is always just flamebait, since there is no such thing as universally better.

Then I don't see a problem. Based on all the fuzz Sun engineers created about C++ ABI just allowed the conclusion that their C++ compiler had the same issues as GCC.

But of course it makes good "reasoning" (aka FUD), though I am quite disappointed to see Sun engineers resorting to this.

Interesting. The only official reason I've read so far was that Sun had more experience with C instead of C++ (in number of developers).

Which is why I said "for business purposes"...obviously licensing that doesn't require paying someone a fee is better from a financial perspective *always*.

Until you see a quote from a Sun engineer, that's wild speculation. If you have, show them.

If you read the original post, you would see the reasoning was based on the mixing of C++ objects compiled by two different compilers, not with problems with the ABI of only one.

It isn't fud. You can't mix C++ objects between Sun Studoi and g++ reliably (or at all in some cases).

Nor does it make sense given that Sun has a lot of engineers that work with C++ (obviously given they produce a C++ compiler!!!).

Heck, gnome folks must have a pretty powerful marketing/lobbying. Or perhaps it's the fact that some gnome contributors work at Sun. Either way I regret that Sun didn't even talk to KDE (afaicr) to see if some collaboration could happen.

"Writing "better licencing" is always just flamebait, since there is no such thing as universally better.

Well, you said for business purposes, not for financial ones.

"...Rewriting Qt in C so it doesn't suffer from the lack of a standard C++ ABI.."
Alan Coopersmith- alan dot coopersmith at sun dot com
http://www.opensolaris.org/jive/thread.jspa?messageID=84595&

If one tries to use compiled binary objects from two compilers with different binary output, this is always a problem. Don't see why this seems to be only be seen as a problem if it involves C++.

It becomes FUD if one makes look it like a problem introduced by the language rather than by using incompatible compilers.

They said they had more C experience than C++, they didn't say they had none.
Or maybe the head honcho in that interview I read just didn't know or didn't want to address other reasons.

Actually, no, it's not factually correct, although it gets stated often as such. If it was factually correct, Trolltech would not have a revenue stream and would have been out of business long ago since customers can always use free toolkits instead for financial reasons. You can't dismiss whether the technology is better or not as a factor, because that is directly related to the value a customer perceives in paying for the license, not the price itself.

I'd be willing to accept that GTK's LGPL simplifies licensing, but not that cheaper = better for business purposes. From a financial perspective, cost != value, and value is what must be considered *always*.

If you really are worried about support length, why dont you later - when the need rises - switch to Solaris? ... And I dont notice any instability issues as Linux sometimes have. Solaris in beta version is more stable than Linux, in my opionion.

How is having to build 2 or more sets of the same libraries a "non-issue"?

Sometimes things build in Sun Studio C++ and not g++, others in g++ and not Sun Studio.

This is not a 'non-issue'.

Alan is part of the X windows group. As far a I know he does not have anything to do with writing the Sun Compilers.

If you read the context of the thread and conversations on that forum, you would realise they are not talking about Sun Studio, but about the lack of a standardized C++ ABI across compilers.

Wrong. There is a very well known and accepted ABI for C code.

It isn't about "incompatible compilers"

it's about the lack of a standardized ABI for that specific language.

You were implying that they didn't have any, you didn't make any sufficient quantitative implications.

On certain platforms, which to my updated knowledge includes Solaris, there is a well known and accepted ABI for C++ code.

It's is always possible to create tool which procudes corrupt output, usually this is referred to as a bug in said tool, not as a inherent flaw in the content the tools operates on.

Well, there is. It is defined by the very compiler that created the standard C++ library of the platform. Any compiler that does not produce compatible binaries has a serious bug.

I've seen this as well, even from Sun engineers. Seems their C++ compiler can't keep stable ABI either, at least not through a Solaris release cycle.

Licence royalties haven't kept them from shipping Motif

Not a problem though, since Solaris is also X11 based, companies can licence the toolkit they want to use instead of relying on what is shipped by the OSV.

Yes, and the problem is that the gcc folks don't use it. They have changed the C++ ABI so many times in the last five years it isn't even funny.

Right, but when that tool is the pervasive one of choice for a platform (GCC for GNU/Linux) it makes life incredibly painful.

Remember that gcc doesn't have a "primary platform" -- it has many in reality.

Sun Studio isn't perfect, but they care a heck of a lot more about not breaking the ABI. I think this is one of the reasons why C++ is far more popular on platforms other than GNU/Linux (which has chosen gcc as its primary compiler). C++ has far better support on Windows, Solaris, Consoles, etc.

Sun's C++ compiler is not included with Solaris, has it's own release cycle, and has maintained a stable ABI for about a decade now.

Now it's free, but OpenSolaris has tried to avoid locking in one compiler over another.