LWN: Comments on "Fedora Core 4 Test 1 slips"

Fedora Core 4 Test 1 slips

EVApilot — Wed, 02 Mar 2005 02:24:57 +0000

Can't compile the kernel on GCC 4? Bugger. Wish I didn't do "yum update"...

GCC 4 Preview in RHEL 4

tzafrir — Fri, 25 Feb 2005 12:55:17 +0000

gcc 4 will probably be upgraded on the next service pack of RHEL . So in about 6 monthes or so RHEL users *will* have a decent gcc4 version.

The other alternative is that RHEL only includes the obsolete (a year from now it will become quite obsolete) gcc3.4 .

GCC 4 Preview in RHEL 4

Duncan — Fri, 25 Feb 2005 11:49:26 +0000

Quoting Richard Stallman, the quote I use in my USENET and mailing list sig:

"Every nonfree program has a lord, a master -- and if you use the program, he is your master."

Let some closed source program be your master, and you are forever enslaved to the whims of its master -- until you break free of that closed source bondage, anyway.

Duncan

Fedora Core 4 Test 1 slips

danielos — Fri, 25 Feb 2005 10:22:20 +0000

The only way to find a compiler bug is to compile code, thing that user usually did not do, or at least not too much as it has to be done for a distros.

That said, if they come out with a 2.4 and 2.6 kernel compiled with gcc 4.0 for mid April then or Fedora or GCC people are real wizard.

BTW, IMHO, (giving a certified no-wrong-code-gcc-4.0) a stable distro should be compiled with gcc 3.3 and g++ 4.0 and gcj 4.0, and provide both gcc 3.3 and 4.0 suite; also I guess this is the Fedora plan.

Fedora Core 4 Test 1 slips

jimmybgood — Fri, 25 Feb 2005 02:35:26 +0000

No, you're wrong about that. Fc3 was released on November 8, 2004. Fc1 wasn't obsoleted until November 20, 2004, twelve days after fc3 was released.

Fc2 is scheduled to be discontinued on March 21, 2005, while fc4 is not scheduled to be released until June 6, 2005 77 days _later_. And I'll wager any money at even odds that they don't make that schedule. After all, there are already delays.

So fc2, released on May 18, 2004, will only exist for 10 months. Where I come from, that's considerably less than a "year or so".

I've already "seen" the Fedora Legacy Project. They didn't start providing support for fc1 until months after it had been obsoleted.

A 10 month release to obsolescence development schedule is just too short for any kind of practical real world use. Who are they making it for? What business could possibly afford to change operating systems every 10 months. Maybe that's what it's about. Is the Fedora project trying to make sure that it can't be used in a production environment to avoid competing with RHEL?

I don't know, but I do know that the folks at the Fedora project aren't disclosing their reason for cutting fc2 so short.

Fedora Core 4 Test 1 slips

djabsolut — Fri, 25 Feb 2005 00:24:20 +0000

This is a bit of a chicken and egg problem. I don't think GCC 4.0 will be full of nasty bugs, but any x.0 release is bound to have some issues. That said, these issues can't get worked out until many people actually start using the compiler and find out what the bugs are. What better place to put a new compiler than on a distribution which is specifically for pushing the envelope?

Fedora Core 4 Test 1 slips

pglennon — Thu, 24 Feb 2005 23:26:02 +0000

it feels like we are losing touch with the article, which, in my mind, highlights why I don't put Fedora on anything but a virtual machine, and even then, only when I'm drunk:

They are delaying the release of FC4 to ship it on a brand spanking new GCC4. Wow. That, to me, says that Fedora has no intention of trying to be a stable operating system, but merely a place to rapidly expose bugs for an overly expensive Red Hat Distro.

Just my opinion.

Bye Fedora, Hello Gentoo

b7j0c — Thu, 24 Feb 2005 18:45:33 +0000

