I wish Debian users would stop and understand the reasons for the DCC release. Unchanging ABI/API and LSB run-time compliance for one. Kudos to the Debian project in general, especially since they support more than one ABI/API "set" per release (I.e., different GCC, GLibC, kernel, etc...). Of course, those decisions come with their own costs - both in workload, release cycle and compatibility. But the negatives are also a major, driving reason behind the DCC releases. I might be long removed from Debian now, and would not even attempt to dissect it. But one thing is the honest truth: the Fedora (and RHEL) and Debian (and DCC) release lifecycles are *NOT* even remotely comparable. In fact, as I detailed in my other post, Debian and many other distros have directly benefitted from RHL/Fedora by "waiting" on their "shake down." Now if you really want to talk about "different," we can start looking a "ports" distros instead of "packages" ones. E.g., Gentoo It even applies far less and cannot be compared at all, no matter how much people try to fit Portage into the comparison. When I want early/bleeding edge, source access, I'm at Gentoo - especially in initial development/adoption. When I want leading edge, but integration tested, software packages, I'm at Fedora - especially for core development/adoption. When I'm want proven, integration tested and regression and change avoidance, I'm at RHEL - especially for long-term release and support. Debian offers you more flexibility, but I've also been hit by bad, unforseen interface changes and regressions in package updates years after initial release. It's hard, damn hard, to balance new features against proven, fixed ABI/API standards. That's why the split lead-edge v. backport packages distros - like RHL/Fedora v. RHEL "just work." And when I need to get to pre-Fedora adopted (e.g., Rawhide-state or even earlier) source, then I have to hit the source, so I just go Gentoo. But only for select development systems or more embedded developments. -- Bryan J Smith - mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com Sent via BlackBerry from T-Mobile -----Original Message----- From: Rahul Sundaram <sundaram@xxxxxxxxxxxxxxxxx> Date: Fri, 22 Jun 2007 04:19:11 To:For discussions about marketing and expanding the Fedora user base <fedora-marketing-list@xxxxxxxxxx> Subject: Re: Linux.org: The Feodra 7 Year Itch Wilmer Jaramillo M. wrote: > On 6/21/07, Jesse Keating <jkeating@xxxxxxxxxxxxxxx> wrote: >> On Thursday 21 June 2007 11:49:57 Chris Negus wrote: >> > Has anyone on the Fedora project considered making one stable Fedora >> > release every three or four releases? You could promote the release as >> > having: >> > >> > * Stable desktop and servers >> > * Three years of security updates >> > * Branding program with hardware manufacturers >> >> We do, it's called Red Hat Enterprise Linux. > > Red Hat is not doubt the leader, But you do not mention the cost. > What cost? Rebuilds are available for gratis downloads. End users pay for support and services. Fedora need a official stable > release (as Debian stable or CentOS for RHEL) matters only for > security updates version of choice for networks and servers for those > for whom dependability matters more than the latest software, and on > one hand the already customary itch out releases. Common misconception is that RHEL updates are only security fixes. This is far from true. There are some selected features backported into major update cycles. For example, RHEL 4.5 added limited para virtualization support. > I believe that Red Hat I do not want to create a new competition of > RHEL and this is the reason for which a branch stable of Fedora is > impossible beyond of operative costs that imply to maintain it. If you mean "stable" as in relatively unchanging then Fedora isn't tied to that goal. The value of RHEL is precisely because there is some real costs in maintaining a commercial product with associated service level guarantees. Rahul -- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list -- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-marketing-list
