From: Les Mikesell lesmikesell@gmail.com

Yes, but... whose choice was it to ship 2.6 with lots of broken and omitted stuff when 2.4 works better for many things?

Again, 2-2-2, 6-6-6

At some point, Red Hat has to start the new series for "early adopters." That means being the first to adopt the new GLibC, GCC, kernel, etc... Looking at just the GLibC 2+ generations (post-LibC4/5)...

EL0 series: GLibC 2.0, GCC 2.8.1.1, kernel 2.0 EL1 series: GLibC 2.1, GCC 2.91.66 (EGCS 1.1.2), kernel 2.2 EL2 series: GLibC 2.2, GCC 2.96, kernel 2.4 EL3 series: GLibC 2.3, GCC 3.2, kernel 2.4 EL4 series: GLibC 2.4, GCC 3.4, kernel 2.6

In each 2-4 "Community Linux" revisions of those "Enterprise Linux" series, Red Hat minimizes changes. Typically the .0 can go through a number of refinements from .0 to .1, but then they taper off in preparation for the .2 and 18 month EL series.

But even what I call CL4.0 (Fedora Core 2) wasn't nearly as much of a shift as CL0.0 (Red Hat Linux 5.0), and still a bit better than CL2.0 (Red Hat Linux 7[.0]). One of my only complaint starting with Red Hat Linux 9 (_well_before_ Fedora Core) is the lack of revisions to warn us of ".0" like shifts.

Just because a developer writes some code and tacks on a higher version number doesn't mean it's ready for prime time.

Correct. I never said so and I have been _very_critical_ of Red Hat no longer using revisions to tell us that its either a major shift (.0) or an evolutionary update (.1, .2, etc...). And this was _before_ evne Fedora Core.

Red Hat should have called Red Hat Linux 9 as Red Hat Linux 8.1. Yes, they added NTPL, but there have always been a few changes from a .0 to a .1 as things are more finalized. Every .0 revision has made some poor considerations in a few regards, and after the "early adopters" start using it, they are exposed.

The reality is that most things are _not_ exposed _until_ people actually start using things. Even Red Hat Linux 7[.0] was regression tested to the anal power with GCC 2.96 and its ANSI C++ requirement, and it wasn't until after Red Hat released it that the projects that weren't writing ANSI C++ compliant software took note.

People like to throw up the fact that Red Hat included GCC 2.91.66 (EGCS 1.1.2) for kernel building and that's why they should have gone with GCC 2.96, but I will return point out that many distros were shipping GCC 2.95 as well, and GCC 2.95 had a lot of issues with various software too.

Well, an occasional rant is therapeutic - or at least cheaper than smashing the equipment that no longer works after you upgrade the software.

Constructive rants are good. They identify real technical issues. But "brand name" rants are typically full of ignorance, blaming companies for things outside their control, or outside their focus (e.g., features on a SLA-centric distro). Again, I think it's good to see projects like CentOS, but that doesn't mean you have to complain about Red Hat on things that are not Red Hat's doing or focus.

The principles of configuration management are universal, and one must be wary of any new version, regardless of where it comes from. In the past, Red Hat made this very easy with revisions. With RHL9+, I think Red Hat really needs to bring them back.

I'm questioning the sensibility of shipping a kernel in what should be an upgrade

If Red Hat doesn't do it, another distro will. And then that distro can be chastized by people like yourself instead of Red Hat, and Red Hat will benefit from being on the trail that other distro's issues.

I purposely kept my CL3.2 (Fedora Core 1) systems well after CL4.0 (Fedora Core 2) came out, and didn't upgrade until CL4.1 (Fedora Core 3) was released. I did the same of CL2.3 (Red Hat Linux 7.3) until CL3.1 (Red Hat Linux 9) came out, CL1.2 (Red Hat Linux 6.2) until CL2.1 (Red Hat Linux 7.1), etc...

It's best to wait on a new distro series until 1 year after it first starts development, typically 6 months after it's first revision's release. Fedora Core 2 was _very_stable_, but it was _very_incompatible_ with many things because of its changes. Those compatibility issues will _not_ get resolved until someone finally releases an "early adopter" release and people then start throwing things at it.