Its been fun, but the bloat on the release is getting out of hand...and the need to get updates from N different yum repositories...and the shoddy coverage of packaged software (so much unpackaged...so much out of date)...and the inability to migrate major components between releases (why must I wait for a release to upgrade the gnome environment?)...

The fact that official repos don't even carry Thunderbird 1.0 in Feb 2005 tells the whole story - I have to keep a $HOME/local path of stuff I compile myself in order to get recent stuff. Your official repos carry Thunderbird 0.7 or 0.8...pathetic.

Now look at Gentoo's package listing. How do you plan to get Fedora extras to get the coverage this repository has? I'm blown away at the coverage in packages.gentoo.org. They have EVERYTHING and it is RECENT.

BYE BYE FEDORA.

Fedora Core 4 Test 1 slips

arafel — Thu, 24 Feb 2005 11:46:17 +0000

>Oh please, if it compiles, and isn't a steaming turd, chances are its
>enabled in Fedora kernels.

You're getting dangerously close to "it builds? ship it!" there. ;-)

GCC 4 Preview in RHEL 4

amacater — Thu, 24 Feb 2005 11:15:09 +0000

Red Hat does include Cygnus - they know what they're doing - no dispute.
As one of the people eagerly waiting for GCC 4.0 (because 3.4.3 has issues on a platform I use at work), I _may_ know what I'm doing :) The issue comes because RH EL is supposed to be unconditionally stable for the enterprise. If you do an rpm -qa gcc* - you see gcc4. Six months from now, when someone needs to build code which has been building quite happily on FC4 with GCC 4.0 - what will they have? - a (potentially buggy)
GCC preview version which isn't tagged _unconditionally_ as such. When developers say "it works for me with GCC 4.0" and it doesn't work on RH EL 4, what then? If a boss says - "We need to keep up with the latest code because it has feature *** which we need" there's pressure to use a prerelease compiler This is not appropriate for a stable distribution for the enterprise which is intended to have a seven year support life: I'd much rather that RH had put in useful stuff like lesstif / OpenSSL development libraries /other libraries.

Fedora Core 4 Test 1 slips

nedrichards — Thu, 24 Feb 2005 10:33:13 +0000

Yes the 'expert mode' for that is calling the installer with 'linux xfs' 'linux jfs' 'linux reiserfs' etc. I've always run my fedora w/ XFS and have had 0 problems.

GCC 4 Preview in RHEL 4

rmyorston — Thu, 24 Feb 2005 10:31:54 +0000

Compiler versions, and ABI compatibility, are a big deal, particularly in the commercial world where things tend to move more slowly. We're still living with the consequences of the GCC 3.0 compilers that shipped with RH72 and then were backed out of RH73.

To interoperate with a third-party product we need to use their closed-source C++ libraries, which were built with the RH72 GCC 3.0 compiler. These libraries are compatible with nothing in the modern world. Using them requires a specially tailored build environment and the installation of ancient support libraries on runtime systems.

I'm happy that Red Hat seem to have learned the lesson of the GCC 3.0 debacle and are being suitably cautious in their Enterprise systems but adventurous in Fedora Core.

Fedora Core 4 Test 1 slips

james — Thu, 24 Feb 2005 10:13:40 +0000

Does this mean that we'll start seeing code compiled for the Pentium III, Pentium 4 or Pentium M?

We already do.

Practically all of Fedora Core 3 for i386 is compiled with Pentium 4 optimisations (which also work well on Athlons). Where code can benefit from the (few) extra instructions introduced between the 386 and the Pentium Pro, then you'll get separate i686 and i386 packages.

I understand that the standing offer is to compile using the extra instructions if someone can show rigorous, repeatable benchmarks that prove it would be beneficial (which rules out "Gentoo feels faster").

I've never seen anyone actually deliver those...

Fedora Core 4 Test 1 slips

danielos — Thu, 24 Feb 2005 10:00:50 +0000

