IMHO this depends on the long term ability for OpenSolaris to continue, rather than the commercialization of such product as Solaris.Next. It all depends on how sustainable continuing this radical design and implementation path is really.
If it is Oracle's intention to continue development unhindered for a set period of time, or with current intention to wait it out and see how quality and areas in compatibility for modern users pans out, then I feel confident that Solaris in general will be in due time a worthwhile prospect, which more vendors, including the FOSS community upstream would support. Of course anything in-kernel has to continue to be mostly driven in-house as some organizations simply won't work with us. The toolchain is irrespective and irrelevant to most package maintainers and developers when such tools provide competitive advantages over others. One area of contention clearly is licensing and distribution of Sun's toolchain, and is not just dependent on our ability to break compatibility, or create shims to interpret legacy applications. Taking into account the seriousness of nature for Solaris to adapt to a large crowd, but maintain its individualism is important, but really has to do with our ability to provide quality software and documentation that is not matched, not playing nice. - James On Wed, 2009-04-22 at 19:41 -0700, David Fan wrote: > Do we have plan to drop the old SunOs 5.x and Solaris 2.x naming > conventions? It's just confusing to new users if they don't know the > naming history. About time for uname to return something like > opensolaris 2008.11. > > dfan > > > Alan Coopersmith wrote: > > One item that's been discussed in various arenas is bumping the > > uname output for the OS version (SunOS) from 5.x to 6.0 in > > OpenSolaris/Solaris.Next, to reflect the major changes occuring, > > especially the completely different packaging/installation system. > > > > Unfortunately, a lot of configure scripts for open source packages > > are written to check the uname output and make decisions based on it, > > either through direct `uname -rs` type calls or via the GNU autoconf > > macros such as AC_CANONICAL_HOST that map SunOS 5.x to *-*-solaris2.x. > > > > When you're working with importing open source packages and contributing > > patches back to their communities, you may want to check and see what > > happens to their builds if you build with uname set to SunOS 6.0 - if you > > have root, you can easily change the uname for a shell with the script at > > http://blogs.sun.com/angelo/entry/dtrace_detective_the_sequel > > > > For instance, I ran this with "pfexec ./uname.d $$" in a shell and then > > ran the latest version of the config.guess script from savannah.gnu.org > > and saw it doesn't know what to do with a uname greater than 5.x yet, > > reporting: > > > > ./config.guess: unable to guess system type > > > > This script, last modified 2009-02-03, has failed to recognize > > the operating system you are using. > > > > So clearly we'll have to work with the GNU autotools upstream before many > > projects can be uname-6-safe, but others may be able to be made clean > > without > > GNU autotool changes and anything you can do to prepare now will help reduce > > the pain for all later. > > > > _______________________________________________ > desktop-discuss mailing list > desktop-discuss at opensolaris.org
