Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

The best server option for Red Hat

On Dec 3, 2010, at 8:57 AM, Edward Ned Harvey wrote:

>> From: discuss-bounces-mNDKBlG2WHs at [mailto:discuss-bounces-mNDKBlG2WHs at] On Behalf
>> 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.  While
> it's not impossible, it certainly doesn't work by default.  Part of the
> 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.

Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /