Slashdot Mirror

Read this and crawl back under your bridge, troll.

Why not? I'll say it: people were wrong for hating it. RedHat made the best decision. Their one mistake was not explicitly marking the compiler as their own - people thought it was an official gcc release.

Anyone who thinks the gcc 2.96 compiler is buggy should read this page.

Two sides to every argument:

http://www.bero.org/gcc296.html

Well... not quite.

Microsoft goes out of their way to break a standard and then to hide the details from the general public. RedHat hasn't been hiding the details, in fact, if anything they've been openly publishing their changes when they break away from standards.

Besides, what did gcc 2.96 really accomplish? Did it further the RedHat monopoly? No, not hardly. The first several versions 2.96 were buggy and if anything hurt redhat reputation more than it gained them. The buggy versions caused friction between redhat and many in the open source community. Did it push gcc and the open source community towards being more standards compliant? Yes.

Redhat's heart seemed to be in the right place, they wanted gcc to be more standards compliant in the first place. As bero said, The standard isn't gcc-2.9x. The standard is ISO C99 and C++ 98

• they have demonstrable reasons for doing what they did (ie: not just doing it for the sake of changing things, and thereby breaking them for everyone else)
• their changes were (naturally) 100% open-source
• when the opportunity finally arose to rejoin what the rest of the community was using (GCC 3), they did just that.

I must respectfully disagree with a few things here:

They have encouraged proprietary software vendors to release their wares in a manner that is compatible with Red Hat and not other distributions, by falsely implying that they, Red Hat, set the standards and everyone else follows.

This is true to an extent. Red Hat did essentially "go their own way" in some respects, setting up their own standards for some things. The most notorious of these breaks is, of course, the use of GCC 2.96 instead of 2.95. This caused a lot of controversy, and deservedly so, but it's what they felt they had to do for their distro. They had customers who required the enhancements of 2.96, and so they met those needs. They took a lot of crap for it, too, but they stuck to their guns (and the customers they were serving).

RH also took some liberties with file system layout, etc. They obviously felt it was important enough to make the change, so they did.

What I'm trying to illustrate here is that in both cases, RH did what they did not to lock out other vendors, or to hyjack the industry, but rather to apply what they felt was some needed sanity into certain aspects of Linux. However, the community has now "caught up" to Red Hat's changes, by releasing GCC 3.x, and the LSB 1.1 spec. RH's next distro (which will undoubtably be called 8.0) is going to be using GCC 3.x, and will be LSB compliant. So it seems to me that Red Hat has only been doing what they felt was necessary until the community made their decision on the direction of things, and then RH re-converged their distro with the community at large.

it is quite possible, and vastly preferable, to package software in a distribution-agnostic form installable by evertyone. Blender did it, Loki did it, Id and several other proprietary vendors do it now.

Yeah, but they did it by making nasty custom installer scripts, typically with no uninstaller! Eek! This might be nice for Slack or Gentoo people, but how about an RPM for the RH, Mdk, Suse, Caldera, and (via alien) Debian users? What's more, they probably also statically linked the stuff to hell and back. I'd prefer to see 2 releases - LSB and non-LSB. A nice RPM for LSB compliant distros, and non-LSB for people who don't give a stuff. ;-) The LSB people are rewarded with package management, and smaller executables, and a smaller memory footprint, but it doesn't keep out the people who aren't compliant.

While I'm on the subject, who isn't compliant now, or won't be by Fall? RH will be fully compliant with 8.0, MDK is/will be soon, all the United Linux distros are/will be (SuSE, Caldera, Connectiva, Turbo), and Debian is/will be as well. What about Gentoo, Slack, and the micro-distros? Anyone know if they plan to conform? FOr that matter, what about Lycoris and Lindows? ANyone have info either way on these?

If these "hackers" are anything like the Linux people I know, Norway is screwed. You know what I'm talking about, they do the following:

a) Pretend Windows doesn't do certain things. ("You can run DNS with Windows?" "Do I need Trumpet Winsock with Windows XP?")

b) Downplay everything that sucks about Linux every chance you get. (TT fonts are "blurry", and "hurt my eyes" - I like my jagged fonts, I think linux fonts are fine!)

