Headline - Linux misses Windows of opportunity

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



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

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux