On Tue, 2003-09-23 at 19:08, Havoc Pennington wrote:
What you are asking for is to get the OS work from Red Hat, then
the support yourself, without charging the customer for the support
incidents twice, right? It's certainly a reasonable thing to bring up,
I believe that this is actually the Red Hat Enterprise Linux Basic
Edition, is it not?
"Basic Edition provides a one-year subscription to Red Hat Network. It
is available via download only."
"Standard Edition provides a full year of Standard support (includes
Monday-Friday 9 a.m.-9 p.m. phone support with four hour response (9
a.m.-5 p.m. outside North America) and a one-year subscription to Red
Hat Network. Customers ordering Standard Edition will receive a full
boxed product with CDs and printed documentation."
I am in a similar quandary with many of the people on the list who are
dealing with either the cost of moving to RHEL or the short maintenance
cycle of Fedora (a year of errata I was able to deal with but it sounds
like Fedora will be much less then that). I have been using Red Hat
Linux since 4.1 and I have never once needed installation hand-holding
or any type of phone support so Basic might be the route I end up going
on some machines. However, for at least half of the machines I manage
even RHEL Basic Edition will be too expensive on a per-year basis so I
know that I will have no choice but to be supporting at least Fedora.
If I am already supporting Fedora for half of my machines I might just
use it for all machines, instead of having to support two similar
separate products and all the various versions of each.
I try to "support myself" via the community on mailing lists. When I do
find bugs I have either lived with them or worked around them (roll my
own RPM to fix the problem, for example) and I just file a Bugzilla
report with as much info as I can (and a patch where I've been able to
provide one) and move on and have left it to Red Hat to either fix or
not fix the problem as they see fit. Perhaps if there are enough people
in a similar situation and who are willing to contribute back to the
project in some fashion, it will start to look like a safer option. I
have few cases where I could ever foresee needing the hardware & ISV
certifications of RHEL so it really all comes down to package
maintenance and life cycles.