c) Research every new Windows feature and figure out how *nix got it first. Then make it sound like the feature has been necessary for mission critical applications and servers, and that only recently has MS "figured it out". If a third party app accomplishes this in Windows, that doesn't count, even though your whole Linux distro is nothing more than a collection of third party apps to begin with.

d) When Linux gets a new feature that Windows has had forever, downplay the feature. ("Yeah, TTF fonts, we got them now, if it'll shut you up, now that I have them, I don't see what the big deal is.")

e) If anything in Linux doesn't have that feature, it is not important. ("Noone uses that junk in Office anyway")

f) You switched to Debian, but you still hate Red Hat because the copy Red Hat you tried 6 years ago sucked.

g) Pray everytime you try a new USB device - ditto for adding new hardware AFTER you've installed linux. Chicken out and use the PS/2 adapter, blame the hardware manufacturer.

h) Blame X11 for every graphical performance measure in your subsystem, even though you have no idea what you're talking about. Complain that X needs to be scrapped for something like Berlin, even though you've never even been to the Berlin website. But everyone says X11 sucks, you just don't know why, but enough people say it on /. that you won't sound like a total idiot if you just toe the party line.

i) Doesn't matter if you install Gnome or KDE, your menu's are going to have 42 text editors, but not one decent word processor.

j) Find a reason to hate GCC 2.96 even though you've never compiled anything in your life.

k) Doesn't matter if you install Gnome or KDE, because you're going to like Evolution, Konqueror, Kate, GVIM, Gnapster, and Koffice. you're going to like Gnome's applets, but the KDE panel. KDE let's you put a seperate background in each virtual desktop, but Gnome lets you mouse from desktop to desktop. Mozilla looks out of place in both. The one or two motif apps you use make you want to punch your monitor. You decide it's impossible to go with a 100% desktop either way or the other, so you say fuck it and just install them both and run twice the libraries that you need to. Now nothing is consistent, your themes don't match, and now you've got twice as much bloat in your system. When some asks you what you run, you say "GNOME, KDE sucks!" or "KDE, GNOME sucks!" even though you know damn well you don't care.

l) You're too lazy to learn a new window manager, but when another *nix guy asks what you use, you say "FWVM, with nothing but xterms, that's all X is good for."

m) If it doesn't run well on your Pentium II 350, it's slow and bloated.

n) Ten years from now, if it doesn't run well on your Pentium II 350, it's slow and bloated.

o) Blame Red Hat for attempting to destroy/take over the linux community, all the while searching for that SuSE .iso that doesn't exist.

p) You hate Microsoft because Windows cost $200 and Office costs $400, and it's too expensive to be affordable and how you're poor blah blah, but you're too cheap to send $10 to debian.org/Mandrake Club.

q) When you compare features between Windows and Linux, you compare Windows 95's features to the latest CVS builds of GNOME/KDE.

r) Make fun of DLL Hell in windows, even though you know damn well you --force your RPMs all the time.

s) Your first answer to a new user in #linux is "recompile your kernel", even though all he needs to do is double-click the little icon his distro gave him. When someone else points that out, complain that real men edit /etc by hand. When newbie leaves, continue to wonder why Linux on the desktop is taking so long.

t) You wait for someone to ask how to install something so you can say "apt-get install foo", just so you can start on your 25 minute tirade on why his distribution sucks compared to Debian.

u) You believe recompiling everything from source will give you a substantial performance benefit, even though you probably just recompiled that app with the default flags, but you didn't know any better. If it doesn't compile, see GCC2.96 comment above.

v) When above user posts problems with GCC2.96, link to http://www.bero.org/gcc296.html and flame user for trying to compile "shitty code", even though a week ago, you were doing the same exact thing.

w) You've been saying that Mozilla has been your only browser since M18, though you know that it took until .9.x for you to REALLY use it. You preach that Galeon is the best browser, even though it only loads .5 seconds faster than regular Mozilla.

x) You hated Macintosh your entire life until you saw the bash console on a Mac at CompUSA. You feel kindred with MacOSX fans, but hate Apple because they won't let you rip off their user interface.

