Re: [CentOS] Re: Hi, Bryan; was: Re: pronunciation? <snip> -- don't shoot the messenger ...
From: Dag Wieers
Sorry to interrupt but he was describing how you appeared in previous postings. And I have to say that I felt the same way reading some of
your postings.
Really? Then I'll re-read them since there's been a second confirmation.
Just know that I wasn't trying to make it about good/bad. I'm just trying to make the point that companies aren't just evil/greedy, and sometimes your friend can be your worse enemy (even SCO knows that one ;-).
Maybe it's best to move these topics to another channel.
I just wish people didn't feel the need to make comments about Red Hat and SCO.
Can we leave the insults out, please ? It serves no purpose here.
Sorry. I'm just still a little disturbed about the "crap" statement, and everything that went with it. I find that many people just don't believe me sometimes.
On Sat, 2005-05-21 at 20:58 -0500, Bryan J. Smith wrote:
From: Dag Wieers
Sorry to interrupt but he was describing how you appeared in previous postings. And I have to say that I felt the same way reading some of
your postings.
Really? Then I'll re-read them since there's been a second confirmation.
Just know that I wasn't trying to make it about good/bad. I'm just trying to make the point that companies aren't just evil/greedy, and sometimes your friend can be your worse enemy (even SCO knows that one ;-).
Maybe it's best to move these topics to another channel.
I just wish people didn't feel the need to make comments about Red Hat and SCO.
The SCO that exists currently ... the one that is suing IBM right now, in the lawsuit as it currently exists, is an enemy to all Linux, IBM and Red Hat customers. That is absolutely clear. I would call them a bad company. Were they always that, no. Did IBM screw some people in the past, yes. Will they again in the future, probably. Same is true for Sun, Red Hat, Novell, SuSE, Mandr(ake/riva), etc.
Red Hat made a business decision that left many people out in the cold (the RHL / RHEL line decision) ... CentOS fills that gap. Some CentOS users are very upset with Red Hat because of that decision. That does not make them shallow, they have the right to their opinion. It also does not change the fact that Red Hat is also the best when it comes to distributing their source code (of all the major enterprise providers).
I personally don't have a problem with the Red Hat business decision ... but I understand why some people do.
Fedora Core just doesn't do it for me ... if it works for you, great. There is nothing wrong with FC, it just doesn't have the lifetime support I am looking for.
CentOS, on the other hand, has exactly the options I am looking for. A vibrant community that actively answers questions via IRC, forums and active mailing lists. It is available for free (though donations SHOULD be made ... especially if you are using CentOS to make money), has rapid security updates, and it has a long lifetime. So, this is while you will find me for quite some time.
On Sat, 2005-05-21 at 21:28 -0500, Johnny Hughes wrote:
The SCO that exists currently ... the one that is suing IBM right now, in the lawsuit as it currently exists, is an enemy to all Linux, IBM and Red Hat customers.
You need to separate the SCO v. IBM aspects from the SCO "smokescreen." The original March 2003 filing was not about Linux, but a "contract dispute." Not my words, but those of Linus, ESR and many others.
But because people took rabid offense to the wording in that lawsuit, wording that was required to make the case on the "Non-Compete" clause in Monterey, the media took it and made it about Linux. So it didn't surprise me when IBM didn't settle that SCO expanded it in May 2003 to include the whole "smokescreen" of Linux IP.
Let the SCO lawsuits against its contractual partners like IBM, Autozone, Chrysler and the like go. Don't bring them on this list, and just act like SCO doesn't exist. Don't add to the rabid environment that has people believing SCO v. IBM is SCO v. Linux.
It never was and every motion and every item SCO tries to introduce that isn't about Monterey, including the Non-Compete, is being shot down. At the same time, SCO is getting motions granted on the Monterey and Non- Compete considerations. So if SCO does finally win on a few counts, it's important that people know they had _nothing_ to do with IP in Linux, and _everything_ to do with IBM's contractual obligations with SCO.
Again, don't make IBM's fight with SCO our fight.
That is absolutely clear. I would call them a bad company. Were they always that, no. Did IBM screw some people in the past, yes.
IBM screwed a very _good_, pro-GPL Linux partner in Caldera-SCO. Why? Because it could. It saw them as a competitor with a similar strategy.
It's doing the same of HP and Sun. Why? Because it can.
I'm not saying IBM is "bad." I'm just saying that you do _not_ want to defense or demonize companies engaged with IBM. In fact, had some in the Linux community not gone so "rabid" on the March 2003 filing, SCO might have not been able to put up the current "smokescreen" on Linux IP.
Red Hat made a business decision that left many people out in the cold (the RHL / RHEL line decision) ... CentOS fills that gap. Some CentOS users are very upset with Red Hat because of that decision. That does not make them shallow, they have the right to their opinion.
When did I say they were shallow?!?!?! Now you're just demonizing anything I say!
I said people who take what I say and say I call company X "bad" and company Y "good" are shallow. Get off the comments about companies and just leave them be! There are long, involved details to the actions of many companies -- and you can't demonize one company without looking at the actions of another.
IBM is no different today then they were before. They just have an equal interest, for now. Unfortunately, some companies with far better, pro-GPL histories have been backed into a corner by IBM. And more are currently in the making right now.
I just wish people could not make non-technical, political statements on this list. Appreciate CentOS for what it is, without feeling the need to make snide comments. That's all.
The SCO that exists currently ... the one that is suing IBM right now, in the lawsuit as it currently exists, is an enemy to all Linux, IBM and Red Hat customers. That is absolutely clear. I would call them a bad company. Were they always that, no. Did IBM screw some people in the past, yes. Will they again in the future, probably. Same is true for Sun, Red Hat, Novell, SuSE, Mandr(ake/riva), etc.
I still remember the FIRST Linux GUI installer for a Linux distro. It came on the Caldera Openlinux 2.2. It worked. It was really nice.
The Novell guys that were behind Caldera deserve plenty of respect for what they have done.
I think, today's SCO bashing should really go to the current owner of SCO and to IBM. IBM for what they did and the guy who put McBride in place to do the stock game.
Red Hat made a business decision that left many people out in the cold (the RHL / RHEL line decision) ... CentOS fills that gap. Some CentOS users are very upset with Red Hat because of that decision. That does not make them shallow, they have the right to their opinion. It also does not change the fact that Red Hat is also the best when it comes to distributing their source code (of all the major enterprise providers).
I really don't understand why some people get so uptight about it. I look after over 30 machines and I have had no problems moving on to Fedora Core 1 and Fedora Core 2. In fact, I like their Fedora project more than their RHL line.
I personally don't have a problem with the Red Hat business decision ... but I understand why some people do.
Fedora Core just doesn't do it for me ... if it works for you, great. There is nothing wrong with FC, it just doesn't have the lifetime support I am looking for.
That lifetime support you are looking at is far less than 2 years I can assure you.
CentOS, on the other hand, has exactly the options I am looking for. A vibrant community that actively answers questions via IRC, forums and active mailing lists. It is available for free (though donations SHOULD be made ... especially if you are using CentOS to make money), has rapid security updates, and it has a long lifetime. So, this is while you will find me for quite some time.
CentOS offers the free and the long lifetime. I personally don't care too much since the advantages on newer Fedora Cores outweigh a 'supported' but static distro. However, others may not see it that way and so it is good that CentOS is here. At the same time, I find it offensive when people starting saying 'Dead Rat' just because the RHL line was pulled and they forget all the work that Redhat puts into the Linux kernel, gcc, glibc and a host of others that are at the core of any Linux distribution.
On 5/23/05, Feizhou feizhou@graffiti.net wrote:
The SCO that exists currently ... the one that is suing IBM right now, in the lawsuit as it currently exists, is an enemy to all Linux, IBM and Red Hat customers. That is absolutely clear. I would call them a bad company. Were they always that, no. Did IBM screw some people in the past, yes. Will they again in the future, probably. Same is true for Sun, Red Hat, Novell, SuSE, Mandr(ake/riva), etc.
I still remember the FIRST Linux GUI installer for a Linux distro. It came on the Caldera Openlinux 2.2. It worked. It was really nice.
I am pretty sure that parts of RH 3.0.3 installation was GUI based as well, as long as you had a supported graphics card..
/Mike
On Mon, 2005-05-23 at 09:53, Feizhou wrote:
I really don't understand why some people get so uptight about it. I look after over 30 machines and I have had no problems moving on to Fedora Core 1 and Fedora Core 2. In fact, I like their Fedora project more than their RHL line.
I take it you didn't run CIPE vpn's among any of those 30 machines or you'd still be on FC1.
Les Mikesell wrote:
On Mon, 2005-05-23 at 09:53, Feizhou wrote:
I really don't understand why some people get so uptight about it. I look after over 30 machines and I have had no problems moving on to Fedora Core 1 and Fedora Core 2. In fact, I like their Fedora project more than their RHL line.
I take it you didn't run CIPE vpn's among any of those 30 machines or you'd still be on FC1.
No, I have no need as yet to run an ipsec vpn.
In any case, we validate the software we run before we move to a new distro. So if we were to encounter problems, we'd get in touch with Redhat. We have found them very helpful in such cases and they get back to us pretty quick.
On Mon, 2005-05-23 at 11:38 -0500, Les Mikesell wrote:
I take it you didn't run CIPE vpn's among any of those 30 machines or you'd still be on FC1.
Actually, Fedora Core 2 wasn't the only distro that dropped it. There were a lot of issues with CIPE and kernel 2.6 -- many that were not solved in the first 6 months of 2.6's release, by the time Fedora Core 2 came out. The first half-way reliable patches were for 2.6.6, which was a month after about Fedora Core 2 came out (with 2.6.5).
Remember, even though Red Hat doesn't revision anymore on Fedora Core, they still make somewhat of a .0-.1 and sometimes .2 revisionary approach. Fedora Core 1 was really an "evolutionary" .2 from Red Hat Linux 8.0 and 9, which were basically .0 and .1 releases. I personally wish Red Hat would go back to revisions to "warn" people of changes**, but that doesn't seem to be happening.
Fedora Core 2 was definitely a "revolutionary" .0, and things break, and Fedora Core 3 was more of an "evolutionary" .1 based on changes done in Fedora Core 2. So what you're seeing is _no_different_ than typical Red Hat Linux .0 release before. People today are still bitching about the GLibC 2.0 change of Red Hat Linux 5.0, and the forced ANSI C++ compliance with the adoption of GCC 2.96/3.0 in Red Hat Linux 7.
Don't shoot the messenger, Red Hat deals with a lot of things on the "cutting edge" when they come out with .0 type revisions that change a lot. That's why they used to designate them as .0 and Red Hat almost _always_ says "don't use this on a production system" in a .0 release (and has since Red Hat Linux 5.0 I believe).
Like adopting kernel 2.6, which Fedora Core 2 did. I still haven't seen a so-called "Fedora Core 2-only" problem. It's typically been kernel 2.6, SELinux (although much was scaled back for Fedora Core 2, and not enabled until Fedora Core 3), Parted, GRUB, etc... In fact, Fedora Core actually had fewer problems with some distros because of changes -- like not putting suid root on cdrecord, which other distros did run into as of kernel 2.6.8 (long story).
**NOTE: I would have revisioned the releases as follows:
Fedora Core 1 -> Fedora Core 3.2 Fedora Core 2 -> Fedora Core 4.0 Fedora Core 3 -> Fedora Core 4.1 Fedora Core 4 -> Fedora Core 5.0
On Mon, 2005-05-23 at 22:41, Bryan J. Smith wrote:
On Mon, 2005-05-23 at 11:38 -0500, Les Mikesell wrote:
I take it you didn't run CIPE vpn's among any of those 30 machines or you'd still be on FC1.
Actually, Fedora Core 2 wasn't the only distro that dropped it. There were a lot of issues with CIPE and kernel 2.6 -- many that were not solved in the first 6 months of 2.6's release, by the time Fedora Core 2 came out. The first half-way reliable patches were for 2.6.6, which was a month after about Fedora Core 2 came out (with 2.6.5).
Yes, I know the history - I just have a knee-jerk reaction when someone says they upgrade frequently and never have problems. It really just means they weren't using any of the features that changed or went away.
Fedora Core 2 was definitely a "revolutionary" .0, and things break, and Fedora Core 3 was more of an "evolutionary" .1 based on changes done in Fedora Core 2. So what you're seeing is _no_different_ than typical Red Hat Linux .0 release before. People today are still bitching about the GLibC 2.0 change of Red Hat Linux 5.0, and the forced ANSI C++ compliance with the adoption of GCC 2.96/3.0 in Red Hat Linux 7.
Except that it still isn't fixed now that it easily could be. If you want CIPE in Fedora >1 or Centos 4, you have to recompile the kernel to make it work. OpenVPN is probably better these days but that's not included either and unlike a lot of other packages, for this one you have to coordinate any changes across locations.
Les Mikesell wrote:
On Mon, 2005-05-23 at 22:41, Bryan J. Smith wrote:
On Mon, 2005-05-23 at 11:38 -0500, Les Mikesell wrote:
I take it you didn't run CIPE vpn's among any of those 30 machines or you'd still be on FC1.
Actually, Fedora Core 2 wasn't the only distro that dropped it. There were a lot of issues with CIPE and kernel 2.6 -- many that were not solved in the first 6 months of 2.6's release, by the time Fedora Core 2 came out. The first half-way reliable patches were for 2.6.6, which was a month after about Fedora Core 2 came out (with 2.6.5).
Yes, I know the history - I just have a knee-jerk reaction when someone says they upgrade frequently and never have problems. It really just means they weren't using any of the features that changed or went away.
:)
Yeah, I personally don't mind the frequent upgrades but others on my team and my manager go bonkers with this sort of thing. So it looks like I will have to move to CentOS 4 for the said 30 and more machines.
Either way, tweaking is needed so I don't see the point of staying on CentOS 4. The kernel needs to be recompiled for XFS support and that means a recompile for every errata kernel release. ext3 + dir_index support is still too heavy although I don't relish a crash on XFS either.
Fedora Core 2 was definitely a "revolutionary" .0, and things break, and Fedora Core 3 was more of an "evolutionary" .1 based on changes done in Fedora Core 2. So what you're seeing is _no_different_ than typical Red Hat Linux .0 release before. People today are still bitching about the GLibC 2.0 change of Red Hat Linux 5.0, and the forced ANSI C++ compliance with the adoption of GCC 2.96/3.0 in Red Hat Linux 7.
Except that it still isn't fixed now that it easily could be. If you want CIPE in Fedora >1 or Centos 4, you have to recompile the kernel to make it work. OpenVPN is probably better these days but that's not included either and unlike a lot of other packages, for this one you have to coordinate any changes across locations.
I guess this means CIPE has not made it to the mainline kernel. With Fedora, Redhat does less patches and pushes more upstream.
On Tue, 2005-05-24 at 14:15 +0800, Feizhou wrote: <snip>
So it looks like I will have to move to CentOS 4 for the said 30 and more machines.
Please do :)
Either way, tweaking is needed so I don't see the point of staying on CentOS 4. The kernel needs to be recompiled for XFS support and that means a recompile for every errata kernel release. ext3 + dir_index support is still too heavy although I don't relish a crash on XFS either.
The kernel in the centosplus repo has XFS, NTFS, ReiserFS, JFS support ... the tools for XFS, JFS, ReiserFS are also in the centosplus repo. These will be maintained.
Except that it still isn't fixed now that it easily could be. If you want CIPE in Fedora >1 or Centos 4, you have to recompile the kernel to make it work. OpenVPN is probably better these days but that's not included either and unlike a lot of other packages, for this one you have to coordinate any changes across locations.
What needs to be enabled in the kernel for CIPE to work. Maybe I already did it .. or can do it on the next version of te kernel in the centosplus repo.
Either way, tweaking is needed so I don't see the point of staying on CentOS 4. The kernel needs to be recompiled for XFS support and that means a recompile for every errata kernel release. ext3 + dir_index support is still too heavy although I don't relish a crash on XFS either.
The kernel in the centosplus repo has XFS, NTFS, ReiserFS, JFS support ... the tools for XFS, JFS, ReiserFS are also in the centosplus repo. These will be maintained.
I guess that is good news for my team to hear.
On Tue, 2005-05-24 at 11:04, Johnny Hughes wrote:
What needs to be enabled in the kernel for CIPE to work. Maybe I already did it .. or can do it on the next version of te kernel in the centosplus repo.
According to: http://sites.inka.de/bigred/archive/cipe-l/2004-12/msg00011.html "Compile kernel with 'config REGPARM = disabled' (if not you got a kernel panic on VPN connection)"
Then the 1.6 version could probably be RPM-packaged again.
On Mon, 2005-05-23 at 23:53 -0500, Les Mikesell wrote:
Yes, I know the history - I just have a knee-jerk reaction when someone says they upgrade frequently and never have problems. It really just means they weren't using any of the features that changed or went away.
And I understand that.
Unfortunately, to me, that comes off as applying a double-standard. A lot of things people are complaining about with Fedora Core were the same complains with Red Hat Linux prior.
Except that it still isn't fixed now that it easily could be. If you want CIPE in Fedora >1 or Centos 4, you have to recompile the kernel to make it work.
Do you know how many things are changed in Linux 2.6 and, therefore, break things? Again, not applicable because they affect more than just Fedora Core 2.
Ahem, e.g. (first Google hit -- I could probably find a better one, I watched the SuSE Linux 9.1 development as well as Fedora Core 2):
http://cert.uni-stuttgart.de/archive/suse/security/2004/11/msg00041.html
SuSE Linux 9.1 switched to kernel 2.6, and had the same problems. A compatible CIPE version did not come out until after it had been released as well.
OpenVPN is probably better these days but that's not included either and unlike a lot of other packages, for this one you have to coordinate any changes across locations.
We could argue "what's included" until we're blue in the face. The reality is that Red Hat, SuSE and most distros maintain lineage as best as the can, and they don't drop something unless it's not supported or a "Really Bad Idea."
It looks like Red Hat tried to make CIPE work as best as it could on all kernels leading up to the release with 2.6.5, but after other people had the same issues, it really wasn't worth the bother considering all the security issues it had as well. I'm sure that's what finally broke the Camel's back.
Many times Red Hat has dropped something to offer it again later. But I do think they need to warn us when they change a lot of things. E.g., UW IMAP got replaced with Dovecot, but man was it ultra-buggy really until Fedora Core 3 was in test (I just built the latest UW IMAP). A little ".0" would have helped warn us of all the massive changes from Fedora Core 2.
Luckily I saw the ABI change (GCC and GLibC) as well as kernel, and treated it exactly like a new version, .0 revision, and held off.
On 5/23/05, Bryan J. Smith b.j.smith@ieee.org wrote:
[ snips ]
On Mon, 2005-05-23 at 11:38 -0500, Les Mikesell wrote:
I take it you didn't run CIPE vpn's among any of those 30 machines or you'd still be on FC1.
Actually, Fedora Core 2 wasn't the only distro that dropped it. There were a lot of issues with CIPE and kernel 2.6 -- many that were not solved in the first 6 months of 2.6's release, by the time Fedora Core 2 came out. The first half-way reliable patches were for 2.6.6, which was a month after about Fedora Core 2 came out (with 2.6.5).
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. 2.6 was cleaner than even numbered kernels in the past, but even so that's way too early, 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.
People today are still bitching about the GLibC 2.0 change of Red Hat Linux 5.0, and the forced ANSI C++ compliance with the adoption of GCC 2.96/3.0 in Red Hat Linux 7.
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).
Like adopting kernel 2.6, which Fedora Core 2 did. I still haven't seen a so-called "Fedora Core 2-only" problem. It's typically been kernel 2.6,,,
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.
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 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).
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?
I give heartfelt thanks to the CentOS developers who are trying to plug some of the holes.
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.
On Tue, 2005-05-24 at 20:15 -0500, Bryan J. Smith wrote:
"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.
This is the last time I'm ever going to explain this.
If you want to wallow in ignorance, not stop to understand how software lifecycle works, but feel the need to bash Red Hat like you're an expert, then I just don't know what to tell you other than such marketing non-sense is what I already hate about the Windows world.
Since Red Hat Linux 4.0 (some things weren't quite formalized until about 5.x), Red Hat has pretty much has a 2-2-2, 6-6-6 release model. What is that?
2 Months New Development -- formulating packages, etc... 2 Months Rawhide -- _individual_ package testing + 2 Months Beta -- regression testing _all_ packages as a whole unit =========================== 6 Month Revision Release
6 Revision .0 "Early Adopter" (non-production) 6 Revision .1 "First Production" + 6 Revision .2 "Mature Production" =========================== 18 Month Stable Release
Well before Red Hat Enterprise Linux, this is what Red Hat done. They even offered SLAs on Red Hat Linux 6.2 and called it 6.2"E". Now sometimes there have been 4 revisionary releases (e.g., RHL7-RHL7.3).
But this hasn't really changed since, and Red Hat still has 2-2-2 Fedora New-Development-Test (instead of New-Rawhide-Beta). Then after 2-3 Fedora Core releases, Red Hat comes out with its next Enterprise Linux release. No different than before.
Without the 2-2-2 and 6-6-6, you do _not_ get people testing packages, testing packages as a distro, figuring out compatibility issues with any changes, accommodating those changes and eventually making it into the 18 Month "Stable" Release. Someone has to force the adoption of GLibC 2, GCC 3, SELinux, etc..., and that has been Red Hat.
So you can't demonize the development model without realizing how it directly affects the quality of Enterprise Linux. It's also why if Fedora's quality suffers, so will that of RHEL.
But Red Hat cannot dictate the will on the community. Yes, they fund a lot of developers, and solve a lot of problems. E.g., when people were bitching about Qt-KDE, Red Hat helped GNOME. Just recently, the whole Java JRE requirement in OpenOffice.org 2.0 has been blown out of proportion, but Red Hat helped put the people on GCJ to work towards solving it -- instead of just arguing.
Sistina was going to close up LVM/LVM2 and not release it GPL anymore. Red Hat bought them out to make sure it stays GPL. There have been countless other, core Linux packages where Red Hat hasn't just stood around and argued, but actually done something _for_ the community. It listens very, very, _very_ well, typically because Red Hat is really just the largest collection of GPL developers and projects itself!
To conclude, if you want something to bitch about, it's not hard to find it. But it's much harder to stop, think and appreciate what people do to make RHEL and CentOS great, enterprise-quality distros. Don't feel you need to demonize Red Hat because you like CentOS. It's not only very inconsiderate of what Red Hat does for the community, but you're only exposing your ignorance in how the quality behind RHEL/CentOS comes into being.
Just as it always has -- by the 2-2-2 and 6-6-6 model.
On 5/24/05, Bryan J. Smith b.j.smith@ieee.org wrote:
I disagree. Both GLibC 2.0 and GCC 2.96 were very, very ready. The problem was that they _broke_ backward compatibility.
Now that's circular logic. The software is ready and tested, but tough luck for all you folks who have dozens of packages that aren't ready to deal with the software that is ready!
"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.
Yep, and the "first" version should stay in the "first" oven (ie Fedora) until existing packages catch up. Just my $.02.
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.
I'm sure you're right. Currently, as the market leader, RedHat gets to pick and choose what it will support. It will be interesting to see whether the newly invigorated Novell decides to support more of the missing pieces. Competition is good.
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).
Of course they're RedHat issues. No one is forcing RedHat to release anything. Their choices turn out to be somewhat limiting for those companies/users who have development invested in the functions that are discarded. The concept that RedHat needs to own everything is moderately ridiculous! As if the only way to progress is through owenership! I commend RedHat for lots of things, but they don't get a free ride
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!
Only in the sense that what they distribute comes from the GPL base. Or do you mean something else.
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.
Not at all. I'm firmly committed to Linux, and I would love to see RedHat improve and succeed, and CentOS along with it.
BTW, in my simple opinion, you would do best to drop that habit of ascribing ignorance to anyone who happens to disagree with you. It's a demeaning habit that will only cost you in the long run.
On Tue, 2005-05-24 at 19:49 -0600, Collins Richey wrote:
Now that's circular logic. The software is ready and tested, but tough luck for all you folks who have dozens of packages that aren't ready to deal with the software that is ready!
Correct. Standards compliant is always a bitch, especially when there is a whole slew of software written for the "old way." Had we stuck with LibC5.3, we'd be several years behind now. Same deal with GCC 2.95.
Jorg is also one guy I see beat up all-the-time for making some of the most POSIX-complaint software.
Yep, and the "first" version should stay in the "first" oven (ie Fedora) until existing packages catch up. Just my $.02.
What difference does it make? .0 is an 'early adopter' release. It's not designed for production, never has been, says right in the README. By the time .1 rolls around, most things (not all) are addressed.
In some cases, somethings _never_ get addressed, but you have to move on. That's what Linus does every major release. It's not his job to stop, or any distro's for that matter, if the interest and volunteering is not there.
Just ask Linus on why he finally rolled out kernel 2.6, even though many, many drivers were not updated. A whole slew of SCSI, NIC and other drivers were deprecated because they failed to have maintainers who "got with the program" on 2.6 -- which was in development for a _long_ time.
People need to _work_together_ and actually donate time. When _no_one_ donates the time to make things work, that typically means no one has an interest.
If you're a user that does, then become a developer. You can't blame a single vendor for Linux, and even the "enterprise" releases are based on prior, community developments. Why? Economies of scale.
If you really, really, really need something for just you, and no one else in the community is addressing it, then we're not talking economies of scale. They you hire Red Hat's, Novell's, IBM's or some other vendors professional services and pay by the hour.
You don't get thousands of man-hours of development included for free with your distro if there's not much interest in the product. It's not worth the time of Red Hat, Novell, etc... What you're complaining about has to do with economies-of-scale and community interest, and not really anything commercial software can do anything about.
I'm sure you're right. Currently, as the market leader, RedHat gets to pick and choose what it will support. It will be interesting to see whether the newly invigorated Novell decides to support more of the missing pieces. Competition is good.
Red Hat and SuSE have been going back and forth for years -- SuSE first with Enterprise Server, Red Hat first with Enterprise Desktop, etc... They have very, very similar development and release models. I don't see Novell changing that.
I'm still waiting on you identifying these "missing pieces" you speak of. If you mean things you want, but no one in the Linux community actually wrote or supported for kernel 2.6, then either pay someone to do it, or volunteer.
Linux is built on the work of a community in the goal of development a commodity solution. It does not stop to work on software that only of limited interest unless that limited interest actually puts forth the effort to do so. Red Hat, SuSE, etc... aren't going to put the thousands of man-hours of development into something unless it's popular enough to do so.
So I don't see Novell-SuSE doing much beyond what Red Hat is already doing. Man, you should really go to NC and meet all the developers working on stuff that'll make you say, "Wow, I didn't know Red Hat paid the salaries of developers on X, Y and Z!"
Of course they're RedHat issues. No one is forcing RedHat to release anything. Their choices turn out to be somewhat limiting for those companies/users who have development invested in the functions that are discarded.
So you feel obligated to complain about this on a technical list of a project that stands on the shoulders of Red Hat? In fact, we _all_ stand on the shoulders of each other!
But because Red Hat is -- whatever, Greedy I guess? -- the bucks supposed to stop and Red Hat and solve all problems that anyone merely wants or wishes for?
The concept that RedHat needs to own everything is moderately ridiculous!
No, not at all. When you sell a Service Level Agreement (SLA), that's _exactly_ what you are selling -- a _binding_contract_! Why can't you just "get this"? ;->
As if the only way to progress is through owenership! I commend RedHat for lots of things, but they don't get a free ride
What "free ride" do you speak of? Really, what "free ride" does Red Hat get? To you even see the hypocracy in your statement? I have to laugh! ;->
Red Hat Enterprise Linux is about shipping a product with _contractually_guaranteed_ Service Level Agreements (SLA) that a product will work, or they will make it work in X hours. Microsoft does not even offer this _except_ to "Enterprise" customers (over 20,000 nodes I believe). These are concepts that do _not_ apply outside of Red Hat, Novell-SuSE, Microsoft (but only large customers) and handful of other OS distributions.
Again, you just don't seem to "get this." ;->
You are complaining about lack of features in a distro that is designed to minimize risk and problems, because of the nature of its SLA-focus. It doesn't take a rocket scientist to realize the problem with that logic.
Only in the sense that what they distribute comes from the GPL base. Or do you mean something else.
Both that and something else. Red Hat Linux's release has always been heavily influenced by contributors. It was a little more "controlled" in the days it was treated as a "product," but that all ended well before the name change, after Red Hat Enterprise Linux appeared and was the "dedicated product" with the SLA focus.
Unless you are, and I'm sorry but, "ignorantly" assuming that Red Hat is a "leech" on the GPL community? But I assume you're not, correct?
Not at all. I'm firmly committed to Linux, and I would love to see RedHat improve and succeed, and CentOS along with it. BTW, in my simple opinion, you would do best to drop that habit of ascribing ignorance to anyone who happens to disagree with you. It's a demeaning habit that will only cost you in the long run.
But you are totally oblivious to the fact that you want your cake and want to eat it too. You want enterprise, but you want features. You don't seem to want to understand anything about how RHEL is developed, you just seem to want to complain about what you don't understand, namely Red Hat and everything the world's largest collection of GPL projects under one commercial entity entails. ;->
Red Hat has features in Fedora Core + the Fedora Project. Red Hat has enterprise, including, SLAs in RHEL. I think it's great that CentOS is trying to address many areas in- between, and there is a community behind that.
Whether you contribute to individual projects, Fedora Core or CentOS directly, you're going to help CentOS regardless. We are all working together towards a common goal, and there might be slight differences in focus. E.g., Red Hat's focus on delivering a product with SLAs.
I'll say it again, why do people feel the need to demonize Red Hat here? I left that in the Windows world, why drag it here in the Linux space? It's self-defeating!
On 5/24/05, Bryan J. Smith b.j.smith@ieee.org wrote:
I'll say it again, why do people feel the need to demonize Red Hat here? I left that in the Windows world, why drag it here in the Linux space? It's self-defeating!
I know almost no one who demonizes RedHat, certainly not on this list. You, OTOH, seem to want to canonize RedHat, and if anyone makes valid complaints that certain features are missing, you consider that bitching. I find RedHat (and by extension, of course, CentOS) to be a fine distro but not necessarily a perfect one. There is missing functionality, and not everyone in the Linux community would choose to be without that functionality.
When I've found the perfect distro, you'll be the first to hear about it. Until then I'll be running CentOS, loving most of it and hating a few things that are missing. That's life, and there's more to life than SLA's.
On Tue, 2005-05-24 at 21:30, Bryan J. Smith wrote:
Just ask Linus on why he finally rolled out kernel 2.6, even though many, many drivers were not updated. A whole slew of SCSI, NIC and other drivers were deprecated because they failed to have maintainers who "got with the program" on 2.6 -- which was in development for a _long_ time.
I'm still wondering about that... If anyone except Linus himself even suggested that changing kernel interfaces in a way that would break device drivers was a good thing, I can't imagine the reaction. I could see that the changes through 2.4 were improving things, but is there anything that is measurably better in 2.6 (at least compared to the RH-patched 2.4)? I've been too busy trying to make some firewire drives work as well as they did on FC1 to notice any other changes.
You are complaining about lack of features in a distro that is designed to minimize risk and problems, because of the nature of its SLA-focus. It doesn't take a rocket scientist to realize the problem with that logic.
Or with the logic of asking customers to pay extra to get something with features removed...
I'll say it again, why do people feel the need to demonize Red Hat here? I left that in the Windows world, why drag it here in the Linux space? It's self-defeating!
I haven't seen anyone demonizing RedHat here. I see some people reporting painful experiences, but I don't think anyone expects perfection and the best thing is to learn from them.
-
Bryan J. Smith -
Collins Richey -
Feizhou -
Johnny Hughes -
Les Mikesell -
Michael Boman