If Fedora's people can compile kernel, libc, qt and all stuff with GCC 4.0 they will make a great work for GCC release. I fear that Fedora test will delay GCC 4.0 release, but this is good anyway.

Fedora Core 4 Test 1 slips

nix — Thu, 24 Feb 2005 08:37:22 +0000

I'm impressed by the Fedora team's dedication to using modern technology and advanced optimization techniques. Does this mean that we'll start seeing code compiled for the Pentium III, Pentium 4 or Pentium M? That would be one way to make use of advanced optimization techniques GCC already has.

Your belief that advanced optimization techniques imply compilation for a particular CPU is... peculiar.

Most of the improvements in GCC 4.0 are infrastructural, and while they should lead to a faster compiler that's much better at optimizing, that improvement will be visible to everyone no matter what their CPU, not just people with new CPUs.

(In fact, the largest single problem with GCC's optimization on IA32 right now is probably the tangled intertwined mess that is the regalloc/reload passes; but so far no attempt to rewrite those monsters has succeeded.)

The largest improvements with GCC 4.0 are invisible: right now, the focus is on getting the tree-ssa optimizers to carry out the same optimizations as the RTL ones did, so the RTL optimizers can be ditched --- well, right now the focus is on stabilization for the GCC 4.0 release, but you know what I mean. (That's not to say that there aren't a whole heap of nifty new optimizations, too. But getting rid of RTL optimizers that try to build palaces using individual grains of sand is I think more important.)

(Joe, feel free to correct me if I'm talking nonsense, which I probably am.)

Filesystems and repositories

jmalcolm — Thu, 24 Feb 2005 07:58:19 +0000

Fedora kernels support all the major filesystems through modules. If the initrd.img loads the modules for your filesystem it will boot Fedora fine. This is true at install time as well. I have more than one Fedora system using XFS. I can RPM a stock Fedora kernel and reboot without problems.

It is true that only Ext3 (and Ext2) is available for new installs though. This is something I do not like about RHEL/Fedora. I believe there is a conflict between SELinux and the other journaled filesystems but that might be changing.

http://66.102.7.104/search?q=cache:_F6n9RZGrZUJ:https://w...

As for repositories...there seems to be a move to try and unify the major RPM providers.

http://rpmforge.net/

Fedora Core 4 Test 1 slips

davej — Thu, 24 Feb 2005 07:53:16 +0000

> The biggest is that they don't support enough hardware.

Oh please, if it compiles, and isn't a steaming turd, chances are its enabled in Fedora kernels.

> They already patch the kernel, so it's not as if they would be doing
> anything arcane.

We're not patching it /that/ much. Asides from a handful of features like exec-shield, Xen and a handful of other bits there's really not that much in there these days. FC4 is currently around 50 or so patches off the top of my head, and I'm working to get this even lower by the time FC4 ships. FC3 is somewhat higher, because its based on 2.6.10, and has a bunch of fixes from 2.6.11rc added to it. (After a rebase to 2.6.11, it'll drop off to around 40-50 or so again).

> Adding madwifi and other unofficial & not included drivers would go a
> long way to making Fedora an instant hit with newbies to Linux

And what happens when upstream then implements something completely different, and I put out an update kernel ? Users get screwed by the change. Merging drivers & subsystems into vendor trees is *not* the way to go. The only drivers added to the Fedora kernel over the last year or so have been speedtouch, and the ipw wireless drivers. Speedtouch was merged so that it could be used out of the box on FC3 (as it was getting merged upstream at the same time, but hadnt yet appeared in a released kernel).
ipw is a little more borderline. It needs work, but at some stage should actually be something mergable.

This stuff needs to be upstream. Read the Fedora manifesto. It clearly states that we strive to be as close to upstream as possible in the kernel we ship. Having a vendor tree filled with random versions of various drivers pulled from here there and everywhere is the road to madness.

I've seen this happen firsthand - We merge a driver, a bug is found, we scratch our heads, ask the upstream developer to take a look - "not interested as its a red hat kernel and there are other patches there".

That model is doomed. The only way this can work is by getting as much as
humanly possible into Linus' tree so everyone is working from as common a base tree as possible.

Fedora Core 4 Test 1 slips

shalem — Thu, 24 Feb 2005 07:36:52 +0000

Please people stop whining about having optimised packages for your cpu, does windows come with 6 different versions?

And if you whine at least know what you're talking about, the i686 family started with the pentium pro, then came along the pentium 2 which was a pentium pro with the internal cache removed and mmx added, the p3 was again just a souped up pentium pro, this is the REAL i686 family.

The p4 otoh is a whole new design and the new p4's (presscots) the ones with the model numbers are again a whole new design (yet still called p4, to hide that they are actually slower then the old p4's), this is for some reason still called the i686 family afaik.