So where is this "evidence"?

I was merely pointing out that if Gentoo can compile essentially all of GNU with a "broken" and "heinous" compiler (with regards to 2.95.3), and producing a working dist (I have evidence, not proof that this is true as well), why RedHat chose to continue with his particular compiler.

Ever heard about binary compatibility? The major version number of 7.x is there for a reason.

I like RedHat, I aprecate them and wish them the best, but no one is without faults. Criticism can be constructive

Well, your's isn't. You've been saying over and over in this thread that you think it's a broken compiler, but without ever mentioning why you think so. Thus it most certainly isn't "constructive criticism" because it lacks the fundamental part with the facts that would make it constructive.
Without it it is only seemingly pointless bad-mouthing.

and at this point, even if they are correct, the crap that has been said about 2.96 would have me running away from it to make the customers happy, or at least give them alternatives to suit their bias.

If you believe everything that people say, I wish you the best of luck.

If a discussion of a feature in a distribution that's being announced isn't relevant to you and you refer to it as a troll, I'm sorry, Mr. Orwellian thought police brave new world prefect. You will not suppress me or my opinions or my experiences simply by trying to pass off an argument as a troll.

Well, 1) you are not argumenting since you don't have any arguments besides "there are some other distributions that use some other compiler version" and 2) you aren't anything new that hasn't been carefully explained over and over on Slashdot and Bero's site for the last couple of years. Thus, unless you haven't been around for that long of a time and taken part in those discussions or read the explanations, you must be trolling.

So where is this "evidence"?

I was merely pointing out that if Gentoo can compile essentially all of GNU with a "broken" and "heinous" compiler (with regards to 2.95.3), and producing a working dist (I have evidence, not proof that this is true as well), why RedHat chose to continue with his particular compiler.

Ever heard about binary compatibility? The major version number of 7.x is there for a reason.

I like RedHat, I aprecate them and wish them the best, but no one is without faults. Criticism can be constructive

Well, your's isn't. You've been saying over and over in this thread that you think it's a broken compiler, but without ever mentioning why you think so. Thus it most certainly isn't "constructive criticism" because it lacks the fundamental part with the facts that would make it constructive.
Without it it is only seemingly pointless bad-mouthing.

and at this point, even if they are correct, the crap that has been said about 2.96 would have me running away from it to make the customers happy, or at least give them alternatives to suit their bias.

If you believe everything that people say, I wish you the best of luck.

If a discussion of a feature in a distribution that's being announced isn't relevant to you and you refer to it as a troll, I'm sorry, Mr. Orwellian thought police brave new world prefect. You will not suppress me or my opinions or my experiences simply by trying to pass off an argument as a troll.

Well, 1) you are not argumenting since you don't have any arguments besides "there are some other distributions that use some other compiler version" and 2) you aren't anything new that hasn't been carefully explained over and over on Slashdot and Bero's site for the last couple of years. Thus, unless you haven't been around for that long of a time and taken part in those discussions or read the explanations, you must be trolling.

There's not much of a problem with 2.96.

Earlier versions than 2.96 are not an option because they don't do real C++ (see http://www.bero.org/gcc296.html).
3.0.x releases are rather broken and don't have any real advantages over the current builds of 2.96.

gcc 3.1 will be a very good release, even better than 2.96. It is what we're likely to use in the next major release (unless, of course, gcc 3.2 comes first and is good).

http://www.bero.org/gcc296.html

Besides, posting of clear text mailto: URLs on Slashdot should be considered unacceptable. That guy gets enough spam already, why not link to his homepage instead?

read this: http://www.bero.org/gcc296.html
DiscaimerL Bero works for Redhat, so you might not believe him either... ;)

My setup (catches some of the more commonly used spambots) uses mod_rewrite to send spammers to a trap.
Setup details at http://www.bero.org/NoSpam/isp.php

Let me guess, they didn't respond at all.
trafficmagnet.net does this all the time; I'm receiving the same piece of spam about once a month for virtually all domains I own as well as a couple of other domains I've never heard of, apparently because someone linked to my email address.

I've tried contacting them and demanding $1000 according to my terms of service, but they don't react, and neither does their uplink -- and since their whois information is fake, there's noone to sue. :/

