Hi all,
I'm building this site about email servers - http://www.qmailrules.com
It intends to be the *most extensive and comprehensive* site about qmail.
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
It is not yet complete, but will be in a matter of days. People will be invitided to participat, for now is only by invitation.
So, I would like to request that you insert a link in qmail.org site for mine.
Kind Regards, Mario Gamito
on 10/22/2007 12:09 PM Mário Gamito spake the following:
Hi all,
I'm building this site about email servers - http://www.qmailrules.com
It intends to be the *most extensive and comprehensive* site about qmail.
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
It is not yet complete, but will be in a matter of days. People will be invitided to participat, for now is only by invitation.
So, I would like to request that you insert a link in qmail.org site for mine.
Kind Regards, Mario Gamito
CentOS does not have any control to insert any links into the qmail.org site.
John R Pierce wrote:
Scott Silva wrote:
CentOS does not have any control to insert any links into the qmail.org site.
or even come with qmail. CentOS includes sendmail and postfix.
and lets not forget the one true MTA to rule them all : Exim!
Karanbir Singh wrote:
John R Pierce wrote:
Scott Silva wrote:
CentOS does not have any control to insert any links into the qmail.org site.
or even come with qmail. CentOS includes sendmail and postfix.
and lets not forget the one true MTA to rule them all : Exim!
Where do we join the MTA bigot club?
on 10/22/2007 5:16 PM Karanbir Singh spake the following:
John R Pierce wrote:
Scott Silva wrote:
CentOS does not have any control to insert any links into the qmail.org site.
or even come with qmail. CentOS includes sendmail and postfix.
and lets not forget the one true MTA to rule them all : Exim!
Time to get out the flame-retardant mousepad! ;-D
Mário Gamito wrote:
Hi all,
I'm building this site about email servers - http://www.qmailrules.com
It intends to be the *most extensive and comprehensive* site about qmail.
LWQ seems to be doing quite adequately.
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
I would really rather make qmail newbies go through the flames and really learn how qmail works than let them loose with a list of instructions.
It is not yet complete, but will be in a matter of days. People will be invitided to participat, for now is only by invitation.
Who are you?
So, I would like to request that you insert a link in qmail.org site for mine.
No thank you. You have no idea who runs qmail.org, you do not have a history of proving yourself to be an expert on qmail on the qmail list and you have actually put this request on the Centos list? I wish Robin Bowes was still around.
Christopher Chan wrote:
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
I would really rather make qmail newbies go through the flames and really learn how qmail works than let them loose with a list of instructions.
Just tell them to ask djb for help.....or if you want to make things a little easier, you could just bathe them in honey and bury a manual at the bottom of a fire ant mound....
How about we talk about supporting MTAs that are actually distributed with CentOS (postfix/Sendmail)????
Best,
Chris Mauritz wrote:
Christopher Chan wrote:
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
I would really rather make qmail newbies go through the flames and really learn how qmail works than let them loose with a list of instructions.
Just tell them to ask djb for help.....or if you want to make things a little easier, you could just bathe them in honey and bury a manual at the bottom of a fire ant mound....
I never needed to approach DJB for help. I managed with the documentation that came with qmail just fine. The manual comes with qmail.
Robin Bowes is no longer on the qmail list among others and so there is very little flaming now there.
How about we talk about supporting MTAs that are actually distributed with CentOS (postfix/Sendmail)????
Hey, don't leave out exim :-P
Oh, and I have supported postfix. I used to post here as Feizhou. Then we have the question of whether the Centos list should take questions on postfix/sendmail instead of redirecting them to the postfix list or the sendmail newsgroup.
on 10/22/2007 9:21 PM Christopher Chan spake the following:
Chris Mauritz wrote:
Christopher Chan wrote:
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
I would really rather make qmail newbies go through the flames and really learn how qmail works than let them loose with a list of instructions.
Just tell them to ask djb for help.....or if you want to make things a little easier, you could just bathe them in honey and bury a manual at the bottom of a fire ant mound....
I never needed to approach DJB for help. I managed with the documentation that came with qmail just fine. The manual comes with qmail.
Robin Bowes is no longer on the qmail list among others and so there is very little flaming now there.
How about we talk about supporting MTAs that are actually distributed with CentOS (postfix/Sendmail)????
Hey, don't leave out exim :-P
Oh, and I have supported postfix. I used to post here as Feizhou. Then we have the question of whether the Centos list should take questions on postfix/sendmail instead of redirecting them to the postfix list or the sendmail newsgroup.
If it comes on the install CD it should be fair game for the list. My car comes with a radio, but I don't have to call a communications specialist if it breaks.
Scott Silva wrote:
on 10/22/2007 9:21 PM Christopher Chan spake the following:
Chris Mauritz wrote:
Christopher Chan wrote:
It is like a step-by-step book, that intendes to *really* help people getting their servers up and running.
I would really rather make qmail newbies go through the flames and really learn how qmail works than let them loose with a list of instructions.
Just tell them to ask djb for help.....or if you want to make things a little easier, you could just bathe them in honey and bury a manual at the bottom of a fire ant mound....
I never needed to approach DJB for help. I managed with the documentation that came with qmail just fine. The manual comes with qmail.
Robin Bowes is no longer on the qmail list among others and so there is very little flaming now there.
How about we talk about supporting MTAs that are actually distributed with CentOS (postfix/Sendmail)????
Hey, don't leave out exim :-P
Oh, and I have supported postfix. I used to post here as Feizhou. Then we have the question of whether the Centos list should take questions on postfix/sendmail instead of redirecting them to the postfix list or the sendmail newsgroup.
If it comes on the install CD it should be fair game for the list. My car comes with a radio, but I don't have to call a communications specialist if it breaks.
Ah but you cannot just replace it with another radio and expect it to work...sendmail and postfix have very different interfaces and design. They have their own ways of handling. Do we have to entertain stuff like writing/debugging sendmail rulesets or how to chain restriction classes in postfix?
Christopher Chan wrote:
Ah but you cannot just replace it with another radio and expect it to work...sendmail and postfix have very different interfaces and design. They have their own ways of handling. Do we have to entertain stuff like writing/debugging sendmail rulesets or how to chain restriction classes in postfix?
I think it depends. If the only solution given by other lists is "update your version of foo", I'd rather have the discussion here.
Ralph
Ralph Angenendt wrote:
Christopher Chan wrote:
Ah but you cannot just replace it with another radio and expect it to work...sendmail and postfix have very different interfaces and design. They have their own ways of handling. Do we have to entertain stuff like writing/debugging sendmail rulesets or how to chain restriction classes in postfix?
I think it depends. If the only solution given by other lists is "update your version of foo", I'd rather have the discussion here.
Well sometimes there will be no choice. Eg: To get milter support in postfix, I have to upgrade to postfix 2.3. There is no other solution possible. So for Centos 4.x, you prefer to have that discussion here?
Christopher Chan wrote:
Ralph Angenendt wrote:
I think it depends. If the only solution given by other lists is "update your version of foo", I'd rather have the discussion here.
Well sometimes there will be no choice. Eg: To get milter support in postfix, I have to upgrade to postfix 2.3. There is no other solution possible. So for Centos 4.x, you prefer to have that discussion here?
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
Cheers,
Ralph
on 10/24/2007 4:42 AM Ralph Angenendt spake the following:
Christopher Chan wrote:
Ralph Angenendt wrote:
I think it depends. If the only solution given by other lists is "update your version of foo", I'd rather have the discussion here.
Well sometimes there will be no choice. Eg: To get milter support in postfix, I have to upgrade to postfix 2.3. There is no other solution possible. So for Centos 4.x, you prefer to have that discussion here?
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
Scott Silva wrote:
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
And what's the point even if you do get paid? The problem is really in distributions that by policy won't do a version level app upgrade even in instances where it would clearly be better than patching the beta version they chose to include.
Les Mikesell wrote:
Scott Silva wrote:
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
And what's the point even if you do get paid? The problem is really in distributions that by policy won't do a version level app upgrade even in instances where it would clearly be better than patching the beta version they chose to include.
Well ... Even IF the dovecot people backported patches to 0.99 ... RHEL would probably not bring those patches in anyway, unless it fixed a problem that they have in the RH bugzilla. That is the whole purpose of freezing on the enterprise distribution.
They fix security updates and bugs and you run it like it was released ... IT IS THE WHOLE FREAKING POINT.
IF that isn't the distribution type you want ... CentOS is not the distribution for you :D
(You being users in general and not anyone in particular)
Johnny Hughes wrote:
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
And what's the point even if you do get paid? The problem is really in distributions that by policy won't do a version level app upgrade even in instances where it would clearly be better than patching the beta version they chose to include.
Well ... Even IF the dovecot people backported patches to 0.99 ... RHEL would probably not bring those patches in anyway, unless it fixed a problem that they have in the RH bugzilla. That is the whole purpose of freezing on the enterprise distribution.
Why should dovecot people have anything more to do with a beta version that they no longer support? It wasn't their choice for that version to live on (nearly) forever.
They fix security updates and bugs and you run it like it was released ... IT IS THE WHOLE FREAKING POINT.
IF that isn't the distribution type you want ... CentOS is not the distribution for you :D
So which distribution makes intelligent decisions about how to best maintain each application package instead of applying a blanket policy that obviously doesn't fit everything? I do, of course, want stability in most of the packages - just not where a barely functional beta was shipped in the first place.
on 10/24/2007 1:26 PM Les Mikesell spake the following:
Johnny Hughes wrote:
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
And what's the point even if you do get paid? The problem is really in distributions that by policy won't do a version level app upgrade even in instances where it would clearly be better than patching the beta version they chose to include.
Well ... Even IF the dovecot people backported patches to 0.99 ... RHEL would probably not bring those patches in anyway, unless it fixed a problem that they have in the RH bugzilla. That is the whole purpose of freezing on the enterprise distribution.
Why should dovecot people have anything more to do with a beta version that they no longer support? It wasn't their choice for that version to live on (nearly) forever.
They fix security updates and bugs and you run it like it was released ... IT IS THE WHOLE FREAKING POINT.
IF that isn't the distribution type you want ... CentOS is not the distribution for you :D
So which distribution makes intelligent decisions about how to best maintain each application package instead of applying a blanket policy that obviously doesn't fit everything? I do, of course, want stability in most of the packages - just not where a barely functional beta was shipped in the first place.
Sometimes you just have to take care of one or two needed apps yourself if you want the extra features. Enterprise class distros are the turtle running against the hare. Slow and steady, and don't break anything else, or break apps themselves because of major config changes.
Les Mikesell wrote:
Johnny Hughes wrote:
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
And what's the point even if you do get paid? The problem is really in distributions that by policy won't do a version level app upgrade even in instances where it would clearly be better than patching the beta version they chose to include.
Well ... Even IF the dovecot people backported patches to 0.99 ... RHEL would probably not bring those patches in anyway, unless it fixed a problem that they have in the RH bugzilla. That is the whole purpose of freezing on the enterprise distribution.
Why should dovecot people have anything more to do with a beta version that they no longer support? It wasn't their choice for that version to live on (nearly) forever.
I said EVEN IF THEY DID ... it would not make any difference. I did not say that they wanted to do so. ALTHOUGH, if they cared to be in 85% of the Enterprise Linux installs in the World, they WOULD support it, but that is another story.
They fix security updates and bugs and you run it like it was released ... IT IS THE WHOLE FREAKING POINT.
IF that isn't the distribution type you want ... CentOS is not the distribution for you :D
So which distribution makes intelligent decisions about how to best maintain each application package instead of applying a blanket policy that obviously doesn't fit everything? I do, of course, want stability in most of the packages - just not where a barely functional beta was shipped in the first place.
Well, the decisions are made, that was what they picked ... it is done and not going to change. I would say the the people planning RHEL are fairly intelligent, as the own 85% market share in the PAID FOR Enterprise Linux world. And even Novell + SUSE + Microsoft (with a cold slap in the face from Oracle too) did not even put a SLIGHT dent into that.
But, what do I know about these things.
on 10/24/2007 12:34 PM Johnny Hughes spake the following:
Les Mikesell wrote:
Scott Silva wrote:
No. But we had that stuff rather regularly with samba - their first line of support seems to be : "Upgrade your version to the most current one, then ask again."
That's what I meant.
That is very common with applications. They don't back patch old versions, and the problem you ask about might be already fixed. Just look at the dovecot list. People still pop in and ask why 0.99 has this problem, because that is what their distro came with, but they are currently at 1.0.5, and have 1.1 in beta. Who has the time to backport fixes to old versions if you don't get paid for it?
And what's the point even if you do get paid? The problem is really in distributions that by policy won't do a version level app upgrade even in instances where it would clearly be better than patching the beta version they chose to include.
Well ... Even IF the dovecot people backported patches to 0.99 ... RHEL would probably not bring those patches in anyway, unless it fixed a problem that they have in the RH bugzilla. That is the whole purpose of freezing on the enterprise distribution.
They fix security updates and bugs and you run it like it was released ... IT IS THE WHOLE FREAKING POINT.
IF that isn't the distribution type you want ... CentOS is not the distribution for you :D
(You being users in general and not anyone in particular)
And if you really need a particular package newer, you just have to bite the bullet and either manage it yourself, or use a third party trusted repo that has what you want. Even Centos made the redhat application stack available "if you want it".
-
Chris Mauritz -
Christopher Chan -
John R Pierce -
Johnny Hughes -
Karanbir Singh -
Les Mikesell -
Mário Gamito -
Ralph Angenendt -
Scott Silva