And the pentium mobile is a pentium pro based design with quite some changes to it, so basicly again a new beast.

So we have 4 different beasts to deal with (counting only intel):
-pentium pro, 2 and 3
-pentium 4 pre-prescot
-pentium 4 prescot
-pentium mobile

Also you really need to make a difference between which instructions are used and for which cpu the code is optimised. All binaries in FC3 are optimised (instructionscheduling wise) for the (pre-prescot) P4, this is doen because this is the most widely used processor now a days and because P4 optimised code also runs pretty good on Ppro/2/3. AMD cpu's really don't mind that much what you feed them, they perform descent with just about any code.

Beside the optimal instruction scheduling, you also have difference between cpu models in available instructions, this is where the i386 and i686 rpm's come into play. i386 rpms use only 386 instructions (needed for via epia systems), but their (much more important) instruction scheduling is optimised for the pre-prescot P4.

For the few cases where the few normal instructions only available in newer CPU's do make a difference there are seperate RPM's.

Programs which benefit from special instructions like mmx and sse usually contain both normal and mmx/sse versions of the code in question and determine the availability of mmx/sse runtime.

Anyways this discussion has been had over and over on the fedoral-devel mailinglist, and the default answer is, if you believe optimalisation for your specific cpu helps then:
-benchmark the stock FC3 package of the program you think will improve
-rebuild the RPM from the SRPM with different rpm_opt_flags.
-benchmark again.
-if you find a significant improvement, please post your results to
fedora-devel so that the people there can decide if it is significant
enough to warrant action.

Fedora Core 4 Test 1 slips

djabsolut — Thu, 24 Feb 2005 07:31:44 +0000

That's the rules of the game with Fedora. If one is concerned about a Fedora release not being maintained after about a year or so, it is better to use an alternative distribution. See also the Fedora Legacy Project.

Fedora Core 4 Test 1 slips

p9ing — Thu, 24 Feb 2005 06:41:49 +0000

There are xfs, jfs, reiser, modules in the update kernel RPMS at least. I can't recall whether they are there at install time.

FC3 is the best hardware support I've seen since 7.2.

DAG claims that not all repositories "play nice" together, but several but not all of them are merging source trees, making the RPMS interchangable -- with yum.

Sorry, I just don't get where you are coming from.

Fedora Core 4 Test 1 slips

jd — Thu, 24 Feb 2005 06:15:00 +0000

I'm impressed by the Fedora team's dedication to using modern technology and advanced optimization techniques. Does this mean that we'll start seeing code compiled for the Pentium III, Pentium 4 or Pentium M? That would be one way to make use of advanced optimization techniques GCC already has.

i686 is the Pentium II and the only programs compiled for it are the kernel, glibc and openssl, although I strongly suspect other programs would benefit. Fedora recognizes the i786, which is the Pentium III, but supplies no binaries for that architecture. The Pentium 4 (I guess the i886) is not recognized by any of the scripts or apps dealing with architecture. For example, if you told the box it was Pentium4, yum would fail as it wouldn't have any idea that it could use any ix86 RPM for that architecture.