• The bug-gnu-utils list is gated to spamnet, formerly known as usenet. While I post to bug-gnu-utils with an obfuscated addresses these days, I can't prevent people from sending bug reports to bug-gnu-utils and Cc'ing me -- thereby making my address visible to spambots harvesting spamnet.
• Address mentioned in public places by someone else, such as "If you're seeing that bug in the Red Hat packages only, contact their packager at ..."
• Address listed on a website (feedback requests, without obfuscating the address to make it easier for users) - this is also what generates a lot of spam on our security contact address

I believe it is (by the way, this message is covered by the bero.org documents license).

Another thing that occasionally helps is enforcing terms of use on your mail server.
e.g. if you connect to mail.bero.org port 25, you'll see 220 www.bero.org ESMTP Postfix - SENDING ANY COMMAND OTHER THAN "QUIT" CONSTITUTES ACCEPTANCE OF THE TERMS OF SERVICE OUTLINED AT http://www.bero.org/smtp-tos.html with smtp-tos.html being terms of service forbidding anything related to spam (including delivery).

I'm not 100% sure this is actually enforcable, but it's surely scary enough for some spammers to pay rather than risking it. (And a relatively safe way to at least get off their lists - they don't want to get an invoice again even if they're ignoring it).

Take a look at http://www.bero.org/NoSpam/isp.php - I've put up my apache configuration there. It does just that at least for some unintelligent spambots.

Mandrake 8.1 and 8.2 come with 3 compilers; 2.91 (egcs), 2.96 (default), and 3.0.3.
The ppc version comes with 2.95 instead of 2.96.
Through /etc/alternatives you can choose whichever you want.

Btw, please read up on gcc2.96.
That should teach you complaining about 2.96.

2.96 has gotten a bad rap. I can't comment on that particular issue, but in most of the cases where people have complained about gcc 2.96 being buggy, it has actually been buggy code (that just happens to compile ok with another version of gcc). Check this out for details: http://www.bero.org/gcc296.html

No question about RedHat's broken GCC 2.96 compiler and what they're doing to fix it in later releases?

It's not broken. It was a move we had to make at the time: gcc 2.95 was badly broken (e.g. didn't compile glibc 2.2), had severe lacks in C++ conformance and didn't support the architectures we needed. Also, performance was abysmal on other architectures we cared about (in particular, the alpha). Here are more details.. Right now, gcc 2.96RH is a very mature and solid compiler

Gcc 2.96RH has served us well for three releases now. We're not going to "fix it" (it's not broken, it's better than the current alternatives and we don't want to break binary compatibility), but at
some point we'll switch again. You can find some hints at that in the current Rawhide.

It's not just about Mplayer versus Joe Barr, it's about a lot of annoyed Mplayer users on major GNU/Linux platforms versus a few Mplayer developers with their own political agenda (anti-gcc-2.96-rh) and their desire to use the software project for false statements and pure FUD to support said agenda. Whatever they are using their power and influence for, it's certainly not about fair play.

As for Joe Barr, he seems to be exhibiting the typical Microsoft attitude of "if enough people use it, everyone should support it." He says that gcc 2.96 must be supported because it comes installed by default on his Mandrake box. That's like a Windows user telling me that my project has to work perfectly on Windows XP or that it has to work perfectly on an ATI card (since they are so popular). Think about it. Should developers allow popularity to dictate what they do? My answer is no. Do what you think is right, don't allow the dominant software to control your actions.

Your argument is flawed. This is not about not working flawlessly on all configurations and systems, this is about spreading blatant lies and FUD.

Joe Barr's argument that gcc 2.96 should be embraced because it is installed by default on distribution only makes sense if the devs are in the business of pleasing customers. But as Joe has obviously forgotten, these devs don't have customers. And they probably don't care about annoying potential users either.. and why should they?

Maybe because no contributor/developer is born as a contributor? Most of them start as users, and the Mplayer project's attitude towards users is rude, to say the least.

2 - Regarding the devs' inflammatory comments in their FAQ ... well, to put it bluntly, I often feel exactly the same way that they do when people ask me incessant questions. The only difference is I force myself not to put my true feelings in the FAQ. Devs are humans and they lose patience and get annoyed.

