On Thu, 21 Jun 2007, Peter Tribble wrote:
On 6/20/07, Ian Murdock <[EMAIL PROTECTED]> wrote:
Ben Creitz wrote:
What about a "long term support" release, too? Ubuntu will support an
"LTS" release for three years on desktops and 5 years on servers.
Fedora doesn't have this as far as I know, but for that type of
stability people turn to CentOS.
Absolutely. The LTS version will be called Solaris. :-)
Is that part of a plan or thinking out loud?
It makes sense, in some ways. But at the moment Solaris is the
LTS version of Solaris Express - so where would Solaris Express
go to in that world view? Replaced by Indiana?
With regard to the LTS concept, as I understand what Ian has
said about that concept so far, yes, that's the idea.
However, it seems like a classic case of "if it sounds too
good to be true, it probably is".
I mainly say that because engineers have posed concerns that
are sound and well-thought-out, but remain out there.
Here's an early example that comes to mind:
------------------------------------------------------------------
From: James Carlson <[EMAIL PROTECTED]>
Date: Thu, 17 May 2007 10:59:53 -0400
Subject: Re: [osol-discuss] Sun to make Solaris more Linux like
Ian Murdock writes:
On 5/17/07, James Carlson <[EMAIL PROTECTED]> wrote:
> Ian Murdock writes:
> > (And, once again, I'm not sure I see anything here that isn't fixed
> > with a "Solaris classic" environment.)
>
> Do we force future project teams to test in both environments?
I don't see why. If both environments are present, can't the application
pick which one it wants to use? Classic is the default, so that existing
Applications are not independent.
Would this scheme fly if (say) the JRE worked in one environment but
not the other? How about if metacity works in one but isn't tested in
the other? Or if RFEs and bugs fixed in libc or some other famous
library are tested in one but not the other?
apps don't break (the driving reason not to change things according to this
thread). Interactive sessions are applications in a sense, and the user
gets to decide which environment they want in that particular case.
What environment an app runs in is orthogonal (and likely transparent).
That's the part that, in my experience, doesn't tend to work out well
for users.
If there were no difference between the environments, then I'd argue
that there's also no need to have "different" environments. The risk
being taken here is that the applications don't _notice_ the
difference. Without engineering work to guarantee this (such as, say,
architectural review that takes this fork into account, as well as
testing that validates it), how do we know?
Yes, I'm no doubt oversimplifying, but this doesn't seem like an
intractable problem. The only incremental burden is testing the
interactive environments, i.e., the additional burden scales
linearly, no exponential complexity blowup. And by definition,
the classic environment doesn't change, so there's
really very little additional testing to be done there. Right?
It's not exponential; it's geometric.
That's precisely what each one of those other projects said, but the
combination of projects is deadly. Many applications will need to
test in the global zone, in a 'classic' non-global, and in a 'punk'
non-global. Now factor in exclusive stack versus shared stack, and
choice of installed metacluster, and you've got a taste of how
unmanageable this becomes.
Choice is nice is theory, but it doesn't come without cost, and
sometimes the cost can be very high. More importantly, the costs are
not avoidable. If you simply say "we won't test, but we'll just
assume everything works," then you're actually saying "we'll leave it
up to the users to test; and good luck to 'em." You can shift the
cost around, but not actually remove it. That's something we've tried
hard to avoid at Sun.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-discuss mailing list
[EMAIL PROTECTED]
_______________________________________________
indiana-discuss mailing list
[email protected]
http://opensolaris.org/mailman/listinfo/indiana-discuss