My biggest gripe with Fedora and Red Hat is this amazing belief that ext3 is the only filesystem on the planet. Whatever happened to XFS? JFS? Reiserfs? Reiser4? If too many options would confuse a novice, have a toggle button that switches to and from "expert mode" or something. It is a fatal mistake of any company to pursue a "not invented here" policy.

Actually, make that the second-biggest mistake. The biggest is that they don't support enough hardware. They already patch the kernel, so it's not as if they would be doing anything arcane. Adding madwifi and other unofficial & not included drivers would go a long way to making Fedora an instant hit with newbies to Linux. One thing you do NOT tell a newbie to do is to configure and compile their own Linux kernel. Not unless you are into serious S&M.

Finally, Fedora and fan-groups need to be a bit more organized and work together. ("Such an alien concept" he says, voice dripping with sarcasm. Or was it butter?) You have Fedora Core, Fedora Extras, Freshmeat, DAG, CCRMA, numerous other collections and plenty of Open Source projects that never get into collections at all. Not all will work with Yum, those that do usually don't have a mirror list that will, prioritization doesn't exist, few archives or projects are signed (and MD5 is broken anyway), duplication of effort is phenomenal and with no coordination, there's no way of knowing how the RPM version tags relate to each other.

I have seriously considered whether it would be worth just mass downloading all the SRPMS from these sites and building a mega RPM collection that resolves all these issues, once and for all. Unfortunately, I woke up a little while later.

GCC 4 Preview in RHEL 4

lakeland — Thu, 24 Feb 2005 04:25:13 +0000

The gcc 2.96 fiasco was a big deal. Programs built on redhat could not be
reliably run on any other distro. It worked 99% of the time, almost as if
the other platform was 'unstable'. For people trying to support two
distros, it was a nightmare.

I disagree with your claim that RH's intimate knowledge of GCC allows them
to choose an unreleased version. Sometimes that familiarity means you can
overlook the weaknesses/lack of polish. Just look at how many people are
still running kernel 2.2 or 2.4 -- many people just don't care about
dozens of better features, just about stability, consistancy and
reliability.

Of course, 2.96 was all a long time ago now, and I really don't see
anything wrong with RH including a preview release of a compiler with
their distro -- just as long as it isn't the default.

Fedora Core 4 Test 1 slips

jimmybgood — Thu, 24 Feb 2005 04:07:23 +0000

What concerns me is that support for fc2 is being dropped so soon while fc4 is still just a hope and promise slipping further into the future. Fc3 simply has too many problems that I can't resolve and I'm not looking forward at all to the prospect of having to switch to fc3 and then to fc4 a month later.

Fedora Core 4 Test 1 slips [GCC 4 status]

jwboyer — Thu, 24 Feb 2005 03:31:20 +0000

The gcc4 package is available on Fedora Core 3. Where do you think RHEL4 got it from? :).

Fedora Core 4 Test 1 slips

jwboyer — Thu, 24 Feb 2005 03:29:26 +0000

Actually, it's the other way around. The GCC 4 preview package has been available since Fedora Core 3.

Fedora Core 4 Test 1 slips [GCC 4 status]

jmalcolm — Thu, 24 Feb 2005 01:48:19 +0000

Given Fedora's intent to be a cutting edge, or even experimental, distribution it makes sense they would want to move to GCC 4 early. I am glad though that they are being at least cautious enough to stick with released versions.

RHEL needs to be much more conservative but I like that RHEL4 includes GCC4 as a preview. It is clearly described as such in the RPM description.

Let's be fair. It is not like they compiled the kernel with GCC 4.0 or anything. All the RHEL packages are compiled with 3.4.3. This is not like the 2.96 situation in my opinion.

Not only is it very useful to be able to preview GCC4 as a developer but given the lifetime that RHEL is supposed to have between upgrades it is only good planning to expect that people will want to use GCC4 in RHEL4 eventually. It seems totally sane that someone might want to use Fortran 95 under RHEL4 a year from now for example. This allows that to happen within a standard RHEL4 installation without requiring the the default system compiler moved to a newer version.