Yes, but by putting their rude remarks towards users asking questions on their web page, they are showing their arrogance towards all users, not just the one(s) that asked a particular question. Even if a rude remark on a mailing list is bad to begin with, putting the same attitude everywhere on the home page is making it many times worse.

Let's face it, should they really be responsible for answering questions about installing shared libraries when it is a more general linux issue and not something specific to MPlayer?

No. There's a major difference between answering "I'm sorry, installing shared libraries is a general Linux topic and is thus out of the scope of this documentation. Please read the manuals for your distribution or other documentation on the Internet" instead of calling users stupid and lusers.

In fact, on a more broader scope, should they really be responsible for answering anyone's questions at all? If you said yes, then I invite you to think about why you said yes. Probably the only reason you can come up with is because "If they are mean to their users, than their users will leave and they won't have any users anymore." Fair enough.. but do the MPlayer devs really care if anyone uses their stuff? They probably don't frankly.

Quite obviously not. The problem is that all contributors are beginners at some point. Thus there's certainly no need to call users names or being otherwise unpolite, even if you don't want to answer all questions yourself.

Any dev who works on free software for the sake of providing a quality product for Mr. Newbie quickly becomes depressed and stops working on the project.

That's not necessarily the case. One doesn't have to answer all users' questions. In my experience, a good FAQ is a good start. If you don't want to answer all questions a short pointer to where the information could be found is a good start to make people "go away". Being rude is not a part of this, it's perfectly possible to give an "look for information elsewhere" answer without being rude.

Only those devs who work on free software for their own amusement, interest, needs, etc. are those who can endure for long periods of time.

In my experience, there's usually no conflict in creating software that you like yourself and that can also be usable by others without insulting them, or continuing to spread information that many people have already pointed out is very untruthful.

The bottom line is, that users of free software often create more headaches for developers of free software than benefits. If that statement shocks you, I'd encourage you to think about it for a while ...

Only if you divide the world into a "we developers", "them users" mindset. This is usually far from true, in particular it doesn't take into account that a person can be both at the very same time, and that noone is born as a contributor/developer.

Then maybe he should:

• Not try to respond to all boring questions himself and try finding some help for this task
• Learn not to come off as a total jerk in his replies although he may have found it boring to answer the same question multiple times.
  That the reader of the FAQ in 99.9% of the cases most likely isn't the person(s) that annoyed him with this question is probably more the reason to stay polite and not try to make fun of people or put them off.

However, everyone I've ever talked to on the mailing list is consistently friendly and helpful.

That may be the case, but the purpose of a FAQ is after all to help people avoid having to ask questions on the mailing list, and a lot of people try to read the FAQ before asking on the mailing list. Even more a reason to stay polite. An unfriendly tone of voice in the FAQ doesn't help getting people with valid questions or interesting feedback get interested in the mailing list either.

The only reason that anyone could really call MPlayer controversial is because they had some lisencing issues a while back, because of incompatible lisences in (if I remember right) the OpenDivX portion of the program.

No, there are lots of other reasons, the rudeness towards users and compiler warnings with false information being major parts. Not many software projects try to avoid having users by being arrogant towards them or include false compile-time warnings with the only purpose of spreading FUD about another software project.

What has building a good movie player for GNU/Linux to do with being arrogant towards users and providing compiler warnings with blatantly false information that only serves my own political agenda? I'm not familiar with the author of the article, but the article summarizes my and many other users' experiences with Mplayer, their documentation, and responses from developers quite well.

AFAIK, gcc-rh 2.96 has compiled all released, stable kernels just fine, from kernel 2.4.x and up. What's the point? What does it have to do with Mplayer and why does Mplayer need to issue a warning about this compiler? Why doesn't it have a warning for gcc 3, which also has had kernel compilation problems?

... and that GCC 2.96 does not even officially exist, according to GNU [gnu.org]?

