The best server option for Red Hat

[gaf-mNDKBlG2WHs at public.gmane.org (Jerry Feldman)]

On 12/03/2010 11:03 AM, Jarod Wilson wrote:
> On Dec 3, 2010, at 8:57 AM, Edward Ned Harvey wrote:
>
>>> From: discuss-bounces-mNDKBlG2WHs at public.gmane.org [mailto:discuss-bounces-mNDKBlG2WHs at public.gmane.org] On Beh=
alf
>>> Of Jarod Wilson
>>>
>>> On Dec 2, 2010, at 10:17 PM, Edward Ned Harvey wrote:
>>>> ... RH does proprietary development for Dell etc, regardless of what=

>>>> anyone else might tell you.
>>> Thank you, I needed a good laugh.
>> Not sure what that's supposed to mean,
> It means that last time you dragged this up, I asked for specific
> details of this supposed proprietary development work Red Hat had
> done, and you provided nothing more than vague recollections that
> something worked with RHEL but didn't with CentOS, which is NOT
> exactly compelling evidence that Red Hat does proprietary devel
> work. And given we've talked about this before, and I asserted
> you were incorrect then, I qualify as "anyone else" who has told
> you different, so by extension, I've tried to "mislead" people
> into believing that Red Hat does not do proprietary development
> for Dell. Thus I laughed.
>
>
>> but if you don't believe me,
> Its not that I don't believe you, its that you're WRONG. :)
>
> Sure, something might not be working, but your reasoning for why
> is completely unfounded.
>
>
>> just try
>> installing Dell OMSA Managed Node on a Dell server running Centos.  Wh=
ile
>> it's not impossible, it certainly doesn't work by default.  Part of th=
e
>> problem is an OS detection script, which greps for "Red Hat" in the
>> /etc/redhat-release file,
> This is Dell's software doing that, NOT Red Hat's, and there's
> definitely nothing underhanded or proprietary about Red Hat putting
> "Red Hat" in /etc/redhat-release, nor with Dell checking to see if
> its actually running on Red Hat (vs. presumably SLES or Ubuntu,
> where the installer may need to make different choices).
>
>
>> but even if you tweak that script to accept
>> Centos, there's still some "open source equivalent" library dependency=
 which
>> doesn't behave the same in centos.
> Specifics, please. This is still far from proof that Red Hat does
> any sort of proprietary development work for Dell. I'm reasonably
> certain that your assertion of proprietary work having been done
> by Red Hat will fall down in the face of detailed examination.
> Show me exactly what this supposed library where CentOS has to
> ship an "open source equivalent" is, and maybe we can make some
> progress understanding what's really going on. But "I can't get
> it to work, something behaves differently" when you install
> 3rd-party software on a target it was never certified on isn't
> proof of your claim.
>
> One more time: Red Hat doesn't ship *anything* proprietary on the
> current RHEL installer discs. There *are* proprietary bits on the
> Supplemental discs, but those are NOT bits developed by Red Hat,
> they're various bits from hardware and/or software partners. If
> there actually *is* something proprietary on the main distro discs,
> both myself and Red Hat would like to know, because it'd likely be
> a violation of the license under which RHEL is distributed. But I'm
> 99.999% certain we don't.
>
>
I don't know about Dell here, but I can comment on HP since I did work
for HP in their Linux expertise centers. Both HP and IBM specifically
certify servers with both Red Hat and SuSE. HP also provides support
directly for their servers delivered with RHEL (as does IBM I believe).
The issue here is that when a customer has an issue with a product, they
don't want to have to tell the customer to call Red Hat. There is a lot
of Red Hat expertise at HP as well as a lot of HP (mostly former
Digital) expertise at Red Hat.

--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846