Assaf Flatto <[EMAIL PROTECTED]> wrote: > Fedora core stable version now is FC4
Actually, it's FC5. Fedora Core (FC) 2 and 4 radically changed the GCC/GLibC versions (as well as the kernel in the case of 2). FC 3 and 5 were largely revisions of the former, respectively. > (which is to say Red hat 10 version 4 or even Red Hat 11 if > we count in the old way RH did ). If feel you must relate versions, it's best to track them by releases, here is how FC/RHL map to Red Hat Enterprise Linux (RHEL) ... RHL 6.2 "E" (the "first" w/Service Level Agreements, SLAs) - Based on: RHL 6.0 -> 6.1 -> 6.2 RHAS 2.1 (later relabeled RHEL 2[.1]) - Based on: RHL 7 -> RHL 7.1 -> RHL 7.2 - Also: RHL7.3 (released after RHAS 2.1) RHEL 3 - Based on: RHL 8.0 -> RHL 9 - Also: FC1 (released after RHEL 3) RHEL 4 - Based on: FC 2 -> FC 3 RHEL 5 (by all estimates ...) - Based on: FC 4 -> FC 5 Red Hat started its original .0 -> .1 -> .2 release model with Red Hat Linux (RHL) 4.0. It stopped differentiating after RHL 7.3. With exception of FC 1 (with added 2 months (8 months total) in the trademark and other review (such as removing a lot of dependency hell and security issues, long story), Red Hat maintained its 6 month release cycle within 2-3 weeks through FC 3. FC 4 and FC 5 took betwen 8-9 months to release. This 6 month release cycle is actually a 2 -> 2 -> 2 month cycle formerly known as Red Hat Rawhide -> Beta -> Release, now known formally as Fedora Development -> Test -> Core (although most Red Hat developers still call "Development" the original label, "Rawhide"). The 18 month RHEL release cycle comes after 2-3 RHL/FC revisions. The earlier you adopt a "major change," the more issues you'll run into with maturity, compatibility (which is where 90% of the problem is -- Red Hat "pushes the envelope early" and forces everyone to adopt newer API changes). The more you "hold off" on latter releases, or RHEL, the less issues you'll have with existing code -- although you might not be able to run the latest stuff. That's why FC is recommended when you're running newer software -- more "leading edge." RHEL is recommended when you're running established software -- more "trailing edge" (which also makes SLAs possible and supportable for Red Hat). Some people go "in between" -- avoiding certain FC releases (just like RHL releases prior). E.g., I avoided RHL5.0, 6.0, 7.0, 8.0, FC2 and FC4. I didn't upgrade until 5.1, 6.1, 7.1, 9, FC3 and, most recently, FC5 came out. In other words, I waited for "+1 release" after a major GCC/GLibC change. > As John suggested CentOs is a good idea to use, Agreed. CentOS is virtually a 1:1 rebuild of RHEL, because Red Hat releases _all_ of its work in Source RPM (.src.rpm aka SRPMS) packages unlike many other vendors (e.g., SuSE for SuSE Linux Enterprise Server or Novell Linux Desktop). CentOS is a great choice when you don't want to pay for a SLA. But it comes with all the same pros/cons of "trailing edge" Red Hat. > however there are some well documented problems with the zaptel > ( that is if you are using digium hardware ) compilation ,but all > in all it shouldn't be a problem. On which CentOS release? CentOS 3? CentOS 4? CentOS 3 has the same GCC/GLibC as RHL9. CentOS 4 has the same GCC/GLibC as FC3. If it's built for FC4+, then yes, CentOS is not ideal ... yet. You'll have to wait for CentOS 5, or consider FC5. You do _not_ want to run FC4 -- FC5 is typically far, far better. Just like FC3 was over FC2 for the most part. -- Bryan J. Smith Professional, Technical Annoyance [EMAIL PROTECTED] http://thebs413.blogspot.com ----------------------------------------------------------- Americans don't get upset because citizens in some foreign nations can burn the American flag -- Americans get upset because citizens in those same nations can't burn their own _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users