Discuss

discuss@lists.centos.org

1 participants
34730 discussions

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Les Mikesell <lesmikesell(a)gmail.com> > Thanks - as you probably know, the long-winded discussion isn't > really about CIPE specifically so much as the philosophy behind > bundling a few thousand things together and then trying to > please anyone with a blanket policy about maintaining backwards > compatibility vs bug fixes vs new features. You just can't please everyone. But it does help if people focus on "why" something is done -- the pros/cons versus doing something else -- instead of trying to assert what is "better" (as well as stopping to listen to someone and realize they are not asserting anything as "better," just trying to explain "why"). CentOS is based on RHEL. RHEL has its policies. > And while I realize that there may never be a good solution, I'll be > really happy if some new options fall out of it, like this being > included in a centos kernel-unsupported-something-or-other package. I think CentOS is optionally filling that gap between FC and RHEL quite well for those that want it. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Official CentOS CD/DVD Vendor Program
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

My $0.02 ... From: Chris Mauritz <chrism(a)imntv.com> > What's the point? Awareness, partnerships, retail notoriety and most of all, a starting point for now. You have to start somewhere. > I checked out linux cd mall. They charge $12.50 for the CD set (or DVD) > and CentOS makes ONE DOLLAR. Unless you envision tens of thousands > of people buying CDs, it hardly seems like a worthwhile endeavor I can envision that volume per year. > unless you're the CD distributor. The CD distributor has the economies-of-scale in the fact that they already have a built infrastructure, web front, relationships, etc... that CentOS can tap. For CentOS to build the same infrastructure, it would cost far more per unit sold -- at least at, again, "a starting point for now." > Why not just find a way to make it easier for people to donate directly > to the project instead of creating a needless middleman who is taking > 92% of the money for each CD/DVD set sold? Again, costs involved are relevative here. > Hell, for 92% of the profit, No, that's 92% of the _revenue_, and _not_ the "profit" (sometimes I think some Linux advocates need a refresher course in basic microeconomics ;-). There are more costs involved than just CD duplication here. > I'd be more than happy to sit at home and burn DVDs all day. And take orders? And handle shipping? And resolve issues with the site, customers, MC/VISA complaince on e-commerce, etc...? You can only do so much on your own before you need someone already doing it who can do it for much cheaper. > Where do I sign? 8-) You sign next to "I will learn how the infrastructure and operational costs of e-commerce works before I speak again." ;-> More seriously now, does everyone have to question everything around here? You don't think the management hasn't thought of these things? Why does everyone seem to believe they know better than the management who not only volunteers their time, but puts in the hours to be productive, including all the "less fun stuff" in the logistics and attention to detail? More pertinent, if you make posts like this, that are only include 5% of the actual details involved with doing such (and expose what can only be termed ignorance of the other 95%), how seriously do you think people can take your comments? I didn't. ;-ppp -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

insmod ip_conntrack_ftp
by Mickael Maddison 26 May '05

26 May '05

Hello CentOS, Is there a specific RPM that makes "insmod ip_conntrack_ftp" available? I've been using that on a number of servers fine, but the latest one I've built, running insmod ip_conntrack_ftp gives me: insmod: can't read 'ip_conntrack_ftp': No such file or directory -- Best regards, Mickael mailto:mike@kamloopsbc.com www.MickaelMaddison.com

3 3

Re: Demonizing generic Linux issues as Fedora Core-only issues -- why I hate these meta-discussions ...
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: "Bryan J. Smith <b.j.smith(a)ieee.org>" > You are indeed correct (I must have been looking at the RHEL3 dir**) First off, that's now 2 strikes for me. Small ones considering the context well outside of the points, but still it hurts my credibility. This is one of the things I hate about meta-discussions, at least how I approach them. Sometimes I just need to learn that it doesn't matter how many additional examples I give, some people aren't going to do anything but blame Red Hat. And by giving example after example, or attempting explain item after item, I'm going to eventually slip up from memory from time-to-time, which hurts my credibility -- regardless if the actual mistake was small given the context of the discussion. Sigh, there is a point where one should just resign and submit to the fact that if something doesn't work for someone, and { Microsoft, Red Hat, SuSE, even Debian as of late, etc... } is involved anywhere at all (even if it's a fork to another architecture -- e.g., anyone who has dealt with Cobalt/Sun releases, a primary reason for Red Hat's latter trademark enforcement ;-), the other person has no interest in understanding the "root" cause and will not see anyting to the contrary. My apologies for tying up the list with this non-sense. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: Demonizing generic Linux issues as Fedora Core-only issues -- MySQL 3 v. 4 linking licensing issues
by Bryan J. Smith <b.j.smith＠ieee.org> 26 May '05

