Hello, I want to compare CentOS to Fedora and other distros on a stability/network-dependance basis. Where should I look for some published statistics on updates? I mean probably megabytes per week (or whichever units, of published updates over time), per distro. Thank you in advance
On 7/24/06, Eduardo Grosclaude eduardo.grosclaude@gmail.com wrote:
Hello, I want to compare CentOS to Fedora and other distros on a stability/network-dependance basis. Where should I look for some published statistics on updates? I mean probably megabytes per week (or whichever units, of published updates over time), per distro. Thank you in advance
http://www.linux-magazine.com/issue/65/CentOS_4.2.pdf http://www.redhat.com/rhel/migrate/whichlinux/ (CentOS is built from the freely available RHEL source rpms, so arguements for RHEL on this page also apply to CentOS, except for support and pricetag.)
Jim Perrin wrote:
On 7/24/06, Eduardo Grosclaude eduardo.grosclaude@gmail.com wrote:
Hello, I want to compare CentOS to Fedora and other distros on a stability/network-dependance basis. Where should I look for some published statistics on updates? I mean probably megabytes per week (or whichever units, of published updates over time), per distro. Thank you in advance
http://www.linux-magazine.com/issue/65/CentOS_4.2.pdf http://www.redhat.com/rhel/migrate/whichlinux/ (CentOS is built from the freely available RHEL source rpms, so arguements for RHEL on this page also apply to CentOS, except for support and pricetag.)
I have a number of CentOS machines that have been up 24/7 in datacenter environments for years and were only rebooted on occasion as a result of security-related kernel upgrades (which would affect any linux distro). I can't recall EVER having uptime or network-related issues on ANY live CentOS server that wasn't the direct result of a hardware failure. It just works...and works...and works. :) The key is to beat up on any new hardware in a test environment first to make sure that you don't have any incompatible hardware bits (which hasn't bitten me often).
Cheers,
On 7/24/06, Chris Mauritz chrism@imntv.com wrote:
Jim Perrin wrote:
On 7/24/06, Eduardo Grosclaude eduardo.grosclaude@gmail.com wrote:
Hello, I want to compare CentOS to Fedora and other distros on a stability/network-dependance basis. Where should I look for some published statistics on updates? I mean probably megabytes per week (or whichever units, of published updates over time), per distro. Thank you in advance
http://www.linux-magazine.com/issue/65/CentOS_4.2.pdf http://www.redhat.com/rhel/migrate/whichlinux/ (CentOS is built from the freely available RHEL source rpms, so arguements for RHEL on this page also apply to CentOS, except for support and pricetag.)
I have a number of CentOS machines that have been up 24/7 in datacenter environments for years and were only rebooted on occasion as a result of security-related kernel upgrades (which would affect any linux distro). I can't recall EVER having uptime or network-related issues on ANY live CentOS server that wasn't the direct result of a hardware failure. It just works...and works...and works. :) The key is to beat up on any new hardware in a test environment first to make sure that you don't have any incompatible hardware bits (which hasn't bitten me often).
Thank you for your point, on which I wholly agree, but I was taking
"stability" as "a measure of velocity in change" of a system's components-- here reflected in a shorter or longer life cycle for each version. Please correct me if I am wrong, I may be misusing the word (I am heading right to Wikipedia in a minute! :) ). We all want CentOS as a server system because of its "stability" which -at least for me- means few, controlled changes over an extended lifetime. As to the network-dependance problem, I was thinking of the "gee, I will really need a bandwidth here to cope with updates" feeling suggested, for instance, by Fedora.
On 7/24/06, Eduardo Grosclaude eduardo.grosclaude@gmail.com wrote:
I have a number of CentOS machines that have been up 24/7 in datacenter environments for years and were only rebooted on occasion as a result of security-related kernel upgrades (which would affect any linux distro). I can't recall EVER having uptime or network-related issues on ANY live CentOS server that wasn't the direct result of a hardware failure. It just works...and works...and works. :) The key is to beat up on any new hardware in a test environment first to make sure that you don't have any incompatible hardware bits (which hasn't bitten me often).
Thank you for your point, on which I wholly agree, but I was taking
"stability" as "a measure of velocity in change" of a system's components-- here reflected in a shorter or longer life cycle for each version. Please correct me if I am wrong, I may be misusing the word (I am heading right to Wikipedia in a minute! :) ).
Er... I'm back from Wikipedia, and found (cough) no traces of "stability" as the proper word for what I meant, but come on, think Debian stable/unstable, that stuff :S
On Mon, 2006-07-24 at 12:45 -0300, Eduardo Grosclaude wrote:
Thank you for your point, on which I wholly agree, but I was taking "stability" as "a measure of velocity in change" of a system's components-- here reflected in a shorter or longer life cycle for each version.
Seems like a bad concept - if something is broken in the initial release you really do want the change that fixes it...
Er... I'm back from Wikipedia, and found (cough) no traces of "stability" as the proper word for what I meant, but come on, think Debian stable/unstable, that stuff :S
This is probably spelled out somewhere in the 'upstream version' documentation, but security-related fixes are made available as needed and bugfix updates are batched infrequently. Version-level application updates are almost never done. I consider it the 'right' amount of stability for servers where the programs have been feature-complete for years but it is getting on the old side for desktop apps now.
On 7/24/06, Les Mikesell lesmikesell@gmail.com wrote:
On Mon, 2006-07-24 at 12:45 -0300, Eduardo Grosclaude wrote:
Thank you for your point, on which I wholly agree, but I was taking "stability" as "a measure of velocity in change" of a system's components-- here reflected in a shorter or longer life cycle for each version.
Seems like a bad concept - if something is broken in the initial release you really do want the change that fixes it...
You surely want them, but I can't see why it's a bad concept-- "Distro X has published Y weekly MB of updates on average over the last year" is just a fact.
You surely want them, but I can't see why it's a bad concept-- "Distro X has published Y weekly MB of updates on average over the last year" is just a fact.
Distro X has had 650MB of updates over the course of the last 4 months. Distro Y has had 130MB of updates over the same period.
Which one is more secure or stable?
Distro Y's updates include a number of tiny but critical updates to things like pam modules, apache and the like because they seem to constantly have critical flaws letting unauthorized evil people into the system via remote exploit. The trending of these updates shows a systemic security problem in the distro's ability to patch properly. This distro also has a number of other flaws still outstanding waiting to be patched.
Distro X has updated openoffice a couple times to add support for Open document format and a few other reasons. OpenOffice.org is just a HUGE package.
The above hypothetical should illustrate why your method is flawed. It's not "bad" exactly, nor is it entirely wrong. It just doesn't figure everything into the equation.
On 7/24/06, Jim Perrin jperrin@gmail.com wrote:
You surely want them, but I can't see why it's a bad concept-- "Distro
X
has published Y weekly MB of updates on average over the last year" is
just
a fact.
Distro X has had 650MB of updates over the course of the last 4 months. Distro Y has had 130MB of updates over the same period.
Which one is more secure or stable?
Y is, per my former definition, more stable. As for security, stability has nothing to do with it, nor I am at the moment interested in it, nor am I pretending to derive any quality assessment from this very simple fact. Seems that I have expressed myself very poorly.
The above hypothetical should illustrate why your method is flawed.
It's not "bad" exactly, nor is it entirely wrong. It just doesn't figure everything into the equation.
It is not a method for anything, nor an equation, it is just a measurement. I don't pretend those facts to be a useful measure to reasonably conclude anything. Of course you still need to take into account several other measurements to fit into any theory...
Y is, per my former definition, more stable. As for security, stability has nothing to do with it, nor I am at the moment interested in it, nor am I pretending to derive any quality assessment from this very simple fact. Seems that I have expressed myself very poorly.
Okay. We'll go with this one then. RHEL and CentOS backport fixes to keep applications at a current functional level. Most updates are bug fixes that do not change functionality. This is not the case with fedora.
CentOS and Fedora can both release an update to fix a bug in apache. CentOS's fix will address just that vulnerability, changing functionality no more than absolutely necessary. Fedora may fix the same flaw by taking the opportunity to update to a new version of apache, introducing several new features, or changing the behavior of the application.
The updates for both systems will be nearly identical in size.
Now which one is more stable?
On Jul 24, 2006, at 6:03 PM, Eduardo Grosclaude wrote:
It is not a method for anything, nor an equation, it is just a measurement. I don't pretend those facts to be a useful measure to reasonably conclude anything. Of course you still need to take into account several other measurements to fit into any theory...
hm, perhaps "stable" is a poorly-chosen word, then. the word "stable" is somewhat emotionally loaded among system administrators, and i suspect many people automatically think "stable==good", and so if their chosen distro performs poorly according to your "stability" metric, they may be inclined to attack your metric or you.
my first thought was that your metric did not seem a particularly useful one; then i realized that if you were collecting it, you probably had some use for it, but it was difficult for me to get over the choice of word.
-steve
--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
On 7/24/06, Steve Huff shuff@vecna.org wrote:
On Jul 24, 2006, at 6:03 PM, Eduardo Grosclaude wrote:
It is not a method for anything, nor an equation, it is just a measurement. I don't pretend those facts to be a useful measure to reasonably conclude anything. Of course you still need to take into account several other measurements to fit into any theory...
hm, perhaps "stable" is a poorly-chosen word, then. the word "stable" is somewhat emotionally loaded among system administrators, and i suspect many people automatically think "stable==good", and so if their chosen distro performs poorly according to your "stability" metric, they may be inclined to attack your metric or you.
my first thought was that your metric did not seem a particularly useful one; then i realized that if you were collecting it, you probably had some use for it, but it was difficult for me to get over the choice of word.
-steve
I agree :) Please let's s/stability/volume of updates/g and start it all over again :) Cheers to all
I agree :) Please let's s/stability/volume of updates/g and start it all over again :) Cheers to all
CentOS still wins over fedora. Mine is probably not the most unbiased of opinions however.... :-P
On Mon, 2006-07-24 at 19:22 -0300, Eduardo Grosclaude wrote:
I agree :) Please let's s/stability/volume of updates/g and start it all over again :)
The concept is still flawed if you pick some arbitrary time interval for the comparison since the distros that backport fixes into the released app versions will tend to tend to have less activity as the distro ages. That is, many problems may be found and fixed soon after release, but finding new ones will eventually taper off and as the developers move on to new versions there is less interest in fixing old ones.
However, almost by definition, fedora uses a fast release cycle and lots of updates and Centos has much less churn - but not quite to the point of Debian stable where there is never even a schedule for the next version.
Eduardo,
I'm wondering what the metric will display that is useful? Volume is dependent upon purpse of the distro. (CentOS & Debian stable will track low volume - their purpose is to provide a predictable environment. Fedora & Debian unstable will track a higher, and fairly variable volume). Do you plan to track against initial volume? When I last looked Debian's full distro was 14 CDs (with a single CD net install option) Again driven by purpose.
Dave
_____
From: Eduardo Grosclaude [mailto:eduardo.grosclaude@gmail.com]
Please let's s/stability/volume of updates/g and start it all over again :) Cheers to all
Eduardo Grosclaude wrote:
On 7/24/06, *Chris Mauritz* <chrism@imntv.com mailto:chrism@imntv.com> wrote:
Jim Perrin wrote: > On 7/24/06, Eduardo Grosclaude <eduardo.grosclaude@gmail.com <mailto:eduardo.grosclaude@gmail.com>> wrote: >> Hello, >> I want to compare CentOS to Fedora and other distros on a >> stability/network-dependance basis. Where should I look for some >> published >> statistics on updates? I mean probably megabytes per week (or whichever >> units, of published updates over time), per distro. >> Thank you in advance > > http://www.linux-magazine.com/issue/65/CentOS_4.2.pdf > http://www.redhat.com/rhel/migrate/whichlinux/ (CentOS is built from > the freely available RHEL source rpms, so arguements for RHEL on this > page also apply to CentOS, except for support and pricetag.) I have a number of CentOS machines that have been up 24/7 in datacenter environments for years and were only rebooted on occasion as a result of security-related kernel upgrades (which would affect any linux distro). I can't recall EVER having uptime or network-related issues on ANY live CentOS server that wasn't the direct result of a hardware failure. It just works...and works...and works. :) The key is to beat up on any new hardware in a test environment first to make sure that you don't have any incompatible hardware bits (which hasn't bitten me often).
Thank you for your point, on which I wholly agree, but I was taking "stability" as "a measure of velocity in change" of a system's components-- here reflected in a shorter or longer life cycle for each version. Please correct me if I am wrong, I may be misusing the word (I am heading right to Wikipedia in a minute! :) ). We all want CentOS as a server system because of its "stability" which -at least for me- means few, controlled changes over an extended lifetime. As to the network-dependance problem, I was thinking of the "gee, I will really need a bandwidth here to cope with updates" feeling suggested, for instance, by Fedora.
Ah, in that case, I think the answer is "it depends". :-) Periodic updates and updates from one minor release to the next seem to use only a small amount of bandwidth and involve a small number of packages. It is approximately the same as you would experience with RedHat Enterprise Linux, which is the basis for CentOS. Compared to Fedora, the changes are significantly less often (except for security fixes) and probably a lot less bandwidth requirements (but I do not currently use Fedora so I am not positive about this part).
I hope that helps.
Cheers,
Chris
Chris Mauritz spake the following on 7/24/2006 8:56 AM:
Eduardo Grosclaude wrote:
On 7/24/06, *Chris Mauritz* <chrism@imntv.com mailto:chrism@imntv.com> wrote:
Jim Perrin wrote: > On 7/24/06, Eduardo Grosclaude
<eduardo.grosclaude@gmail.com
mailto:eduardo.grosclaude@gmail.com> wrote: >> Hello, >> I want to compare CentOS to Fedora and other distros on a >> stability/network-dependance basis. Where should I look for some >> published >> statistics on updates? I mean probably megabytes per week (or whichever >> units, of published updates over time), per distro. >> Thank you in advance > > http://www.linux-magazine.com/issue/65/CentOS_4.2.pdf > http://www.redhat.com/rhel/migrate/whichlinux/ (CentOS is built from > the freely available RHEL source rpms, so arguements for RHEL on this > page also apply to CentOS, except for support and pricetag.)
I have a number of CentOS machines that have been up 24/7 in datacenter environments for years and were only rebooted on occasion as a result of security-related kernel upgrades (which would affect any linux distro). I can't recall EVER having uptime or network-related issues on ANY live CentOS server that wasn't the direct result of a hardware
failure. It just works...and works...and works. :) The key is to beat up on any new hardware in a test environment first to make sure that you don't have any incompatible hardware bits (which hasn't bitten me often).
Thank you for your point, on which I wholly agree, but I was taking "stability" as "a measure of velocity in change" of a system's components-- here reflected in a shorter or longer life cycle for each version. Please correct me if I am wrong, I may be misusing the word (I am heading right to Wikipedia in a minute! :) ). We all want CentOS as a server system because of its "stability" which -at least for me- means few, controlled changes over an extended lifetime. As to the network-dependance problem, I was thinking of the "gee, I will really need a bandwidth here to cope with updates" feeling suggested, for instance, by Fedora.
Ah, in that case, I think the answer is "it depends". :-) Periodic updates and updates from one minor release to the next seem to use only a small amount of bandwidth and involve a small number of packages. It is approximately the same as you would experience with RedHat Enterprise Linux, which is the basis for CentOS. Compared to Fedora, the changes are significantly less often (except for security fixes) and probably a lot less bandwidth requirements (but I do not currently use Fedora so I am not positive about this part).
I hope that helps.
Cheers,
Chris
The biggest bandwidth use with Fedora would be downloading the ISO's for the new version because the support for your version fell off the face of the earth. Even Fedora Legacy is dropping Core 1 and 2.