Lamar Owen wrote:
>On Wednesday 28 September 2005 20:18, Max wrote:
>
>
>>Ignacio Vazquez-Abrams wrote:
>>
>>
>>>Wow. Blaming the OS vendor for an ISV's issues.
>>>
>>>That whizzing sound you hear is my eyes rolling over and over again,
>>>really quickly.
>>>
>>>
>
>
>
>>Yeah, wow...I've been using Red Hat products since 7.3. I've ran 8, 9,
>>and all the Fedora Core distros. Now I run CentOS, and we use RHEL 3 at
>>my work. I've never had any distro, even the Fedora "Testbed's" just
>>stop working, unless I caused the issue myself from playing.
>>
>>
>
>Hmmm, interesting. Now, understand that I use Linux daily, and that I have no
>plans of switching around. However, reading the article I get the following
>summary:
>1.) Paying Customer had to use particular software components, including a
>particular version of RHEL;
>2.) Paying Customer had intermittent lockups of the machine that were
>difficult to reproduce;
>3.) Paying Customer got tired of Red Hat's 'WORKSFORME' bug resolution (that's
>the typical bugzilla tag when such an irreproducible problem occurs);
>4.) Paying Customer quit paying and switched to Windows, which worked better
>for them (meaning, it didn't crash).
>
>Now, just exactly what part of this is untrue or would require a Microsoft
>payoff? I personally have seen instances of Red Hat's WORKSFORME attitude;
>one example is the version of tftp being shipped with RHEL3 and 4, 0.39.
>0.40 has been out for a while, and it fixes a nasty bug in the tftp file
>translation (remapping) feature/misfeature (which I have had to use before on
>certain releases of Cisco's 7960 IP telephone). Red Hat has a bug in
>bugzilla on this issue for RHEL3 that predates U4, yet the bug won't be
>addressed until U7! And even then the two-line patch has to be backported;
>can't let the customer see a higher version number! (Bugzilla:
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143536 ) Follow the
>thread; with such a simple bug taking so long, what kind of mess are bigger
>bugs in?
>
>And there are several kernel bugs that are like this, with strange lockups and
>such that are either ignored (NOTABUG or WONTFIX resolution) or the reporter
>is told to file 'upstream'. See the list at
>https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Red+Hat+Enterprise+Linux&version=4&component=kernel&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=CLOSED&bug_status=NEEDINFO&bug_status=MODIFIED&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=
>for yourself, particularly bug ID's 157170 (Closed: Wontfix), 162653 (Closed:
>Wontfix because it's a CentOS kernel) and163373 (Closed: Wontfix
>megaRAID-old). Yeah, I can just see a bug filed in LKML by a Red Hat customer
>getting priority attention from Linus and Co. I can see that about as good
>as I can see myself walking on the moon tomorrow.
>
>Let me put it this way: if I were paying $1,200 per server per year for RHEL
>support, I would not tolerate the WORKSFORME attitude either; I would expect
>and demand that Red Hat send someone out to my site and diagnose my problem
>for those costs (and if they wouldn't do it, I would find a vendor that
>would, for that price, which is exactly what this particular customer did).
>Since I am not paying Red Hat for support at this point, I obviously cannot
>have that attitude with bugs I find that are clearly Red Hat bugs; but I
>certainly can understand this guy's attitude. We shouldn't just
>automatically dismiss such a problem as being a troll. We should look
>intelligently and logically at the problem.
>
>And no matter what ISV's software is running, the OS should not LOCK UP!
>Sounds like a RHEL kernel issue to me.
>
>So, Jim Perrin, I think a HAHAHAHAHA is entirely inappropriate. This guy had
>a real problem, and Red Hat couldn't fix it. Meaning CentOS still has the
>problem on that same hardware under the same conditions, since CentOS is as
>close to upstream RHEL as is possible under the trademark guidelines.
>
>We're not told what 'diagnostic' Red Hat recommended be run on the box, but I
>know that if I were in the same situation I would ask Red Hat to come to my
>site and pull that data themselves. That's what I pay for for support, in my
>opinion. If I buy 'turnkey' I expect field circus to make it turnkey. (Of
>course, old-timers will recognize the DEC jab there, and the whole idea of
>turnkey is a Bad Idea in my opinion, but that is the world we're in. See
>http://nemesis.lonestar.org/stories/stages.html for a very humorous tale from
>an old-timer in the computer business. This guy, Frank Durda IV, wrote much
>of the I/O processor code for the Tandy 6000 Xenix computer of the mid-80's,
>so he is quite a character.)
>
>Further, as to 'automatic' updates, I totally agree with Mr. Horton in the
>article. Automatic updates should Just Work and should not break the whole
>system (things like, oh, I don't know, caching-nameserver hosing files
>(caching-nameserver is STILL INSTALLED BY DEFAULT EVEN WITH bind-server
>installed, which is a recipe for this sort of problem), an httpd update that
>fails to properly restart httpd after update, the kernel quits working with
>your hardware, you know, minor inconveniences that can only cost thousands of
>dollars of downtime, nothing major). Everyone has seen some of the updates
>come down in broken states; search the archives of nahant-list or taroon-list
>for lots of those. I personally have turned off automatic updating at
>several sites for these reasons and because of the poor track record of
>automatic updates.
>
>And, furthermore, I thought the whole idea of the RHEL platform was ABI
>stability. If SAP thinks, as an ISV, that they need to recertify every
>update then something is bad wrong, and it's not necessarily at SAP. I
>personally hypothesize that SAP perhaps got burned one too many times by a
>poor update and now blanket recertifies for every update to make sure their
>customers keep running. "Poor stupid ISV trying to serve their
>customers...they should Get With the Program!" Of course, Windows has this
>problem, too, but it's typically limited to Service Packs. Yuck, just typing
>that phrase turns my stomach, thinking about what Win2k3 SP1 does to certain
>many dozens of programs...
>
>Sorry for the rant, but it is ridiculous to automatically dismiss a real-world
>problem. Note that the same Mr. Horton is still using Linux for web services
>and such, and likes and supports it in that role; it's just the SAP server he
>had to transition to Windows due to a lowly business concern. Nope, the
>business bottom line should never interfere with technological zealotry!
>
>Oh, quick quiz: what happens to a CentOS box when you reboot after running out
>of disk space on the / filesystem? You get a graphical login just fine, but
>then you can't login (you login, and it returns you to a login). Not hard to
>fix, but very mysterious to the newbie.
>
>
I quite agree with this post, especially the part about 'automatic
updates should just work' !!!! I am on the SuSE AMD64 list as well, and
about 1/2 of the posts there start out with 'My machine updated itself
last night w/ YOU (their auto-update package) & now it won't boot'. I
came to Linux from SGI's, *EXPENSIVE*, but darn close to 'it just
works'. I realize that for the cost savings of Linux compared to SGI, I
might have to sacrifice a bit of 'it just works', but the problem of
apparently-incompletely-tested OS updates seems far too prevalent in the
Linux world. I am here to stay (Linux vs. SGI), make no mistake, but
this is a situation that *SOMEONE* needs to drum up a fix for. I lay the
problem mostly at the feet of the distro-providers, since they DO make
$$$$ selling the software & would seem to be in the best position to
police their own distro. I have also had a few of RH's bug-blow-offs in
the more distant past (several years ago, circa 1999) & it does nothing
for the Linux movement or themselves professionally. SGI uses a fairly
sophisticated & probably proprietary suite of utilities to test new OS
components and assure that at least bugs aren't re-introduced and that
bugs that are claimed to be fixed actually are. I don't know who would
assume this responsibility in a distributed developement environment
such as Linux flourishes under, but it seems increasingly obvious that
*SOMEBODY* needs to. My $0.02 ....
There, I feel better now :-).
--
William A. Mahaffey III
---------------------------------------------------------------------
Remember, ignorance is bliss, but
willful ignorance is LIBERALISM !!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos/attachments/20050929/2f786c24/attachment.htm
