The "2005 Readers' Choice Awards" voting is in progress at Linux Journal, and CentOS is Nominated in the "distribution:" category.
So ... all you guys and gals who think CentOS is the best thing ever, get over to:
http://www.linuxjournal.com/article/8266
and vote for CentOS :) ------------------------------- Also, since write ins are allowed on the e-mailed ballot, if you don't have a favorite for the "web hosting service:" category, might I suggest you pick your favorite from the hosting companies on our website who donate servers to the CentOS project:
http://www.centos.org/mirrors/
(one hosting company who is making a server donation now, but it isn't quite setup yet ... and isn't on the donor list just yet is: http://www.eurovps.com/ ) ------------------------------- This is the first round of voting, which ends June 27th and then there will be a final ballot.
Make sure to send in the e-mail ballot in plain text ... and not HTML.
Thanks, Johnny Hughes
On Thursday 02 June 2005 07:35, Johnny Hughes wrote:
So ... all you guys and gals who think CentOS is the best thing ever, get over to:
http://www.linuxjournal.com/article/8266
and vote for CentOS :)
Don't you think in that case one should vote for RHEL? Giving credit where credit is due...
* On Thu, Jun 02, 2005 at 08:58:57AM -0400 Simon Perreault wrote:
On Thursday 02 June 2005 07:35, Johnny Hughes wrote:
So ... all you guys and gals who think CentOS is the best thing ever, get over to:
http://www.linuxjournal.com/article/8266
and vote for CentOS :)
Don't you think in that case one should vote for RHEL? Giving credit where credit is due...
Wouldn't the key word be "Choice" in "2005 Readers' Choice Awards" - not some other criteria such as where "credit is due"?
As in politics, your vote counts no matter the reason it is cast.
Back to lurking.
Mark
On 2 Jun 2005, at 14:40, Mark Frank wrote:
- On Thu, Jun 02, 2005 at 08:58:57AM -0400 Simon Perreault wrote:
On Thursday 02 June 2005 07:35, Johnny Hughes wrote:
So ... all you guys and gals who think CentOS is the best thing ever, get over to:
http://www.linuxjournal.com/article/8266
and vote for CentOS :)
Don't you think in that case one should vote for RHEL? Giving credit where credit is due...
If that's the case, shouldn't the credit vote go to Fedora?
Wouldn't the key word be "Choice" in "2005 Readers' Choice Awards" - not some other criteria such as where "credit is due"?
As in politics, your vote counts no matter the reason it is cast.
Back to lurking.
Mark
"The fix is only temporary...unless it works." - Red Green _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Thursday 02 June 2005 10:20, Christopher Snow wrote:
If that's the case, shouldn't the credit vote go to Fedora?
I think you will agree that the difference between RHEL and Fedora is greater than the one between CentOS and RHEL, enough for RHEL to be a different distro from Fedora.
On Thu, 2005-06-02 at 07:58, Simon Perreault wrote:
On Thursday 02 June 2005 07:35, Johnny Hughes wrote:
So ... all you guys and gals who think CentOS is the best thing ever, get over to:
http://www.linuxjournal.com/article/8266
and vote for CentOS :)
Don't you think in that case one should vote for RHEL? Giving credit where credit is due...
If your favorite choice is accepting a contract that imposes limits on where you can install free software that itself has a license that says additional restrictions cannot be imposed, then by all means pick RHEL.
On Thursday 02 June 2005 10:48, Les Mikesell wrote:
If your favorite choice is accepting a contract that imposes limits on where you can install free software that itself has a license that says additional restrictions cannot be imposed, then by all means pick RHEL.
If you want to explain that sentence, which I am probably too stupid to understand, then by all means do.
On Thu, 2005-06-02 at 10:18, Simon Perreault wrote:
On Thursday 02 June 2005 10:48, Les Mikesell wrote:
If your favorite choice is accepting a contract that imposes limits on where you can install free software that itself has a license that says additional restrictions cannot be imposed, then by all means pick RHEL.
If you want to explain that sentence, which I am probably too stupid to understand, then by all means do.
Almost all of the software in the RHEL distribution is covered by the GPL, which elaborates on your rights to copy and redistribute the software within its own terms and conditions and includes the following literal text in section 6:
"You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
I am not a lawyer, but I don't see any way to reconcile this statement with a restriction that any particular copy of it may only be installed on one computer, even if that restriction comes from a separate contract that provides your service agreement.
Of course, as long as distributions like Centos exist, we can assume that the RH restrictions only apply to their artwork and trademarked name.
On Thursday 02 June 2005 12:04, Les Mikesell wrote:
I am not a lawyer, but I don't see any way to reconcile this statement with a restriction that any particular copy of it may only be installed on one computer, even if that restriction comes from a separate contract that provides your service agreement.
Isn't it acceptable for Red Hat to sell SLAs on a per-computer basis?
I really don't get where you're going.
On Thu, 2005-06-02 at 12:06, Simon Perreault wrote:
I am not a lawyer, but I don't see any way to reconcile this statement with a restriction that any particular copy of it may only be installed on one computer, even if that restriction comes from a separate contract that provides your service agreement.
Isn't it acceptable for Red Hat to sell SLAs on a per-computer basis?
Of course. What does an SLA have to do with restricting copying or redistribution?
I really don't get where you're going.
What kind of restriction would be excluded by the GPL if not ones that restrict copying, installing on additional machines, or redistribution?
On Thursday 02 June 2005 16:01, Les Mikesell wrote:
What kind of restriction would be excluded by the GPL if not ones that restrict copying, installing on additional machines, or redistribution?
Nobody's restricting anyone to do that with RHEL.
Is anybody else as confused as I am?
On Thursday 02 June 2005 10:48, Les Mikesell wrote:
If your favorite choice is accepting a contract that imposes limits on where you can install free software that itself has a license that says additional restrictions cannot be imposed, then by all means pick RHEL.
RHEL's SLA does not in any way impose restrictions on where you can install anything. It does, however, place restrictions on where and how you can or cannot use RHN and its entitlements; that is, if you want to buy RHEL and then install it on more machines than for which you have RHN entitlements, you agree to forfeit your right to use the RHN entitlements; but in no case do you lose the right to continue to use the RHEL installations you currently have installed; you just are blocked from using the RHN service. And you are out the amount of money you paid for the entitlements; not a good bargain.
This is in contrast to say the Microsoft EULA where a license breach causes you to not be able to use the Microsoft software at all from any machine.
On Thu, 2005-06-02 at 11:07, Lamar Owen wrote:
On Thursday 02 June 2005 10:48, Les Mikesell wrote:
If your favorite choice is accepting a contract that imposes limits on where you can install free software that itself has a license that says additional restrictions cannot be imposed, then by all means pick RHEL.
RHEL's SLA does not in any way impose restrictions on where you can install anything. It does, however, place restrictions on where and how you can or cannot use RHN and its entitlements; that is, if you want to buy RHEL and then install it on more machines than for which you have RHN entitlements, you agree to forfeit your right to use the RHN entitlements; but in no case do you lose the right to continue to use the RHEL installations you currently have installed; you just are blocked from using the RHN service. And you are out the amount of money you paid for the entitlements; not a good bargain.
So a contract doesn't 'impose restrictions' because you could accept the penalty of breaking the contract if you wanted? If you look at it that way, what could possibly impose a restriction?
This is in contrast to say the Microsoft EULA where a license breach causes you to not be able to use the Microsoft software at all from any machine.
That's a rather different case. The MS software doesn't start with a license that ensures your right to copy it except in the case where you impose additional restrictions.
On Thursday 02 June 2005 12:46, Les Mikesell wrote:
On Thu, 2005-06-02 at 11:07, Lamar Owen wrote:
On Thursday 02 June 2005 10:48, Les Mikesell wrote:
If your favorite choice is accepting a contract that imposes limits on where you can install free software
RHEL's SLA does not in any way impose restrictions on where you can install anything.
So a contract doesn't 'impose restrictions' because you could accept the penalty of breaking the contract if you wanted? If you look at it that way, what could possibly impose a restriction?
If you break the Red Hat contract, Red Hat cannot remove your right to continue to run the RHEL servers you have already installed; they just simply would refuse your login to RHN to fetch updates. So you lose updates; this is one reason to buy RHEL in the first place, making it nice to follow the terms of the RHN SLA. RHN!=RHEL. So you could word it like: "So, if you want to continue to use the Red Hat Network to retrieve updates, you may only have the number of RHEL installations for which you have purchased RHN entitlements. If you install RHEL to more machines than which you have entitlements, you lose your access to RHN for any machines entitled." But this does not restrict your right to the code in the kernel, gcc, or other GPL licensed software inside the distribution, or for that matter does not restrict the right for you to take that software (other than the RH trademarks) and redistribute it in part or total (as long as you are happy to lose all your entitlements to RHN, but losing RHN entitlements does not mean you have to return your CD's or uninstall RHEL from all your servers).
But remember, there are other licenses present in RHEL: apache, X, PostgreSQL, Perl, among others are not GPL. The RHEL artwork is not freely redistributable, for instance. Red Hat didn't go the SuSE route though and not freely license their installer; Anaconda is GPL, but YaST was not, thus you couldn't even do with SuSE what is being done now with RHEL.
As a great example, PostgreSQL is a BSD-licensed package. Red Hat has made significant contributions to the PostgreSQL community (one by providing full-time PostgreSQL employment for Tom Lane, a Core PostgreSQL developer, two by paying for several enhancements and backported bugfixes): Red Hat is not required by the terms of the BSD license to return ANYTHING to the PostgreSQL community, nor are they required to make their version of PostgreSQL, Red Hat Database (now known as PostgreSQL, Red Hat Edition) source code available to anyone. But they did make it available.
On Thu, 2005-06-02 at 13:19, Lamar Owen wrote:
RHEL's SLA does not in any way impose restrictions on where you can install anything.
So a contract doesn't 'impose restrictions' because you could accept the penalty of breaking the contract if you wanted? If you look at it that way, what could possibly impose a restriction?
If you break the Red Hat contract, Red Hat cannot remove your right to continue to run the RHEL servers you have already installed; they just simply would refuse your login to RHN to fetch updates. So you lose updates;
Let me ask again... What could possibly impose a restriction if you don't the consider the penalties of contract breakage to be a restriction? Since RH does permit source redistribution regardless and hence the existence of projects like Centos, they are not strictly breaking the GPL here, but if that contract isn't a restriction I'd like someone to explain what would be in the sense excluded by the GPL.
But remember, there are other licenses present in RHEL: apache, X,
I'm not a particular fan of the GPL. I just don't see how it works to distribute GPL'd stuff along with a contract that imposes additional restrictions and penalties for breaking them.
On Thursday 02 June 2005 15:43, Les Mikesell wrote:
Let me ask again... What could possibly impose a restriction if you don't the consider the penalties of contract breakage to be a restriction? Since RH does permit source redistribution regardless and hence the existence of projects like Centos, they are not strictly breaking the GPL here, but if that contract isn't a restriction I'd like someone to explain what would be in the sense excluded by the GPL.
'Additional restrictions' is meant to include things like: 1.) You can use my software under the GPL unless you're commercial; 2.) You can use my software under the GPL unless you are located in a country allowed by the US; 3.) You can use my software under the GPL as long as you give me credit on your website; 4.) You can use my software under the GPL as long as you don't try to design software that competes with mine; etc. These are the restrictions meant by the GPL; the FSF has in fact found that Red Hat's SLA's don't violate the GPL, even though they're not terribly happy about them.
Red Hat's SLA simply says 'you can use this software under the GPL. Additionally, as long as you follow our contract, you can use the value-added service of RHN to update your software.' The SLA does not restrict your use or distribution of the software itself; it restricts your use of the RHN service to conditions of the contract. If you break the contract, you do not lose the right to the GPL covered software; it is still usable and redistributable by you. You simply lose the ability to use RHN and get updates (inlcuding major version upgrades like RHEL3 to 4 if you so chose). However, there may be other penalties; but nowhere do those penalties include the lose of the right to use or distribute the GPL covered software in RHEL.
On Thu, 2005-06-02 at 14:19 -0400, Lamar Owen wrote:
redistributable, for instance. Red Hat didn't go the SuSE route though and not freely license their installer; Anaconda is GPL, but YaST was not, thus you couldn't even do with SuSE what is being done now with RHEL.
Ummm after SuSE was purchased by Novell YaST was released under the GPL. Also IIRC you can download ISOs of SuSE Linux since the real product now is SLES, NLD and OES ... SuSE Linux is more like Fedora now.
Paul
On Thursday 02 June 2005 22:29, Paul wrote:
On Thu, 2005-06-02 at 14:19 -0400, Lamar Owen wrote:
redistributable, for instance. Red Hat didn't go the SuSE route though and not freely license their installer; Anaconda is GPL, but YaST was not, thus you couldn't even do with SuSE what is being done now with RHEL.
Ummm after SuSE was purchased by Novell YaST was released under the GPL.
Which is why I used past tense in my statement. You can now do these things, but there was a time when one could not.
On Thu, 2005-06-02 at 21:29 -0500, Paul wrote:
Ummm after SuSE was purchased by Novell YaST was released under the GPL.
I think that's why he used the word "was" [Confirm?]
Also IIRC you can download ISOs of SuSE Linux since the real product now is SLES, NLD and OES ... SuSE Linux is more like Fedora now.
As so it would seem. If Novell is opening up "SuSE(R) Linux" then I have to assume they are going to do something about the "SuSE(R) Linux Enterprise Server" product since it shares the same trademark.
As many have heard me say before, it's funny to see Red Hat and SuSE go back and forth, covering the same tech-legal-source issues, one after another, learning from each other.
One difference was that SuSE never opened up the Trademark. In Germany, it would have been deadly.
On Thu, 2005-06-02 at 08:58 -0400, Simon Perreault wrote:
On Thursday 02 June 2005 07:35, Johnny Hughes wrote:
So ... all you guys and gals who think CentOS is the best thing ever, get over to:
http://www.linuxjournal.com/article/8266
and vote for CentOS :)
Don't you think in that case one should vote for RHEL? Giving credit where credit is due...
No ... not at all. RedHat does not spend any time making sure that the people who use CentOS can get free updates.
They did not put together a world wide mirror network for free that everyone can use to get free enterprise level software.
I am sick and tired of people minimizing the work that the CentOS Developement Team does.
If you don't want to use CentOS, then don't use it ... but it is not easy to maintain a distro based on RHEL ... (or anything else for that matter).
So, no, if you like and use CentOS, you should vote for CentOS.
A couple hundred thousand people use it ... and hopefully they appreciate the amount of work it takes to maintain.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Johnny Hughes wrote: | | No ... not at all. RedHat does not spend any time making sure that the | people who use CentOS can get free updates. | | They did not put together a world wide mirror network for free that | everyone can use to get free enterprise level software. | | I am sick and tired of people minimizing the work that the CentOS | Developement Team does. | | If you don't want to use CentOS, then don't use it ... but it is not | easy to maintain a distro based on RHEL ... (or anything else for that | matter). | | So, no, if you like and use CentOS, you should vote for CentOS. | | A couple hundred thousand people use it ... and hopefully they | appreciate the amount of work it takes to maintain.
Johnny,
I certainly appreciate all of the work that has gone into CentOS. I've not done that ballot just yet, but I will certainly be casting my vote for CentOS.
Thanks Johnny for the work.
- -- Alex White prata@kuei-jin.org Fingerprint = 58DC 9199 CE73 74E8 B2C1 442E ACF5 92E0 E068 C46C gpg key location: http://www.kuei-jin.org/GPG-KEY-PRATA ~From the withered tree, a flower blooms --Zen Proverb
On Thu, 2005-06-02 at 18:31 -0500, Johnny Hughes wrote:
No ... not at all. RedHat does not spend any time making sure that the people who use CentOS can get free updates. They did not put together a world wide mirror network for free that everyone can use to get free enterprise level software. I am sick and tired of people minimizing the work that the CentOS Developement Team does.
I agree. Everyone stands on the shoulders of others. And _no_one_ is greater than anyone else. We're all a GPL community that works together.
[ You'll note that I carefully said "GPL." ]
If you don't want to use CentOS, then don't use it ... but it is not easy to maintain a distro based on RHEL ... (or anything else for that matter). So, no, if you like and use CentOS, you should vote for CentOS.
Once again, I agree.
A couple hundred thousand people use it ... and hopefully they appreciate the amount of work it takes to maintain.
And I think votes like this are a great way to let people know.
On Thursday 02 June 2005 19:31, Johnny Hughes wrote:
So, no, if you like and use CentOS, you should vote for CentOS.
As I did a few minutes ago.
A couple hundred thousand people use it ... and hopefully they appreciate the amount of work it takes to maintain.
Appreciation is a mild word for the feeling people should have for this effort.
On Thursday 02 June 2005 19:31, Johnny Hughes wrote:
No ... not at all. RedHat does not spend any time making sure that the people who use CentOS can get free updates.
I think you will agree with me that the amount of work Red Hat put on CentOS (by way of RHEL) is much more significant than the work put on CentOS by CentOS volunteers. That is not to say that the work of CentOS volunteers is not to be appreciated. Don't get all worked up for nothing.
On Fri, 2005-06-03 at 07:33 -0400, Simon Perreault wrote:
On Thursday 02 June 2005 19:31, Johnny Hughes wrote:
No ... not at all. RedHat does not spend any time making sure that the people who use CentOS can get free updates.
I think you will agree with me that the amount of work Red Hat put on CentOS (by way of RHEL) is much more significant than the work put on CentOS by CentOS volunteers. That is not to say that the work of CentOS volunteers is not to be appreciated. Don't get all worked up for nothing.
I am a little touchy on this subject ... being that I hear it so often.
I disagree ... the work that RedHat put into RHEL is significant. It is a great distro, and worthy to win this award and many others ... but so is CentOS.
If you think RHEL is a BETTER distro than CentOS, you should vote that way.
BUT ... they didn't put any work into CentOS. All their work was put into RHEL. They are compensated fairly well for that work too, I might add.
I, on the other hand, spend an average of 8-12 hours a day on CentOS related activities. As does Karanbir Singh (z00dax on IRC). Most of the other developers spend almost as much time as well. Not only do we not get paid anything for doing that, some of us end up having to pay for centos related things (I have increased my bandwidth, bought compile platforms, changed my home network infrastructure, etc. to be able to better build CentOS and decrease the release times, at my own expense). This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
As pointed out many times before on this list, RedHat is a great company, and they do a lot of things for the OSS community ... but they are not the "owners" of the code that CentOS uses. They get almost all the items they publish from somewhere else. They are required, therefore, to make their source code public. They take that requirement seriously, and they do an outstanding job of publishing their source code openly. They should be commended for that. I do it every chance I get :)
They published their Source code, as required by the GPL. They added Trademark requirements. We took their GPL work, modified it to comply with their Trademark requirements (we actually go much further than their stated requirements), and to created a distro. A significant amount of their packages have to be modified to build properly ... all of them have to be reviewed.
Using your logic, The only people who would get credit are the programmers who write the code for the parent projects. Or the Fedora Core volunteers who actually package and test probably 95% of the stuff that get into RHEL.
So no, I don't think that you should vote for RHEL in a place where CentOS is also listed ... any more than I think you should vote for Debian if you use Ubuntu. If CentOS isn't in that poll, then voting for RHEL would be fine. Now, if someone feels that RHEL is a better Distro than CentOS (as distributed) ... then they should absolutely vote for RHEL instead of CentOS.
That is, of course, only my opinion. You have yours. We are both entitled to our own. Neither is right or wrong.
On Friday 03 June 2005 08:48, Johnny Hughes wrote:
I am a little touchy on this subject ... being that I hear it so often.
Yes, I understand that.
Using your logic, The only people who would get credit are the programmers who write the code for the parent projects. Or the Fedora Core volunteers who actually package and test probably 95% of the stuff that get into RHEL.
No. People should get credit in an amount proportionate to the amount of work they put in. If I'm evaluating a distro, I look at all the people who made the distro. And because I'm voting for a distro, I don't take into account the upstream programmers because their work goes into all the other distros so that's not a differentiating factor. So basically the people who made CentOS are: Red Hat and CentOS and Fedora volunteers. I don't know the percentage, but I'm fairly sure Red Hat gets most of the credit.
But the basic point is that CentOS is not a fork. It does not give added value over RHEL in the distro itself. It *is* RHEL, with a community and removed trademarks. So CentOS volunteers should get credit for the community and removing trademarks and Red Hat should get credit for everything else (ie. what we're voting for).
So no, I don't think that you should vote for RHEL in a place where CentOS is also listed ... any more than I think you should vote for Debian if you use Ubuntu.
Ubuntu is a fork of Debian with added value, not a rebranding.
That is, of course, only my opinion. You have yours. We are both entitled to our own. Neither is right or wrong.
Sure, this is only friendly discussion.
On Jun 3, 2005, at 9:10 AM, Simon Perreault wrote:
But the basic point is that CentOS is not a fork. It does not give added value over RHEL in the distro itself. It *is* RHEL, with a community and removed trademarks. So CentOS volunteers should get credit for the community and removing trademarks and Red Hat should get credit for everything else (ie. what we're voting for).
i assume you think that this directory magically populated itself? :)
http://mirror.centos.org/centos/4/centosplus/
and Red Hat pays for the creation and maintenance of this mirror network?
http://www.centos.org/modules/tinycontent/index.php?id=13
and Red Hat employees work to resolve these bugs?
http://bugs.centos.org/view_all_bug_page.php
i'm not sure you've considered your position thoroughly.
-steve
--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
On Friday 03 June 2005 09:20, Steve Huff wrote:
i assume you think that this directory magically populated itself? :)
http://mirror.centos.org/centos/4/centosplus/
and Red Hat pays for the creation and maintenance of this mirror network?
That's what I was referring to by "community".
and Red Hat employees work to resolve these bugs?
I agree with you that resolving these bugs in CentOS creates additional value for CentOS, and makes CentOS more of a fork rather than a rebranding. However these bugs should also be reported to Red Hat.
i'm not sure you've considered your position thoroughly.
I am, and I will say it again just for the shock value:
Red Hat is the main developer of CentOS.
On Jun 3, 2005, at 10:36 AM, Simon Perreault wrote:
That's what I was referring to by "community".
i may be misinterpreting your statements, but you seem to be dismissing the "community" as something of little importance and its creation and maintenance as a trivial task. i believe you are mistaken.
I agree with you that resolving these bugs in CentOS creates additional value for CentOS, and makes CentOS more of a fork rather than a rebranding. However these bugs should also be reported to Red Hat.
i don't see anything in the CentOS bugzilla that precludes those bugs being reported to Red Hat. are you saying that CentOS developers should *not* work on those bugs, and should instead wait for Red Hat to address them? if so, why?
-steve
--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
On Friday 03 June 2005 10:46, Steve Huff wrote:
i may be misinterpreting your statements, but you seem to be dismissing the "community" as something of little importance and its creation and maintenance as a trivial task. i believe you are mistaken.
I just think that a vote for "best distro" should be based on the distro, not on its community.
i don't see anything in the CentOS bugzilla that precludes those bugs being reported to Red Hat. are you saying that CentOS developers should *not* work on those bugs, and should instead wait for Red Hat to address them? if so, why?
Because
1) It is assumed that Red Hat will fix them anyway. 2) There's a lot of other stuff to do so less time spent doing Red Hat's job is more time doing stuff Red Hat won't do.
Steve Huff wrote:
I agree with you that resolving these bugs in CentOS creates additional value for CentOS, and makes CentOS more of a fork rather than a rebranding. However these bugs should also be reported to Red Hat.
And they are..
i don't see anything in the CentOS bugzilla that precludes those bugs being reported to Red Hat. are you saying that CentOS developers should *not* work on those bugs, and should instead wait for Red Hat to address them? if so,
Non CentOS specific issues are always reported upstream by CentOS Developers, and where possible we try and provide patches, fix's and/or commentary that would help the upstream developers address these issues.
Everyone is working on a common code base, fix's help everyone.
- KB
On Fri, 2005-06-03 at 09:36, Simon Perreault wrote:
i'm not sure you've considered your position thoroughly.
I am, and I will say it again just for the shock value:
Red Hat is the main developer of CentOS.
I'd put it this way instead: Red Hat is responsible for any difficulty in creating the CentOS distribution, while sharing the same upstream developers as all other Linux distributions.
BULLSHIT
On Fri, 3 Jun 2005, Les Mikesell wrote:
On Fri, 2005-06-03 at 09:36, Simon Perreault wrote:
i'm not sure you've considered your position thoroughly.
I am, and I will say it again just for the shock value:
Red Hat is the main developer of CentOS.
I'd put it this way instead: Red Hat is responsible for any difficulty in creating the CentOS distribution, while sharing the same upstream developers as all other Linux distributions.
On Friday 03 June 2005 11:48, Les Mikesell wrote:
I'd put it this way instead: Red Hat is responsible for any difficulty in creating the CentOS distribution, while sharing the same upstream developers as all other Linux distributions.
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do; source doesn't have to be provided in SRPM form to meet the GPL-covered packages license requirements). The CentOS teams builds upon a foundation laid; the building is the work of the CentOS team, but it would fall were it not for the foundation.
Also, while Red Hat may share the upstream developers as all other Linux distributions, let's not forget that Red Hat (as well as SuSE and others) employ many of these upstream developers and share their work product open source with their competitors.
Or, more bluntly, the SRPM tree for RHEL didn't just magically appear out of nothing. And there is a significant difference in a tree of SRPMs ready to roll (with some modifications, as Johnny said, since RHEL isn't self-hosted) and having a tree of upstream tarballs with no spec files to tell where to put the files, build with the unified options, etc. I have written spec files, and have maintained a specfile of moderate complexity; spec file hacking is not trivial. Then there's the work of building an installable ISO image or image set; this is nontrivial as well.
On Fri, 2005-06-03 at 21:26, Lamar Owen wrote:
I'd put it this way instead: Red Hat is responsible for any difficulty in creating the CentOS distribution, while sharing the same upstream developers as all other Linux distributions.
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do;
I was just having a moment of nostalgia for the old days. Do you remember the time when Red Hat was building their reputation and building a free version of Red Hat Linux took exactly *no* extra work by another team that might instead be adding value by packaging new programs in their repository?
I have written spec files, and have maintained a specfile of moderate complexity; spec file hacking is not trivial. Then there's the work of building an installable ISO image or image set; this is nontrivial as well.
There are other distributions. Much of the value of this one comes from that RPM-packaging work by others - much of which was started when (and because) the RH base distribution was freely available.
On Fri, 2005-06-03 at 22:22 -0500, Les Mikesell wrote:
I was just having a moment of nostalgia for the old days. Do you remember the time when Red Hat was building their reputation and building a free version of Red Hat Linux took exactly *no* extra work by another team that might instead be adding value by packaging new programs in their repository?
Yes. And it nearly got "Red Hat(R)" declared public domain by the USPTO. No other commercial distributor has had their distribution with trademark so grossly modified and redistributed.
Hence why Red Hat went with Fedora(TM).
Everything else was already in motion. If you have a real problem with it, then run Fedora Core. Red Hat _never_ promised more than 1 year of updates with Red Hat Linux prior either. And Fedora Core is developed with the same model as Red Hat Linux.
If Fedora Core's quality tanks, then Red Hat Enterprise Linux's will as well.
There are other distributions. Much of the value of this one comes from that RPM-packaging work by others - much of which was started when (and because) the RH base distribution was freely available.
??? I don't remember too many forks returning fixes to Red Hat. Most of them went their own route. And it became extremely frustrating for Red Hat at times to see heavily modified versions still bearing their trademarks.
But they held steadfast until it became a real legal issue for them.
BTW, a lot of people in the community contributed fixes for Red Hat Linux directly. And that is largely how Fedora Core continues to work as well. A project by Red Hat, but with community support. And Red Hat is basically the largest commercial employer of GPL software developers.
On Fri, 2005-06-03 at 22:22 -0500, Les Mikesell wrote:
I was just having a moment of nostalgia for the old days. Do you remember the time when Red Hat was building their reputation and building a free version of Red Hat Linux took exactly *no* extra work by another team that might instead be adding value by packaging new programs in their repository?
BTW, I don't know what you are talking about on this.
A _lot_ of people who worked on forks used to complain about RPM _in_compatibility with Red Hat. Different projects and different people maintaining different versions would clash, compatibility nightmares resulted -- especially on a lot of forks.
Worse yet, because they didn't remove the trademarks, people assumed it was Red Hat, and that it wasn't compatible with itself. The forks actually made it far worse, while people assumed they were still Red Hat Linux.
Cobalt was a perfect example. I'd hear people complain about Red Hat having "too much control" over what was released, then they'd turn around and say "we need to break from Red Hat" -- all when that's what they _already_did_!
And even then, Red Hat tried to clarify its trademark guidelines and other issues. And people just ignored them. It really didn't come to a point until Sun bought Cobalt, and was just blatantly redistributing all sorts of modifications that were nothing like the original Red Hat Linux, with all the trademarks intact.
And when Red Hat tried to get them to stop, that's when their entire history of allowing their trademark to be freely redistributed came back to haunt them.
You say "*no* extra work"? Hardly! The forks and just blatant mis- appropriation of "Red Hat(R)" caused a lot of headaches before. Because everyone was releasing modifications of Red Hat Linux -- some just with updates (which Red Hat allowed under several of its guideline revisions), and some completely built for other architectures, with complete changes in GCC, GLibC and other components.
At this point, I don't know what fantasy world you live in, but it's getting old. People keep "re-inventing" this Red Hat Linux history that _never_ existed. Nothing has changed other than Red Hat put its foot down on trademarks because companies like Sun finally forced them to.
Today, we have the Fedora Project. It's not perfect, but Red Hat is trying, and re-trying and will continue to try to "get it right." Fedora Core is developed just as Red Hat Linux always was.
On Fri, 2005-06-03 at 23:38, Bryan J. Smith wrote:
I was just having a moment of nostalgia for the old days. Do you remember the time when Red Hat was building their reputation and building a free version of Red Hat Linux took exactly *no* extra work by another team that might instead be adding value by packaging new programs in their repository?
BTW, I don't know what you are talking about on this.
A _lot_ of people who worked on forks used to complain about RPM _in_compatibility with Red Hat.
I'm talking about 3rd party efforts at RPM packaging. In most cases, my decision to use RH in any particular situation was motivated by the odds that any add-on software I wanted would already be available in RH compatible RPMs. And, I think that was mostly true because the RH base was freely available. Now there there are probably more .deb packages available, but it is painful to switch existing installations, especially after getting used to the RH init script conventions and all the gunk in /etc/sysconfig.
And I didn't mean forked distributions at all - I was referring to the time when forks were not necessary for free copies.
On Friday 03 June 2005 23:22, Les Mikesell wrote:
On Fri, 2005-06-03 at 21:26, Lamar Owen wrote:
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do;
I was just having a moment of nostalgia for the old days. Do you remember the time when Red Hat was building their reputation and building a free version of Red Hat Linux took exactly *no* extra work by another team that might instead be adding value by packaging new programs in their repository?
Yes I do. I remember the first time Red Hat 4 was a new Linux version. Times have changed, and the Fedora Project holds the position once held by the 'regular' Red Hat Linux, other than the 'boxed set' angle. Red Hat being able to stay in business to help support Open Source Software (which they do, in spades) is a good enough reason for me for the current situation. They genuinely thought that this was the only way; people who are in the know have stated that there are still warehouses full of boxed sets of Red Hat Linux 5.x, 6.x, and 7.x. With RHEL they sell fewer boxes, but sell more product, driving the cost down and making it possible for them to employ some of the best open source hackers around, like Ulrich Drepper, Alan Cox, Jacob Jelinek, Tom Lane, and many others. Maybe these fine folk would find employment elsewhere, and maybe they wouldn't; fact is Red Hat pays them to work on Open Source, and we benefit from their upstream work, funded in part by Red Hat.
Yes, Fedora changes too quickly. That's why I'm here with CentOS instead. Tried WhiteBox; kindof an odd situation there; haven't followed it from version 4, but had some problems with version 3. Why don't I use RHEL? Too expensive for my operation here at PARI. If CentOS weren't around I'd be doing a from source rebuild for myself.
One size does not fit all.
On Sat, 2005-06-04 at 08:40 -0400, Lamar Owen wrote:
They genuinely thought that this was the only way; people who are in the know have stated that there are still warehouses full of boxed sets of Red Hat Linux 5.x, 6.x, and 7.x. With RHEL they sell fewer boxes, but sell more product, driving the cost down and making it possible for them to employ some of the best open source hackers around, like Ulrich Drepper, Alan Cox, Jacob Jelinek, Tom Lane, and many others.
It's all about economies of scale. The less you sell compared to your competitor, the higher price you have to sell to match your competitor.
I also want to point out that the 18-month release cycle for a product is heavily preferred by CompUSA and other retailers. They have a lot of old stock of 6-month release cycle products that got returned to Red Hat.
Novell is seeing the same thing happen with 6-month SuSE Linux Professional v. their new 18-month Novell Linux Desktop. So like Red Hat stopped selling Red Hat Linux 9 in the stores and switched to Red Hat Professional Workstation (RHEL WS), now Red Hat Desktop (also RHEL WS), I seriously doubt we'll see a SuSE Linux product in a retail box come version 10.
On Sat, 2005-06-04 at 07:40, Lamar Owen wrote:
Yes I do. I remember the first time Red Hat 4 was a new Linux version. Times have changed, and the Fedora Project holds the position once held by the 'regular' Red Hat Linux, other than the 'boxed set' angle.
Well, no. Fedora sort-of matches the X.0 Red Hat Releases that, after one or a few trials, most system administrators knew to avoid in production and wait for the usable X.2 version that developed quickly because the bait of a free reliable version drew help from a huge community in fixing the initial bugs that were always pushed out. But Fedora never gives you the fixed/usable release.
Red Hat being able to stay in business to help support Open Source Software (which they do, in spades) is a good enough reason for me for the current situation. They genuinely thought that this was the only way; people who are in the know have stated that there are still warehouses full of boxed sets of Red Hat Linux 5.x, 6.x, and 7.x.
I don't doubt that there were a lot of bad decisions made about the quantity and pricing for those boxes - or even where to try to sell them. And if anyone is still storing a boxed copy in a warehouse they are still making a mistake. They didn't have to switch away from their initial good ideas to drop the bad ones.
With RHEL they sell fewer boxes, but sell more product, driving the cost down and making it possible for them to employ some of the best open source hackers around, like Ulrich Drepper, Alan Cox, Jacob Jelinek, Tom Lane, and many others. Maybe these fine folk would find employment elsewhere, and maybe they wouldn't; fact is Red Hat pays them to work on Open Source, and we benefit from their upstream work, funded in part by Red Hat.
But what Red Hat claims to be selling is support, not product. And Centos as a free product actually makes that claim come true. However, it is more work for everyone and takes away any feeling of community support behind Red Hat. I do understand why they insist on removing the trademarks on modified products but in the Centos case that is the only reason the product is modified in the first place. It doesn't make any sense compared to continuing to allow free distribution of an unmodified product without support.
Why don't I use RHEL? Too expensive for my operation here at PARI. If CentOS weren't around I'd be doing a from source rebuild for myself.
Exactly - and how is anyone better off than they would be seeing Red Hat trademarked products in all those places where the paid support is unnecessary or overpriced and feeling like part of a single community when they report a bug, recommend the product or help someone else install it? Ahh, nostagia - I fell for the bait...
One size does not fit all.
Right, but you probably no longer even recommend trying on that badly-fitting model. And since it now seems unrelated to anything you use, you are probably much less motivated to test the upstream side which, in case anyone forgets, is what actually makes this stuff usable. Dig up one of those prettily-boxed X.0 sets and try to run it if you need help remembering what the developers push out *before* they get the user feedback. If you aren't using Fedora now, who is going to supply the wide scale testing that will make some future Centos better? Hmmm, maybe Fedora will try to re-claim the community now. It will be interesting to see if they use their new independence to re-institute point releases or some similarly usable product as a reward for the pain of testing the initial releases.
On Sat, 2005-06-04 at 12:57 -0500, Les Mikesell wrote:
But Fedora never gives you the fixed/usable release.
Actually, that started with Red Hat Linux 9. But yes, it is one of my largest complaints as well.
On Saturday 04 June 2005 13:57, Les Mikesell wrote:
Well, no. Fedora sort-of matches the X.0 Red Hat Releases that, after one or a few trials, most system administrators knew to avoid in production and wait for the usable X.2 version that developed quickly because the bait of a free reliable version drew help from a huge community in fixing the initial bugs that were always pushed out. But Fedora never gives you the fixed/usable release.
FC3 is very stable, very close to RHEL4, and many packages in RHEL4 are bit-for-bit at the executable level identical to the FC3 package. Check for yourself.
It doesn't make any sense compared to continuing to allow free distribution of an unmodified product without support.
They tried that. Some distributors modified the result AND still called it Red Hat Linux. This is known as trademark dilution, and is intolerable from a corporate standpoint.
One size does not fit all.
Right, but you probably no longer even recommend trying on that badly-fitting model. And since it now seems unrelated to anything you use, you are probably much less motivated to test the upstream side which, in case anyone forgets, is what actually makes this stuff usable. Dig up one of those prettily-boxed X.0 sets and try to run it if you need help remembering what the developers push out *before* they get the user feedback.
Since I was a part of the Red Hat Beta Team I installed prior to x.0 releases, and saw just how much better the x.0 was as a result. Was it perfect? Not really, but for the most part the x.0 release was a far cry more stable than three or four beta releases prior, which were just RawHide snapshots.
If you aren't using Fedora now, who is going to supply the wide scale testing that will make some future Centos better? Hmmm, maybe Fedora will try to re-claim the community now. It will be interesting to see if they use their new independence to re-institute point releases or some similarly usable product as a reward for the pain of testing the initial releases.
I think the idea was to replace the closed, small, Red Hat Beta Team with a much wider community and open the development up where more testers get a swing at the codebase. This has happened to a degree. However, the trademark issue came to a head, and the name had to be different for it to be a real community release. What's in a name, anyway, if you know the packages are the same or very close? (I know, marketing people will harangue me for that....) But apparently there is a perception issue related to 'Red Hat' versus 'Fedora' (and woe to the pre-existing Fedora Project (not even related to Linux)).
Had the split not happened I would likely have had to reduce my activities in the beta process anyway, as it became too time-intensive and more and more difficult to justify testing releases and using scads of bandwidth downloading updates where the set of updated packages was basically the whole distribution. At this point, I really need the stability of the EL line, but quite honestly can't afford the EL line. And I'm talking stability within a version. But at the same time I need the flexibility of adding a few things; like KDE3.4 or later to a dist that ships (and only supports) KDE 3.3. Modify your RHEL install and Red Hat may refuse to support it; you do so at your own peril, and at that point you might as well run a community OS instead.
On Sat, 2005-06-04 at 15:29 -0400, Lamar Owen wrote:
FC3 is very stable, very close to RHEL4, and many packages in RHEL4 are bit-for-bit at the executable level identical to the FC3 package. Check for yourself.
Yes. And Fedora Core 1 was largely a maturity of Red Hat Linux 9, which was already a majority of Red Hat Linux 8. Because the 2-2-2 and 6-6-6 model is still there.
Now I wish Red Hat would make Fedora Core 4 an even more mature version of the FC2-3 series. But they are moving forward with GCC 4.0. I can understand that, given there was a lot of time between FC3 and RHEL4's release, so FC3 and RHEL4 are about as mature as they can get.
A lot of any "immaturity" in FC3/RHEL is really more about Linux 2.6 (including LVM2, CIPE, etc...). And as Linux 2.6 matures, so will anything based on it. After all, it took a long time for Linux 2.4 to mature in the RHL7.x series too, before becoming quite solid in FC1/RHEL3.
If you don't want to deal with Linux 2.6 yet, then stick with FC1 or RHEL3, and wait on FC5/RHEL5.
On Sat, 2005-06-04 at 14:29, Lamar Owen wrote:
But Fedora never gives you the fixed/usable release.
FC3 is very stable, very close to RHEL4, and many packages in RHEL4 are bit-for-bit at the executable level identical to the FC3 package. Check for yourself.
I'm using it - and crashing regularly with a raid on firewire setup... Other than that oddball configuration it might be OK now, but look at all the updates you have to download after an install to get that mostly-usable version. If they'd roll out a respin with the fixes on new install images when the initial bugs are mostly fixed it might be reasonable to use.
On Sat, 2005-06-04 at 21:21 -0500, Les Mikesell wrote:
I'm using it - and crashing regularly with a raid on firewire setup...
Well, that's just asking for trouble on most platforms (NT and Darwin included).
Other than that oddball configuration it might be OK now, but look at all the updates you have to download after an install to get that mostly-usable version.
Was this any different then RHL7.x/RHAS2.1? It adopted the 2.4 kernel early too. Then FC1/RHEL3 has a latter 2.4 kernel, and things worked much better.
Now we have a new 2.6 kernel in FC3/RHEL4. Things are going to take time to mature. So I'd stick with FC1/RHEL3 for now, until FC5/RHEL5 come out.
If they'd roll out a respin with the fixes on new install images when the initial bugs are mostly fixed it might be reasonable to use.
??? Don't you know how to mix in your own RPMS into an install?
On Fri, 2005-06-03 at 22:26 -0400, Lamar Owen wrote:
On Friday 03 June 2005 11:48, Les Mikesell wrote:
I'd put it this way instead: Red Hat is responsible for any difficulty in creating the CentOS distribution, while sharing the same upstream developers as all other Linux distributions.
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do; source doesn't have to be provided in SRPM form to meet the GPL-covered packages license requirements).
This I disagree with ... to quote the GPL:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
So, they can't just publish the tar.gz files, they have to publish the SRPMS. The spec file and SRPM controls the compilation of the source code to make the executable. Now, whether they have to give to everyone, or just their customers (and how to define who is their customers), is a different story.
The CentOS teams builds upon a foundation laid; the building is the work of the CentOS team, but it would fall were it not for the foundation.
Agreed ... CentOS (as it is currently done) depends upon RedHat to distribute their SRPMS. I wasn't implying that is not the case, just that CentOS builds upon it.
Also, while Red Hat may share the upstream developers as all other Linux distributions, let's not forget that Red Hat (as well as SuSE and others) employ many of these upstream developers and share their work product open source with their competitors.
This is also true ... but who employs the upstream employees doesn't matter. No one is saying that Slackware is Redhat because they include PostgreSQL and Red Hat employees a significant amount of the people who produce changes to that project. It is CentOS that supposedly has no added value, not slackware.
Or, more bluntly, the SRPM tree for RHEL didn't just magically appear out of nothing. And there is a significant difference in a tree of SRPMs ready to roll (with some modifications, as Johnny said, since RHEL isn't self-hosted) and having a tree of upstream tarballs with no spec files to tell where to put the files, build with the unified options, etc. I have written spec files, and have maintained a specfile of moderate complexity; spec file hacking is not trivial. Then there's the work of building an installable ISO image or image set; this is nontrivial as well.
On Sat, 4 Jun 2005, Johnny Hughes wrote:
On Fri, 2005-06-03 at 22:26 -0400, Lamar Owen wrote:
On Friday 03 June 2005 11:48, Les Mikesell wrote:
I'd put it this way instead: Red Hat is responsible for any difficulty in creating the CentOS distribution, while sharing the same upstream developers as all other Linux distributions.
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do; source doesn't have to be provided in SRPM form to meet the GPL-covered packages license requirements).
This I disagree with ... to quote the GPL:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
So, they can't just publish the tar.gz files, they have to publish the SRPMS. The spec file and SRPM controls the compilation of the source code to make the executable. Now, whether they have to give to everyone, or just their customers (and how to define who is their customers), is a different story.
Indeed, this is often overlooked by people and makes RMS a visionary in my book. The GPL is a well thought-out piece (both the technical side as well as the legal side).
Beware though, that Red Hat does not have to offer this publicly, only to those who buy the distribution/license. In practice of course, this makes little difference.
With this in mind I wonder why there's eg. no SLES-recompilation initiative from someone who buys an official SLES and recompiles the SRPMS (and distributes both). It will no doubt be much harder (given the overall quality of SLES packages) but it's possible.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Saturday 04 June 2005 01:27, Johnny Hughes wrote:
On Fri, 2005-06-03 at 22:26 -0400, Lamar Owen wrote:
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do; source doesn't have to be provided in SRPM form to meet the GPL-covered packages license requirements).
This I disagree with ... to quote the GPL:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
This is a good point. But this would not apply to the non-GPL covered works.
So, they would have to make the SRPMS available to the recipients of the binary code for the GPL covered packages. Thanks for the correction, Johnny.
On Sat, 2005-06-04 at 08:44 -0400, Lamar Owen wrote:
On Saturday 04 June 2005 01:27, Johnny Hughes wrote:
On Fri, 2005-06-03 at 22:26 -0400, Lamar Owen wrote:
I'd put it this way: Red Hat makes CentOS possible at all by providing Source RPMs (which they are not required to do; source doesn't have to be provided in SRPM form to meet the GPL-covered packages license requirements).
This I disagree with ... to quote the GPL:
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
This is a good point. But this would not apply to the non-GPL covered works.
So, they would have to make the SRPMS available to the recipients of the binary code for the GPL covered packages. Thanks for the correction, Johnny.
And, let me make this point, just in case anyone has taken anything I have posted on this thread to be negative to Red Hat.
I am not trying to be negative to Red Hat, nor minimize their work. As I have stated in other posts on this list, they are absolutely the best Enterprise related Distribution (for this I mean Mandriva / Novell (SuSE) / RHEL) at re-distributing their software ... and they could purposely make it much harder than they do. They should be praised for doing it the way they do.
The point that I am trying, but seem unable to make is:
CentOS is it's own distro ... and it would not be that much harder to deviate from the RHEL source code map (from a development perspective) as it is to be an exact replica of the RHEL. In fact, lots of times, it would be easier to change things to provide better (or needed functionality) ... like most of the items in extras and centosplus repos would be part of the distro, for example.
We choose to provide a replica of the upstream sources as our model for the distro, not because it is easier ... but because that is what we want to provide as a distro. We appreciate the upstream distro, think it (and the company that provide it) are the best Enterprise options, and want to legally produce an alternative to it BECAUSE we like it.
So, my point is, CentOS is a distro in it's own right, whose goals are to be as closely compatible to upstream as we can, so as to provide a Enterprise solution for people who like the upstream product but do not want or need the upstream support.
Just because we chose that path, that doesn't make CentOS any less a separate distro than Knoppix, Slackware, Gentoo, Debain, Ubuntu, or any of the other distros. We choose to make CentOS track the upstream versions so that it can be used by the same people ... it is however a separate distro, and is not at all affiliated with RedHat.
It is not trivial to do a rebuild project ... and on top of just rebuilding, there is management and distribution of the tree, the ISOs, and updates. In these areas, we are absolutely and totally different from upstream. Having the greatest rebuild in the world means nothing if it can't be downloaded ... or if there is no community behind it.
The best part of CentOS is not the technical RPMS and version numbers ... it is that it performs a certain way because of those things _AND_ there is an active IRC channel with more than 100 people in it all the time, a forum and list of FAQs where users can contribute, an active mailing list and announce list. The fact that all the CentOS developers are on IRC for much of the day helping people and listening. Those are the reasons I became involved in the CentOS Project ... and the reasons why it is a separate distro ... and the reasons why it should get your support.
Hopefully, this is making sense ... at least to someone :)
On Saturday 04 June 2005 09:43, Johnny Hughes wrote:
And, let me make this point, just in case anyone has taken anything I have posted on this thread to be negative to Red Hat.
[snip]
The point that I am trying, but seem unable to make is:
[snip]
Those are the reasons I became involved in the CentOS Project ... and the reasons why it is a separate distro ... and the reasons why it should get your support.
Hopefully, this is making sense ... at least to someone :)
This in some form should be on the centos.org website, perhaps under a heading 'Why CentOS' or somesuch. This captures the gist of what I believe the CentOS project is currently about, and why I have standardized on CentOS 4 for my relatively small site.
On Sat, 2005-06-04 at 08:44 -0400, Lamar Owen wrote:
This is a good point. But this would not apply to the non-GPL covered works. So, they would have to make the SRPMS available to the recipients of the binary code for the GPL covered packages. Thanks for the correction, Johnny.
I think people forget that RPM is basically just a 5KB block USTAR (cpio System-V) archive. Debs in DPKG are also similar. The meta-data built around them is not required for the package to be built and function.
So Red Hat _could_ package it in a tarball for building too. Or they could even just reference Fedora Core for the packages that do not differ (which is the overwhelming majority).
The GPL guarantees you can built and use the software as it was intented for its purpose. But if it further guarantees that it will work with other, non-required packages for it to function, that would open up a can of worms.
In other words, I don't see the terms of the GPL "extended" to the point where it must be released in a form guaranteed to work as part of a distribution with other packages that are not required for its to function. That would, again, open up a whole can of worms.
Johnny Hughes wrote:
On Fri, 2005-06-03 at 07:33 -0400, Simon Perreault wrote:
<snip>
BUT ... they didn't put any work into CentOS. All their work was put into RHEL. They are compensated fairly well for that work too, I might add.
I, on the other hand, spend an average of 8-12 hours a day on CentOS related activities. As does Karanbir Singh (z00dax on IRC). Most of the other developers spend almost as much time as well. Not only do we not get paid anything for doing that, some of us end up having to pay for centos related things (I have increased my bandwidth, bought compile platforms, changed my home network infrastructure, etc. to be able to better build CentOS and decrease the release times, at my own expense). This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
<snip>
good point, I gave a 1 time donation then forgot about it :( have just paid again (not a lot but that's what's needed), that's my vote :)
PS add a remind again in x months option somewhere Johnny :D
regards tom
On 6/3/05, Tom admin@homemachine.net wrote:
Johnny Hughes wrote:
This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
<snip>
good point, I gave a 1 time donation then forgot about it :( have just paid again (not a lot but that's what's needed), that's my vote :)
PS add a remind again in x months option somewhere Johnny :D
Johnny,
I am very much appreciative of the effort that is put into CentOS. I leave my machine doing BT all the time and have donated 225+GB so far. I would be willing to give money, but only after I see an accounting and description of where the money is going.
I asked for that many months ago and got no response, so I left it that there was enough money coming in that it isn't worth doing the accounting to get even more money.
I would probably just trust that the money goes to a good place, but the second result on this search doesn't sit well with me. That story is also the reason I am concerned about the slow and unpublicized drift from RHEL-SRPM rebuilds (change to Glade, change to Mozilla cert-db).
http://www.google.com/search?q=lance%20davis%20linux
Greg
On Fri, 3 Jun 2005, Greg Knaddison wrote:
On 6/3/05, Tom admin@homemachine.net wrote:
Johnny Hughes wrote:
This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
<snip>
good point, I gave a 1 time donation then forgot about it :( have just paid again (not a lot but that's what's needed), that's my vote :)
PS add a remind again in x months option somewhere Johnny :D
Johnny,
I am very much appreciative of the effort that is put into CentOS. I leave my machine doing BT all the time and have donated 225+GB so far. I would be willing to give money, but only after I see an accounting and description of where the money is going.
There is no accounting as no money has gone anywhere !!
I asked for that many months ago and got no response, so I left it that there was enough money coming in that it isn't worth doing the accounting to get even more money.
In fact there is virtually no money coming in. Approximately $200 since the split with cAos some months ago. There is some money that cAos still hold that is due to CentOS which they say is approx $1500 although we have seen no accounting records or details of donations to justify the figure.
I would probably just trust that the money goes to a good place, but the second result on this search doesn't sit well with me. That story is also the reason I am concerned about the slow and unpublicized drift from RHEL-SRPM rebuilds (change to Glade, change to Mozilla cert-db).
Isnt is nice that people can publish unfounded allegations on the Internet and leave them there and there really isnt anything that you can do about it. Needless to say my version of the story differs markedly in all substantial respects , although I dont intend to explain them here.
You are reading the rantings of a disgruntled employee, who did not deliver what he promised and as a result, and the fact that he started his own business in the time of his employer and didnt see that as an issue that affected his emplyment, left the company and set up in competition using most of the same suppliers and knowledge gained whilst employed.
uklinux.net sponsored the development of cAos and the development of CentOS by providing 3 dedicated servers when no one else was interested, besides paying my wages and allowing me to spend time on the project(s). I can easily say that without uklinux.net CentOS would not now exist as a distribution in any form whatsoever.
uklinux.net also sponsors the community stands at UK linux exhibitions and has done so for many years.
The basic error in his argument is that he never understood the difference between turnover and profit.
Lance
On 6/3/05, Lance Davis lance@uklinux.net wrote:
There is no accounting as no money has gone anywhere !!
Well then this is an accounting of it (200 in, zero out) which is a good step in the right direction.
In fact there is virtually no money coming in. Approximately $200 since the split with cAos some months ago. There is some money that cAos still hold that is due to CentOS which they say is approx $1500 although we have seen no accounting records or details of donations to justify the figure.
I'm glad that you have come into a place where you have more control and can let us know these details.
Isnt is nice that people can publish unfounded allegations on the Internet and leave them there and there really isnt anything that you can do about it. Needless to say my version of the story differs markedly in all substantial respects , although I dont intend to explain them here.
It certainly isn't nice and is rather unfortunate that any old web page garners an immediate level of believability...on the other hand, if you provide little information to the contrary and don't provide accounting, then you understand if I continued to believe his comments.
Having read your comments, I can certainly understand your respective positions.
And certainly a thanks to you and UKLinux for your work.
Greg
On Fri, 2005-06-03 at 13:39 -0600, Greg Knaddison wrote:
On 6/3/05, Tom admin@homemachine.net wrote:
Johnny Hughes wrote:
This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
<snip>
good point, I gave a 1 time donation then forgot about it :( have just paid again (not a lot but that's what's needed), that's my vote :)
PS add a remind again in x months option somewhere Johnny :D
Johnny,
I am very much appreciative of the effort that is put into CentOS. I leave my machine doing BT all the time and have donated 225+GB so far.
That is a contribution, and it is appreciated.
I would be willing to give money, but only after I see an accounting and description of where the money is going.
Not that I am opposed to providing information, but if you are using a product like CentOS, and you think it has value, why would you not contribute a fair value to the people who develop it, regardless of what they do with the money. Each person is able to determine what monetary value the software has to them, and contribute it.
I give money to distrowatch.com, gentoo.org, slackware.com and several other open source projects ... I don't care what they do with the money. They provide things that I find have value, so I give them a fair donation. It seems quite simple to me, if you use a free software product that accepts donations, especially if you use that product to make money or in a business, you should make a contribution to the organization.
I asked for that many months ago and got no response, so I left it that there was enough money coming in that it isn't worth doing the accounting to get even more money.
At the time you asked, you were asking the cAos Foundation. We are no longer a member of that group. There have been all of about $200.00 contributed to the CentOS project since March 20 (the date of split). I can't comment on the accounting of the cAos foundation, as I know nothing about it, but while the CentOS project was a member I wasn't happy with the information provided.
We haven't spent any of the $200.00 for anything yet. It is sitting in the account.
I would probably just trust that the money goes to a good place, but the second result on this search doesn't sit well with me.
Don't know anything about that. I know that 2 developers have bought and paid for computer systems to expand the number of distros we can build CentOS for, I think they should be compensated for that. ----------------------------------------------
That story is also the reason I am concerned about the slow and unpublicized drift from RHEL-SRPM rebuilds (change to Glade, change to Mozilla cert-db).
Neither of these things was unpublicized.
The Mozilla cert-db is done .. we will continue to support CACert as a free alternative to the get SSL Certificates. There were MANY posts on this issue in the Mailing list. If you don't like it, it is easy to remove it yourself (trivially easy in fact).
The Glade issue may never be addressed by RHEL ... they built theirs in a way that it works. Their SRPM will not build as is on itself. This issue is documented as broken by all 3 major rebuild projects. We have 2 choices ... a non working glade, or we fix glade based on a patch BY the glade people (who saw it as a problem and patched it). We submitted the bug and the patch (that come from the glade website) to RedHat. They have not acted.
But, since theirs works and ours does not, ours needs patching.
There is also a required patch to Thunderbird and several other packages need to have special parameters passed in to build.
All these things are documented fully in the bug tracker: http://bugs.centos.org/ -----------------------------------------------------------
The PPC distro will need several patches, as RH doesn't care to release the packages required to build that distro (or any distro for that matter):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134188 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109697 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134192
SO ... building the Centos Distro is trial and error, since we do get everything that RH releases, but they don't necessarily release everything that is need to BUILD RHEL (or build things on RHEL).
Everyone thinks it is just plug and play to build and maintain the distro ... it is not.
On 6/3/05, Johnny Hughes mailing-lists@hughesjr.com wrote:
Not that I am opposed to providing information, but if you are using a product like CentOS, and you think it has value, why would you not contribute a fair value to the people who develop it, regardless of what they do with the money. Each person is able to determine what monetary value the software has to them, and contribute it.
I give money to distrowatch.com, gentoo.org, slackware.com and several other open source projects ... I don't care what they do with the money. They provide things that I find have value, so I give them a fair donation. It seems quite simple to me, if you use a free software product that accepts donations, especially if you use that product to make money or in a business, you should make a contribution to the organization.
Yeah, I generally agree and have done. I don't feel the CentOS project is worth enough to make a donation beyond the BT. If I ever do, I'll probably go buy it from RH, to be honest.
For a while I used CentOS at work and encouraged my employer to contribute...I'm not sure if they did (don't think so) and I'm not sure if they will.
I asked for that many months ago and got no response, so I left it that there was enough money coming in that it isn't worth doing the accounting to get even more money.
At the time you asked, you were asking the cAos Foundation. We are no longer a member of that group. There have been all of about $200.00 contributed to the CentOS project since March 20 (the date of split). I can't comment on the accounting of the cAos foundation, as I know nothing about it, but while the CentOS project was a member I wasn't happy with the information provided.
So, you were in a position where you couldn't state the accounting nor could you get the accounting? Why not state that at the time?
We haven't spent any of the $200.00 for anything yet. It is sitting in the account.
I would probably just trust that the money goes to a good place, but the second result on this search doesn't sit well with me.
Don't know anything about that. I know that 2 developers have bought and paid for computer systems to expand the number of distros we can build CentOS for, I think they should be compensated for that.
That story is also the reason I am concerned about the slow and unpublicized drift from RHEL-SRPM rebuilds (change to Glade, change to Mozilla cert-db).
Neither of these things was unpublicized.
The Mozilla cert-db is done .. we will continue to support CACert as a free alternative to the get SSL Certificates. There were MANY posts on this issue in the Mailing list. If you don't like it, it is easy to remove it yourself (trivially easy in fact).
Yeah, I know there were many posts on Centos-devel on the subject.
The Glade issue may never be addressed by RHEL ... they built theirs in a way that it works. Their SRPM will not build as is on itself. This issue is documented as broken by all 3 major rebuild projects. We have 2 choices ... a non working glade, or we fix glade based on a patch BY the glade people (who saw it as a problem and patched it). We submitted the bug and the patch (that come from the glade website) to RedHat. They have not acted.
But, since theirs works and ours does not, ours needs patching.
There is also a required patch to Thunderbird and several other packages need to have special parameters passed in to build.
All these things are documented fully in the bug tracker: http://bugs.centos.org/
I understand what happened and why you did it and I'm glad you did, but I caught the fact that there was a change on the WBEL list of all places...I just feel that as a RHEL rebuild, that is what draws 16TB to the group so you should state clearly whenever there is a change. The CaCERT issue is on the front page - but not the fact that it was edited in the SRPM. Open source projects live and die on transparency...if it's not readily clear to the group what changes are made until they slip out, then how can we trust that the rest of the packages are unedited?
I really hope that I'm dense and wrong and that on the "hey bozo click here" page of the website it states all these changes, but it hasn't plonked me on the head yet.
Pointing to the 411 bugs in bugs.centos isn't much consolation on that front. If there is an easy report that brings them up, stick it in the faq and the suspicions will be squashed and I (and any others who feel like me on this front...) will get a warm fuzzy in our hearts.
The PPC distro will need several patches, as RH doesn't care to release the packages required to build that distro (or any distro for that matter):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134188 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109697 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134192
SO ... building the Centos Distro is trial and error, since we do get everything that RH releases, but they don't necessarily release everything that is need to BUILD RHEL (or build things on RHEL).
Everyone thinks it is just plug and play to build and maintain the distro ... it is not.
I'm sure it's not and I appreciate the work you've done and the quick level of accounting given just now.
Thanks, Greg
On Fri, 2005-06-03 at 16:21 -0600, Greg Knaddison wrote:
On 6/3/05, Johnny Hughes mailing-lists@hughesjr.com wrote:
Not that I am opposed to providing information, but if you are using a product like CentOS, and you think it has value, why would you not contribute a fair value to the people who develop it, regardless of what they do with the money. Each person is able to determine what monetary value the software has to them, and contribute it.
I give money to distrowatch.com, gentoo.org, slackware.com and several other open source projects ... I don't care what they do with the money. They provide things that I find have value, so I give them a fair donation. It seems quite simple to me, if you use a free software product that accepts donations, especially if you use that product to make money or in a business, you should make a contribution to the organization.
Yeah, I generally agree and have done. I don't feel the CentOS project is worth enough to make a donation beyond the BT. If I ever do, I'll probably go buy it from RH, to be honest.
That is your choice, of course, but $24 for an enterprise OS is quite a bargain. You and I obviously see the value of CentOS very, very differently.
If the 168,000 people who used the CentOS mirrors in the last 2 months donated $1.00 we might be able to do some things like have booths at Linux events, ect.
For a while I used CentOS at work and encouraged my employer to contribute...I'm not sure if they did (don't think so) and I'm not sure if they will.
I asked for that many months ago and got no response, so I left it that there was enough money coming in that it isn't worth doing the accounting to get even more money.
At the time you asked, you were asking the cAos Foundation. We are no longer a member of that group. There have been all of about $200.00 contributed to the CentOS project since March 20 (the date of split). I can't comment on the accounting of the cAos foundation, as I know nothing about it, but while the CentOS project was a member I wasn't happy with the information provided.
So, you were in a position where you couldn't state the accounting nor could you get the accounting? Why not state that at the time?
Because I was fairly new to the project then, and I was developing a beta distro ... I didn't know anything about the money end at that time. I am now more involved in all aspects of CentOS as the Lead for CentOS-4.
We haven't spent any of the $200.00 for anything yet. It is sitting in the account.
I would probably just trust that the money goes to a good place, but the second result on this search doesn't sit well with me.
Don't know anything about that. I know that 2 developers have bought and paid for computer systems to expand the number of distros we can build CentOS for, I think they should be compensated for that.
That story is also the reason I am concerned about the slow and unpublicized drift from RHEL-SRPM rebuilds (change to Glade, change to Mozilla cert-db).
Neither of these things was unpublicized.
The Mozilla cert-db is done .. we will continue to support CACert as a free alternative to the get SSL Certificates. There were MANY posts on this issue in the Mailing list. If you don't like it, it is easy to remove it yourself (trivially easy in fact).
Yeah, I know there were many posts on Centos-devel on the subject.
The Glade issue may never be addressed by RHEL ... they built theirs in a way that it works. Their SRPM will not build as is on itself. This issue is documented as broken by all 3 major rebuild projects. We have 2 choices ... a non working glade, or we fix glade based on a patch BY the glade people (who saw it as a problem and patched it). We submitted the bug and the patch (that come from the glade website) to RedHat. They have not acted.
But, since theirs works and ours does not, ours needs patching.
There is also a required patch to Thunderbird and several other packages need to have special parameters passed in to build.
All these things are documented fully in the bug tracker: http://bugs.centos.org/
I understand what happened and why you did it and I'm glad you did, but I caught the fact that there was a change on the WBEL list of all places...I just feel that as a RHEL rebuild, that is what draws 16TB to the group so you should state clearly whenever there is a change. The CaCERT issue is on the front page - but not the fact that it was edited in the SRPM. Open source projects live and die on transparency...if it's not readily clear to the group what changes are made until they slip out, then how can we trust that the rest of the packages are unedited?
I really hope that I'm dense and wrong and that on the "hey bozo click here" page of the website it states all these changes, but it hasn't plonked me on the head yet.
Both of those changes we announced ....
You mentioned the discussion for Mozilla, and here is the announcement for glade:
http://lists.centos.org/pipermail/centos-announce/2005-April/000052.html
We painstakingly document everything in bugzilla, on the announce list and inside the changlog of the SRPM/RPM. If you are interested, you can look up any changes made to anything in all 3 of those places.
ALSO ... each and every SRPM that has been edited is marked as .centos and the command:
rpm -qp --changelog packagename.rpm (if the RPM is on disk)
(or rpm -q --changelog package ... if it is installed)
will tell you why it is changed ... glade2 says:
* Wed Apr 06 2005 Johnny Hughes johnny@centos.org
- added the glade-infinite-loop.patch to correct bug #855 - thanks to David Parsley of TaoLinux.org for this patch :)
Pointing to the 411 bugs in bugs.centos isn't much consolation on that front. If there is an easy report that brings them up, stick it in the faq and the suspicions will be squashed and I (and any others who feel like me on this front...) will get a warm fuzzy in our hearts.
If you go there, click on view issues, then search for glade2 you can easily see the issues. This is the Mantis program, and links to the full documentation are also on bugs.centos.org.
You can also get an account on bugs, login, click Summary and while in the summary, click "Print Reports" and see whatever you want.
Being that we host the bugzilla for TaoLinux, and WBEL doesn't have one ... and neither have forums, I can say that we are by far the most supported and document distro (at least it seems so to me).
The PPC distro will need several patches, as RH doesn't care to release the packages required to build that distro (or any distro for that matter):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134188 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109697 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134192
SO ... building the Centos Distro is trial and error, since we do get everything that RH releases, but they don't necessarily release everything that is need to BUILD RHEL (or build things on RHEL).
Everyone thinks it is just plug and play to build and maintain the distro ... it is not.
I'm sure it's not and I appreciate the work you've done and the quick level of accounting given just now.
On Sat, 2005-06-04 at 01:17 +1200, Tom wrote:
This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
<snip>
good point, I gave a 1 time donation then forgot about it :( have just paid again (not a lot but that's what's needed), that's my vote :)
PS add a remind again in x months option somewhere Johnny :D
I'd gladly donate. Problem is donate is much harder to justify to the wife than "hey, I have to pay for the OS". :-)
Maybe someday soon. One thing that would be fun is if I could buy CentOS swag.
Preston
Vote for CentOS thread is now a lost cause and I was sure many of you are ignoring it, hence this new thread to get your attention.
Most of us simply underestimate the time and effort that goes into maintaining CentOS. While recognising the enormous contribution of Redhat to opensource, its also high time for us to thank(and donate if possible, which I cant in the near future) CentOS maintainers for doing whatever they have been doing so far and hope that Redhat accepts the existance of this project and finds a way to utilize it for good of both.
It may not be posible for us to push CentOS to the top of this year's favouraite lists due to the sheer number of users accumulated by other distro's in their many years of existance (ubuntu being a exception).
So lets start now and be done with the thankyou notes as soon as possible and let some sanity return to this mailing list.
THANKS GUYS :)
Quoting Johnny Hughes mailing-lists@hughesjr.com:
--=-+b21QgMYp1Hp7hcicwPL Content-Type: text/plain Content-Transfer-Encoding: quoted-printable
On Fri, 2005-06-03 at 07:33 -0400, Simon Perreault wrote:
On Thursday 02 June 2005 19:31, Johnny Hughes wrote:
No ... not at all. RedHat does not spend any time making sure that the people who use CentOS can get free updates.
=20 I think you will agree with me that the amount of work Red Hat put on Cen=
tOS=20
(by way of RHEL) is much more significant than the work put on CentOS by=20 CentOS volunteers. That is not to say that the work of CentOS volunteers =
is=20
not to be appreciated. Don't get all worked up for nothing.
I am a little touchy on this subject ... being that I hear it so often.
I disagree ... the work that RedHat put into RHEL is significant. It is a great distro, and worthy to win this award and many others ... but so is CentOS.
If you think RHEL is a BETTER distro than CentOS, you should vote that way.
BUT ... they didn't put any work into CentOS. All their work was put into RHEL. They are compensated fairly well for that work too, I might add.
I, on the other hand, spend an average of 8-12 hours a day on CentOS related activities. As does Karanbir Singh (z00dax on IRC). Most of the other developers spend almost as much time as well. Not only do we not get paid anything for doing that, some of us end up having to pay for centos related things (I have increased my bandwidth, bought compile platforms, changed my home network infrastructure, etc. to be able to better build CentOS and decrease the release times, at my own expense). This is because people using CentOS won't donate even $1, one time, to the project....oh well, such is life.
As pointed out many times before on this list, RedHat is a great company, and they do a lot of things for the OSS community ... but they are not the "owners" of the code that CentOS uses. They get almost all the items they publish from somewhere else. They are required, therefore, to make their source code public. They take that requirement seriously, and they do an outstanding job of publishing their source code openly. They should be commended for that. I do it every chance I get :)
They published their Source code, as required by the GPL. They added Trademark requirements. We took their GPL work, modified it to comply with their Trademark requirements (we actually go much further than their stated requirements), and to created a distro. A significant amount of their packages have to be modified to build properly ... all of them have to be reviewed.
Using your logic, The only people who would get credit are the programmers who write the code for the parent projects. Or the Fedora Core volunteers who actually package and test probably 95% of the stuff that get into RHEL.
So no, I don't think that you should vote for RHEL in a place where CentOS is also listed ... any more than I think you should vote for Debian if you use Ubuntu. If CentOS isn't in that poll, then voting for RHEL would be fine. Now, if someone feels that RHEL is a better Distro than CentOS (as distributed) ... then they should absolutely vote for RHEL instead of CentOS.
That is, of course, only my opinion. You have yours. We are both entitled to our own. Neither is right or wrong.
--=-+b21QgMYp1Hp7hcicwPL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQBCoFG2TKkMgmrBY7MRAnLYAKCxuUUpdhbd+Gmqi+uyLQ/ms8N3QwCfee7t M7x/K/qA0Yg59loKRKuFPQs= =oyQc -----END PGP SIGNATURE-----
--=-+b21QgMYp1Hp7hcicwPL--
On Friday 03 June 2005 08:48, Johnny Hughes wrote:
I am a little touchy on this subject ... being that I hear it so often.
I most assuredly understand this. I reply to your message in this thread because I find you quite level-headed.
I disagree ... the work that RedHat put into RHEL is significant. It is a great distro, and worthy to win this award and many others ... but so is CentOS.
BUT ... they didn't put any work into CentOS. All their work was put into RHEL. They are compensated fairly well for that work too, I might add.
Um, I don't if I can agree with that statement. CentOS is built upon the source RPMs of RHEL with sometimes substantial modifications, right? So, out of the changelog entries in the various spec files in CentOS what percentage of persons making changelog entries have an @redhat.com address? I have some work in CentOS in the PostgreSQL set, but it is quite small compared to the rest of the work. But Red Hat developers (some of who are upstream developers paid to work on the upstream package by Red Hat) have put a substantial amount of nontrivial work into the packages that through the CentOS team's efforts became CentOS.
I do understand what you are saying, why you are saying it, and the distinction you are attempting to make, but it comes across at least to me as understating the work Red Hat people have done. Let's not overstate Red Hat's contribution, by all means; but let's ot understate it either.
the items they publish from somewhere else. They are required, therefore, to make their source code public. They take that requirement seriously, and they do an outstanding job of publishing their source code openly. They should be commended for that. I do it every chance I get :)
They are not required to make the source for non-GPL code public (unless the license requires it; the PostgreSQL BSD license for instance does not require it), nor are they required to distribute any spec files or special initscripts they may use. They are not required to distribute source to anyone but the receipients of the binary code, and they cannot restrict said recipient's right to redistribute the source under the GPL. But GPL code is not the majority of the Red Hat dist, is it? Anyone have a count of bytes under GPL versus other licenses in CentOS? If not, I'll do the math, tomorrow. So Red Hat could make the job much more difficult by distributing the source as simple tarballs with no specs, no initscripts, no notes. Like you say, they have done an outstanding job releasing things they don't have to release as source in SRPM format, making it not as difficult as it could be to rebuild a trademark-free build. Not that it is trivial or even easy; but it could be more difficult.
Using your logic, The only people who would get credit are the programmers who write the code for the parent projects.
Many of whom work for Red Hat. Some of whom could not afford to work fulltime on their project were it not for Red Hat's employment.
Or the Fedora Core volunteers who actually package and test probably 95% of the stuff that get into RHEL.
Most of the Fedora Core packagers work for Red Hat, with notable exceptions.
So no, I don't think that you should vote for RHEL in a place where CentOS is also listed
I agree wholeheartedly with your conclusion, but not with all your reasons.
On 6/3/05, Lamar Owen lowen@pari.edu wrote:
Um, I don't if I can agree with that statement. CentOS is built upon the source RPMs of RHEL with sometimes substantial modifications, right? So, out
Lamar Owen pays attention to what's going on here.
If he thinks that there are substantial modifications - what is the casual user to think?
Regardless of what is in the rpm name, the spec file, the mantis, etc. their should be a better communication of what has or has not been changed.
Greg
On Fri, 2005-06-03 at 23:27 -0600, Greg Knaddison wrote:
On 6/3/05, Lamar Owen lowen@pari.edu wrote:
Um, I don't if I can agree with that statement. CentOS is built upon the source RPMs of RHEL with sometimes substantial modifications, right? So, out
Lamar Owen pays attention to what's going on here.
If he thinks that there are substantial modifications - what is the casual user to think?
Regardless of what is in the rpm name, the spec file, the mantis, etc. their should be a better communication of what has or has not been changed.
Then please volunteer to help the project create a 4th and 5th system besides the other 3 we already have to track changes. Since no one will donate any money or time ... I can't spend more than 12 hours a day on CentOS.
Johnny Hughes wrote:
On Fri, 2005-06-03 at 23:27 -0600, Greg Knaddison wrote:
On 6/3/05, Lamar Owen lowen@pari.edu wrote:
Um, I don't if I can agree with that statement. CentOS is built upon the source RPMs of RHEL with sometimes substantial modifications, right? So, out
Lamar Owen pays attention to what's going on here.
If he thinks that there are substantial modifications - what is the casual user to think?
Regardless of what is in the rpm name, the spec file, the mantis, etc. their should be a better communication of what has or has not been changed.
Then please volunteer to help the project create a 4th and 5th system besides the other 3 we already have to track changes. Since no one will donate any money or time ... I can't spend more than 12 hours a day on CentOS.
what do you mean? what do you need?
tom
On Saturday 04 June 2005 01:27, Greg Knaddison wrote:
On 6/3/05, Lamar Owen lowen@pari.edu wrote:
Um, I don't if I can agree with that statement. CentOS is built upon the source RPMs of RHEL with sometimes substantial modifications, right? So, out
Lamar Owen pays attention to what's going on here.
Well, thanks.
If he thinks that there are substantial modifications - what is the casual user to think?
Regardless of what is in the rpm name, the spec file, the mantis, etc. their should be a better communication of what has or has not been changed.
The only way to really tell is to check the changelogs for all packages and diff that with a RHEL system. Assuming the changelogs are modified (which AFAICT they are). rpm -qip --changelog packagename.rpm. Iterate over 1,494 packages. :-)
I used to provide lots of detail in my changelog entries (see the PostgreSQL spec files for the previous versions of PostgreSQL; the changelog historically has been truncated at each major version to keep the size down) so that people could fathom what I had changed from release to release.
Tracking these sorts of changes either needs to be fully automated (Johnny is so right that it takes time to do this) or someone needs to step up to the plate to chug through the changelogs, spec files, and patchsets. A specfile changelog tracker might be nice; if the specfiles are in CVS (or other revision control system) a committers list could be set up that would e-mail that list on each CVS commit (lots of projects, including PostgreSQL, do this). Then it's up to someone to digest this for public consumption. I get these sorts of e-mails from the PG rpmfoundry CVS server (while not terribly active there anymore, I still track it and provide advice when asked).
The practice of segregating the repo into a CentOS base, the addons, and centosplus is great; unfortunately there are changes that are in the base that really must be in the base. Such is life.
As far as the 'substantial' part of things, the centosplus repo is what I'm thinking about, along with the building into the ISO form, setting up the install, etc.
On Fri, 2005-06-03 at 22:19 -0400, Lamar Owen wrote:
On Friday 03 June 2005 08:48, Johnny Hughes wrote:
I am a little touchy on this subject ... being that I hear it so often.
I most assuredly understand this. I reply to your message in this thread because I find you quite level-headed.
I disagree ... the work that RedHat put into RHEL is significant. It is a great distro, and worthy to win this award and many others ... but so is CentOS.
BUT ... they didn't put any work into CentOS. All their work was put into RHEL. They are compensated fairly well for that work too, I might add.
Um, I don't if I can agree with that statement. CentOS is built upon the source RPMs of RHEL with sometimes substantial modifications, right? So, out of the changelog entries in the various spec files in CentOS what percentage of persons making changelog entries have an @redhat.com address? I have some work in CentOS in the PostgreSQL set, but it is quite small compared to the rest of the work. But Red Hat developers (some of who are upstream developers paid to work on the upstream package by Red Hat) have put a substantial amount of nontrivial work into the packages that through the CentOS team's efforts became CentOS.
I do understand what you are saying, why you are saying it, and the distinction you are attempting to make, but it comes across at least to me as understating the work Red Hat people have done. Let's not overstate Red Hat's contribution, by all means; but let's ot understate it either.
Let me try to say it another way then, I think my meaning is not clear.
Red Hat did their work, not at all for CentOS, but only for RHEL. They release their work for others to use (and they are very good about erring on the side of open source if releasing a specific file is questionable). CentOS uses that released work to build a distro ... and we do so meeting all their requirements (even go further than they require in some instances).
So ... CentOS depends upon RHEL to release their code ... but RedHat doesn't do the work FOR the CentOS project ... they do the work for themselves. I am not suggesting that their work is not significant ... quite the opposite is true. It is a huge amount of work. CentOS could not be published as it is without the excellent work done by Red Hat. They released it as open source software and released a set of rules to use it ... which CentOS follows.
However, they do not release everything required to build all the SRPMS, nor do they tell you what combinations of programs are required to be installed to get the SRPMS to build correctly. There are many -devel packages that must be built from code to get the SRPMS provided to build. The build hosts have to be prepared in certain ways, with certain specific software installed (some of which is not provided by RedHat at all). They do not provide instructions to do this (nor would I expect them to).
the items they publish from somewhere else. They are required, therefore, to make their source code public. They take that requirement seriously, and they do an outstanding job of publishing their source code openly. They should be commended for that. I do it every chance I get :)
They are not required to make the source for non-GPL code public (unless the license requires it; the PostgreSQL BSD license for instance does not require it), nor are they required to distribute any spec files or special initscripts they may use. They are not required to distribute source to anyone but the receipients of the binary code, and they cannot restrict said recipient's right to redistribute the source under the GPL. But GPL code is not the majority of the Red Hat dist, is it? Anyone have a count of bytes under GPL versus other licenses in CentOS?
1005/1494 is GPL/LGPL 146 is BSD
I did not do a detailed comparison on the BSD works ... if the BSD products are totally separate, then they don't have to be redistributed. If they use GPL libraries, then the source might need to distributed.
If not, I'll do the math, tomorrow. So Red Hat could make the job much more difficult by distributing the source as simple tarballs with no specs, no initscripts, no notes. Like you say, they have done an outstanding job releasing things they don't have to release as source in SRPM format, making it not as difficult as it could be to rebuild a trademark-free build. Not that it is trivial or even easy; but it could be more difficult.
I disagree. I think the below clause requires that they release their spec file and SRPMS (at least for GPL/LGPL items):
"For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable."
That is, to people who they distribute their executables to. Not to the public as a whole. BUT, if someone had a legitimate AS license and they met all the requirements to redistribute the code, then they could redistribute the SRPMS and RPMS they built even if full public access to the SRPMS was removed by RedHat. (Not that Red Hat would remove public access ... but that is an argument that is sometimes heard)
Using your logic, The only people who would get credit are the programmers who write the code for the parent projects.
Many of whom work for Red Hat. Some of whom could not afford to work fulltime on their project were it not for Red Hat's employment.
Or the Fedora Core volunteers who actually package and test probably 95% of the stuff that get into RHEL.
Most of the Fedora Core packagers work for Red Hat, with notable exceptions.
Red Hat just distanced themselves from DIRECT control of Fedora to try and get more volunteers to become part of the project:
http://informationweek.com/story/showArticle.jhtml?articleID=16430008
http://news.com.com/Red+Hat+lets+go+of+Fedora+Linux/2100-7344_3-5730931.html...
http://www.eweek.com/article2/0,1759,1823403,00.asp
http://business.newsforge.com/article.pl?sid=05/06/03/1729211&tid=18
So no, I don't think that you should vote for RHEL in a place where CentOS is also listed
I agree wholeheartedly with your conclusion, but not with all your reasons.
On Saturday 04 June 2005 02:20, Johnny Hughes wrote:
On Fri, 2005-06-03 at 22:19 -0400, Lamar Owen wrote:
On Friday 03 June 2005 08:48, Johnny Hughes wrote:
BUT ... they didn't put any work into CentOS. All their work was put into RHEL. They are compensated fairly well for that work too, I might add.
I do understand what you are saying, why you are saying it, and the distinction you are attempting to make, but it comes across at least to me as understating the work Red Hat people have done. Let's not overstate Red Hat's contribution, by all means; but let's ot understate it either.
Let me try to say it another way then, I think my meaning is not clear.
[snip]
This is much clearer, thanks.
However, they do not release everything required to build all the SRPMS, nor do they tell you what combinations of programs are required to be installed to get the SRPMS to build correctly. There are many -devel packages that must be built from code to get the SRPMS provided to build. The build hosts have to be prepared in certain ways, with certain specific software installed (some of which is not provided by RedHat at all). They do not provide instructions to do this (nor would I expect them to).
IIRC, at one time the Red Hat build host was a heavily modified Red Hat Linux 6.2 box. Building a self-hosting system is not one of the goals, unfortunately. At least they provide enough of the pieces of the anaconda setup stuff to make it possible at all. But rebuilding from source is not trivial, or even easy. That said, there are many people who have done it; I have, once, as an exercise for grins and giggles (I also did a stage 1 Gentoo on a DEC AlphaServer 2100 four-way SMP box; took a very long time but was a great learning experience; if nothing else, I learned that I don't like the Gentoo experience!). But I wouldn't do it for public consumption; the abuse ratio is too great (look at poor John Morris; if he had known what he knows now about the distribution of WhiteBox he might not have ever done it to begin with; I know I wouldn't!).
But GPL code is not the majority of the Red Hat dist, is it? Anyone have a count of bytes under GPL versus other licenses in CentOS?
1005/1494 is GPL/LGPL 146 is BSD
LGPL still requires source redistribution, even though it doesn't pass the redistribution requirements down to dependent packages. Ok.
I did not do a detailed comparison on the BSD works ... if the BSD products are totally separate, then they don't have to be redistributed. If they use GPL libraries, then the source might need to distributed.
I know the PostgreSQL project tries to go to great pains to not link to GPL libs, but I believe in the case of CentOS as distributed it links to at least one GPL covered library, readline.
But I tend to agree that we have probably beaten this horse far past death and into the glue stage.
I'll have to acknowledge a bias in that Red Hat Software is located in my home state, and that fact is one of the reasons I have used and supported Red Hat Linux (by being on the beta team, testing public betas, tracking RawHide when it was still rawhide, and even up until a month and a half ago following and tracking Fedora Development, which I simply ceased to have time to do). And I really hate to see the fine contributions of a company that is really trying to help out and get things right pushed down and away as if they were trivial. That is, many take Red Hat for granted, and I see that as a shame. It is an equal shame when the efforts of the CentOS team are trivialized or worse, marginalized.
-
Ajay -
Alex White -
Bryan J. Smith -
Christopher Snow -
Dag Wieers -
Greg Knaddison -
Johnny Hughes -
Karanbir Singh -
Lamar Owen -
Lance Davis -
Les Mikesell -
Maciej Żenczykowski -
Mark Frank -
Paul -
Preston Crawford -
Simon Perreault -
Steve Huff -
Tom