Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
RedHat doesn't suck after all?

By Zeram in MLP
Wed Oct 11, 2000 at 09:59:16 AM EST
Tags: Software (all tags)
Software

Looks like that other site made a really bad judgement call in posting an article about there being 2,500 bugs in RedHat 7.0. This article at LinuxToday clears up a bit of the debate.


Apparently someone got into RedHat's ticketing system and after doing a quick tally decided that RedHat sucks. The tally included the internal developers wish list among other things. This rather unfair count lead to a submission to bugzilla asking for the recall of RedHat 7.0 in general. Add onto that the fact that RedHat made a bold (or perhaps foolish) decision to include GCC 2.96 (any thing that will compile under 2.96 will not compile under either 2.95.3 or 3.0)and RedHat has been through the wringer lately.

Ok dispite the fact that I'm putting this into MLP I think the whole dirty issue begs the question of have people been too quick to judge? I would say yes, but maybe not.

Wether you agree with RedHat trying to be cutting edge or not there are certain business considerations to make too. How else is RedHat going to make any real money unless they play the "release early, release often" game? Again this is also quite questionable, but if Linux is ever to make serious in roads into the "business mind share", then there has to be at leat one company there that businesses can look to for direction and support.

Not that any of that is new, but it just seems that the question has come up once again.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Was it a good idea for RedHat to include GCC 2.96?
o Yes 16%
o No 64%
o Whats GCC 5%
o Death to RedHat 13%

Votes: 240
Results | Other Polls

Related Links
o other site
o article
o article [2]
o LinuxToday
o bugzilla
o Also by Zeram