You are free to call it anything you like... gcc2.96, gcc 2.96, gcc-rh 2.96, rh-gcc 2.96, gcc 2.96-rh, and so on. Pick anyone you like. It's still an excellent compiler (maybe currently the best free one) and one that is used by at least two major GNU/Linux distributions. It still doesn't answer the question why the Mplayer developers would need to issue a warning and refuse compilation unless you pass a special flag and type in a lie?

http://www.bero.org/gcc296.html has some relevant facts regarding gcc 2.96, I really recommend that page.

Xine can now do DivX, OpenDivX, DVD, MPEG 1/2, Windows Media Video 8 and 8, and most of the formats MPlayer can. So can Avifile. They're open source, Mplayer isn't - read their documentation sometime, specifically the part on packaging. And no, not just the codecs, but the project itself.
Non-Sorenson Quicktime in only useful for people making movies under Linux.

Many people put in a bloody large amount of time and effort into getting newcomers to the platform. Telling someone they're an idiot because they don't know how ldconfig works undoes that hard work and pisses me off. Its possible to answer newbiew questions withotu being a fuckwit, but the mplayer team would rather serve their own egos. Especially if mplayer was packaged like most Linux programs (the mplayer team forbid this) the postinstaller would do that anyway.

Ogle, Xine and Avifile are also more well designed, with most options avaliable via the GUI and command line switches rather than compile time options.

The MPlayer team have also yet to respond to Bero's response re: their GCC 2.96 claims, leaving something on their web page which has seemingly been proven to be technically false.

Furthermore, telling me in captial letters that MY SYSTEM IS TO SLOW TO PLAY THIS MOVIE when I'm fairly sure a 900 Mhz Athlon with 640MB of RAM is capable of playing a VGA res DivX is worth a laugh or two.

When there's a billion better players out there which don't go out of their way to be rude to people and Open Source licensing, why use Mplayer?

Yes. Many people are considering it a better compiler than most gcc:s in the past because it is less sucky and less buggy in a lot of areas. Also, it still (AFAIK) has an edge over gcc 3 in that it compiles glibc and such.

I also did a bit of google-ing about this warning in mplayer, and AFAIK some people were a bit angry that 2.96 has been singled out (probably just because it's a RH release) I wonder if the reasons for so prominently warning people about 2.96 are at least in part political...

They are only political. There used to be problems with the Mplayer code but those have been corrected, but the warning wasn't removed (most likely because of the Mplayer developers' own political agendas and so that they would not looose too much face).

Sure - try DOSEMU with FreeDOS ripcord.

If it doesn't work, try dosemu with DR-DOS - not open source, but at least $0.

I love postfix, but people wanting to use it on RHL should be aware of this issue with procmail. (And if anyone has a solution, we'd all love to know.)

Is any of this proprietary, or has RH managed to stay comeletely OS?

With the sole exception of Netscape (which will disappear later), it's 100% OS.
And Netscape will disappear with the next release - we're already including Konqueror, Mozilla and Galeon as free (and better) alternatives right now.

Also, what RH specific changes are in this gcc?

It's a stabilized fork of a CVS version. See http://www.bero.org/gcc296.html for a further explanation.

Why isn't gcc-3.01 being distributed? Does it have major issues?

It's included as a preview package, but it's not ready for a standard compiler.
It breaks binary compatibility with the compiler used in prior 7.x releases (which is something we don't do in minor releases), and its C++ part is quite broken ATM (try running a version of KDE that was compiled with gcc 3.0.1 and you'll see what I mean - it crashes at startup).

Redhat has dropped support for Postfix (a sendmail replacement), which used to be on the Powertools CD. I really don't know why

It's because Powertools was dropped, and everything on Powertools that conflicts with something on a main CD (e.g. you can't install postfix and sendmail on the same system) had to go because at this time, the installer doesn't handle conflicting packages (breaking the "Everything" install isn't nice).

This is likely to get fixed in a future release (no promises though, it's not my decision [I'm all for postfix]).

Those who prefer it can grab the current official postfix package from rhcontrib. I'll open up the 7.2 section there later today.

Since it is a .2 version, RedHat is going to support it for a looong time

<obligatory "we don't preannounce releases" rant>
What makes you think the next release will be 8.0? ;)
</rant>

Red Hat Linux RPMs are available here.