26 May '05

From: Johnny Hughes <mailing-lists(a)hughesjr.com> > RHEL-4 shipped with MySQL 4.1.x (and has a 3.23.58 client to work with > older databases) ... the latest SRPMS are mysql-4.1.10a-1.RHEL4.1.src.rpm > and mysqlclient10-3.23.58-4.RHEL4.1.src.rpm. You are indeed correct (I must have been looking at the RHEL3 dir**): ftp://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/ Hmmm, that's actually a _major_ variance from Fedora Core 3: http://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/RP… [ **NOTE: I have not supported MySQL since the RHL9/RHEL3 series, hence why I didn't know it off-hand, just of the linking issues with version 4. ] Which begs the questions: 1) How much testing did it get in the Fedora Development/Core series? 2) How did they solve some of the linking issues I've heard about? As I mentioned before, the current Fedora Core 4 Test has it too, so I have to assume one of the following: A) Red Hat negotiated a license to redistribute as built as before but now for MySQL 4 (not likely since even FC4 has it now, unless the license also applies there, but I doubt it based on how Red Hat makes sure any FC/FE packages are always 100% redistributable by others) B) Red Hat shifted away from the few static links that it has previously used (more likely?) C) The packages causing the linking licensing issues have change their licensing? (NuSphere possibly?) D) MySQL AB changed its stance on linking in MySQL 4 as of v4.1? Anyone know the answer? I have to go back and research why Red Hat stuck with 3.23 and see how they are now redistributing 4.1x? > CentOS-4 has the identical programs {as with all other items except > LOGOS, trademarked text, and yum and where updates are done} in it's > base :) Which is why I love it. I must have just looked at the wrong directory. I'm also very disturbed that Red Hat would not give the public time to test in the leading community releases. If I had to speculate, I'd say it's because it was already testing in most other distros, but I'll have to read up in Bugzilla on why the change was made (as well as what allowed Red Hat to change it's stance on MySQL 4 in the first place). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

CentOS-announce Digest, Vol 3, Issue 15
by centos-announce-request＠centos.org 26 May '05

26 May '05

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2005:413 Important CentOS 3 i386 ImageMagick - security update (Tru Huynh) 2. CESA-2005:413 Important CentOS 3 x86_64 ImageMagick - security update (Tru Huynh) 3. CESA-2005:472 Important CentOS 3 i386 kernel - security update (Tru Huynh) 4. CESA-2005:472 Important CentOS 3 x86_64 kernel - security update (Tru Huynh) ---------------------------------------------------------------------- Message: 1 Date: Thu, 26 May 2005 00:46:09 +0200 From: Tru Huynh <tru(a)centos.org> Subject: [CentOS-announce] CESA-2005:413 Important CentOS 3 i386 ImageMagick - security update To: centos-announce(a)centos.org Message-ID: <20050525224609.GA30869(a)sillage.bis.pasteur.fr> Content-Type: text/plain; charset="us-ascii" CentOS Errata and Security Advisory 2005:413 ImageMagick security update for CentOS 3 i386: https://rhn.redhat.com/errata/RHSA-2005-413.html The following updated file has been uploaded and is currently syncing to the mirrors: i386: updates/i386/RPMS/ImageMagick-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-c++-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-c++-devel-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-devel-5.5.6-14.i386.rpm updates/i386/RPMS/ImageMagick-perl-5.5.6-14.i386.rpm source: updates/SRPMS/ImageMagick-5.5.6-14.src.rpm You may update your CentOS-3 i386 installations by running the command: yum update ImageMagick\* Tru -- Tru Huynh (CentOS-3 i386/x86_64 Package Maintenance) http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B

1 0