Display: Sort:
RedHat doesn't suck after all? | 33 comments (14 topical, 19 editorial, 0 hidden)
Business and cutting edge (3.45 / 11) (#7)
by recursive on Mon Oct 09, 2000 at 05:08:05 PM EST

How else is RedHat going to make any real money unless they play the "release early, release often" game? [..] if Linux is ever to make serious in roads into the "business mind share", then there has to be at leat one company there that businesses can look to for direction and support.

Since when are cutting edge and early (read: unstable) releases important to business? It seems that the latest release caters the student who admires flashy release numbers and does not mind some time consuming bumps on the road.


-- My other car is a cdr.


Re: Business and cutting edge (2.20 / 5) (#9)
by mondo_t on Mon Oct 09, 2000 at 06:24:10 PM EST

Well since redhat is open source by putting in cutting edge people will want to buy the newest stuff. You ever had people ask you what version of linux do you run? They dont want you to say kernel 2.2.43 or somethiing they want to hear like 6.0 7.0. Thats why slackware changed its version. Another reason is how RH makes there money. Support. Supporting leading technology might be hard, but it also brings in more questions from consumers which brings in more money. Mondo_T

[ Parent ]
The lastest release *does* matter (3.57 / 7) (#10)
by cme on Mon Oct 09, 2000 at 06:50:59 PM EST

Since when are cutting edge and early (read: unstable) releases important to business? It seems that the latest release caters the student who admires flashy release numbers and does not mind some time consuming bumps on the road.

The latest release *does* matter when speaking of "business mindshare". A businessperson (suit) cares about support, yes, but remember that suits care about competition- they want to *be* the most competitive and *use* the most competitive (however you're defining "competitive in this instance). They want to use the most "advanced" product available- the latest and greatest. (How many times have you seen commercials where the announcer is bragging about the newness of the product as one of the main selling points?) So they *do* care about releasing early and often, and about running the freshest software possible- it shows that they're "with it" and "up to speed". Not only that, but it *doesn't occur* to them that the newest may be too new- even if you try to point it out to them.

My father has a story about when he was cofounder and VP of Engineering of a desktop publishing company. The Quadras with the first ever version of System 7 had just come out, and everyone else in the company was hot to have one. He tried to advise caution- told them to wait six months, because the first release of anything that new invariably has bugs, often large and/or subtle ones, but they wouldn't listen and bought one immediately. It turned out that the earliest version of System 7 had a bug where the OS would *lose* 1% of the files that it handled in *any manner* (even just examining a floppy). These files were really truly irretreivably lost- and not only did they have to wait for upgrades to use their beautiful new Quadra, but it was very embarrassing to have their projects slowed while they asked customers for another floppy with those files....



[ Parent ]
Re: The lastest release *does* matter (3.40 / 5) (#11)
by recursive on Mon Oct 09, 2000 at 07:10:17 PM EST

I agree that business wants support and especially someone who maintains the software they are using. Otherwise every business would run BSD :-) But: using always the latest version for the sake of is too risky if you really want 24/7 and your users stay away from the internal hot line. I simply doubt that any business running more than 10 machines with RH will ftp the latest version when it comes out and install it immediately. Having the highest version number may be important for RH's business, but it should be not for yours.

-- My other car is a cdr.


[ Parent ]
C++ Incompatibilities in Linux (4.37 / 16) (#15)
by julian on Mon Oct 09, 2000 at 09:38:50 PM EST

"any thing that will compile under 2.96 will not compile under either 2.95.3 or 3.0"

As was pointed out by tom0, that is an incorrect statement. The only major issue here is C++.

For the sake of having a real example, I'll demonstrate some of the pains I'll have with my own C++ application, Gabber. Gabber requires three C++ libraries which it dynamically links with: libsigc++, gtkmm, and gnomemm.

If someone has a binary of libsigc++ which was compiled on 2.95.2, but gtkmm which was compiled on 2.96, Gabber will segfault. If someone has a binary of gtkmm which was compiled on 2.96, but a binary of gnomemm which was compiled on 3.0, Gabber will segfault. Take any combination, the result is a segfault. Fun, no?

Unfortunately, the stituation already exists today between mandrake and red hat 6.x. Mandrake has 2.95.(1/2), and red hat has egcs 1.1.2... Red Hat 7 just adds yet another source that people could be getting binaries from.

The only solution that I have is to either tell people to ensure they get everything compiled on the same distribution, compile it all themselves, or statically link and give them a gigantic binary.

Welcome to the world of C++ on Linux. Not to mention that g++ is so hideously slow when compared to any C++ compiler on any given OS (especially Windows, there are some really fast compilers there). You think Mozilla takes forever to compile? A large part of that is g++'s fault.

I really urge anyone who can to please try to help improve g++. Unfortunately there aren't many people who know how.

Like C++ or not, there are a lot of people who do, and unless Linux gets a *good* C++ compiler, and a standardized ABI, we're going to lose a lot of potential developers.

KDE, by the way, gets around a lot of these problems by combining a lot of things into just a couple of packages, so people are more likely to have everything compiled on the same system.
-- Julian (x-virge)
Re: C++ Incompatibilities in Linux (4.16 / 6) (#20)
by your_desired_username on Tue Oct 10, 2000 at 01:28:04 AM EST

(I am not a gcc developer (though I often wish I was). Here, I speak
  only my own guesses and opinions.)

Speaking of a stable C++ ABIs, there will hopefully soon be one - gcc
  3.0 is intended to be the last major change in the core C++ ABI for
  a long time. (however, there will still be minor ABI changes in the
  library, as necessary for bug fixes.)
  
However, 3.0 will *not* be ABI compatible with 2.96 - or 2.95.x . What
  this means is that sometime during next year, most of the other
  linux distros will be switching to gcc 3.0 - but red hat will
  probably not, because they will not want to break the C++ ABI
  again. The result will be that the current mess will
  continue.


Redhat's decision to use 2.96 will extend a minor nightmare 
  for KDE developers, and a major nightmare for all other linux
  targeting C++ developers. I strongly disagree their
  decision. However, they did not (as I once thought) make this
  decision blindly - here is Richard Henderson's
  statement as to why they did it.(For 99.99% of you who do not
  know, Richard Henderson is now, and has been for many years, one the
  primary gcc developers - though he does not usually work on the C++
  front end.) 
  
3.0 will also have a vastly improved standard C++ library (on par with
  stlport or dinkumware), and improved support for the core
  language. (IMHO, 2.95.2 already supports the core langauge better than
  any other compiler I have used - but its support for the standard
  library sucks.) Note that the 2.96 released with rh7.0 does not have
  the improved C++ library, which will constitute the vast majority of
  the C++ improvements over 2.95.x . 3.0 will also be strict about the
  use of namespace std.

As for alienating C++ developers, I think the linux community as a
  whole does more to alienate C++ developers than any C++ compiler ever
  did. My experience at linuxworld was that mentioning I liked C++
  (and I do) was a sure-fire way to invite massive verbal abuse. I
  have had the same experience on most linux-related online forums (k5
  being the only exception.)

(g++ in particular is actually well-liked by many C++ developers -
  primarily because committing to g++ only is an easy way to ensure
  being able to port one's C++ code to most unices - as gcc runs well
  on most unices, and its definition of C++ is almost identical on all
  the platforms it supports.)


[ Parent ]
Part of the real story... (4.30 / 13) (#17)
by RenderMonkey on Mon Oct 09, 2000 at 10:19:50 PM EST

A quick check on RedHats Bugzilla the day of the Slashdot post revealed something on the order of 120 bugs relating to RH7 directly. Most were low severity. Even today checking RedHat 7 with all packages only yeilds 269 bugs total (no enhancement or translation requests).

The 2500 bugs quoted in /. was including all apps, all versions, and included feature enhancement requests etc. Basically whoever did the search on Bugzilla didn't know how the search form worked and didn't bother to figure it out. (Giving the benefit of the doubt that they were not being malicious.)

The posting up there is relevant (if mis-sectioned maybe even belonging on scoop) because this whole episode shows that these community news/discussion sites have some pull in real world news and events. The story there did some real damage to Red Hat (at least PR wise) and it's basis was in inaccurate data that could have been easily checked (took me 2 minutes) If it had been checked at all (by the original poster or by the reviewer) it would have been prevented. It is something that must be considered when designing site review and submission issues as well as the whole culture bit. I think in this case slash should help Red Hat cover the PR damage done either via a story, interview or retraction.

and what about gcc? (3.00 / 9) (#22)
by semis on Tue Oct 10, 2000 at 02:35:25 AM EST

redhat 7.0 uses an interim version of gcc.. with lots of binary incompatibilities. If you read the other site, then you would have seen a link to this statement from the gcc-announce@gcc.gnu.org mailing list.

Most importantly, it says this:

Please note that both GCC 2.96 and 2.97 are development versions; we do not recommend using them for production purposes. Binaries built using any version of GCC 2.96 or 2.97 will not be portable to systems based on one of our regular releases.

I voted -1 because I think that you should have wrapped this up into your story.

GCC 2.96 for good reasons (4.20 / 5) (#27)
by /ASCII on Tue Oct 10, 2000 at 09:19:59 PM EST

I don't think people understand the reason why RedHat chose to use 2.96. RH ships for several other platforms than i386, and while GCC 2.96 isn't much better than 2.95 for i386, the improved quality of code on other platforms is enormous.

So, basically RH traded away the benefit of a single compiler for all tasks (use kgcc for kernels, gcc otherwise) on all systems in order to gain vast improvements on 5 or 10 percent of the systems.

They COULD have shipped with different compilers for different platforms. But that would be a support nightmare!

You don't have to belive me, get the info from the horses mouth.
"The time has come", the Walrus said, "To talk of many things: Of shoes and ships and sealing wax, of cabbages and kings."

RH to not support SPARC anymore (2.50 / 6) (#29)
by Jack9 on Wed Oct 11, 2000 at 04:08:58 AM EST

The future lack of SPARC support was the thing that got me. Now I have no respect for RedHat and I already had little reason to be using UltraLinux anyways. Out comes my OpenBSD.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.

Re: RH to not support SPARC anymore (3.00 / 2) (#30)
by ameoba on Wed Oct 11, 2000 at 09:22:04 AM EST

Interestingly enough, wasn't better support for SPARC one of their justifications for using GCC 2.96?

[ Parent ]
Re: RH to not support SPARC anymore (4.00 / 3) (#33)
by your_desired_username on Wed Oct 11, 2000 at 03:24:34 PM EST

For most RISC archs (including, but not limited to sparc), for C, gcc 2.96 does generate much faster code than 2.95.2 .

(For C++, gcc 2.96 generates much slower code than 2.95.2 on most platforms - and gcc 3.0 will not be released until that is fixed.) (Note: I do not speak for the gcc developers.)

[ Parent ]
Bugs in Windows, bugs in Linux (1.75 / 4) (#31)
by bmetzler on Wed Oct 11, 2000 at 10:28:35 AM EST

It is astounding to me that people would take 63,000 unique bugs in Windows 2000 and claim that that wasn't a problem because obviously most of those bugs weren't 'critical.' Yet, when Redhat releases a new version and 2500 bugs are processed that are mostly duplicates, and mostly not critical, that people would be calling for a recall.

Are people that stupid? Why would they choose to overlook 63,000 bugs on Windows as being unimportant, but call for a recall because Red Hat 7, has at the most 250 bugs?

-Brent
www.bmetzler.org - it's not just a personal weblog, it's so much more.
Why Red Hat Sucks (4.46 / 13) (#32)
by Caranguejeira on Wed Oct 11, 2000 at 11:46:43 AM EST

I easily thought of these ten reasons that Red Hat sucks:

1) According to the Fred Moody Number System, Red Hat, which is also Linux, has 1.3 billion bugs. This is a lot more bugs than Windows.

2) Red Hat, which is Linux, should be called "GNU/Linux," but it's not. This confuses people by making them think that Linux comes from the Mafia instead of from GNU.

3) Red Hat, which is really Linux, does not have .NET.

4) Red Hat, or Linux, has a really bad compiler called "2.96" that doesn't work. It won't even compile VB code. Therefore no developers can program on Linux.

5) Red Hat, a.k.a. "Linux," does not support things like video cards and other advanced hardware. It's mostly for 486s.

6) Red Hat, also called Linux, is too hard for users to use. They have to type a lot of things before something will happen. Also, it is impossible for a mortal to install it.

7) Red Hat, commonly known as Linux, can not browse the Web because it doesn't have IE 5. It doesn't have ActiveX either.

8) Recent benchmarks that Red Hat, the Linux OS, is really slow. A Red Hat web server can only serve 100 web pages a day on Dell computers.

9) Red Hat, alias Linux, is not really free. You will see that all Red Hat boxes at Comp USA have a price tag on them. If you try taking it, they will get you.

10) Red Hat does not have kayaking technology.

RedHat doesn't suck after all? | 33 comments (14 topical, 19 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!