Heck, even SuSE does this too. And SuSE even came out with their Linux 2.6-based enterprise distro much sooner than Red Hat. So you could easily "double" your chastizing of Red Hat towards SuSE in the same regard. At some point, Red Hat has to "give up" further development on Linux 2.4, or anything else, and "move on." There's nothing stopping you from delaying your adoption for 6+ months, or even 36+ months (in the case of RHEL/CentOS).

I've had this argument over and over with people -- not just Linux. You can't always blame vendors for your own professional negligence. Sometimes vendors just ship what consumers want, even when they tell them "we don't recommend this." A perfect example was Windows 95/98/Me -- something I _never_ allowed on my networks (only Windows NT 3.1, 3.50, 3.51, 4.0 and 2000). And that means you don't just go off and upgrade when the vendors says "we've changed all the core stuff" which is a definite sign that things might break.

Your option is always that you can stick with the older release. Again, 6+ months for Fedora Core today, 36+ months for RHEL/ CentOS.

with many things that don't work at all that worked in the previous version.

Of course not! That's what change does! ;->

Red Hat release 2-4 revisions every 6 months before changing things up. SuSE does much of the same as well, and more distros are moving to this model too. Things break, but the idea is to maintain 2-4 revisions over 12-24 months that don't. In the case of Red Hat and SuSE, they also release a distro every 18 months based on the "most mature" revision and then support that for 60+ months under a subscription model.

Otherwise, the overwhelming distros don't do such a good job, and _any_ release of theirs can dork up anything! I'd really like to find a vendor who balances "early adoption" with "anal SLA-level reliably" so well and for so long. It's the 2-2-2, 6-6-6 model that everyone, even Novell-SuSE, have adopted.

As you point out, these aren't surprises. While I hate to complain about free software, I think that user's experiences are relevant and should be reported even if they are painful.

That's fine, if you report them. But then people go beyond that and start "analyzing." And when I say "analyzing" I mean they "blame the vendor." And the illogic doesn't stop there -- they will blame Red Hat for issues with CentOS, or not realize that Red Hat really did take time, effort and extensive consideration to get it to work, and couldn't.

And not only that, but when other distros ran into the same issues.

I'm not sure I believe that in the case of CIPE, since the 1.6 version specifically addresses the changes in the 2.6 kernel and was available well before FC3 or RHEL4 releases which did not include it again.

Both FC3 and RHEL3 started with FC2. And FC2 has already been through 6 months of development and Fedora Core 3 was already entering into Test by the time CIPE 1.6 was finally available. And even then there were issues -- let alone issues with security and the lack of interest.

At some point Red Hat crosses a threshhold where they have to say it's too close to release date. There's just not enough time to not only integrate the package, but give its "due dilligence" in package test (Rawhide/Development), distro regression test (Beta/Test) and post-release resolution.

And when a package doesn't get modified to support kernel 2.6 until some 9 months after kernel 2.6 release, and still has issues, at some point, Red Hat's gotta say "this is going to cause us headaches to support."

If I were to speculate about intentions as you suggest above, I'd guess that someone at RedHat read the one negative review published about CIPE, decided it was no longer a selling point, and walked away from the integration they had done before.

And I'd say you haven't looked through Bugzilla. I don't know how many times I've seen people complain about Red Hat and then a few of them actually take the time to submit Bugzilla reports and then realize what happens. The few that do then change their tune.

Any and every major decision on EL begins with their development of CL. And that has not varied in Fedora Core since the days of Red Hat Linux 4.0 on-ward. If you want to see something change, you have to get involved. And that means taking the time to understand what you _can_ do to see things change.

It's very easy in the Red Hat Linux world. And its even easier now that Fedora Core is no longer the "product" that Red Hat Linux is, even though Red Hat Enterprise Linux has a 1:1 package relationship just like Red Hat Linux prior.

But of course I wouldn't speculate about something like that...

You don't need to. Hit Bugzilla.

There are people who like to complain from ignorance. And then there are people who like to complain from familiarity.

I typically choose to be the latter, although I'm sure I've done the former more than once too.

It's a complicated system, and it isn't immediately obvious that other distros have exactly the same problems.