Re: Betr.: [CentOS] VPN
by Peter Farrow 26 May '05

26 May '05

Hi there, yes it was with a Nortel contivity on a few occassions and the other times with a Cisco pix. interstingly enough the Cisco VPNs often required updates to the IOS to make them 3Des compliant, As its late here in the UK (past midnight GMT+1) here is a very quick and dirty freeswan guide. Needless to say the things that cause the biggest headache for most users is the use of RSA keys and opportunistic encryption. Since this is NOT what 99.9% of the masses need or want then there is a quick and simple and just as secure alternative setup, but its not that well documented. Opportunistic encryption came in versions 2 and above of freeswan by default, this has the effect of clobbering the network default route and replacing it down the ipsec interface (what you want if you want to encrypt everything, but not really any great use in the real world). Most people want to do site <-> site vpns and these are best achieved without opportunistic encryption and by the use of preshared keys. 1)Make sure you get a version of freeswan suitable for your kernel, if you can't find one go to somewhere like rpms.pbone.net and find a kernel for which there is a freeswan version. Many people try and hunt a freeswan version to match their kernel, I do it the otherway round, find the latest freeswan compatible kernel you can for your architecture, you can always compile it from source but why my life harder for yourself. 2)get the freeswan module for the kernel you found, and the same freeswan-userland version as well. then proceed as follows: after you have installed the [from rpm] Typically to kill opportunistic encryption add these lines to your ipsec.conf file: after the config setup section near the top, conn block auto=ignore conn private auto=ignore conn private-or-clear auto=ignore conn clear-or-private auto=ignore conn clear auto=ignore conn packetdefault auto=ignore Doing this stops all the crap you get when ipsec starts and then kicks you off the system about 60 seconds later if you're connected remotely as this kills the opportunistic setup feature. Do the same at the other end as well. Then start the service. Then add a section for each tunnel you want to set up. if you have multiple subnets at each site which can't be encapsulated in a single subnet declaration, you will need to add a new tunnel defintion for each. Here is an example : conn site1-site2 #this is the connection name [tunnel] identifier left=21.21.100.10 #This is the ip address of the first linux box leftnexthop=21.21.100.9 #This is usually set to the defualt gateway for the first linux box leftsubnet=10.11.2.0/24 #This is the LAN subnet behind the first linux box right=21.21.100.178 #This is the IP address of the second linux box at the other end of the tunnel rightsubnet=10.11.4.0/24 #This is the LAN subnet behind the second linux box rightnexthop=21.21.100.177 #This is the IP address of the default gateway setting of the other linux box authby=secret #We are going to use a "password" or secret to encrypt/auth the link pfs=no #Turn off perfect forward security, this makes it faster and easier but less secure auto=add #Authorise but don't start esp=3des-md5-96 #encapsulating security payload setting, encryption used for auth and data Now cut and paste this and add it to the ipsec.conf file on the second machine completely as is, unmodified. Then in you /etc/ipsec.secrets file on each machine you will need to add a password [secret] for each each of the tunnels you have specified, in the above example we would have: 21.21.100.10 21.21.100.178 : PSK "a-passwordin-here-with-the-quotes" Add this to the very top of the ipsec secrets file, one entry for each pair of machines in this format leftmachineip rightmachineip : PSK "password" Then do a service ipsec restart on each machine, bring the link up with this command, it only needs to be invoked from either one of the ends ipsec auto --up site1-site2 You should get output like this if you did it right: ipsec auto --up site1-site2 104 "site1-site2" #2086: STATE_MAIN_I1: initiate 106 "site1-site2" #2086: STATE_MAIN_I2: sent MI2, expecting MR2 108 "site1-site2" #2086: STATE_MAIN_I3: sent MI3, expecting MR3 004 "site1-site2" #2086: STATE_MAIN_I4: ISAKMP SA established 112 "site1-site2" #2087: STATE_QUICK_I1: initiate 004 "site1-site2" #2087: STATE_QUICK_I2: sent QI2, IPsec SA established Remember you will need to allow the ipsec interface in your firewall and you will need to add lines like this: # Accept udp connections to port 500 for ipsec $IPTABLES -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT $IPTABLES -A OUTPUT -p udp --sport 500 --dport 500 -j ACCEPT This is just about the quickest way to set up a VPN tunnel with Freeswan, it takes minutes. If you want to make if more secure, you can tune the config once you get it running this way! Remember the only machines that can't see the full extent of the other LAN network are the linux boxes creating the tunnel. So the left linux box will not be able to ping stuff on 10.11.4.0/24 network and the right linux box will not be able to ping stuff on 10.11.2.0/24 network - don't forget this.... its commonly mistaken by some to mean the tunnel isn't working, to truly test it end to end you need hosts on the LANs at each end to ping each other. If you want to make it work through NATing gateways you will need to port forward the udp 500 setting above on your firewall. Enjoy! Pete Kennedy Clark wrote: >Any chance of getting a quick HOW-TO posted to the group for that? >;-) Sounds interesting. > >I saw your post about using it with Cisco & Nortel equipment -- I work >with both a lot at my current customer. What types of equipment have >you used it with from both vendors (e.g., Cisco: IOS, PIX, VPN3K; >Nortel = Contivity)? > >Thanks!! >Kennedy > >

