On Sun, 9 Aug 2009 03:23:57 +0100 Marko Vojinovic vvmarko@gmail.com wrote:
Unfortunately, governments are typically not made of experts, but of opportunists. Name one president of <insert your favorite political entity here> that has been elected because he has a PhD in political sciences/history/law/whatever, or because he had enough hands-on experience in governing the state (maybe without a formal degree).
Woodrow Wilson. Ph.D. in Political Science (John Hopkins), President of Princeton University, Governor of the State New Jersey, President of the United States of America.
Even if one such exists, I doubt he would listen to whatever random non-initiated group of people are "suggesting".
Then you would be wrong. Once his mind was made up then Wilson became quite closed to further suggestion on a subject. Up to that point he sought as wide and varied a range of opinion as he could obtain.
Your pride in what you know is blinding you to the value of knowledge of others in areas where you know little and presume much.
I have had much experience with volunteer organisations. I now stay well clear of any involvement with them. This recent string of interrogations by concerned people, whether ignorant or not, and the aggrieved tone of the responses of some of the inner circle demonstrate the type of emotional blackmail which I frequently encounter and find so distressful in these bodies.
I have no doubt that everyone involved with CentOS is pursuing some goal that they believe serves the greater good. However, difficulties ofttimes arise when one encounters another who either does not share ones belief or, as is more often the case, understands the nature of the shared goal, or the means by which it is attained, in a fashion fundamentally at odds with ones own.
These uncomfortable collisions with political reality often occur at junctures such as CentOS recently experienced. Most of the people here were no doubt quite content to allow the sages of the project whatever leeway that the sages desired. In return we got a free (as in beer) copy of a very reputable Linux distribution. Had the recent inner conflict not become public then this happy arrangement might have persisted indefinitely. I still consider this arrangement a very good bargain having neither the talent nor the desire to become a sage myself.
However, when the mortal nature of the sages is revealed together with the possibility of a project collapse as very real consideration, regardless how unlikely, then those dependent upon the stability of the project become fearful. Fearful people seek reassurance that their fears are baseless. A bald statement by the sages that the fear is baseless is in itself insufficient. Doubtless the fearful have told themselves that many times already.
Having inoculated doubt it is now incumbent upon those who sowed it to address specific concerns raised by those who fear. Telling people who voice concerns to get lost and find another distribution, even if their concerns are presented in the form of ill-considered suggestions, smacks of arrogance to me, however it appears to others. Further, it does absolutely nothing to address the fears that prompted the suggestion. The baleful effects of these kind of replies upon those who read but choose not to participate may only be imagined, but be assured they are neither positive nor insignificant.
The fact that one is a volunteer leader does not lessen the requirement that to receive the trust and support of others one must meet satisfactorily the expectations of those who follow. I am not clamoring for any immediate changes. I do not propose a program that I wish anyone else to follow. I do appreciate very much the efforts of all who contribute to the success of the CentOS projects. I further acknowledge that those who presently form the core support team are probably best equipped to evaluate the bona fides of prospective core members.
Nonetheless, it is very evident from the heated exchanges on this mailing list that there exists a substantial divergence on which path to take from here. It seems to me insupportable that the past practices of a small coterie of initiates deciding on everything without community input will suffice for the future. If that does become the choice taken then I foresee the community splitting in the future in consequence.
Finally, please drop the word "meritocracy" in future communications. It implies a natural worthiness of those to whom it is applied which is simply not appropriate to these discussions. The proper word in this circumstance is "oligarchy."
On Mon, Aug 10, 2009 at 3:12 PM, James B. Byrnebyrnejb@harte-lyne.ca wrote:
Nonetheless, it is very evident from the heated exchanges on this mailing list that there exists a substantial divergence on which path to take from here. It seems to me insupportable that the past practices of a small coterie of initiates deciding on everything without community input will suffice for the future. If that does become the choice taken then I foresee the community splitting in the future in consequence.
I think your conclusions are wrong. I don't think there is "substantial divergence" in the CentOS community, and I don't think the project is in danger of forking. I also think that if you open up the core development to "community input" you'll have endless discussion, and a degraded product (the "when all is said and done, a lot more will be said then done" principle). Again, what does community input have to do with the mechanical process of turning "upstream" code into a 100% binary compatible distribution?
I have a system who's normal activity is running Xen 3.3.1 with Centos 5.3 as the DomU. I had reason to connect an IDE drive to the single IDE interface that this board has. I was getting slow performance. hdparm -t revealed that the thoughput was down to just 2.7 MB/sec. After some tweaking (switch on 32 bit,etc) and retesting under a non-Xen config, I managed to get that to 8MB/Sec. When I move the drive to a USB to IDE adapter, hdparm -t gives me about 18MB/Sec. Big improvement, although I don't know if it is then perfect..
My kernel is 2.6.18-128.4.1.el5. I have kernel parameter pci=nomsi. I can't remember exactly why I needed this, but there was a good reason, maybe SATA drive not working properly or some such. Could this be the cause of my issue?
The motherboard blurb states that the IDE interface is ATA/133 compliant and I am using the provided IDE cable. I have tried three hard disks, all with similar results. (2x 40gb + 1x 160gb)
lspci | grep IDE gives 00:06.0 IDE interface: nVidia Corporation MCP78S [GeForce 8200] IDE (rev a1)
As a reference, hdparm -t against the SATA drive in AHCI mode on the same board gives about 110MB/Sec.
Any ideas, anyone?
Thanks in advance,
Ian.
Please stop hijacking threads. If you want to ask a question, well, then hit the button for "new message". Thanks.
Kai
On Monday 10 August 2009 22:12:41 Ron Blizzard wrote:
Again, what does community input have to do with the mechanical process of turning "upstream" code into a 100% binary compatible distribution?
Nothing, of course. :-) There seem to be only two things such "input" would provide:
(1) the *illusion* that the community is "in control" of the project, while having no technical skill to really enforce this control, and (2) the big *overhead* in the development process which could potentially make it more complicated.
I completely understand why the core devs refuse this "community input". If members of the community want to do something useful, they should simply follow the seven-point outline given in
http://lists.centos.org/pipermail/centos/2009-August/080334.html
Best, :-) Marko
On Monday 10 August 2009 21:12:11 James B. Byrne wrote:
On Sun, 9 Aug 2009 03:23:57 +0100 Marko Vojinovic vvmarko@gmail.com wrote:
Unfortunately, governments are typically not made of experts, but of opportunists. Name one president of <insert your favorite political entity here> that has been elected because he has a PhD in political sciences/history/law/whatever, or because he had enough hands-on experience in governing the state (maybe without a formal degree).
Woodrow Wilson. Ph.D. in Political Science (John Hopkins), President of Princeton University, Governor of the State New Jersey, President of the United States of America.
Born December 28, 1856, died February 3, 1924. I could also name someone from middle ages or ancient Greece, for that matter. But today is 2009. :-)
However, you are right, I agree that I went over the line with this, and since it is OT, let me be the one to drop my own argument. ;-)
Your pride in what you know is blinding you to the value of knowledge of others in areas where you know little and presume much.
This is not about pride, just signal-to-noise ratio, as I stated. Also, regarding presumption, in areas where I have no serious knowledge (building a CentOS distribution from scratch being the one that matters here), the only thing I can do is build *trust* to the people who *do* have appropriate knowledge, and let them guide and make decisions about the project.
I understand your argument that project consumers (ie. the community) are in a bad situation when their trust gets shaken, but in the CentOS case I see no alternative but to continue to trust the core developers. They have several years of demonstration of rock solid performance behind them, and that accounts for something. The proposed alternative is to change the inner structure of the project, expose more the development process and change the decision-making authority (the "board" proposal). This proposed alternative comes from people who have little to no credibility and trust established (in my eyes at least, and it seems in core dev's eyes as well). Therefore I would never support such an alternative over the "old way".
The way I see it, the multiple-years-rock-solid-distro showed an inner problem in public, and a couple of loudmouths (no insulting intended) took the opportunity to "offer suggestions" and criticize. Of course, holding as well no credibility with the core devs and the rest of the community, I myself also fall into this "loudmouth" category, the only difference being that I offer a counter-argument to previous ones. This is based on my point of view, and offers a balance of arguments to an outside reader of this thread.
I also agree that everyone's motives are for the greater good, it's just that the approach is different. And every reader who cares for the subject will make up his mind based on the opinions presented.
No pride and no presumptions here, except when I simply need to assume *something* (ie. trust someone) in order to have an opinion at all.
I have had much experience with volunteer organisations. I now stay well clear of any involvement with them. This recent string of interrogations by concerned people, whether ignorant or not, and the aggrieved tone of the responses of some of the inner circle demonstrate the type of emotional blackmail which I frequently encounter and find so distressful in these bodies.
[snip]
The whole thread put shortly (the way I see it) goes like this:
* A community member shouts "Because of recent dev-internal events, I don't trust the developers any more, I want the project changed so that I can regain my trust!"
* The developers answer "The changes you propose are unacceptable from our pov, so you have a choice to continue trusting us, or go find another distro."
* The member than says "No, I want in on development and decision-making in order to rebuild my trust, regardless of the fact that I have no appropriate technical skills."
* The developers answer "This is a ridiculous proposal, you are a fool to think we will ever accept that. Our product is there, use it or don't."
During the discussion, things may get emotional and tense to the point of aggrieved tone and name-calling on either side, but essentially --- who is trying to make a blackmail here?
As a casual thread-reader/ordinary-member-of-the-community, one can choose to ignore the discussion or to pick a side. When picking sides, the developers have some credibility in my eyes because of past performance. The other side has little to no credibility from my pov (being "just another community member", afaik), and their behavior is as emotional as that of the developers.
With pro's and con's evaluated, I say the developer's pov wins here. That is all I am saying. Others may have different opinion, of course.
Having inoculated doubt it is now incumbent upon those who sowed it to address specific concerns raised by those who fear.
I disagree here. The developers have been doing all the heavy lifting here from day one, and have demonstrated superb performance. They have no obligation to address raising fears from members of the community. Past performance is the only objective indication of future performance (however "only potential" this may be), and if this is not enough assurance for the members, they should indeed go elsewhere. But the fearful members instead choose to press the developers into changing the project structure, only to address their fears. This is irrational and undeserved, especially when one looks at the details of the proposed changes.
Telling people who voice concerns to get lost and find another distribution, even if their concerns are presented in the form of ill-considered suggestions, smacks of arrogance to me, however it appears to others. Further, it does absolutely nothing to address the fears that prompted the suggestion.
True, this behavior is arrogant, but completely called for, since the fearful members had the same arrogant attitude to begin with. Maybe not in profane words, but the general attitude that they are Members of The Community, and they *demand* the the developers to obey their requests. This is extremely arrogant, even when phrased politely. From a developer's point of view, being a Great Member of The Community doesn't mean squat. People who do the work get to make decisions, others can use or not use the end-product. They don't ever get to demand anything. If they do, the developers have every right to be arrogant as well.
The fact that one is a volunteer leader does not lessen the requirement that to receive the trust and support of others one must meet satisfactorily the expectations of those who follow.
Is several years of rock-solid distro not satisfactory enough? The developer, being the one who does all the work, is not required to do anything more than that, as far as I can see. If he is willing to do more, great. If not, let him be, he is doing more than anybody in the user community anyway.
Nonetheless, it is very evident from the heated exchanges on this mailing list that there exists a substantial divergence on which path to take from here. It seems to me insupportable that the past practices of a small coterie of initiates deciding on everything without community input will suffice for the future.
Community can provide no useful decisions if the members are not knowledgeable enough to do so. A child cannot educate the parent. A patient cannot educate the doctor. (I seem to be reiterating my previous post... :-) )
If that does become the choice taken then I foresee the community splitting in the future in consequence.
The way I see it, the developers have no problem with community splitting (they even say "use it or don't" quite openly). As a community member, I have no problem with that either, those who are not satisfied here are free to go elsewhere.
If somebody chooses to fork, he'd better be equipped with knowledge and resources to do all the heavy lifting, if he is to succeed. And I wish him luck. But the problem is that "fearful users" do not wish to to fork a project, they wish to redesign the current one, without any merit other than satisfying their own fears about the project's future. And this redesigning puts extra work on developer's shoulders. More pain, no gain for the developers. If I were a dev, I would never accept that.
Finally, please drop the word "meritocracy" in future communications. It implies a natural worthiness of those to whom it is applied which is simply not appropriate to these discussions. The proper word in this circumstance is "oligarchy."
Well, the difference between the two terms is ultimately in the eye of the beholder, ie. the way one defines "merit". So you are free to take your pick.
But for completeness sake, let me just quote some pieces from wikipedia, and let the readers decide for themselves :-) :
"Meritocracy is a system of a government or other organization wherein appointments are made and responsibilities assigned based on demonstrated talent and ability (merit)[1], rather than by wealth (plutocracy), family connections (nepotism), class (oligarchy), friendship (cronyism), seniority (gerontocracy), popularity (democracy) or other historical determinants of social position and political power."
"Technocracy is a form of meritocracy, whereby appointments for positions are made based on demonstrated technical expertise."
"Open Source ------------------ There is a general tendency among open source projects toward meritocracy; the more able a programmer or developer seems, the higher their position (albeit informal) will be. The Apache Software Foundation is an example of an (open source) organization which officially claims to be a meritocracy."
Best, :-) Marko
Marko Vojinovic wrote:
The whole thread put shortly (the way I see it) goes like this:
- A community member shouts "Because of recent dev-internal events, I don't
trust the developers any more, I want the project changed so that I can regain my trust!"
That's not at all what I saw. I saw requests for some transparency and evidence that the project was not likely to fail due to other problems besides the one being disclosed. I saw offers to help being dismissed with no distinction of whether it was out of arrogance or because it was unneeded.
- The developers answer "The changes you propose are unacceptable from our
pov, so you have a choice to continue trusting us, or go find another distro."
- The member than says "No, I want in on development and decision-making in
order to rebuild my trust, regardless of the fact that I have no appropriate technical skills."
- The developers answer "This is a ridiculous proposal, you are a fool to
think we will ever accept that. Our product is there, use it or don't."
None of which really addresses the issue of whether delays like we see in the 4.x security updates are a one-time quirk or something the users should come to expect from here out - or worse. You can't make a decision about replacing your infrastructure product without at least a hint about what to expect next.
During the discussion, things may get emotional and tense to the point of aggrieved tone and name-calling on either side, but essentially --- who is trying to make a blackmail here?
As a casual thread-reader/ordinary-member-of-the-community, one can choose to ignore the discussion or to pick a side. When picking sides, the developers have some credibility in my eyes because of past performance. The other side has little to no credibility from my pov (being "just another community member", afaik), and their behavior is as emotional as that of the developers.
It's not a matter of sides. Everyone wants the project to succeed and continue, there just was not any information until pretty late in the thread.
Having inoculated doubt it is now incumbent upon those who sowed it to address specific concerns raised by those who fear.
I disagree here. The developers have been doing all the heavy lifting here from day one, and have demonstrated superb performance. They have no obligation to address raising fears from members of the community.
Of course a volunteer doesn't have any obligation at all. But if they don't address the obvious issues they shouldn't be surprised at the uproar.
Past performance is the only objective indication of future performance (however "only potential" this may be), and if this is not enough assurance for the members, they should indeed go elsewhere.
Hmmm, I take it you didn't own any GM stock - or any of the other things that have tanked in spite of past performance... Nobody expected infrastructure issues, nobody expected late security updates. But all it would have taken to keep everyone happy would have been a simple explanation from a few insiders as to why they believe that everything will be back to normal and stay that way, explained in some detail instead of dismissing the questions or the reasons they are being asked.
But the fearful members instead choose to press the developers into changing the project structure, only to address their fears. This is irrational and undeserved, especially when one looks at the details of the proposed changes.
It is not irrational to choose something you expect to be supported in the future for your operating system. It's not irrational to worry about it when that future is in question. What happened may be undeserved, but shouldn't have been unexpected.
Community can provide no useful decisions if the members are not knowledgeable enough to do so. A child cannot educate the parent. A patient cannot educate the doctor. (I seem to be reiterating my previous post... :-) )
I take it you don't actually have a child. And probably haven't had a doctor miss-diagnose you yet. And you probably don't have anything to do with producing an actual product that other people use. How do you feel about juries?
James B. Byrne wrote:
Nonetheless, it is very evident from the heated exchanges on this mailing list that there exists a substantial divergence on which path to take from here. It seems to me insupportable that the past practices of a small coterie of initiates deciding on everything without community input will suffice for the future. If that does become the choice taken then I foresee the community splitting in the future in consequence.
Finally, please drop the word "meritocracy" in future communications. It implies a natural worthiness of those to whom it is applied which is simply not appropriate to these discussions. The proper word in this circumstance is "oligarchy."
I've been reading this and other threads on the subject and feel compelled, though I know I'm straying OT, to add my US$0.02 here.
<vent> IMNSHO, the 'heated exchanges' as you've said here, are the result not of fears that the project will collapse or splinter - that, again in my not-so-humble opinion, is FUD and nothing more - but that those of us who reap the rewards of a rock-solid, stable and secure, 100% upstream compatible OS should simply appreciate the golden goose (no disrespect to the CentOS team here, quite the opposite).
From the typical 'when will version XXXX be out' to 'why don't you do it this way' to 'how dare that IRC op say that to me' are daggers which shouldn't be flung at the folks who freely give their time, effort, brain cells and often funds to make CentOS happen.
I've also had a wealth of experience in volunteer organizations, and I still do volunteer my time to several. The work is hard, the rewards are entirely based in the feeling of satisfaction of having done something which makes the world better. The occasional 'thank you' from the folks being helped through the efforts of my chosen volunteer organization is of far greater value than one can put a price on. Do people sometimes get little napoleon complexes? Of course they do. But when there's a common goal, that is quickly evaporated with humor or, when needed, a stern reminder that we're all giving, not taking. In our little distro's volunteer organization, I am well aware that there are far fewer givers than takers. I, myself, am an admitted taker. I use and appreciate this distro and am amazed by the brain trust and dedication which make up our core developers.
The issue of community involvement is simple. The community is free ( as in beer ) to use the mailing list, the forums and submit for publication to the wiki, any additions or updates they choose to provide. They can share their own repos or communicate with the commonly used 3rd party repos for CentOS for sharing what they've done to add to the community. For the core developers to require a vetting process for inclusion to that circle is entirely appropriate, just as it is entirely appropriate for me, if I choose not to endorse what they're doing, to go upstream or elsewhere (Which I'm not doing...but I am wholly free to do so). I'm cognizant of the pros and cons of using this rebuild of upstream's product and I've chosen to be responsible for systems I administer. Thankfully, the members of this community mailing list have saved my <expletive> many times - without an upstream entitlement. It is *that* level of support that makes for positive community involvement. There are countless professionals on this list, of which I am in the lower tiers of knowledge, who offer freely their experience and help. That those professionals include our core development team, makes this distro *very* special.
I applaud the private attempts to get the project's domain owner in line. I further applaud the team for taking it public when no private channel was sufficient. I think it speaks volumes about the integrity of all those currently involved and makes me even more certain that this distro will continue down a healthy path of being 100% binary compatible with upstream and will remain my OS of choice.
The bottom line is that neither meritocracy nor oligarchy are appropriate terms. A distro is a dictatorship (without forced citizenry). A good distro, like this one, is a benign dictatorship. </vent>
<smirk> Long live the kings </smirk>
-Ray
<vent>
</vent>
<smirk> Long live the kings </smirk>
-Ray
I must admit, may be I missed something here, but there seems to be quite a bit of outpouring of appreciation on this thread. I am sure that all that give up their time and effort to make CentOS happen really deserve all the thanks and appreciation they get. I don't think anybody on this list would deny that, certainly not me. On the contrary, my concern is that some guys are potentially overworked or over stressed by the demands of the project. The slowing of the dot releases suggest to me that either the releases are getting technically harder or ppl are less able to give time time to them. Either way, with more releases and the long maintenance period that the CentOS team have committed to things are only going to get harder. According to Karanbir's comments in response to an article (http://broadcast.oreilly.com/2009/08/the-future-of-centos-and-crite.html), CentOS developers are easy to replace. I am not so sure if that really is true if the process isn't documented and there is some kind of induction to get guys on-board before a developer leaves. This represents a risk to the project. One which I am not comfortable with. Part of my professional work is risk assessing system upgrades. I have been doing so long now that everything I professionally do is considered from a risk perspective. Maybe those of us that have to assess risk on a daily basis understand what I am on about and the ones that don't.... don't.
For the record, I don't care whether dictatorship, oligarchy or what ever. Just please don't spread yourselves too thin to a point where walking away is the only option to keep you sane.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ian Murray wrote:
Part of my professional work is risk assessing system upgrades. I have been doing so long now that everything I professionally do is considered from a risk perspective. Maybe those of us that have to assess risk on a daily basis understand what I am on about and the ones that don't.... don't.
Exactly. I once built things on AT&T Unix and hardware. Nice big company with plenty of resources, dedicated, bright developers, a history of following through many releases, and then out of the blue it was gone. Dell was the next choice since it was pretty much the same code base as AT&T SysVr4 with some extra drivers. Then when Windows95 came out, Dell dropped it and pretended they'd never heard of unix. (I understood much later after reading their transcripts in the Microsoft antitrust case...) Then there was Red Hat which didn't really work at the time but had the redeeming features that bugs you reported sometimes got fixed and you didn't have to count licenses - and then that went away too. So yes, I'm paranoid. There aren't many survivors in this business. Hmmm, I left out an interesting interlude with BSDI in there somewhere but they were killed by a lawsuit.
On Tue, Aug 11, 2009 at 3:16 PM, Les Mikeselllesmikesell@gmail.com wrote:
Ian Murray wrote:
Part of my professional work is risk assessing system upgrades. I have been doing so long now that everything I professionally do is considered from a risk perspective. Maybe those of us that have to assess risk on a daily basis understand what I am on about and the ones that don't.... don't.
Exactly. I once built things on AT&T Unix and hardware. Nice big company with plenty of resources, dedicated, bright developers, a history of following through many releases, and then out of the blue it was gone. Dell was the next choice since it was pretty much the same code base as AT&T SysVr4 with some extra drivers. Then when Windows95 came out, Dell dropped it and pretended they'd never heard of unix. (I understood much later after reading their transcripts in the Microsoft antitrust case...) Then there was Red Hat which didn't really work at the time but had the redeeming features that bugs you reported sometimes got fixed and you didn't have to count licenses - and then that went away too. So yes, I'm paranoid. There aren't many survivors in this business. Hmmm, I left out an interesting interlude with BSDI in there somewhere but they were killed by a lawsuit.
I look at CentOS' track record. The foundation has consistently put out a good, solid distribution with regular updates. When that changes, then I'll worry.
But, as you've shown above, there are no absolute guarantees -- so, at some point you've got to go with your gut. Even if CentOS was shaky (which it's not) you still have Scientific Linux and Red Hat -- so it's not like you're putting all your eggs in one basket. From a "risk management" standpoint I think CentOS is a pretty good bet.
I am troubled by the window of opportunity that a hacker has between RH releasing a point release and CentOS releasing the equivalent. Every RH published errata for that stream is a known weakness to your system and there is not a sausage you can do about it until the CentOS project delivers the point release. The quicker it is, the less of a problem, but the slower it is, the more exposed you are. CentOS have not exactly been knocking out the updates very quickly.
Having asked the question on the SL list, I've been informed that they release interim security errata and build all dependencies. They freely admit that doesn't always work and somethings do get missed, especially immediately after RH does a point release. However, as was also pointed out, you have the choice to take the updates or not, so you are never worse off than you are with CentOS, in that respect at least.
________________________________ From: Ron Blizzard rb4centos@gmail.com To: CentOS mailing list centos@centos.org Sent: Tuesday, 11 August, 2009 22:06:05 Subject: Re: [CentOS] CentOS Project Infrastructure
On Tue, Aug 11, 2009 at 3:16 PM, Les Mikeselllesmikesell@gmail.com wrote:
Ian Murray wrote:
Part of my professional work is risk assessing system upgrades. I have been doing so long now that everything I professionally do is considered from a risk perspective. Maybe those of us that have to assess risk on a daily basis understand what I am on about and the ones that don't.... don't.
Exactly. I once built things on AT&T Unix and hardware. Nice big company with plenty of resources, dedicated, bright developers, a history of following through many releases, and then out of the blue it was gone. Dell was the next choice since it was pretty much the same code base as AT&T SysVr4 with some extra drivers. Then when Windows95 came out, Dell dropped it and pretended they'd never heard of unix. (I understood much later after reading their transcripts in the Microsoft antitrust case...) Then there was Red Hat which didn't really work at the time but had the redeeming features that bugs you reported sometimes got fixed and you didn't have to count licenses - and then that went away too. So yes, I'm paranoid. There aren't many survivors in this business. Hmmm, I left out an interesting interlude with BSDI in there somewhere but they were killed by a lawsuit.
I look at CentOS' track record. The foundation has consistently put out a good, solid distribution with regular updates. When that changes, then I'll worry.
But, as you've shown above, there are no absolute guarantees -- so, at some point you've got to go with your gut. Even if CentOS was shaky (which it's not) you still have Scientific Linux and Red Hat -- so it's not like you're putting all your eggs in one basket. From a "risk management" standpoint I think CentOS is a pretty good bet.
On Tuesday 11 August 2009 23:25:23 Ian Murray wrote:
I am troubled by the window of opportunity that a hacker has between RH releasing a point release and CentOS releasing the equivalent. Every RH published errata for that stream is a known weakness to your system and there is not a sausage you can do about it until the CentOS project delivers the point release. The quicker it is, the less of a problem, but the slower it is, the more exposed you are. CentOS have not exactly been knocking out the updates very quickly.
Having asked the question on the SL list, I've been informed that they release interim security errata and build all dependencies. They freely admit that doesn't always work and somethings do get missed, especially immediately after RH does a point release. However, as was also pointed out, you have the choice to take the updates or not, so you are never worse off than you are with CentOS, in that respect at least.
Why don't you go with the SL or even pay RH, if you are that concerned about hacking attempts? It seems clear that CentOS is not a good distro for you if you are not satisfied with its update schedule. I believe it is better to make a different choice of distro, than to ask for substantial changes in the current one, especially if other people should do that extra work for you.
And please don't tell me that SL has other flaws. If security is your first and most important concern, the best thing is to buy RH, it is definitely worth it. If you cannot invest money, go with SL, they have faster updates. If things break, well, at least you didn't get hacked. You should evaluate what is best for your situation and go with it, not ask CentOS to be both rock-solid and fast with updates at the same time.
HTH, :-) Marko
Marko Vojinovic wrote:
Why don't you go with the SL or even pay RH, if you are that concerned about hacking attempts? It seems clear that CentOS is not a good distro for you if you are not satisfied with its update schedule. I believe it is better to make a different choice of distro, than to ask for substantial changes in the current one, especially if other people should do that extra work for you.
And please don't tell me that SL has other flaws. If security is your first and most important concern, the best thing is to buy RH, it is definitely worth it. If you cannot invest money, go with SL, they have faster updates. If things break, well, at least you didn't get hacked. You should evaluate what is best for your situation and go with it, not ask CentOS to be both rock-solid and fast with updates at the same time.
First off, after reading this thread, or should I say book, entirely, like a few others have said, I thank the CentOS developers greatly for all that they do. They spend an incredible amount of time keeping this project going, and I think they do a great job at it, considering it costs nothing to us as users.
What we do at my employer is exactly that. We pay for RH support and updates on business critical servers, and servers that are facing the outside world. We get our updates quickly, and have support available should we need it on those machines that we feel are critical in this regard to security and support.
CentOS fits into our organization by utilizing it for all non-critical deployments, PCs/workstations where they can be used, along with terminals and backup servers inside the network. A lot of our CentOS installations are actually virtualized too. It works out perfectly for us this way.
If you absolutely need updates and your main concern is security, buy some RH support on all machines that you're worried about. Then utilize CentOS on the inside where it's probably not so critical that a patch isn't applied for a few weeks.
This philosophy has served up very well over the years, and we've never had any issues in this regard. CentOS saves our non-profit organization a lot of money every year by applying this configuration, and we get the feel good fuzzy feeling that we have outside machines patched immediately.
While I think there probably are or have been some communications issues with CentOS, I don't think it warrants beating up the developers over it. I cannot begin to understand the build process, since I'm not a developer, but I think people need to cut some slack to those that offer you a product free of charge.
Personally my company chooses and sticks with CentOS because it has been rock-solid, and is always 100% compatible with upstream, which is important to us.
I'm a very un-important CentOS user, but this is how my company runs things, and how we feel, and perhaps you should consider this as well.
Regards, Max
I believe it is better to make
a different choice of distro, than to ask for substantial changes in the current one, especially if other people should do that extra work for you.
Believe what you like, but I believe it's better to raise my concern for discussion in the first instance. For the most part, I am happy with CentOS. I am only trying to suggest how the product may be improved, in my opinion. Why shouldn't I ask for what I like, as long as I am polite? I am not obliging any one. Besides, as has been said before, what I speak of must have merit because there is clearly been an internal discussion about it.
As for using another distro, *of course* that is what I am researching, how are problems solved elsewhere ,etc.
Oh hang on a minute, I am reading too much into what you say.... Now that I think about it, I get what your saying "if you don't like it, then push off somewhere else". Great.
Ian Murray wrote:
I believe it is better to make a different choice of distro, than to ask for substantial changes in the current one, especially if other people should do that extra work for you.
Believe what you like, but I believe it's better to raise my concern for discussion in the first instance. For the most part, I am happy with CentOS. I am only trying to suggest how the product may be improved, in my opinion. Why shouldn't I ask for what I like, as long as I am polite? I am not obliging any one. Besides, as has been said before, what I speak of must have merit because there is clearly been an internal discussion about it.
As for using another distro, *of course* that is what I am researching, how are problems solved elsewhere ,etc.
Oh hang on a minute, I am reading too much into what you say.... Now that I think about it, I get what your saying "if you don't like it, then push off somewhere else". Great.
Personally I think we'd have all been better off walking away from anything related to Red Hat on the day they changed their redistribution policy, but there wasn't a great alternative at the time. Now there's ubuntu and OpenSolaris if I weren't too lazy to learn a new administration style. Maybe if enough people switch RH will go back to selling service without restricting access.
You are probably right there. I lost interest in Linux for ages because of what RH did. It was CentOS that re-ignited my interest. I felt like I could 'get back' what I had lost when Redhat killed RHL. I didn't 'get' the security implications of the rebuild stuff til it was explained to me the other day. I spent some time this morning looking at alternatives to the rebuild type distro because I now realise there are flaws in the approach (not CentOS's fault, before anyone starts!). My day job is a Lotus Domino consultant. Domino is certified to run on RHEL and Suse, AFAIR, so the rebuild is a Godsend. I haven't tried running it on OpenSuse, yet!
________________________________
Personally I think we'd have all been better off walking away from anything related to Red Hat on the day they changed their redistribution policy, but there wasn't a great alternative at the time. Now there's ubuntu and OpenSolaris if I weren't too lazy to learn a new administration style. Maybe if enough people switch RH will go back to selling service without restricting access.
On Wed, 12 Aug 2009, Joseph L. Casale wrote:
I didn't 'get' the security implications of the rebuild stuff til it was explained to me the other day.
Share the knowledge:) Aside from the delay involved while the devs build rpm's from the srpm's, is there more to it?
This thread will never end if it starts running 'DC al Coda' and ad infinitum.
There are build order dependencies, and build environment checking, to get to a 'warts and all' replication of the upstream's binary product, detailed yet again, as I recall in a post from hughesjr earlier in this thread. Karanbir's cited response post as to one of the external press articles alludes to it as well. The 'I think SL is a possibility' subthread as well notes that this is a slippery slope that sometimes has minor cracks.
_Please_ read it from the freely open pipermail archive, rather than reprising here
--Russ herrold
Joseph L. Casale wrote:
I didn't 'get' the security implications of the rebuild stuff til it was explained to me the other day.
Share the knowledge:) Aside from the delay involved while the devs build rpm's from the srpm's, is there more to it?
It's been covered already. When RH does a point release, CentOS has to match the full rebuild before any more security updates go out for some unavoidable technical reasons. RH 4.8 http://www.redhat.com/archives/rhelv4-announce/2009-May/msg00000.html still isn't matched in CentOS, so no security updates in the 4.x line since May. But, if you want to be up to date you probably shouldn't be running a 4.x release anyway - so other than stating the facts I wouldn't want to beat anyone up over this particular issue.
This applies to 5.X as it stands, as 4.X. Once RH 5.4 hits the streets, then CentOS 5 users will be in the same boat. I would hope nobody feels they are getting beaten up about this. The intention is not to beat anybody up. Anyway, I am going to try *really* hard not to post on the matter again (I said that yesterday, but I am going to try *harder*) because I am just repeating myself now, which may come across as brow-beating.
________________________________ From: Les Mikesell lesmikesell@gmail.com To: CentOS mailing list centos@centos.org Sent: Wednesday, 12 August, 2009 3:41:24 Subject: Re: [CentOS] CentOS Project Infrastructure
Joseph L. Casale wrote:
I didn't 'get' the security implications of the rebuild stuff til it was explained to me the other day.
Share the knowledge:) Aside from the delay involved while the devs build rpm's from the srpm's, is there more to it?
It's been covered already. When RH does a point release, CentOS has to match the full rebuild before any more security updates go out for some unavoidable technical reasons. RH 4.8 http://www.redhat.com/archives/rhelv4-announce/2009-May/msg00000.html still isn't matched in CentOS, so no security updates in the 4.x line since May. But, if you want to be up to date you probably shouldn't be running a 4.x release anyway - so other than stating the facts I wouldn't want to beat anyone up over this particular issue.
Ian Murray wrote:
This applies to 5.X as it stands, as 4.X. Once RH 5.4 hits the streets, then CentOS 5 users will be in the same boat. I would hope nobody feels they are getting beaten up about this. The intention is not to beat anybody up. Anyway, I am going to try *really* hard not to post on the matter again (I said that yesterday, but I am going to try *harder*) because I am just repeating myself now, which may come across as brow-beating.
Look ... either use it or not, how many times do we have to hear this?
The same people keep posting the same things.
Everything for 4.8 is built and in qa testing, including the updates after 4.8. We have a COMMUNITY QA team that we have test our distro, this adds a couple weeks to the process. I thought you guys liked community things. This adds a week or two to the release cycle.
4.8 should be released in a couple days as soon as the QA team finishes, assuming there are no major issues (which is how it is looking right now).
If you want the updates when Red Hat releases them, buy Red Hat.
We have a process to release normal updates without the QA team and a QA team period for point releases ... it takes time.
I keep hearing Scientific Linux this and that ... Go back and look at release dates for all the releases and you will see this:
Release SciLinux CentOS 4.0 2005-04-21 2005-03-02 4.1 2005-08-06 2005-06-12 4.2 2005-12-03 2005-10-13 4.3 2006-05-08 2006-03-21 4.4 2006-10-10 2006-08-30 4.5 2007-06-26 2007-05-18 4.6 2008-03-10 2007-12-16 4.7 2008-09-03 2008-09-13 4.8 2009-07-21 *In QA
5.0 2007-05-07 2007-04-12 5.1 2008-01-16 2007-12-02 5.2 2008-06-28 2008-06-24 5.3 2009-03-19 2009-04-01
I post these only to show that in general, the dates are similar with CentOS usually finishing faster.
I do not know how they QA test their distro or if they compare the binaries to upstream like CentOS does. I do know that they do more mods to the base OS than CentOS does:
https://www.scientificlinux.org/about/customize
I also point out that it takes at least a couple of days for us to sync to all the external mirrors so that we can distribute to our millions of users when we update (300ish mirrors in 56 countries world wide). We hold off our release announcement until after most of the external mirrors are updated.
This is taking nothing away from Scientific Linux, they make a great distro. If I was not using CentOS, I would surely be using SL. I'll not bash them on this list, they are good people and do good work. I also have no idea what kind of mirror distribution they have for updates. If you want answers to these questions, I would suggest the SL Mailing lists.
Thanks, Johnny Hughes
On Tue, Aug 11, 2009 at 5:25 PM, Ian Murraymurrayie@yahoo.co.uk wrote:
I am troubled by the window of opportunity that a hacker has between RH releasing a point release and CentOS releasing the equivalent. Every RH published errata for that stream is a known weakness to your system and there is not a sausage you can do about it until the CentOS project delivers the point release. The quicker it is, the less of a problem, but the slower it is, the more exposed you are. CentOS have not exactly been knocking out the updates very quickly.
If security and immediate updates is your main criteria, then you probably are better off with RH. But a lot of people use CentOS and, as far as I can tell, there have not been any major security problems caused by the unavoidable delay between RH's release and CentOS's release. But, as someone else mentioned here, a mixture might be your best option. RH on critical servers and CentOS on less critical ones.
On Tue, 2009-08-11 at 20:42 -0500, Ron Blizzard wrote:
On Tue, Aug 11, 2009 at 5:25 PM, Ian Murraymurrayie@yahoo.co.uk wrote:
I am troubled by the window of opportunity that a hacker has between RH releasing a point release and CentOS releasing the equivalent. Every RH published errata for that stream is a known weakness to your system and there is not a sausage you can do about it until the CentOS project delivers the point release. The quicker it is, the less of a problem, but the slower it is, the more exposed you are. CentOS have not exactly been knocking out the updates very quickly.
If security and immediate updates is your main criteria, then you probably are better off with RH. But a lot of people use CentOS and, as far as I can tell, there have not been any major security problems caused by the unavoidable delay between RH's release and CentOS's release. But, as someone else mentioned here, a mixture might be your best option. RH on critical servers and CentOS on less critical ones.
Ok I have been reading and reading this thread and I finally had to say something. I am a fairly new user to CentOS and as such I supposed am not entitled to my opinion but here goes anyway.
I really don't understand all the griping there has been alot of sniping and other such complaints in the past few weeks and to me it all got started with the open letter to lance, but that is moot now as the problem has been resolved and the powers that be are settings things straight and it has even been said that they have new things planned for us in the future, this is excellent news.
It seems the two complaints thrown out there the most are
A) lack of a contrib or community repo
B) speed of updates
Ok lets address A first - there are several repo's out there that you can use with cent as we all know and if you don't know I refer you here
http://wiki.centos.org/AdditionalResources/Repositories
Now if you still are missing a package that you want I would suggest either learning how to make your own rpm's and make yourself a nice little server and run your own repo I know a great OS that would be ideal for this : )
There has also been hints and such at a contrib repo that may or may not appear at sometime in the future, this is also more excellent news. But again questions have been raised about who can put things in this repo or not. Well that is left up to the powers that be not me or you. So Ideally this really is a moot point because one can use whatever repo they wish to add extra functionality to their machine, or build your own rpm's or dare I say it built it from source( although this is not reccommended).
So on with B - From my understanding the main core of things in cent is maintained from a people that I can count on two hands. So lets put this in the simplest of terms, they are maintaining how many different versions, and as the link provided earlier to the 4 series update this is a large laundry list of things to do. So I can understand why somethings will take a longer time frame sometimes. And I have also did some reading on rebuilding the entire OS from rhel sources and this is not as simple as just rebuilding a src.rpm, be nice if it was though huh.
Ok on with my .02 I am an old RH junkie I started with 7.0 and since they pulled the distro I have been bouncing ever since. With finding cent I have found a home again something I can use is stable and easy to maintain and break if I choose to break it. IMHO other distro's are all just racing for the latest features and who can boot the fastest while most simple and normal desktop features get neglected. My biggest disappointment in this thread is all I read is why cant this ? why cant I, why why why. Where is the How ? How can I help? How can I be of service? How can I help to push updates and releases out faster ? These are the questions that are lacking and should be asked. We are all after the same thing here, we like cent we use cent how can we make a better cent?
The core group has made a clear and concise statement of what the goal of the project is, if this suits you great but you cannot bang on them for staying true to their goals, they never once said - oh you cant use that repo, or you cant do this. Once you download and install its yours use it as YOU see fit. If something should arise where you need help, ask, from my experience so far everyone has been very friendly and willing to help(though not spoon feed) I love that in the IRC topic. If you have idea's or questions by all mean's please ask but do so politely.
The fact of the matter is this I understand all the concerns and questions in this thread but beating a dead horse will solve nothing. Again those of us outside of the core group need to stop griping and beating the core group up over it. We need to stand up and ask - How may I help ? What do you need to get this done. Ask yourself what talents do you have that you can offer the project. There are many ways to do this and you can find them here
http://wiki.centos.org/Contribute
I for one thank the Dev's for their work I know it is time consuming and you guys are doing one hell of a job. I know some of the barking can be discouraging but please do not let a few impede your progress, on what is a great os for us to use, and to finish up may I offer my help in any way I can. I am no super guru by any means but I do have some skills and would be happy to help, and yes I know I have to earn it, so be it I love a challenge, thank you again for the excellent os that is CentOS
On Wednesday 12 August 2009 20:34:55 lostson wrote: <long snip>
We need to stand up and ask - How may I help ? What do you need to get this done. Ask yourself what talents do you have that you can offer the project. There are many ways to do this and you can find them here
http://wiki.centos.org/Contribute
I for one thank the Dev's for their work I know it is time consuming and you guys are doing one hell of a job. I know some of the barking can be discouraging but please do not let a few impede your progress, on what is a great os for us to use, and to finish up may I offer my help in any way I can. I am no super guru by any means but I do have some skills and would be happy to help, and yes I know I have to earn it, so be it I love a challenge, thank you again for the excellent os that is CentOS
+1
Lostson, kill the fatted calf. It's time someone injected some positive thinking into the list.
Anne