You can install the two GCC packages at the same time. Typing 'gcc' will get you gcc-3.4.3 and typing 'gcc4' will get you gcc-4.0.0.

Because you have to type 'gcc4' to get the new compiler I doubt anybody innocent enough to make the kind of mistake you predict is likely even to find gcc4. Your standard Makefile will be looking for 'gcc' and find gcc-3.4.3 for example (or nothing if the standard 'gcc' is not installed).

As for alienation, I would like to point out that RHEL4 includes compatibility libraries for 2.96 so even that past decision should not cause any problems for current RH customers.

RH makes their share of mistakes. I am glad to see them admit to some of them now. I am glad that the community works to actively keep RH and the other vendors in line. I do not think that we are served however by projecting a cloud over the company or whipping up negative hype for no reason.

Fedora Core 4 Test 1 slips [GCC 4 status]

dang — Thu, 24 Feb 2005 01:28:02 +0000

What Redhat lets you do by provide both compilers is run your production stuff on the known sane compiler, and play in your development sandbox with the new compiler ( with the idea that RHEL5 will ship with the new one and, gee wouldn't it be nice to see where the surprises are ).

I'm not sure why this is such a bad thing.

Fedora Core 4 Test 1 slips

simosx — Thu, 24 Feb 2005 00:52:13 +0000

So what?

Red Hat is testing with Red Hat Enterprise Linux 4 so that Fedora Core 4 users do not get surprises.

GCC 4 Preview in RHEL 4

dowdle — Thu, 24 Feb 2005 00:42:48 +0000

Ok, Red Hat has two versions of GCC included with RHEL 4:

1) gcc-3.4.3-9.EL4
and
2) gcc4-4.0.0-0.14.EL4

The package summary for the later is described as, "Preview of GCC version 4.0".

What's so wrong with that?

You have to remember that Red Hat includes Cygnus... which is the core of the gcc development team. Perhaps I'm overstating that but I don't think I am. My point is that Red Hat should know what they are doing with regards to building and shipping gcc.

A couple of years ago there was a big stink because a new release of Red Hat Linux shipped with a brand new GCC... which many people felt was premature... and that particular version lacked backwards binary compatibility of C++. It was touted at the time as some conspiracy by Red Hat to break binary compatibility with other people's C++ packages. Wasn't really that big of a deal. I imagine that is why Bill mentioned that the ABI is compatable for C and C++ in the upcoming gcc 4.

I'm not a developer nor do I play one on TV.

Fedora Core 4 Test 1 slips [GCC 4 status]

amacater — Thu, 24 Feb 2005 00:27:18 +0000

Fedora Core may not be stupid enough to ship a pre-release GCC - but
Red Hat Enterprise Linux 4 does. gcc.gnu.org describe the GCC 4.0 branch
as being in stage 3 (bugfixes only) prior to release "early in 2005" or
some such. Snapshots out of CVS are available for the brave. RHEL 4 ships
gcc4 - rpm is gcc4-0-0-0.14.EL4 (and the accompanying g++/fortran etc.)
Running gcc4 --version reveals it to be gcc4 (GCC) 4.0.0 20041214 (Red Hat
4.0.0-0.14 EL4) Copyright (C) 2004 Free Software Foundation, Inc.
The default gcc is gcc 3.4.3 - gcc-3.4.3-9.EL4 - and gcc --version gives gcc
(GCC) 3.4.3 20041212 (Red Hat 3.4.3-9-EL4) This sort of thing may well come
back to bite people, particularly since gcc 3.4.3 was released 2004-11-04
and I could understand people saying "I used the latest version ..."
I stand by my comments earlier in the week that Red Hat inadvertently
alienated many of their best potential customers by handling developers and
end users badly - this flagship corporate release may alienate their current
high paying customers as well. [RH EL4 for i386 - will check amd64 soonest]