- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Circling The Wagons
|
|
|
Comments (31)
11 earlier comments in the full thread.
@hughesjr I think it would be fair to say that CentOS needs to prove that they can get patches out on a timely basis if they want to continue to be taken seriously as an enterprise product.
Interesting points, there are two related (to each other, not to CentOS) distros that prove the opposite sides here. One Distro proves that you dont have to do it 100% right as long as you do it often, while the other proves that you dont have to do it often as long as you do it right.
The difference is, both of these other distros has a plethora of developers. This is the main difference here, that in large projects you can absorb the loss of one fairly easily, while in smaller the loss of one can reduce the abilities of the dev team 25%. This is where some of the trust issues seem to stem from.
The difference is, both of these other distros has a plethora of developers. This is the main difference here, that in large projects you can absorb the loss of one fairly easily, while in smaller the loss of one can reduce the abilities of the dev team 25%. This is where some of the trust issues seem to stem from.
Quoting:CentOS has to prove they can get patches out on a timely basis to be taken seriously as an enterprise product.
@hughesjr: Let me add an additional qualifier to the above since, as written, you have a valid point. The rewritten version:
Given the recent concerns about security patches and how the distro is managed, CentOS has to prove they can get patches out on a timely basis to be taken seriously as an enterprise product from here on out.
There, that's better, and really hard to dispute as well.
Quoting:Given the recent concerns about security patches and how the distro is managed, CentOS has to prove they can get patches out on a timely basis to be taken seriously as an enterprise product from here on out.Then there is also what is termed the 'Infinite monkey theorem', http://en.wikipedia.org/wiki/Infinite_monkey_theorem Literally, it goes that "a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will almost surely type a given text, such as the complete works of William Shakespeare." Basically a quantitative raw-numbers, brute-force type of approach.
Figuratively as applied here, it could indicate that given a fantastically high number of CentOS patches coming out one after the other an a regular basis.... major security concerns in CentOS will almost certainly be resolved on a timely basis. Obviously, this is an idealized goal of quantity (mere brute force) over quality, and is thus vastly far away from being any sort of an achievable goal for the small team of CentOS maintainers.
Quoting:You can't change a year of erratic and often very late delivery of patches in a week or three. You have a year of problems to undo and had patches come as much as two months late. If next year you can say you've delivered within 72 hours for a solid year with either no or few exceptions I would certainly modify my opinion. You've taken steps and that is positive. You need to build a track record.Indeed, a consistent and qualitative record of due diligence is needed here rather than a very few yearly bursts of cranked-out CentOS patches doled out together with might be considered PR-type spin -- the latter, as the highly reactionary Circling The Wagons Syndrome.
@vainrveenr: All good points. I will also point out that not all Red Hat errata are necessarily security patches. Most are, but not all. Even those that are would not all be classified as severe or critical. Finally, even Red Hat is late now and again, which is why I said "few exceptions" rather than no exceptions. Also, when discussing exceptions, if a minor flaw is patched a day or two later nobody is going to make a big issue out of it. Being late with critical patches frequently will draw the ire of many, not just me.
I take no pleasure out of writing something negative about a Linux distribution. None at all. However, if I am to have any credibility at all I have to be honest about what I comment on and what I report, both positive and negative.
I take no pleasure out of writing something negative about a Linux distribution. None at all. However, if I am to have any credibility at all I have to be honest about what I comment on and what I report, both positive and negative.
Red Hat releases these updates in 2 different ways:
1. An updated set (or point release). This is done 2-4 times a year and is where the .2 and .3 in 5.2 and 5.3 come from. These update sets contain hundreds of packages and the packages have to be compiled in a fairly precise order to get the correct results.
This type of update normally takes CentOS at least a month to do because we may have to rebuild many of the packages more than one time to get the libraries to link correctly. Red Hat releases both security updates and bugfix updates in these "update sets".
It is not easy to build a security update that happens chronologically in the middle of this update set because it will depend on things built earlier in the update set.
No one tells CentOS the order that the packages were built or integrated into the build system for these update sets, we have to experimentally determine that by making our best guesses and building the updates. We then test them against the upstream binaries, spin-rinse-repeat as necessary to get it right The problem is, just because they built an updated package, they may not have rolled it into their build system at that time. If we get the order wrong, we can have things linked to the wrong libraries, etc. This is main reason we can't just grab a security update from the update set and just build it and push it.
It is also the reason we can't just build a security update released 2 days after the point release (until we release the point release) since that update is built upstream against packages they have released in the update set.
These update sets can take up to a month (or maybe longer) to do. CentOS generally completes these updates faster than any other rebuild group, and the above release dates are a comparison of when these releases happen.
Red Hat does a beta for these releases for 4-5 months before they release them. The comparison dates above show when CentOS and Scientific Linux finished each of these.
2. The second type of update is the ones released between updates sets. These are generally released one or two at a time and are usually easier to build and to test as the build system is not also in flux during their release. These are the types of updates CentOS has a goal to release within 72 hours. Sometimes it takes longer.
===== @caitlyn: You don't make any distinction as to which update type you are talking about. If it is during the update set, we may have to build the packages in several stages, and redo them several times to get it right. If it is the 2nd type of update, I agree that they should be built and released quickly.
1. An updated set (or point release). This is done 2-4 times a year and is where the .2 and .3 in 5.2 and 5.3 come from. These update sets contain hundreds of packages and the packages have to be compiled in a fairly precise order to get the correct results.
This type of update normally takes CentOS at least a month to do because we may have to rebuild many of the packages more than one time to get the libraries to link correctly. Red Hat releases both security updates and bugfix updates in these "update sets".
It is not easy to build a security update that happens chronologically in the middle of this update set because it will depend on things built earlier in the update set.
No one tells CentOS the order that the packages were built or integrated into the build system for these update sets, we have to experimentally determine that by making our best guesses and building the updates. We then test them against the upstream binaries, spin-rinse-repeat as necessary to get it right The problem is, just because they built an updated package, they may not have rolled it into their build system at that time. If we get the order wrong, we can have things linked to the wrong libraries, etc. This is main reason we can't just grab a security update from the update set and just build it and push it.
It is also the reason we can't just build a security update released 2 days after the point release (until we release the point release) since that update is built upstream against packages they have released in the update set.
These update sets can take up to a month (or maybe longer) to do. CentOS generally completes these updates faster than any other rebuild group, and the above release dates are a comparison of when these releases happen.
Red Hat does a beta for these releases for 4-5 months before they release them. The comparison dates above show when CentOS and Scientific Linux finished each of these.
2. The second type of update is the ones released between updates sets. These are generally released one or two at a time and are usually easier to build and to test as the build system is not also in flux during their release. These are the types of updates CentOS has a goal to release within 72 hours. Sometimes it takes longer.
===== @caitlyn: You don't make any distinction as to which update type you are talking about. If it is during the update set, we may have to build the packages in several stages, and redo them several times to get it right. If it is the 2nd type of update, I agree that they should be built and released quickly.
There wouldn't be such a ruckus over the way the CentOS project is managed and the manner in which the team releases security patches if there wasn't an acute need and desire for a distribution that does what CentOS does, namely releases a free clone of a high-quality product that is not free (RHEL).
I can believe that millions are using it, that Amazon subsists on it.
My question to those who know more than me: What would it take to make, say, Debian, an equally attractive product for the enterprise server?
I can also see the Ubuntu LTS taking some of this share.
I can believe that millions are using it, that Amazon subsists on it.
My question to those who know more than me: What would it take to make, say, Debian, an equally attractive product for the enterprise server?
I can also see the Ubuntu LTS taking some of this share.
@hughesjr: I think you missed something in my post earlier. I said that delayed dot releases are fine so long as the previous release is properly supported and secured. Red Hat understands that not all of their customers will do each dot release. Some ISVs (Oracle immediately comes to mind) will support an earlier dot release but not the latest. So long as all the patches to the previous release are posted then all is well.
Dot releases do two things: 1. Compile all the security patches since the last release, and 2. Add bugfixes not related to security.
So... we now agree that patches (what you call the second type) should be released quickly. Do that on a regular basis for a while and I will drop my complaints about CentOS security. Fair enough?
Dot releases do two things: 1. Compile all the security patches since the last release, and 2. Add bugfixes not related to security.
So... we now agree that patches (what you call the second type) should be released quickly. Do that on a regular basis for a while and I will drop my complaints about CentOS security. Fair enough?
@caitlyn: Sure. Keep an eye on the updates ... I think you will like what you see.
As a wakeup call, this could make the project much better going forward ...
> Keep an eye on the updates ... I think you will like what you see.
Everyone hopes so. No one here wishes CentOS ill, at least AFAIK.
Everyone hopes so. No one here wishes CentOS ill, at least AFAIK.
@jdixon: Absolutely. I wish CentOS well and I would like to see them succeed with no further drama.
Quoting:I would like to see them succeed with no further drama.But... but... drama is good for PR!
"There is no such thing as bad publicity except your own obituary."
Brendan Behan
> But... but... drama is good for PR!
I can see it now: Tune in tomorrow for our next exciting installment of "As the Distro Turns".
I can see it now: Tune in tomorrow for our next exciting installment of "As the Distro Turns".
@jdixon So you are saying that tomorrow we find out that CentOS is the illegitimate love child of Red Hat?
@rijelkentaurus:
What a day to be posting that quote.
What a day to be posting that quote.
> So you are saying that tomorrow we find out that CentOS is the illegitimate love child of Red Hat?
Well, we always knew that. The question has always been who the other parent is. :)
Well, we always knew that. The question has always been who the other parent is. :)
@jdixon Sounds like a good story line...
Nah, they already did that one on "South Park."
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post