Since spam is getting more and more of a problem, I've decided to release my partial solution (content based spam filtering).
It currently kills about 70% of the spam I receive (still leaving about 20 messages per day in my normal mailbox :( ).

ftp://ftp.bero.org/pub/experimental/NoSpam-0.0.1.t ar.bz2

And yes, it kills spam from monsterhut.com.

You know, if you're going to just copy word-for-word what Bernhard Rosenkraenzer (bero@redhat.com) said on his own website, (http://www.bero.org/gcc296.html) you should at least give credit where credit is due.

For a clue, please read this.

Clearly you have never read this.

Red Hat 7 doesn't use egcs. If you meant gcc-2.96-rh, you should probably have a look at http://www.bero.org/gcc296.html for lots of reasons why gcc 2.96 could be a good choice.

and moves things around in such a way that if a software developer writes a program to be installed on a RedHat Linux system, it won't install on any non-RedHat-based distribution.

Red Hat 7 and later plays rather nicely with FHS...

If it does install, the crazy egcs release will keep it from running on the new machine.

Use binaries compiled for the platform you're using, or compile yourself. Complaining that some binary compiled for JoeRandomsDistro won't work with your Red Hat install isn't very relevant, IMHO.

RedHat often screws with things like init scripts just enough to make them UNIX-like, but to break POSIX standards.

Examples?

What pisses me off about RedHat is how deliberate their embrace-and-extend design policies are. I don't recommend RedHat for anything, because learning the quirks of RedHat puts users into bad practices of using their proprietary tools

What proprietary tools exactly? Red Hat doesn't do proprietary tools.

or expecting the proprietary behavior of their tools to be standard cross-platform.

A behavior cannot be proprietary (unless it's patented), afaik.

It's sort of like how a lot of linux distros have a 'route' command that, for some reason, won't accept 'route add -net default' (which is standard across UNIX) but will accept 'route add default gw'... annoying.

1. chkconfig is IRIX-like. linuxconf is depricated (and is from someone else anyway. rpm is very powerful and good despite its few flaws.

2. The 6.2 installer needed some work -- it was newly re-written in python. The 6.0 installer was a terrible ugly chunk of C code which needed to be rewritten, but which was very solid. If you use 7.1 or the 7.2 beta, you'll find the installer is much more stable. I've never seen netconfig segfault, but I probably haven't seen the situation you're referring to.

3. See http://www.bero.org/gcc296.html for some good information on the GCC issue. Red Hat is a part of the Linux Standard Base project, and makes a very strong effort to be FHS-compliant. Library differences are a fact of Unix -- you can't expect to move binaries between *any* two distributions without some glitches. I'm pretty sure that POSIX doesn't specify init scripts, so I'm not sure exactly what you're talking about there -- care to clarify? And in general, can you point to some evidence of this "deliberate"ness?

4. Red Hat's tools aren't proprietary. The installer, anaconda, is GPL'd. So are chkconfig and RPM, and linuxconf is too, although as I said it doesn't really have anything to do with Red Hat per se. netconfig is part of pump, which is released under the MIT license. Your route gripe might be valid, but as far as I know, that's not Red Hat specific.

5. The ps that ships with Red Hat (GPL'd, by the way) will accept either BSD options or SysV flags. So you can do either "ps ax" or "ps -ef".

If you don't like the compiler, take a look at http://www.bero.org/gcc296.html and then fix your applications.

There are 2 reasons why we're still using 2.96 even though 3.0 has been released.

The first is binary compatibility - gcc 3.0 is not binary compatible with anything else, and we don't break binary compatibility between minor releases.

The second is that 2.96 is way more stable than the 3.0 release (though the current 3.0 branch in CVS works somewhat better). If you've ever tried compiling KDE with gcc 3.0, you'll know what I mean.

I don't think you can come up with any program that uses correct code and doesn't work with gcc 2.96 - if you can, report it so we can fix it. If you can't, don't complain.

The final will include KDE 2.2 and a proper compiler (namely 2.96 ;) ).

Guess what? Everyone that complained about GCC 2.96 being broken (and not reading http://www.bero.org/gcc296.html) despite the fact that their code wasn't C99 complient STILL WON'T COMPILE. Now you can't complain that your code won't work because it's a developmental compiler, you'll actually have to fix it. Numerous examples of this are listed at the above URL, I'd highly suggest you try it out. I have a feeling quite a few people are gonna be red in the face over this one. ;-)

Guess what? Everyone that complained about GCC 2.96 being broken (and not reading http://www.bero.org/gcc296.html) despite the fact that their code wasn't C99 complient STILL WON'T COMPILE. Now you can't complain that your code won't work because it's a developmental compiler, you'll actually have to fix it. Numerous examples of this are listed at the above URL, I'd highly suggest you try it out. I have a feeling quite a few people are gonna be red in the face over this one. ;-)

P.S. It's GCC 3.0, FYI.

Maybe because gcc 2.96 is a better compiler? Bero has a page that you might want to check out.

That's because the sources are broken (not ISO C99/ISO C++98 compliant), not because the compiler is broken.

Check http://www.bero.org/gcc296.html for a couple of examples of broken code that used to work with older compilers, and how to fix it.

• xinetd: making the switch was the correct (and IMO overdue) choice, both for ease of use and for security (xinetd implements IP based access control), and for compatibility with the future (xinetd can do IPv6). Handling legacy inetd.conf files is a problem: If a service is described in both, which do you take? Also, inetd.conf has no way of providing information like permitted/rejected IPs.
  If we never dared to change anything because of compatibility issues, we'd still be punching holes in cards for programming.
  You can configure xinetd by hand (my favorite system configuration tool is and will always be vim) - its config files aren't more difficult to understand than inetd.conf. They're just more powerful.
  
  This is very different from changing / to C:\ -
  one was a big step forward, the other would make no sense at all and be a big step backwards.
• wine: We're shipping it on Powertools.
  Putting a lot of resources into wine wouldn't make much sense. First of all, there's two sides to wine. Of course it's nice that I can run a Windoze application on Linux if I need to (I'm doing my tax declarations with wine, for example), but if it runs too well, companies won't see a need to write native Linux applications ("But our Windows version works for you, why should we do anything else?").
  Second, the desktop isn't our primary target, and there's no reason whatsoever to run wine on a server or embedded device.
• gcc: This has been discussed to death many times. Go to http://www.bero.org/gcc296.html and let me know if this doesn't answer your questions.
• What we do at "work": Coding, packaging and fixing bugs. Have you ever used the Linux kernel? glibc? gcc? KDE? GNOME? rpm? If you answered yes to any of those, you've used Red Hat code. (No, I'm not claiming we invented them or did all the work on them, but all of them contain a lot of code we wrote).
  Since everything we do is released under the GPL or LGPL, many people aren't aware of the fact that they're using a lot of our code even if they aren't using Red Hat Linux. (Yes, the same goes for most other distributions to an extent.)

Sure. See http://www.bero.org/gcc296.html

We've all seen numerous pictures... And since he's wearing a Red Hat(tm) in each of them, we even know what OS he's running. ;)

greetings, eMBee.
--

It's not the same, though in the long run merging them will probably make sense.

They're very similar, but not exactly the same.
unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are VERY welcome...

I can see that this page is going to be attract
free software wannabees, who see the opportunity to take responsibility for an already partially complete codebase in order to try to get kudos as the project manager. In reality though, this is likely to be bad for the project. I doubt that these newcomers will see the project as little more than an ego boost and a nice addition to their curriculum vitae, and many of these new 'project managers' will lack the ability or dedication to put the project back on track.

I agree that this is a potential problem - At ufo.bero.org, I'm trying to solve it by requiring that a new maintainer sends in a couple of patches before taking it over officially.

They're very similar indeed, but not exactly the same.
unmaintained.sourceforge.net wants to create a list (probably with the purpose of someone just taking the initiative and releasing a new version), UFO (which has moved on to ufo.bero.org) wants to keep the stuff alive while trying to look for new maintainers and requires the consent of the original maintainer. So far, it hasn't really started off (largely my fault; I started it, didn't have enough time to work a lot on it myself, and didn't manage to start a real community effort). Contributors are welcome...