Re: Any "gotcha's" for D3/Linux 7.5.1 over RHEL5.2

I'm really fed up with this BS. There is a complete lack of
consideration for the facts - and even when the facts are presented in
a way that's favorable toward RD/TL they're still twisted into
something that sounds unfavorable.

Guys, I haven't been employed by that company for 8 years. It's
ancient history in my career. I don't sell their stuff. I don't have
any particular allegiance to them compared to any of the other MV DBMS
companies. They're just another company to me, and for the record (no
reflection on the people who implement policy decisions) I don't think
much of the company as a business entity either. So any claim of bias
on my part is simply targeting the messenger and not the message.
Like any other company I think they deserve fair commentary. So when
I'm commenting on the unfair commentary here, just remember I'd do the
same for you, whether I agree with you or not.

cheseroo wrote:
RD/TL more or less ran away from the problem as soon as
they discovered we were running on an unsupported O/S
(CentOS).

Let's start with a technical perspective.

I'll preface all of this with the point that I always use CentOS when
possible and have not installed RHEL for my own use since they
implemented the mandatory fee-for-support model. So I fully support
CentOS and it would be in my best interest if TL supported it.
However, I use CentOS with full understanding of the ramifications,
which apparently other people still don't quite understand.

CentOS is not a supported platform for D3. What this means is that TL
is fully aware that it is based off of the same upline code as RHEL,
but TL has simply not gone through the testing cycle to certify this
platform as they would RHEL. Does this mean they think it's bad? No.
Will they refuse all support calls outright if you mention you're
running over CentOS? No. They can't claim support for a platform
that they simply haven't tested.

There is no reason at all why most code in the VME will run
differently on CentOS than RHEL, so if you have an issue inside the
environment then they will probably address it like any other with no
further questions.

As to the underlying OS, you need to understand that CentOS is a
completely separate distribution of Linux. It is assembled by
dilligent people, not being paid for their FLOSS efforts, who seek out
and modify the patches required to create their distro. Their goal is
to produce an equivalent package, but they don't always get it right.
Just look at the CentOS forum and you'll see that there are always
reports of some issue that was missed.

The VME makes frequent use of the OS for many features including
anything related to process handling for each PIB/Phantom, !executes,
tape operations, memory, disk access, and for compilation and
execution of FlashBASIC code. Because of this frequent cross-over
there will be many areas that turn out to be related to the D3 monitor
(the one that gets M patches) even if it doesn't look obvious that the
OS is involved at all. When D3 is being developed we can't expect
them to recompile and test over RHEL and CentOS. When a patch is
issued we can't expect that this very focused code will work over
CentOS.

Now to the commentary blaming this on TL:

 Perhaps we could have pushed the issue more
but the reason why we run d3/linux is because we don't
have to think about those machines so we took the easy
route and switched the O/S to RHEL 5.1

"We don't have to think about those machines"? What the hell does
that mean? Do you mean "we didn't want to pay the support fees for
those machines"?

Further, are you saying RHEL worked but CentOS did not? Doesn't that
clarify once and for all that CentOS is a derivative of RHEL and not a
copy, and that this and other derivatives like WhiteBox Linux are
subject to functioning differently?

As soon as the point is proven that some feature works in RHEL and not
CentOS, the position to not "support" CentOS is justified. If TL
claims support for the platform, they commit to testing, keeping up
with the latest product changes, and some amount of training for
internal people. All of that implies a budget for the effort. At
this point the question is not technical, it's a matter of who's money
is going to be spent - yours for RHEL Support or theirs to support
your free software.

And once again here is where people are severely confusing the line
between the concepts of Free beer and Free liberty. If you love Open
Source so much, and you're getting CentOS as Free (beer) software,
then hire someone to work with TL to support the software. That's the
price you pay for your free (liberty) software! If you can't afford
that, then pay RedHat their fee to produce their platform. But face
the facts that free (liberty) software is not always going to be
completely free (beer).


From Mike:
The attitude from RD/TL is disappointing, but not entirely unexpected.

