On Tue, 2005-05-24 at 18:43 -0600, Collins Richey wrote: > I'm sure other releases had the same problem, but it doesn't warm the > cockles of my heart that RedHat settled on a very early 2.6 release. ??? They waited several months beyond Rawhide and Test before release, no different than any release before -- especially a ".0" release. > 2.6 was cleaner than even numbered kernels in the past, but even so > that's way too early, Actually, kernel 2.6.5 was the first "mainstream compatible" release IMHO. I had helped people who had Debian systems and had run from 2.6.0 + on-ward, and 2.6.5 was really the first one that "came together." Red Hat updated to 2.6.7 and 2.6.8.1 fairly soon too. > unless you have a paraallel effort to reintegrate the kernel when more > things have been fixed. I'm not a CIPE user, but I can certainly > understand the gripes. The issue wasn't the kernel, it was CIPE being modified to support the new kernel, not vice-versa. It didn't matter when Red Hat adopted the 2.6 kernel, period. > Yep, when you (by means of your choices) break lots of things, people > will gripe. And I believe RedHat justifiably has a reputation for > pushing not-quite-cooked software into a production release (whether > you call it .0 or not). I disagree. Both GLibC 2.0 and GCC 2.96 were very, very ready. The problem was that they _broke_ backward compatibility. LibC 4 and 5 were forks from the old GLibC 1, and there were a lot of security issues as well as little management/development. Getting back to GLibC with 2.0 brought massive improvements in many areas. Same deal for finally forcing, what would become, the "GCC 2.96" issue. GCC 2's C++ implementation was not ANSI compliant. And in reality, GCC 2.9x was supposed to be "beta" but because GCC 3 took so long, people adopted GCC 2.91.66 (EGCS 1.1.2, which was at least proven), and even worse, GCC 2.95.x which really caused some issues. "Not-quite-cooked"? There has to be a "first" and that company gets all the blame for addressing all the problems that people are going to deal with sooner or later. > That's just semantics. If you base your release on an unproven kernel > release, you get to take the flack when it breaks. Personally, I > expect things to break in Fedora releases because it's the labrat > environment for the enterprise releases. And so was Red Hat Linux before it. But that's why the README on _any_ Red Hat Linux x.0 CD used to say "DO NOT USE THIS ON PRODUCTION SYSTEMS!" Go look, that's what they did, and always did. You avoid .0, adopt .1, upgrade to .2 for longer-term support. FreeBSD has a very similar model on ".0" being the "TEST" version. It's not unique to Red Hat. > More problematic for me (and CIPE users) is the decision in the latest > enterprise releases to drop support for quite a few functions that > people (rightly or wrongly) have come to rely on - CIPE, LVM, XFS > filesystem, Reiserfs filesystem, etc., etc. I'm not getting into this. Red Hat has to support what they ship. Other distros might not care, but that's what Red Hat does. That's their focus -- they support anything they ship, and that means not shipping things they don't feel they can support. ReiserFS wasn't supported by Red Hat for very damn good reasons early on. Red Hat is typically the preferred distro for high-throughput NFS networks for a reason, and ReiserFS' long issues with lack of legacy inode compatibility was why even SuSE told me not to use it for my applications back in 2000. As far as XFS, I wish they would, agreed. > I don't have the full > picture, but there's some kind of a problem with the versioning of > OpenLDAP/OpenSSL in REHL4=CentOS4. That's something my firm has to > sort out before moving off RH9 with LDAP authentication. And of course > there's the brand spanking new LVM2 which came out without support for > extending a filesystem. That, too, is a major sticking point for our > RH9 systems deployed with LVM (working flawlessly on RH9). Again, these are _not_ Red Hat issues, but largely kernel 2.6 issues (e.g., LVM2) -- or other package issues. In fact, Red Hat has really tried to buy out companies and take control of some of the GPL work on these capabilities (largely to make them more consistent, as well as keep them GPL). You are blaming Red Hat for all sorts of things that Red Hat cannot be blamed for any more than any other distro. In fact, because Red Hat does buy out these companies to try to take "better control" of these projects, they should be commended, not chastized. > It makes you wonder: does RedHat ever solicit input from its customer > base before making these left turns? Wouldn't you as a paying customer > expect something better? I could expect this type behavior from a > non-commercial distro. We the public always gripe when M$ leaves users > behind with a new non-compatible Winxx or M$Office release, but does > Linux really have a better track record? Who do you think always helped develop Red Hat Linux? The community! I think you're just lashing out at Linux in general here, and not Red Hat. You are just using Red Hat as an example -- and from quite an ignorant standpoint I might add. > I give heartfelt thanks to the CentOS developers who are trying to > plug some of the holes. And I do too. But don't forget that much of CentOS is built on the shoulders of Red Hat. -- Bryan J. Smith b.j.smith at ieee.org --------------------------------------------------------------------- It is mathematically impossible for someone who makes more than you to be anything but richer than you. Any tax rate that penalizes them will also penalize you similarly (to those below you, and then below them). Linear algebra, let alone differential calculus or even ele- mentary concepts of limits, is mutually exclusive with US journalism. So forget even attempting to explain how tax cuts work. ;->