[ I've moved this to indiana-discuss and bcc'ed the others as it seems
to be moving off-topic for the other lists. ]
> And, is there an official decision already that project Indiana will be
> Solaris Next?!
As one of the leads for Project Indiana, yes, I believe many of the
technologies that have been introduced through Project Indiana will
form the basis of what makes up Solaris.Next. How this will take place
is still to be determined, but I expect that the Caiman and IPS
projects and many of the other "smaller" changes will integrate over
the next year into current OpenSolaris consolidations such as ON.
No, we're not trying to clone Linux. What we are trying to do is make
a version of Solaris which combines the best of the attributes
traditionally associated with Solaris including those listed under
"Design Principles" here
http://opensolaris.org/os/community/on/os_dev_process/
with a user interface which is more familiar with users and developers
who have not used Solaris the past 25 years. In some cases, doing the
latter will require some changes that may give pause to users who
expect the user interface, the value of uname, even the contents of
/usr/bin to never change or to change in a 100% compatible manner.
However, it's my belief that while our current customer/user base is
extremely important, there is an even larger group of potential users
out there who otherwise will not examine the technologies of
OpenSolaris and the benefits those technologies can bring them unless
we change the system is some fundamental ways. I would argue, in fact,
that it's imperative we make these changes in OpenSolaris because to do
otherwise would leave an operating system, beautifully designed, but
used by an ever-descrasing set of users.
What this might mean is
o A version of "uname -r" that doesn't return 5.x.
o A shell which provides such radical concepts as command line
editing, history and something that is familiar with users of
Fedora or MacOS X.
o Versions of traditional UNIX commands which work the same way
that other platforms do, rather than shipping a set of
utilities which have largely been neglected over past decade.
o A packaging system that concerns itself with laying down the
files of the package and not post-install configuration.
o An installation framework that is built on open source and
redistributable components, which makes simple installations
easy but also provides a way to do automated installations for
more complex situations.
o Some incompatible changes although the intent is to minimize
that as much as possible and preserve 100% compatibility in
areas like the ABI.
And so on. Note that although the GNU toolchain is often quoted as the
desired end games, that simplifies things excessively. I believe the
implementation may come from different sources - some might use the
existing toolchain as a starting point and then iterate from that. In
other cases, yes, a GNU command may be the best starting point because
it's something that is both familiar and modern. And in other cases,
it might be some other implementation altogether.
What's long overdue is a Familiazation Project - it's something I'll
work on proposing formally just as soon as I get out of some current
project deliverables for 2009.06. I would definitely welcome your help
in drawing up requirements and even more so, in getting one's hands
dirty dealing with undoubtedly a complex set of trade-offs.