My friend, I'm sorry, but that's another one of those "bandwagon"
statements that are completely unfounded but popularly accepted. If
the exact same statement were made about Martin Phillips for exactly
the same situation, there would be an uproar. Decisions need to be
made about which platforms will and will not be supported. These
decisions are based on the relative benefit vs expense of the effort
and need to be addressed at a business level - condemning Support
people for this is simply wrong. When a policy decision is made you
can't expect a Support technician or the Engineering department to
offer to go down the rabbit hole for you to thoroughly vet and resolve
any issue related to the "unsupported" platform.

The term "disappointing" is used when someone can do something and
they don't. In this case there are potentially hundreds of hours that
need to be spent to support a new platform. If you want the company
to support the platform, justify that time for them, but don't say a
technician's attitude is disappointing when they can't start to jump
into the middle of that process and try to change it.

The phrase "not entirely unexpected" would have a place elsewhere (and
I can think of many places where shortsighted thinking at TL is "not
entirely unexpected") but here it's simply inflamatory.


Cheseroo, your misrepresentation of the facts is heinous:
You said:
RD/TL more or less ran away from the problem as soon as
they discovered we were running on an unsupported O/S
(CentOS).
Then you said:
Rick Davies was trying to convince them to certify CentOS and they
were considering it under the argument that it was based upon RedHat
but that effort kind of faded after this episode.

So they didn't run away. It went to Engineering, they loaded up
CentOS, and tried to debug your issue. They were supporting an
unsupported platform - as they've done for many of us many times.
Once again quoting Mike: "The attitude from RD/TL is disappointing,
but not entirely unexpected." Doesn't it seem now like their attitude
was quite accommodating? Doesn't anyone get brownie points for the
effort? Why do you make it sound like there was no effort at all?


RD/TL tried to run
gdb on the machine and discovered it wasn't installed as a part of
CentOS and that was the end of that.

Ibid. Obviously they did try to accommodate you.

Installing gdb is easy. Obviously there was more to it and that's
when the distinction between CentOS and RHEL made this an effort which
involved expense on one hand and ROI on the other. That's a business
decision. If you don't like it, take it up with management and
explain to them why your lack of desire to spend a few hundred dollars
is worth their tens of thousands of dollars in engineering.

Shifting gears a bit: Honestly I've tried to fight with that "prove to
me that it's worth it" attitude over there before, and again their
short-sightedness is amazing, but "not entirely unexpected". Then
again, while there are some areas where I know the long-term returns
to them would be better, I can only rarely cite a near-term positive
business case for them to make changes - so their short-sightedness
almost always wins. I'm not pleased with the results, but I'm happy
that I was given the opportunity to make a case. THAT's what's
important. If you have a case for them to support some platform, make
it. If you don't - other than it will save you some bucks - drop it.

Nuff outta me.
T
.

Relevant Pages

  • Re: ever migrate from Fedora to Scientific Linux or CentOS?
    ... There is no reason at all why you can't install SL, and use packages from the CentOS repos, RHEL users do it fairly regularly. ... Both are supported by mailing lists, and I reckon if one's using RHEL-Clone then hanging out on the relevant RHEL list is also appropriate. ... Academe should also check out RHEL prices; I haven't for some time, but I think one can run RHEL for a modest cost (and get extremely modest support). ... I think that all that's needed to upgrade from FC to Tikanga-clone is to boot the media and go for it. ...
    (Fedora)
  • Re: [kde-linux] dought
    ... It has the same software as RHEL*, but without the commercial support. ... So for CentOS, it's up to the users to figure things out (with help from RHEL documentation) and share information. ... Matthew Seitz ...
    (KDE)
  • Re: Updating FC3
    ... FC3 is no longer supported, ... is to use a RHEL clone such as Scientific Linux or CentOS. ... updates that were available before the support for FC3 stopped. ...
    (linux.redhat.misc)
  • Re: CentOS vs Redhat
    ... > Can anyone tell me if the driver support in CentOS is identical to Redhat's? ... Use Fedora Core unless you actually need RHEL because ...
    (comp.os.linux.misc)
  • Re: How to delete a feature type in PB4.2
    ... > My platform(Sitsang: a reference board of PXA250) are difficult to start. ... > Setting the "Exclude from build" flag on the PCMCIA driver for ... > the necessary support is not present in your platform. ... > Setting the "Exclude from build" flag on the Local Area Networking ...
    (microsoft.public.windowsce.platbuilder)