Do you know how many times I hear people say that? And I just have to shake my head because it can't be categorized as anything else but ignorance?

Do you know how many times I hear someone call something a "Fedora Core 2-only issue" yet it plagues SuSE Linux 9.1, even SuSE Linux Enterprise Server (SLES) 9 and Mandrake 10.x as well? And they will actually sit there and say "it's only a Fedora Core 2 issue" no matter how many times I send them links?

Red Hat has its model and it is extremely effective. But it also means that you have to understand why the "end" of 2-2-2 and 6-6-6 is more "reliable" than the "beginning." Fedora Core 2 was the beginning. Red Hat Enterprise Linux 4 was the end. At some point, if you keep introducing latest'n greatest that still have compatibility issues, you are going to affect the quality of the end.

If you follow www.distrowatch.com for a few months you'll see that they each keep trying to improve things in different ways.

Yes, and the overwhelming majority of distros on distrowatch.com don't have a good release model, and they break all sorts of things everytime they come out with a new version -- at least in comparison to Red Hat or SuSE.

Switching distros should always be an option - that's one of the big reasons for using open source.

But sometimes people switch distros out of "brand name blame" instead of actual "technical focus." I don't know how many times I've seen people argue over 2 distros that use the _exact_same_ base! I've literally had people argue to death that APT is Deb-centric, and the RPM world doesn't have anything equivalent.

And sometimes I think people aren't "up-to-date" on different distros because they used one from years ago, and their preference more currently. As someone who deploys Debian, Fedora, Gentoo, SuSE and RHEL and SLES regularly, there's a lot of overlap.

But, in spite of what I consider an occasional bad choice,

Like CIPE I assume? At what point are you going to recognize that CIPE was really "no choice" until Fedora Core 3 was in Test?

Fedora/RH seem to be among the best and I do give the fact that they've been responsible for getting buggy software in front of a vast number of people credit for it eventually being fixed.

"Buggy"? Or "incompatible?" Big difference!

If GNU Tar is incompatible with POSIX, and someone introduces a new version or replacement program, like Star, that is, do you know how much the "ignorant majority" absolutely derail that person?

Or when LibC5 is not getting the attention it needs, has security issues, yet GLibC2 is active, solves a lot of security and compatibility issues, etc...?

Or when lack of ANSI C++ compliance hurts compatibility with future code, and GCC 3 is being finally pushed? Or when the fact that GCC 2.95 was adopted by many distros even when the GCC team said they should not and stick with GCC 2.91.66 (EGCS 1.1.2) which is proven (and the kernel uses)?

If you remember the state of free software before RH 4.0 was released you will know what I mean. I do sometimes wonder how things would have turned out if someone had built an equally easy to install CD based on freebsd first, though.

Who says it isn't and I don't also deploy FreeBSD and NetBSD? [ If you own the book "Samba Unleashed," you might open up the Appendix on BSD UNIX and see someone's name you recognize. ;-]

Hmmm, just who would you blame for WindowsME?

Oh, that was Microsoft.

Although oeople professionally negligent enough to ever allow _any_ "Chicago" release on their network were the start of the issue. Windows Me was Microsoft's attempt to get their own application developers to stop using "Chicago" interfaces. The result was that they created a release that was both incompatible and unreliable.

As I always said about Windows, you had your choice between incompatible (NT) and unreliable ("Chicago"). I choose the former, and I was in the minority. But I didn't have 98% of the problems other people had.

Who would you blame for the upgrade that made interfaces not start if the hardware address in the configs didn't match the NIC? That was bad news for my remote machines where all the drives had been cloned and the IP addresses set before shipping.

I'd blame you because you cloned, not installed. ;-> You can't blame Red Hat for an install approach they don't test for.

[ BTW, Ethernet hardware addresses are used in IPv6. ]

I'm not positive about this, but I think it happened at about the same time across Fedora/RH/Centos updates instead of following the scenario you mentioned for testing things that are supposed to change behavior.

What version? I can tell you exactly if it was a major or minor change.

.0 always changes stuff. Sometimes .1 changes a few things that didn't make it or needed to be addressed. .2 rarely does, as well as the "enterprise" release.

-- Bryan J. Smith mailto:b.j.smith@ieee.org