3 13

Re: [CentOS-announce] CESA-2005:472 Important CentOS 3 i386 kernel - security update
by John Newbigin 26 May '05

26 May '05

The yum headers for these updates seem to be incomplete or out of date... perhaps only for non i686 arch. 0:kernel-source-2.4.21-32.EL.i386=RPMS/kernel-source-2.4.21-32.EL.i386.rpm Tru Huynh wrote: > CentOS Errata and Security Advisory 2005:472 > > kernel security update for CentOS 3 i386: > https://rhn.redhat.com/errata/RHSA-2005-472.html > > The following updated file has been uploaded and is currently syncing to > the mirrors: > > i386: > updates/i386/RPMS/kernel-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-2.4.21-32.0.1.EL.i586.rpm > updates/i386/RPMS/kernel-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-BOOT-2.4.21-32.0.1.EL.i386.rpm > updates/i386/RPMS/kernel-doc-2.4.21-32.0.1.EL.i386.rpm > updates/i386/RPMS/kernel-hugemem-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-hugemem-unsupported-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-smp-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-smp-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-smp-unsupported-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-smp-unsupported-2.4.21-32.0.1.EL.i686.rpm > updates/i386/RPMS/kernel-source-2.4.21-32.0.1.EL.i386.rpm > updates/i386/RPMS/kernel-unsupported-2.4.21-32.0.1.EL.athlon.rpm > updates/i386/RPMS/kernel-unsupported-2.4.21-32.0.1.EL.i586.rpm > updates/i386/RPMS/kernel-unsupported-2.4.21-32.0.1.EL.i686.rpm > > source: > updates/SRPMS/kernel-2.4.21-32.0.1.EL.src.rpm > > You may update your CentOS-3 i386 installations by running the command: > > yum update kernel\* > > Tru > > > ------------------------------------------------------------------------ > > _______________________________________________ > CentOS-announce mailing list > CentOS-announce(a)centos.org > http://lists.centos.org/mailman/listinfo/centos-announce -- John Newbigin Computer Systems Officer Faculty of Information and Communication Technologies Swinburne University of Technology Melbourne, Australia http://www.ict.swin.edu.au/staff/jnewbigin

1 0

Re: [CentOS] Re: Centos and SAMBA
by Robert Moskowitz 26 May '05

26 May '05

At 05:14 PM 5/25/2005, Bryan J. Smith <b.j.smith(a)ieee.org> wrote: >From: Robert Moskowitz <rgm(a)htt-consult.com> > > I meant what is Centos equiv to in terms of Fedora. > > As the scripts I am using are set up for core 4. > >Fedora Core 4 isn't even out yet. Test 3 just hit the other week. I do not know where I got that core 4. My blunder. Barrs Law of Recursive futility If you're smart enough to use one of these.... .....you can probably manage without one!

1 0

Re: [CentOS] Re: Demonizing generic Linux issues as Fedora Core-only issues -- WAS: Hi, Bryan
by Bryan J. Smith <b.j.smith＠ieee.org> 25 May '05

25 May '05

From: Les Mikesell <lesmikesell(a)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

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss