Submitted by Ian Murdock took the stage in one of the small rooms at the Moscone Center West to talk about the OpenSolaris Binary Distribution that is currently known as Project Indiana. We captured all of the slides Ian had shown, and while most of the information he shared was just reiterated from his past talks, there was some interesting details worth sharing. Among the advantages of Project Indiana is that it will use Sun’s ZFS as the default file-system, and Project Indiana will be taking full advantage of its abilities to create snapshots and perform rollbacks if something with the system’s software goes wrong. With Sun’s past work with the GNOME project, GNOME will be the desktop environment in Project Indiana said Ian Murdock.
If you take a look at the Indiana FAQ at GenUnix: http://www.genunix.org/wiki/index.php/Indiana_FAQ
You can see that these details have been in the public domain for quite a while. Glynn told us in the Sydney OSUG most of these details months ago.
+ Solaris with apt-get!
+ ZFS as default!
BUT!
“Ian had stated that the Solaris driver situation in the past year or two has improved dramatically and he believes the situation will continue to improve once the OpenSolaris user-base expands with Project Indiana. Once the user-base expands, he believes the OEM vendors will begin providing the drivers themselves.!
Translation: “We hope this will sort itself out just like it did with Linux and *BSD.”
Err…well, it haven’t quite done that yet, now have it?
All in all, Project Indiana looks promising, but time will tell what kind of hardware it’ll support.
> “Ian had stated that the Solaris driver situation in the
> past year or two has improved dramatically and he
> believes the situation will continue to improve once the
> OpenSolaris user-base expands with Project Indiana.
> Once the user-base expands, he believes the OEM
> vendors will begin providing the drivers themselves.!
I don’t mind much that lots of hardware isn’t supported. What I do mind is that it’s impossible to find out what hardware is supported. There should be a hardware compatibility database for OpenSolaris (much like there is one for Solaris, except with normal desktop hardware too).
(E.g., I’ve search a lot for either a normal mobo (i.e., not any $200+ server board) and/or a cheap pci-e sata adapter or two with a total of at least 6 ports. Either nobody is successfully running OpenSolaris on normal modern hardware or they just won’t speak up about it, AFAIK.)
Didn’t look very hard did ya?
http://www.sun.com/bigadmin/hcl/
> > There should be a hardware compatibility database for
> > OpenSolaris (much like there is one for Solaris, except
> > with normal desktop hardware too).
>
> Didn’t look very hard did ya?
> http://www.sun.com/bigadmin/hcl/
Didn’t read what I wrote, did ya?
I have this one. It gets detected right out of the box, the drivers are included on the Solaris CDs. It has 8 sata ports and works flawlessly. It is a PCI-X card, but fits in a normal PCI slot (though the transfer rate drops from 2GB/s to 150MB/s or something like that). I have a PV-800 Asus or something like that, mobo. [email protected]. I have 4 Samsung 500GB discs in RaidZ. Works like a dream.
The reason I bought an external card, is that I can change the mobo without bothering to check if it’s SATA chipset is compatible with Solaris. I just buy which mobo I want, and insert this card. No more worries. I can recommend this card.
http://www.supermicro.com/products/accessories/addon/AoC-SAT2-MV8.c…
> [The AOC-SAT2-MV8] gets detected right out of the box,
> the drivers are included on the Solaris CDs. It has 8
> sata ports and works flawlessly. It is a PCI-X card,
> but fits in a normal PCI slot (though the transfer rate
> drops from 2GB/s to 150MB/s or something like that).
First of all it’s an incredibly rare piece of hardware. At least in this part of the world, where it costs 160 EUR (=220 USD) +shipping. That’s more than a complete motherboard with 6 integrated SATA ports which are A LOT faster than those PCI-X-card-in-PCI-slot ports.
PCI-X is a really bad option if you have normal desktop hardware. A PCI-E 4X or 8X card would be a hundred times more sensible. Or even a bunch of cheap PCI-E 1X cards with 2 SATA ports per card.
Edited 2007-09-24 17:46
> [The AOC-SAT2-MV8] gets detected right out of the box,
> the drivers are included on the Solaris CDs. It has 8
> sata ports and works flawlessly. It is a PCI-X card,
> but fits in a normal PCI slot (though the transfer rate
> drops from 2GB/s to 150MB/s or something like that).
>First of all it’s an incredibly rare piece of >hardware. At least in this part of the world, where >it costs 160 EUR (=220 USD) +shipping. That’s more >than a complete motherboard with 6 integrated SATA >ports which are A LOT faster than those PCI-X-card-in->PCI-slot ports.
>PCI-X is a really bad option if you have normal >desktop hardware. A PCI-E 4X or 8X card would be a >hundred times more sensible. Or even a bunch of cheap >PCI-E 1X cards with 2 SATA ports per card.
Yes, I agree with you, that this SATA card may not be optimal (as it is targeted for server motherboards because of the PCI-X slot) and it is quite expensive. But I wouldnt want to take a chance, I KNOW this card works happily with Solaris. Ive also heard that Solaris is picky about SATA discs – chances are that your mobo doesnt work with Solaris. What do you then? Now (let me reiterate) I dont have to check HCL list for mobos SATA chipset – I just can buy any fancy mobo I wish, and know that SATA wise my discs work with Solaris.
But if you always happen to choose mobos that has SATA chipset that Solaris likes, then you dont need this card. And if you find a PCI-E SATA card that Solaris likes, please tell me (Ive spent a month on Sata and Solaris and couldnt find anyone that is guaranteed to work).
Edited 2007-09-25 08:57
> chances are that your [SATA-]mobo doesnt work with Solaris.
> […] if you find a PCI-E SATA card that Solaris likes,
> please tell me
Those are reasons why we need a hardware compatibility database. It’s just stupid that many people test loads of hardware and then never report about it in a way that others could easily benefit from it. And even if I did know a decent PCI-E card that works well with OpenSolaris (which I don’t) then a comment on an osnews article is definitively the wrong place to mass-communicate this information. I re-iterate my original point: What OpenSolaris needs even more than more drivers is a hardware compatibility database. I would even go as far as to say that this is what OpenSolaris needs most of all at the moment. People won’t use it as much when they don’t know what it runs on. I certainly won’t buy a new computer to run OpenSolaris on when there’s a big chance that most of the hardware can’t be used with OpenSolaris. I also don’t have the money to buy tons of hardware just to check whether OpenSolaris works on it or not.
The second most important thing OpenSolaris needs is to support a few pieces of cheap and very common hardware. Just pick a few SATA adapters, gbnet cards, etc. and write drivers for those and put the info in the hardware compatibility database. Then hobbyists around the world could easily buy cheap hardware to run OpenSolaris on, and I would bet my left ball on that these two things would make people use OpenSolaris at least an order of magnitude more.
The article is wrong. They won’t be using apt-get, but it will be something like it.
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.
Meanwhile, I know some KDE contributors who are dedicatedly making sure that KDE works fine with Solaris and Sun Studio. So I think Sun’s attitude is a bit disappointing.
If I’m not mistaken, Sun already runs Gnome on quiet a few (customer) desktops.
KDE is an official OpenSolaris project, like many others: http://www.opensolaris.org/os/community/desktop/communities/kde/
See also Adriaan’s blog http://people.fruitsalad.org/adridg/bobulate/index.php?/categories/…
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.
Well, the slides indicate that Project Indiana is looking for a lot of help/feedback from the community. It won’t take long until they have a KDE “spin” just like Fedora.
Sun will use GNOME as they are a key contributor to the source code. They aren’t preventing you from rolling your own KDE, nor would they – this is the point of open source.
Just as Linus says use KDE, Sun just have an opposite preference. THats the ting about freedom – you don’t have to follow what someone else does
I’m not sure if Sun even wants to support GNOME any longer. Sun lost, Novell won. Mono and C# are everywhere in GNOME (F-Spot, Beagle, Banshee,…)[*]. Sun wanted GNOME to be another Java troyan horse just like OpenOffice, but in reality Java is nowhere in GNOME.
Sun may have to support, because the customers want it, but I wouldn’t be suprised if Sun tried to take over XFCE within a year or two.
[* While not part of GNOME itself, these apps are installed on almost any GNOME desktop is the wild.]
Edited 2007-09-23 14:32
Hmm, not exactly.
I think that as far as OpenSolaris is concerned, there isn’t any or not much difference.
As far as the official Sun Solaris is concerned, there obviously is a difference, since Sun e.g offers commercial support for GNOME on Solaris.
However, as we have seen on other occasions, a well working community based subproject, in this case KDE, can become a commercial supported option when customers request it.
I ask this issue in an OpenSolaris mailing list some time before and someone replied me answering my questions. Basically, Solaris will not support KDE as its desktop environment because three things:
1. The C ABI is standard, so, any library compiled with any C compiler can be used by any application compiled with another C compiler (this is very important, because Sun pushes SUNWpro C compiler but they want to provide compatibility with the GNU C compiler also.
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++. This is a very critical problem because KDE is written in C++; as far as I know, Qt does not support SUNWPro C++ compiler and in order to provide library usability on KDE, they should build several versions of the same library, compiled with several compilers: impractical.
2. GTK+, the GNOME base library, has a LGPL license; meanwhile, Qt, the KDE base library, has a dual license: GPL for open source applications and a commercial license for proprietary applications. If Solaris would support officially KDE, the developers that want to write some commercial applications for KDE, should buy the Qt library; in the other extreme, nothing stops them from writing commercial applications using GTK+.
3. Solaris has invested a lot of resources in the GNOME accessibility framework, so, GNOME fully implements an accessibility standard [I do not remember its code] and KDE, no.
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.
Probably their C++ team is a lot smaller than any other engineering unit and therefore can’t keep the same stability as others.
I’d say this is more an excuse than an argument.
Given a platform there is always one compiler defining “the standard” and since we are talking about Solaris here, it is Sun’s own one.
If g++ is incompatible, bad luck.
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.
Sometimes generates loads of warning for our code, all correct though
One of the prime advantages when doing mulitplatform software.
Licence royalties haven’t kept them from shipping Motif and hasn’t kept hunderts of companies from licencing Qt so far.
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.
Edit: fixed quoting
Edited 2007-09-23 18:15
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.
Yep, the original statement was wrong. You can compile Qt with Sun Studio (though you need RogueWave too with the latest versions).
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.
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.
If it doesn’t there are no ABI problems on Solaris.
But of course it makes good “reasoning” (aka FUD), though I am quite disappointed to see Sun engineers resorting to this.
True, but tells a lot about ISVs accepting royalties on base libraries. Motif didnt even have an exception for free software.
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).
My guess is they try to avoid the fact that different from Motif ISVs can basically no longer link the toolkit statically (without providing relinkable object files)
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).
Official reason? Really? Officially posted where? I have never seen that reasoning. Nor does it make sense given that Sun has a lot of engineers that work with C++ (obviously given they produce a C++ compiler!!!).
In contrast, if you go look at posts on this based off Sun engineers, you will see licensing as one of the reasons.
Edited 2007-09-24 13:17
http://www.osnews.com/reply.php?news_id=18661&comment_id=273836
“…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’s really a non-issue. Anyone using an incompatible compiler for whatever reason knows that they are incompatible.
On the other hand Microsoft doesn’t seem to have a problem shipping C++ libraries even if GCC has a different ABI in Windows as well.
Assuming that Sun’s engineers are at least as good as Microsofts, the only interpretation left to me was that their own C++ compiler wasn’t ABI compatible to it’s other versions.
It becomes FUD if one makes look it like a problem introduced by the language rather than by using incompatible compilers.
Any such statement that doesn’t include the information that it is based on the comparison of two different and incompatible compilers is way to over generailzes and, from my point of view, is FUD targeting at making look C++ like a bad choice.
Especially if coming from an engineer of a platform that has, according to you, no such issues with the platform’s standard C++ compiler.
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.
> It’s really a non-issue. Anyone using an incompatible compiler for whatever reason knows that they are incompatible.
How is having to build 2 or more sets of the same libraries a “non-issue”? I call it an absolute pain in the ring piece. Sometimes things build in Sun Studio C++ and not g++, others in g++ and not Sun Studio. Later on you have an application dependant 2 libraries which only compile using the different compilers. This is not a ‘non-issue’.
> Especially if coming from an engineer of a platform that has, according to you, no such issues with the platform’s standard C++ compiler
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. He just has very valid reasons why he prefers to not use C++.
Well, doing that would be an issue, but why would one do it in the first place?
If a piece of code does not compile on the target platform, it is broken and needs to be fixed or replaced with something that compiles.
Since g++ is obviously not capable of complying with the Solaris standard C++ ABI, it is not available for anyone who wants to deploy C++ based code on Solaris.
On Solaris and a couple of other system where there is a canonical C++ ABI (based on the vendor’s toolchain) it is a non-issue.
Just like one doesn’t use an editor that breaks the text encoding, one doesn’t use a compiler that breaks the binary.
If GCC developers want their compiler to be used on platforms where GCC is not the canonical compiler, they need to make sure it complies with the platforms binary formats.
Well, I hope that the people who write the compilers are not unhappy that engineers from other departments suggest their work is sloppy.
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.
In which case, it isn’t find. It isn’t about “incompatible compilers” — it’s about the lack of a standardized ABI for that specific language.
The rest of your argument is wrong since you made an incorrect assumption.
You were implying that they didn’t have any, you didn’t make any sufficient quantitative implications.
Assuming (probably wrongly) that it is obvious to any engineer that it’s a problem to use broken tools, I took it that Alan sees a problem with C++ under any circumstances.
Since I have just recently, in this very thread, been educated that in fact there is no C++ ABI problem on Solaris, he is likely concerned that some developers might not be smart enought to not use broken tools.
IMHO not a problem of the language though, so it should probably be phrased differently.
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.
You are right, bad wording on my side. It is about a certain compiler being buggy and not producing the correct binary output. Sorry.
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 wrote “more”. Don’t see how this implies “none”.
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.
I’ve built and distributed a closed-source but free-as-in-beer app for Linux for many years now that’s written in C++. Every major gcc upgrade has broke the binary unless users install a special compatibility library. Even then, for some reason, that doesn’t always work. You also run into the joy of C++ libraries compiled with a newer version of gcc not working with binaries compiled with an older version, etc.
It makes for a dependency hell.
Right, but when that tool is the pervasive one of choice for a platform (GCC for GNU/Linux) it makes life incredibly painful.
That’s where things get screwy for gcc. Remember that gcc doesn’t have a “primary platform” — it has many in reality. The Sun Studio compiler on Solaris has produced C++ output that has been compatible for years and years and years now. In comparison, the gcc folks have broken it several times in the same period.
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.
No argument about that. My point is that if a tool, in this case GCC, has broken output, in this case not complying with the platform’s C++ ABI, it is not worth considering.
For any other tool, e.g. a text endocing converter, we wouldn’t even have this discussion, but somehow when it comes to C++ compilers, there are always people who blame it on C++ rather on the faulty compiler.
I agree. Doesn’t, however, make it a problem of the language, since other platforms, including the one of the topic (Solaris), manage it well.
True, but this doesn’t mean they can’t be compatible to the requirements of the platform, if the platform has such requirements, e.g. explicitly (through a specification) or implicitly (through a vendor supplied compiler) specifies a C++ ABI.
It’s debatable whether it is a good idea to break their own output on platforms where such standards do not exists, e.g. Linux, but in this case it’s rather an inconvenience than a bug.
Exactly!
This is why I was so puzzled to read this kind of sentiment when from my personal experience the platform in question does it right.
I find it kind of uncalled for to make all C++ compiler teams look like they are bad engineers just because one team messes up.
> 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).
I depends on what part of Sun you are talking about. Solaris ofcourse is written mostly in C. OpenOffice, and many of their enterprise applications are written in C++. They also do some Java
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. It also used to cost $1500, so many people preferred gcc/g++. Now it’s free, but OpenSolaris has tried to avoid locking in one compiler over another.
Sun is a co-owner of Motif, and neither Sun nor Sun’s customers pay license royalties for Motif on Solaris.
Absolutely. Sun can’t bundle every possible bit of software in the OS – that’s what ISV’s are for.
This is why I have a problem with such rather generic “C++ has ABI problems” kind of statements. It is just not fair to your own C++ compiler team, because they do a good job.
Perhaps, the next time you feel about pointing out possible pitfalls, you could phrase it in a way which makes it more explicit that certain toolchains might lead to compatability issues.
Which I absolutely understand, but neither does Microsoft and on Windows there are several third party compilers capable of producing compatible binaries.
But, just like Microsoft’s compiler does on Windows, Sun’s own compiler basically defines the requirements for binaries on Solaris.
They forgot to mention point number 4. The one where they explain that endorsing a third-party cross-platform framework designed for effective write-once/compile-anywhere development would sort of conflict with the original java strategy.
Gnome made sense originally because it lacked a real development framework, and I remember how the whole “Java Desktop” thing was supposed to be about a java desktop framework for app development, or something to that effect. Never took off, and then the primates came along and muddied the waters as well with their attempt to make mono the de facto development framework.
It’s also worth mentioning, in fairness, that one of the Sun offices in Europe has been supporting some of the local KDE devs working on KDE4/Solaris, and have even provided hardware for test builds etc.
Nor does Ubuntu arguably, and nor do many others.
Just like many KDE-centric distributions (Linspire, Xandros, etc.) don’t support GNOME equally.
I see posts on here all the time about people complaining about wasted resources and lack of focus.
Well, here’s some focus, enjoy it!
KDE is the largest non-distribution open source project (non-distribution = not counting eg. FreeBSD or various Linux distros, because lots of their activity is syncing code with other projects).
I can’t remember a single day when GNOME had more activity on http://cia.vc/ than KDE.
When Sun got involved, GNOME was even smaller. Sun tried to hijack GNOME (smaller projects are easier to take over), but apart from the inclusion of the results from their usability tests Sun didn’t succeed. Almost no desktop software for GNOME is written Java.
Is isn’t that some gnome contributors work at sun. It is more like several gnome maintainers work at sun. Several years ago, Sun was looking for something to replace their venerable CDE desktop environment. Their choice was gnome pretty early on and they have been shipping it for sometime. Even their discontinued Linux distro, the Java Desktop System was gnome based.
Sun also paid a lot of money for the original gnome HIG (Human Interface Guidelines) and initial documentation to be written. They have an investment in gnome.
Sun made the GNOME decision a long time ago.
The short version at this point is that:
1) GNOME has better accessibility
2) GNOME has better licensing (for business purposes, no flame wars please)
3) GNOME has a time-based release schedule that makes it very easy and predictable to integrate
4) Until recently, KDE didn’t even work fully on Solaris! (Thanks to Stefan Teleman for changing that)
5) Sun has invested millions of man hours and dollars into GNOME (through the HIG, etc.) and it doesn’t make good financial sense to waste that investment.
GNOME doesn’t have a powerful marketing/lobby campaign, it’s just that some of the choices it has made as a project fit in better with what some folks are doing.
Ubuntu chose GNOME as their primary desktop as well, so you can gripe to them too.
Ian has already stated he would like to see someone do “Kindiana”.
Everyone has their personal preference and I hope to see KDE 4.x on Solaris as well and plan on helping out in any way I can.
I just think your accusations aren’t fair or right.
Edited 2007-09-24 01:22
This is highly debatable, so do not add it if you want to avoid friction.
Licencing is always just a part of the decision making and depends on a lot of things.
Writing “better licencing” is always just flamebait, since there is no such thing as universally better.
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*. That doesn’t mean the technology is better, but the terms of the licensing certainly are. That is a factually correct statement.
Edited 2007-09-24 13:13
Well, you said for business purposes, not for financial ones.
Being a non English native speaker, I interpreted it as “from companies’ point of view”, which would depend on what the company’s goals are.
It still assumes that the financial perspective does only cover licencing cost and no other cost involved in development, deployment or maintenance of the software.
It’s quite educating that native English interpretation of “business purposes” means “low initial cost”.
That’s probably why so many US based companies always talk about TCO separately
Language barrier. I didn’t feel like I needed to be that specific, but if you want to be all technical about it, yes, financial business purposes. Whatever. The point is the cost, and that should have been obvious given the context. I’m not talking about those “ROI/TCO” or other weasel word terms that Microsoft likes to use to makes Windows look better than Linux.
The problem with ROI and TCO is that they are subjective. Cost of licensing alone is easy to analyze and not subjective.
Edited 2007-09-24 16:59
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.
Businesses make decisions on ROI, not in terms of static prices and costs, hence the old adage “you need to spend money to make money”. The license fee for a Qt license is but one aspect of an equation that different organizations will measure with different points of emphasis and value. If Qt in comparison to GTK (or alternatives) can help an ISV deliver applications with reduced turnaround, can enable cross-platform development, can provide support and documentation, etc., then the license fee becomes fairly moot in comparison to the overall equation, particularly considering it amounts to a one time-payment equivalent to 2-3 weeks of the average paid developer’s salary.
So as a simplistic example, if an ISV can develop and deliver an application in 20 weeks using Qt versus 30 weeks using GTK, then GTK very likely provides a financial disincentive from a business perspective, despite it’s “free” license price since it actually increases the cost to the ISV in terms of the number of weeks required for development. Certainly not saying that’s the case for all developers and applications and situations, and as I said, I’m oversimplifying, but it’s more indicative of how the decision making gets made with businesses.
For organizations developing and deploying internal applications, the licensing fee doesn’t apply since there is no obligation to deliver source with a product that is not being distributed. Though even in those cases, many of Trolltech’s customers continue to pay for support simply because of the value they perceive.
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*.
I agree.
One point is that the GTK port on windows is a joke, while Qt is virtually indistinguishable from other applications. Its not like the lisence fee is abhorrently expensive, and if being cross platform is important, the value vastly outweighs the lisence cost.
That’s an opinion, and one that not everyone shares.
My statement stands.
On a cost-of-licensing-only basis, not ROI or anything else you can twist to say whatever you want to say (see Microsoft’s TCO/ROI arguments for Windows), something you don’t pay to license for is better.
Whether you consider that a valid evaluation is subjective.
That is not always true. If you don’t have the money to pay for the licensing, then it doesn’t matter what the value is.
OR it could be because Sun has been one of the major supporters of GNOME for years, both in source contributions and in developers. It is also on the GNOME advisory board, and GNOME has been the desktop they have used in Solaris for as far back as I can remember.
For a moment there I thought the new packaging would use Gentoo’s Emerge.
But I misread the title.
This is one of the best features for the opensolaris adoption in the desktop.
I think this project is looking better and better. One could argue that it is looking more and more like Linux (this is only skin deep of course). Things like ZFS have their own technical merits, but I honestly don’t see how it will affect me (current grad student in French, and with any luck will be a professor). The one thing that I look for is a long support cycle. One of the slides said that OpenSolaris would be supported 1 to 2 years. If it is only for one year, there is no real difference from most Linux distributions. So why would a Linux user want to switch to OpenSolaris? I know I would not (but I then again, I am not like most Linux users – i.e. no technical background). If OpenSolaris is supported for two years, my interest goes up. Right now, only a handful of Linux distributions are supported longer than one year – OpenSuse at 2, Fedora at 13 months, Debian at about 4 years (if you assume two years between releases), *buntu LTS at 3 years, and the RHEL clones at seven years. I am not sure about PCLinuxOS, but their support cycle seems long as they don’t release with great frequency. I think that making the support cycle for OpenSolaris 2+ years would create another difference between it and Linux, and would perhaps give others a reason to switch. I know I would seriously consider it.
If you really are worried about support length, why dont you later – when the need rises – switch to Solaris? Me personally are not running nuclear reaction software or something similar. In fact I am running OpenSolaris Express version build 68 which is – in reality a beta software. And I dont notice any instability issues as Linux sometimes have. Solaris in beta version is more stable than Linux, in my opionion.
And after becoming used to OpenSolaris, want support length, you should just switch to Solaris which have support length of 10 years. Problem solved.
I agree that Solaris releases and development builds are pretty stable but you can’t judge Linux in some generic way. What amazes me in the Linux distribution landscape is that everyone wants to release his own distribution, wildly varying in quality.
That doesn’t mean that I am against the fact that there are so many of them, in fact I’d say the more the better! But a distinction must be made between work and play.
For work you need the best stability, reliability, security and performance. For play you can have all the eye candy and bleeding edge system software and applications you want to have.
Most distributions, including Red Hat, Novell/SUSE and Ubuntu have these two confused. I just don’t understand this, but maybe that’s just me. All the while there is a distribution that really rivals Solaris and BSDs, which I won’t mention but its maintainer’s initials are P.V.
I have found it easier to kill Solaris than this distribution I use, but I also agree that sometimes the Linux distribution landscape just looks like kindergarten.
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:-)
Edited 2007-09-23 13:47
It can’t connect to the registration because you can’t register the Nevada build – only the ‘stable release’ (latest being 08/07) can be registered – as it is the only one officially supported via Sun with updates and so forth.
Indiana will be the first ‘Nevada derived distribution’ which will include updates.
That works only as part of Solaris, not OpenSolaris…
Check the FAQ/forums in opensolaris.org