On Wed, 9/24/08, G. Matthew Rice <[EMAIL PROTECTED]> wrote:
> You mean this one?
> http://blogs.msdn.com/crispincowan/archive/2008/09/02/go-ahead-make-my-day.aspx
That, among others.
Again, I cannot comment on Novell-SUSE. They will do what
they will do, both for SLAs on past products, as well as
future products. Enterprise customers need only use "common
sense" to realize that a vendor is not going to "leave them
hanging." Enterprise vendors have to balance a lot, and
they do -- past, current and future.
E.g., I'll use a similar situation with Red Hat.
Red Hat ships the Xen hypervisor (dom0) in Red Hat Enterprise
Linux (RHEL5) 5 is a major, public debate right now among
many people outside of Red Hat. A big spark was Fedora 9
not shipping the hypervisor (only the domU "guest"), although
it should return in 10. As with any SLA on a past product,
even if Red Hat should choose a future direction on
virtualization, people should expect, "common sense" (based
on any Enterprise Linux product history):
A. Existing virtualization technologies will be supported
throughout the support lifetime of the product, and
B. Future virtualization technologies will have a migration
path so existing technologies can be upgraded to them
For some people, that's still not good enough.
Some start getting into the para-virt v. full-virt debate,
as a few customers really like Xen paravirt. From Wall
Street to Web Providers, they like it, because it's a
crapload better than VMWare at response times and I/O
throughput can be well maintained (let alone VMWare's
stack is really geared towards GUI management of Windows,
not automated deployment of Linux, and not easily scripted).
So what I've fallen back on is saying things like ...
- It really matters what you need to do, and what other
customers need to do, and Red Hat will act accordingly.
RHEL 5 is supported until 2014, so Xen is supported on
at least one platform product until 2014.
- A lot depends on whether KVM ends up being higher
performing than Xen at paravirt, not just fullvirt.
If that happens, I think you can put together what will
happen (and the A-B above)
- Etc...
Is AppArmor dead? Hardly! It's alive in a Novell-SUSE
product that will be supported into the next decade.
Is AppArmor going to be dropped in the future? As I tried
to use an similar situation, it's like asking if Xen is
going to be dropped in the future. It's really not a
question, it's more of a concern, and concerns are really
tied to future product, not past/current product that will
still be supported in the future.
Remember, we're talking an Enterprise Linux distro, not
some leading edge distro that makes major ABI/API changes
far more frequently, and is dropped in a couple of years.
So what's this mean from the standpoint of LPI objectives
at the next revision?
- AppArmor's future is not so bright, just like Xen's is
questionable at this point to
- AppArmor and Xen will still be supported in products for
the next 5+ years, so they aren't "dead" by a long
stretch
- We have to question if designing objectives over the
next 1-2 years for an exam 2-3 years out is a good idea
on technologies that are not quite "deprecated," but are
a good bet not to be the "preferred" technologies in the
next iteration of Enterprise Linux distros
- Although we always have to consider the popularity of
technologies on non-Enterprise Linux distros, there are
always the real, enterprise adoption considerations of
those distros to also consider
- It's always hard to both predict direction and gage
adoption of this stuff, in general, anyway. Matt Rice
wasn't the "Swami" the last time I checked, but then
neither is Chris Berman. (sorry, American football
season here in the US ;)
_______________________________________________
lpi-examdev mailing list
[email protected]
http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
