[Dovecot] Dovecot 1.1.x and 1.2.x differencies
Hello,
I have been using successfully Dovecot 1.1.x for about a year now. It has been very stable. Now I'm uprading that same system to newer and more powerful hardware and I was wondering whether it is good idea or not to switch to Dovecot 1.2.x series. Could anybody direct me to feature comparision document or explain here main differences betweeen thos two branches?
-- Veiko
On 14.06.2010 14:43, Veiko Kukk wrote:
Could anybody direct me to feature comparision document or explain here main differences betweeen thos two branches?
Check the release notes: http://www.dovecot.org/doc/NEWS
and the fine manual on upgrading to 1.2: http://wiki.dovecot.org/Upgrading/1.2
-- Eray
On 2010-06-14 7:43 AM, Veiko Kukk wrote:
Could anybody direct me to feature comparision document or explain here main differences betweeen thos two branches?
Isn't it enough to know that 1.2 is the current *stable* branch?
Personally, unless there was something about 2.0 that wasn't stable in my environment, I'd go with that, since its almost to RC status, and will be the next stable branch soon.
--
Best regards,
Charles
On 06/14/2010 04:41 PM, Charles Marcus wrote:
Isn't it enough to know that 1.2 is the current *stable* branch?
I prefer "don't fix if it isn't broken" philosophy. I don't see that 1.2 is stable enought from what I have read from this list and Changelog. There have been lots of bugfixes during last year for 1.2 branch. From reading changelog (http://www.dovecot.org/doc/NEWS), I did not find functional improvement to justify switching to 1.2 instead of keeping really stable 1.1.
Thank you for your suggestions!
-- Veiko
On 2010-06-15 4:05 AM, Veiko Kukk wrote:
I prefer "don't fix if it isn't broken" philosophy.
I also subscribe to that philosophy, but there are limits.
Keeping current makes sure you take advantage of possibly unknown bugfixes and/or security holes, and also means when asking for help you won't get responses like 'that's already fixed in the current stable version', not to mention (sometimes considerable) performance improvements - at least in the case of dovecot.
Security is the main reason I like to stay on current stable versions for software I use though.
I don't see that 1.2 is stable enought from what I have read from this list and Changelog. There have been lots of bugfixes during last year for 1.2 branch.
It is stable. There were a lot of bugfixes to the 1.1 branch too... most of which are corner cases that most people will never encounter anyway.
On more than one occasion I have seen Timo say he won't fix some particular problem in older versions because it is already fixed in current stable version, etc...
No software is bug free - thankfully, Timo is like 'The Flash' when it comes to fixing bugs with dovecot...
From reading changelog (http://www.dovecot.org/doc/NEWS), I did not find functional improvement to justify switching to 1.2 instead of keeping really stable 1.1.
Again - 1.2 is the current stable branch.
Luckily for you though, there are no laws requiring anyone to use any particular version of any particular piece of software... ;)
--
Best regards,
Charles
On 06/15/2010 01:27 PM, Charles Marcus wrote:
Keeping current makes sure you take advantage of possibly unknown bugfixes and/or security holes, and also means when asking for help you won't get responses like 'that's already fixed in the current stable version', not to mention (sometimes considerable) performance improvements - at least in the case of dovecot.
Ok, you convinced me. I'll give 1.2 a try. Seems that atrpms has 1.2. http://atrpms.net/dist/el5/dovecot/
-- Veiko
-----Original Message----- From: dovecot-bounces+arto.saraniva=artio.net@dovecot.org [mailto:dovecot-bounces+arto.saraniva=artio.net@dovecot.org] On Behalf Of Veiko Kukk Sent: Tuesday, June 15, 2010 1:52 PM To: dovecot@dovecot.org Subject: Re: [Dovecot] Dovecot 1.1.x and 1.2.x differencies
On 06/15/2010 01:27 PM, Charles Marcus wrote:
Keeping current makes sure you take advantage of possibly unknown bugfixes and/or security holes, and also means when asking for help you won't get responses like 'that's already fixed in the current stable version', not to mention (sometimes considerable) performance improvements - at least in the case of dovecot.
Ok, you convinced me. I'll give 1.2 a try. Seems that atrpms has 1.2. http://atrpms.net/dist/el5/dovecot/
-- Veiko
You can also try http://www.city-fan.org/ftp/contrib/mail/
-arto
Charles Marcus put forth on 6/15/2010 5:27 AM:
No software is bug free - thankfully, Timo is like 'The Flash' when it comes to fixing bugs with dovecot...
Too bad the Debian Dovecot maintainer isn't 'The Flash' in getting binaries uploaded. For i386 anyway. He had the AMD64 1.2.11 binary uploaded to backports within a week IIRC. Took something like 2 weeks IIRC before he got the i386 binary uploaded. If it weren't for the fact that one of the bugs fixed was 'critical' for me (I actually contributed to discovery), I'd probably not have cared. Some debian-user list folks say I should simply be grateful we have current Dovecot revs in backports period. I say if we didn't have stuff in backports nobody would use Debian, as all the packages would be 2 years out of date the moment the next stable is released...
-- Stan
On 2010-06-15 6:57 AM, Stan Hoeppner wrote:
Too bad the Debian Dovecot maintainer isn't 'The Flash' in getting binaries uploaded. For i386 anyway. He had the AMD64 1.2.11 binary uploaded to backports within a week IIRC. Took something like 2 weeks IIRC before he got the i386 binary uploaded. If it weren't for the fact that one of the bugs fixed was 'critical' for me (I actually contributed to discovery), I'd probably not have cared. Some debian-user list folks say I should simply be grateful we have current Dovecot revs in backports period. I say if we didn't have stuff in backports nobody would use Debian, as all the packages would be 2 years out of date the moment the next stable is released...
This is precise reason I have never been inclined to try Debian other than once over 5 years ago (and why I like gentoo so much)...
I do understand the argument, and it's apparently worked well for them, but imo the 'hard' line should be drawn more against the *system* (compiler, kernel, system tools, etc), and not so much the software that rides on top.
I'm still running multiple gentoo servers that were originally installed 7 years ago, and are currently running mostly up to date versions of everything. I keep all of the *system* packages at 'stable', and applications at 'unstable', and it has worked flawlessly, with only a few minor bumps easily solved using google and/or the user forums. Yeah, 7 years is a long time hardware wise, but if it still works well and handles the load well, it fits my criteria of 'if it ain't broke don't fix it'.
--
Best regards,
Charles
Charles Marcus wrote:
On 2010-06-15 6:57 AM, Stan Hoeppner wrote:
Too bad the Debian Dovecot maintainer isn't 'The Flash' in getting binaries uploaded. For i386 anyway. He had the AMD64 1.2.11 binary uploaded to backports within a week IIRC. Took something like 2 weeks IIRC before he got the i386 binary uploaded. If it weren't for the fact that one of the bugs fixed was 'critical' for me (I actually contributed to discovery), I'd probably not have cared. Some debian-user list folks say I should simply be grateful we have current Dovecot revs in backports period. I say if we didn't have stuff in backports nobody would use Debian, as all the packages would be 2 years out of date the moment the next stable is released...
This is precise reason I have never been inclined to try Debian other than once over 5 years ago (and why I like gentoo so much)...
I do understand the argument, and it's apparently worked well for them, but imo the 'hard' line should be drawn more against the *system* (compiler, kernel, system tools, etc), and not so much the software that rides on top.
I'm still running multiple gentoo servers that were originally installed 7 years ago, and are currently running mostly up to date versions of everything. I keep all of the *system* packages at 'stable', and applications at 'unstable', and it has worked flawlessly, with only a few minor bumps easily solved using google and/or the user forums. Yeah, 7 years is a long time hardware wise, but if it still works well and handles the load well, it fits my criteria of 'if it ain't broke don't fix it'.
Charles, thanks for the making the distinction between the OS (*system*) and applications. I've believed for years that there is a difference there, and this is one good example of why.
-- -Eric 'shubes'
On Tue, 15 Jun 2010 11:05:51 +0300 Veiko Kukk veiko.kukk@ekp.ee articulated:
On 06/14/2010 04:41 PM, Charles Marcus wrote:
Isn't it enough to know that 1.2 is the current *stable* branch?
I prefer "don't fix if it isn't broken" philosophy.
A true conservative.
Our ancestors use to feel that a sharpened rock was a cool tool for cutting. Then they found that by attaching a handle to it they could also use it as a weapon. From there a natural progression continued.
Sarcasm aside, you obviously must be aware that further development on the 1.1 branch is effectively dead. As long as you are content and not in need of the advances brought forth by the newer 1.2 and soon 2.x line of Dovecot, then all is well in your world.
Since you did not give a detailed outline of your network, it is impossible for anyone else to make a sufficiently knowledgeable assessment for you.
-- Jerry ✌ Dovecot.user@seibercom.net
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
Conversation, n.: A vocal competition in which the one who is catching his breath is called the listener.
Quoting Veiko Kukk veiko.kukk@ekp.ee:
I prefer "don't fix if it isn't broken" philosophy.
Reasonable, as long as the version you are running is still supported...
I don't see that 1.2 is stable enought from what I have read from
this list and Changelog.
Some versions are, some are not... I've been running 1.2.11 and found it stable...
From reading changelog (http://www.dovecot.org/doc/NEWS), I did not
find functional improvement to justify switching to 1.2 instead of
keeping really stable 1.1.
I did (shared folders), but your usage case may be different. I upgraded only to get shared folders. Otherwise, I'd have had no reason either... Your millage may vary...
Thank you for your suggestions!
-- Veiko
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!
On Tue, Jun 15, 2010 at 11:30, Eric Rostetter rostetter@mail.utexas.edu wrote:
Quoting Veiko Kukk veiko.kukk@ekp.ee:
I prefer "don't fix if it isn't broken" philosophy.
Reasonable, as long as the version you are running is still supported...
And if it isn't, you should upgrade. But when? Immediately? Or later when an issue crops up (since you'd likely have to change something, then, anyway).
On 2010-06-15 1:26 PM, Phil Howard wrote:
On Tue, Jun 15, 2010 at 11:30, Eric Rostetter rostetter@mail.utexas.edu wrote:
Quoting Veiko Kukk veiko.kukk@ekp.ee:
I prefer "don't fix if it isn't broken" philosophy.
Reasonable, as long as the version you are running is still supported...
And if it isn't, you should upgrade. But when? Immediately? Or later when an issue crops up (since you'd likely have to change something, then, anyway).
I *always* wait at least a few days, if not a week or two *after* an update is available before upgrading, monitoring the support list for any gotchas... but... I always do update as soon as practicable.
Waiting almost always keeps me from any major bugs from new packages (one exception was a minor update to mailman that changed directory locations), and still lets me stay up to date with the latest stable releases.
--
Best regards,
Charles
Charles Marcus put forth on 6/15/2010 12:44 PM:
Waiting almost always keeps me from any major bugs from new packages (one exception was a minor update to mailman that changed directory locations), and still lets me stay up to date with the latest stable releases.
I waited "forever" to get hold of 1.2.10 in the form of the backport for Debian Lenny, which was the first 1.2.x backport available IIRC (I hate installing apps from source for many reasons). Once I installed it I almost immediately found problems with performance. I reported the symptoms here, and within a day or two Timo identified the cause relating to mbox processing and fixed it. It took a couple/three weeks IIRC before the 1.2.11 backport with this fix was available. I installed it and it fixed my problems instantly.
So, waiting a few days isn't always going to cut the mustard. Sometimes obscure problems may not surface for weeks or months. It seems I found this particular problem where others did not because my Dovecot server runs on really old "slow" CPUs. Others' have such stout CPUs that they just didn't notice the mbox processing slowdown.
I agree with Charles' logic in most cases, but as shown above, not all cases. In this case, my issue was laggy performance, not broken functionality. One can usually limp along with laggy performance for a while until a fix is available. Broken functionality issues are identified and fixed rather quickly as they usually hit multiple OPs simultaneously.
-- Stan
On 2010-06-16 1:15 AM, Stan Hoeppner wrote:
Charles Marcus put forth on 6/15/2010 12:44 PM:
Waiting almost always keeps me from any major bugs from new packages (one exception was a minor update to mailman that changed directory locations), and still lets me stay up to date with the latest stable releases.
I waited "forever" to get hold of 1.2.10 in the form of the backport for Debian Lenny, which was the first 1.2.x backport available IIRC (I hate installing apps from source for many reasons).
Again - this is why I have never been inclined to even give debian a try... with gentoo, with a very few minor exceptions, the most I've ever had to wait was a few weeks...
Once I installed it I almost immediately found problems with performance. I reported the symptoms here, and within a day or two Timo identified the cause relating to mbox processing and fixed it. It took a couple/three weeks IIRC before the 1.2.11 backport with this fix was available. I installed it and it fixed my problems instantly.
What does this have to do with sticking with 'really stable' 1.1.x? You do realize that 1.1.x had any number of similar situations with certain releases, right?
I agree with Charles' logic in most cases, but as shown above, not all cases.
<snip>
Broken functionality issues are identified and fixed rather quickly as they usually hit multiple OPs simultaneously.
I am *always* prepared to roll back to a previous non-broken version in the case of an upgrade gone bad.
We are not in disagreement, we just apparently do things differently. I prefer the 'rolling release' type of system that always has *everything* reasonably up to date, and gentoo gives me that.
--
Best regards,
Charles
On 2010-06-16 7:29 AM, Charles Marcus wrote:
Once I installed it I almost immediately found problems with performance. I reported the symptoms here, and within a day or two Timo identified the cause relating to mbox processing and fixed it. It took a couple/three weeks IIRC before the 1.2.11 backport with this fix was available. I installed it and it fixed my problems instantly.
What does this have to do with sticking with 'really stable' 1.1.x?
Sorry Stan, confused you with the OP...
--
Best regards,
Charles
Charles Marcus put forth on 6/16/2010 6:34 AM:
On 2010-06-16 7:29 AM, Charles Marcus wrote:
Once I installed it I almost immediately found problems with performance. I reported the symptoms here, and within a day or two Timo identified the cause relating to mbox processing and fixed it. It took a couple/three weeks IIRC before the 1.2.11 backport with this fix was available. I installed it and it fixed my problems instantly.
What does this have to do with sticking with 'really stable' 1.1.x?
Sorry Stan, confused you with the OP...
Heh, no problem. We were both arguing against hanging back _that_ far. I was just saying that sometimes you can snag a bug no matter how long you wait before installing a new rev. It just depends on whether you're that "one percentile user". For this last minor bug, I was a one percenter, had the right combination--slow hardware plus mbox storage and full text searches on very large mbox files.
-- Stan
On 2010-06-16 7:56 AM, Stan Hoeppner wrote:
For this last minor bug, I was a one percenter, had the right combination--slow hardware plus mbox storage and full text searches on very large mbox files.
Right, now I remember...
So, its working well for you now I presume (since you're still here)?
--
Best regards,
Charles
Charles Marcus put forth on 6/16/2010 7:18 AM:
On 2010-06-16 7:56 AM, Stan Hoeppner wrote:
For this last minor bug, I was a one percenter, had the right combination--slow hardware plus mbox storage and full text searches on very large mbox files.
Right, now I remember...
So, its working well for you now I presume (since you're still here)?
Has been since 1.2.11 and even more so since Timo suggested I try mbox_very_dirty_syncs. That made a huge difference WRT the 10k+ mboxen, not search specifically, but just general access after new mail arrival, etc. 1.0.15 worked well also. It was just 1.2.10 that caused problems.
-- Stan
We're drifting quite OT here, but...
On 06/16/2010 08:29 AM, Charles Marcus wrote:
Again - this is why I have never been inclined to even give debian a try... with gentoo, with a very few minor exceptions, the most I've ever had to wait was a few weeks...
If you want newer releases, you can use debian "testing" or "unstable". Note that "stable"/"unstable" means changing/not changing, not necessarily that the software is prone to instabilities (crashes, random bugs, etc.). Naturally, software in testing/unstable was tested for less time than the ones in the "stable" releases, but this will be true in any rolling release system.
-- Eduardo M KALINOWSKI eduardo@kalinowski.com.br
caution OS war related statements within :)
On Wed, 2010-06-16 at 07:29 -0400, Charles Marcus wrote:
We are not in disagreement, we just apparently do things differently. I prefer the 'rolling release' type of system that always has *everything* reasonably up to date, and gentoo gives me that.
As does Slackware, however I have a problem convincing PV to include dovecot in mainstream, but hey, he still prefers sendmail over postfix, which is fine for system only users, but most of us do a lot more, and Claus has told me directly they will never support MySQL so we removed them from use, and, most serious sys admins use source anyway, it is in my opinion that all serious system admins should always use source for key daemons as you can build it to include and not include what you require, not rely on some bloated, out dated, feature-less distro build.
I will never use debian or its derivatives for its outdated crud, and I would rather not use RHEL because of its old but patched methods, gentoo and slackware are the only two serious "Linux" OS's that should ever be in a serious data centre, IMHO.
On Wed, 2010-06-16 at 21:49 +1000, Noel Butler wrote:
dovecot in mainstream, but hey, he still prefers sendmail over postfix, which is fine for system only users, but most of us do a lot more, and Claus has told me directly they will never support MySQL so we removed
Just want to clarify, that's Claus from Sendmail Inc.
Noel Butler put forth on 6/16/2010 6:49 AM:
I will never use debian or its derivatives for its outdated crud, and I would rather not use RHEL because of its old but patched methods, gentoo and slackware are the only two serious "Linux" OS's that should ever be in a serious data centre, IMHO.
That's an interesting position/observation given that RHEL, SLES, and CentOS (RHEL derivative) have the largest datacenter footprint in the US by far. Across both oceans, mainly Europe and South America, SuSE rules pretty much everything, from what I've read.
All the numbers I've seen show Slackware and Gentoo at the very bottom of the charts, almost zero penetration. Debian has far more datacenter penetration than either of these.
-- Stan
On 2010-06-16 8:07 AM, Stan Hoeppner wrote:
That's an interesting position/observation given that RHEL, SLES, and CentOS (RHEL derivative) have the largest datacenter footprint in the US by far. Across both oceans, mainly Europe and South America, SuSE rules pretty much everything, from what I've read.
All the numbers I've seen show Slackware and Gentoo at the very bottom of the charts, almost zero penetration. Debian has far more datacenter penetration than either of these.
All thanks to those darned PHBs... ;)
--
Best regards,
Charles
On 16/06/2010 13:07, Stan Hoeppner wrote:
Noel Butler put forth on 6/16/2010 6:49 AM:
I will never use debian or its derivatives for its outdated crud, and I would rather not use RHEL because of its old but patched methods, gentoo and slackware are the only two serious "Linux" OS's that should ever be in a serious data centre, IMHO.
That's an interesting position/observation given that RHEL, SLES, and CentOS (RHEL derivative) have the largest datacenter footprint in the US by far. Across both oceans, mainly Europe and South America, SuSE rules pretty much everything, from what I've read.
All the numbers I've seen show Slackware and Gentoo at the very bottom of the charts, almost zero penetration. Debian has far more datacenter penetration than either of these.
Agreed - I'm a Gentoo user exclusively and would argue in favour of it's use under certain circumstances, but definitely it's for a niche market. If you want a product which competes headon with the OSX and Windows products then it's not gentoo, instead the RHEL/SLES (Ubuntu?) type systems are what suit best
I think I can make a case for either being "best", but to summarise the key features:
Gentoo packages... In fact it's a bone of contention that there is a second
- Rolling "stable" version.
- Packages updated on an ad-hoc basis
- Small regular updates vs massive OS updates
- Tendency to push new versions of packages to fix bugs rather than backports of bug fixes to older packages
- Has a "stable" slice which is well tested and evolves more slowly.
Its unusual for the stable package set to be internally inconsistent, ie two packages in stable having some serious bugs versus one another - Tracking "unstable" involves using less well tested packages. But note that there is still a *high* level of Q&A on the unstable
level of "unstable" which exists as a mess of repos just like with Debian/Redhat, where packages that don't yet meet core Q&A standards tend to hang out.
- Suits administrators with a strong linux skillset who want the option to build a customised infrastructure around a core packaging system and a fairly stable well tested set of packages
RHEL/SLES, etc package versions
- Favour picking a slice of packages and labelling them stable until the next OS release
- Favour backporting bug fixes to old packages rather than bumping
- Tends to prefer functionality and APIs to remain stable between OS releases
- Often semi-official backport repos available to offer new versions of software, but this author's opinion is that if you are looking to install some fairly recent software package it frequently descends into a case of adding unsupported ad-hoc repos, and/or building your own packages or source installs... For this author at least it's very easy to get stuck in "package hell" where bumping one package seems to require bumping many other packages to meet dependency requirements...
- Basically it's a big bang upgrade cycle which favours avoiding changing APIs and "stability" over offering the latest and greatest
- Binary updates often have a speed advantage over source packages
- One source of binaries should mean that systems all over the world look the same! Important if you are distributing some third party software binary!
So I think the package based approach of RHEL/SLES will dominate the distros in mainstream services, mainly because whilst it doesn't preclude administrators being skilled, it does seem to lower the bar and allow less skilled users to admin systems. Also the consistency of infrastructure is something which is easier to sign-off on than a source based architecture.
However, at least when I last looked, the Engine Yard (engineyard.com) was using Gentoo to deploy their fairly substantial hosting service machines... So at least one "larger" user is using a source based distro in the field.
If you are a fairly skilled Unix admin then I would definitely suggest you check-out a source based distro such as Gentoo - it really offers a lot of benefits and for those who can master it it actually has the potential to reduce the complexity of maintaining your systems... For everyone else stick with an RPM/DEB system - gentoo will just drive you nuts...
Cheers
Ed W
On 6/16/10 7:07 AM -0500 Stan Hoeppner wrote:
Noel Butler put forth on 6/16/2010 6:49 AM:
I will never use debian or its derivatives for its outdated crud, and I would rather not use RHEL because of its old but patched methods, gentoo and slackware are the only two serious "Linux" OS's that should ever be in a serious data centre, IMHO.
That's an interesting position/observation given that RHEL, SLES, and CentOS (RHEL derivative) have the largest datacenter footprint in the US by far. Across both oceans, mainly Europe and South America, SuSE rules pretty much everything, from what I've read.
All the numbers I've seen show Slackware and Gentoo at the very bottom of the charts, almost zero penetration. Debian has far more datacenter penetration than either of these.
Partly that's due to mindshare or just plain "what I learned in college".
But mostly it's because most software, by far, are internal applications. These are written to specific versions of system software and may even depend on specific bugs ... er, features. The more and bigger of these apps you have, the more you want your system to be "stable" and could care less about having the latest and greatest, modulo security issues.
re-sent , this never made it to the list, my anti spam system ate it :)
On Wed, 2010-06-16 at 07:07 -0500, Stan Hoeppner wrote:
That's an interesting position/observation given that RHEL, SLES, and CentOS (RHEL derivative) have the largest datacenter footprint in the US by far. Across both oceans, mainly Europe and South America, SuSE rules pretty much everything, from what I've read.
Dunno, I speak from my part of the world where I've been associated with over past twenty years It doesn't surprise me that RedHat have a larger footprint in U.S and SuSE in EU, being Inc there and having support, This pretty much means D.C's can employ clueless or first year in the work force 18 year old's to look after the equipment. (not attacking that age group, I've met some that run rings around some doing this for 30 odd years or more
All the numbers I've seen show Slackware and Gentoo at the very bottom of the charts, almost zero penetration. Debian has far more datacenter penetration
Don't know where you get those figures from, I hope your not going to try use distrowatch as example :)
Though debian, like RH, have a reasonable userbase, I've found again mostly clueless drones who forever flood lists asking how to do A, B or C many, if not most debian admins are also scared shitless to use source code of anything, some I've come across were "shocked" to learn that source code is available, there little world doesn't evolve outside of "DEB", I gave out 7 updates for SM project plugin a couple months ago ( as the plugin version is still in beta), one guy replied complaining it was broken package, guess why, because DPKG couldnt install it - I, ROFLMFAO! and this person worked for a multi-national company in the U.S.
it comes down to how much you care about your customers needs, this isnt the '80s where using the latest and greatest was generally shied upon, I've used it exclusively for key daemons since about the mid nineties, all without a single problem.
I do have issue with auto package updates, as an employer in the mid nineties was bitten by a botched RH update, that rendered several servers useless. I guess I was also lucky not to be fried by the infamous debian openssl destructive patch they pushed out couple years ago, which also affected other OS's if their cert was generated on a debian system, using the closest to how the software dev team release their software, and not butchering/distro-ising it and so, means, more often than not, fewer problems.
Now, this is so far OT if you wish to continue with this discussion, please reply directly, there have been too many threads lately on this list generate into non-dovecot related noise factors which may impact on the genuine needy.
Charles Marcus put forth on 6/16/2010 6:29 AM:
On 2010-06-16 1:15 AM, Stan Hoeppner wrote:
Charles Marcus put forth on 6/15/2010 12:44 PM:
Waiting almost always keeps me from any major bugs from new packages (one exception was a minor update to mailman that changed directory locations), and still lets me stay up to date with the latest stable releases.
I waited "forever" to get hold of 1.2.10 in the form of the backport for Debian Lenny, which was the first 1.2.x backport available IIRC (I hate installing apps from source for many reasons).
Again - this is why I have never been inclined to even give debian a try... with gentoo, with a very few minor exceptions, the most I've ever had to wait was a few weeks...
I run Debian Stable. If I were to run Debian Testing I'd have much more up to date packages available. Call me conservative I guess. On a positive note, Debian Stable, as far behind as it is, has _much_ newer packages than RHEL and some other "stable" or "enterprise" distros.
Once I installed it I almost immediately found problems with performance. I reported the symptoms here, and within a day or two Timo identified the cause relating to mbox processing and fixed it. It took a couple/three weeks IIRC before the 1.2.11 backport with this fix was available. I installed it and it fixed my problems instantly.
What does this have to do with sticking with 'really stable' 1.1.x? You do realize that 1.1.x had any number of similar situations with certain releases, right?
The point is that waiting a few days or weeks after a release for the other guinea pigs to find the problems doesn't always guarantee you won't run into a bug, as I describe above. 1.2.10 had been out for quite some time, months IIRC, before Debian had a Lenny backport of 1.2.10 available which, I installed as soon as it hit the FTP. I found problems and reported them. This was many weeks or months after the general release of 1.2.10 IIRC.
We are not in disagreement, we just apparently do things differently. I prefer the 'rolling release' type of system that always has *everything* reasonably up to date, and gentoo gives me that.
I actually would prefer a rolling release system for some things. The problem as I see it with Debian is they support so darn many architectures the sheer weight of compiling all the packages and what not prevents them from doing anything stable quickly. There may be other causes for this as well. They actually put up a poll recently asking users what release cycle they prefer. The options were from 6 months to over 2 years, but no rolling release option. The only mid life updates Stable gets are security updates to current package revs. If you want newer packages for a stable release, the only options are backports or installing from source. Sometimes you can directly install a package from Testing, but it's a crap shoot, as you have to be running a similar kernel rev, and more importantly, you have to have the same rev of gcc and many libraries. This is one of the reasons backports stays pretty busy. Debian Stable has been averaging about 2 years between releases. Two years is a _LONG_ damn time to wait for a new rev of say, Dovecot. However, IIRC, Dovecot 2.0 is in Debian Testing. Testing should turn to Stable within the next 6 months or so, as the current Stable (Lenny) was released in Jan 2009. Jan 2011 will be the two year mark.
What's the ETA for the first stable release of Dovecot 2.0? Less than 6 months?
-- Stan
On 2010-06-16 7:52 AM, Stan Hoeppner wrote:
The point is that waiting a few days or weeks after a release for the other guinea pigs to find the problems doesn't always guarantee you won't run into a bug, as I describe above.
True, of course... I think babies should be required to have 'There are *no* guarantees in life, with one possible exception: you will die some day.' stamped on their foreheads so they'd see it every time they looked in a mirror. ;)
1.2.10 had been out for quite some time, months IIRC, before Debian had a Lenny backport of 1.2.10 available which, I installed as soon as it hit the FTP. I found problems and reported them. This was many weeks or months after the general release of 1.2.10 IIRC.
Yes - iirc though, yours was a corner case for some reason?
I actually would prefer a rolling release system for some things. The problem as I see it with Debian is they support so darn many architectures the sheer weight of compiling all the packages and what not prevents them from doing anything stable quickly.
Gentoo supports just as many:
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Architecture_...
Debian Stable has been averaging about 2 years between releases. Two years is a _LONG_ damn time to wait for a new rev of say, Dovecot.
I know... imo, a formal process for nominating certain critical applications - like postfix, dovecot, etc - for upgrading to stable would be a good thing. How often does a postfix update require an update to gcc or other system libs?
What's the ETA for the first stable release of Dovecot 2.0? Less than 6 months?
Only Timo knows, but just from past experience, yeah, I'd say less...
--
Best regards,
Charles
Charles Marcus put forth on 6/16/2010 7:16 AM:
On 2010-06-16 7:52 AM, Stan Hoeppner wrote:
The point is that waiting a few days or weeks after a release for the other guinea pigs to find the problems doesn't always guarantee you won't run into a bug, as I describe above.
True, of course... I think babies should be required to have 'There are *no* guarantees in life, with one possible exception: you will die some day.' stamped on their foreheads so they'd see it every time they looked in a mirror. ;)
Haha. That would just make the shrinks rich.
1.2.10 had been out for quite some time, months IIRC, before Debian had a Lenny backport of 1.2.10 available which, I installed as soon as it hit the FTP. I found problems and reported them. This was many weeks or months after the general release of 1.2.10 IIRC.
Yes - iirc though, yours was a corner case for some reason?
Yes, as I stated, I believe it was a corner case. I do a bit of full text searching of very large mbox files (10k+ messages, 50MB). My Dovecot server is a rather old machine with dual 500 MHz CPUs, which are actually overkill and idle 99.99% of the time (which is why I've not bothered to upgrade the hardware but for disk). After I reported serious search slowdowns, Timo found some problems with the mbox parsing code that were causing something just shy of an infinite loop situation, IIRC. It was also causing one or two other issues with mbox systems, though I don't recall what they were. Most other OPs using mbox just didn't notice a slow down as they had plenty of excess CPU.
I actually would prefer a rolling release system for some things. The problem as I see it with Debian is they support so darn many architectures the sheer weight of compiling all the packages and what not prevents them from doing anything stable quickly.
Gentoo supports just as many:
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Architecture_...
Yes, but Gentoo isn't supplying binaries. The amount of project time/effort to get all those Debian binaries compiled and out the door is gargantuan compared to the Gentoo source model. My point was that building binaries is one of the reasons it takes Debian so long to get a new release out. AFAIK, Gentoo isn't shackled with this issue.
Debian Stable has been averaging about 2 years between releases. Two years is a _LONG_ damn time to wait for a new rev of say, Dovecot.
I know... imo, a formal process for nominating certain critical applications - like postfix, dovecot, etc - for upgrading to stable would be a good thing. How often does a postfix update require an update to gcc or other system libs?
Almost never. Right now this is done with the backports system, which I think is fine. They just need to be Johnny on the spot WRT getting the new releases into backports in a timely manner. With Dovecot they're actually not that bad. I can't really bitch about a few weeks lag time, all things considered. Replacing packages with newer versions in the Stable repos has its own set of management problems especially for OPs managing large numbers of servers. Say you bring up a new server, install all the packages you need, then copy over your current config. Then shit breaks because the new version of the software in the repos doesn't recognize old config files or formats. Something very similar to this happened going from dovecot 1.1.x to 1.2.x. Debian OPs aren't expecting those kind of changes to occur invisibly on the repos and would be thrown for a major loop in a situation like this. This is actually one of the selling points of Debian Stable, similar to RHEL, etc. Package consistency from release to retirement.
So, I can see both sides of the issue. As long as they can keep the backports up to date I'll be happy. :)
What's the ETA for the first stable release of Dovecot 2.0? Less than 6 months?
Only Timo knows, but just from past experience, yeah, I'd say less...
Well, I'd say there's a good chance then that Sqeeze may end up shipping with Dovecot 2.0 when it flips to Stable. Frankly I'm pretty happy with 1.2.11. Performance is now decent and I'm not wanting for any features that I know of.
-- Stan
On 2010-06-16 11:39 AM, Stan Hoeppner wrote:
Yes, but Gentoo isn't supplying binaries. The amount of project time/effort to get all those Debian binaries compiled and out the door is gargantuan compared to the Gentoo source model.
Ah, forgot about that... its amazing how you get used to the freedom of a source based system.
The biggest argument against source based installs is they take too long. On reasonably modern hardware it isn't much of an issue, and even on older hardware - I mean, really how often do you have to do the installation? Mine last for many years...
My point was that building binaries is one of the reasons it takes Debian so long to get a new release out. AFAIK, Gentoo isn't shackled with this issue.
Correct, it isn't, and with USE flags, it makes custom compiling (and recompiling if needs change) with support for *precisely* what you need extremely easy even for people like me... ;)
--
Best regards,
Charles
On Wed, 16 Jun 2010, Charles Marcus wrote:
On 2010-06-16 11:39 AM, Stan Hoeppner wrote:
Yes, but Gentoo isn't supplying binaries. The amount of project time/effort to get all those Debian binaries compiled and out the door is gargantuan compared to the Gentoo source model.
Ah, forgot about that... its amazing how you get used to the freedom of a source based system.
Yeah, I've been enjoying that with FreeBSD for a very long time. They have "packages" as well, but I never really used them - what are the chances that the maintainer and I both want the exact same compile-time options?
The biggest argument against source based installs is they take too long. On reasonably modern hardware it isn't much of an issue, and even on older hardware - I mean, really how often do you have to do the installation? Mine last for many years...
I do binary installs of the OS, source installs of the additional software, source based upgrades of the OS. I also get something that I haven't yet seen in the mainstream linux distros, which is a clear delineation between what's the "OS" and what's "added-on". If it's under /usr/local somewhere, it came from elsewhere. Otherwise, it's part of the OS. Makes upgrades simple, even if I'm moving /usr/local wholesale from one box to another - since I have a nice stable ABI and backwards compatibility, I can take a bunch of stuff built for say, FreeBSD 4.8 and run it on a new 8.0 box, then upgrade at my leisure.
My point was that building binaries is one of the reasons it takes Debian so long to get a new release out. AFAIK, Gentoo isn't shackled with this issue.
Correct, it isn't, and with USE flags, it makes custom compiling (and recompiling if needs change) with support for *precisely* what you need extremely easy even for people like me... ;)
FreeBSD supports much fewer architectures, but I know they still have dealt with issues trying to crank out packages for a few archs plus a few supported versions of the OS. I think Yahoo recently gave them a bunch of boxes to help with this, but yeah, when you start thinking about building not just what *you* might install, but every X11 app available, every window manager, etc. that's a pretty hefty chunk of cpu time, regardless of how modern your build cluster is.
And yeah, having either a config file or make flags to repeatedly build the software with the same options kicks ass. :)
Charles
--
Best regards,
Charles
Gentoo supports just as many:
http://en.wikipedia.org/wiki/Comparison_of_Linux_distributions#Architecture_...
Yes, but Gentoo isn't supplying binaries. The amount of project time/effort to get all those Debian binaries compiled and out the door is gargantuan compared to the Gentoo source model. My point was that building binaries is one of the reasons it takes Debian so long to get a new release out. AFAIK, Gentoo isn't shackled with this issue.
Hmm, not as much as you think. Actually you can kind of turn Redhat into Gentoo if instead of distributing the actual binaries, instead you distribute the SRPMS and let the user build the software locally... If we just hold that thought for a moment (and kick some holes in the idea...) we can see that we would still need to build the binaries to check that the SRPMS actually build correctly. And more importantly we need to build them all in random permutations to check that other packages work ok in conjunction with them!
Gentoo is somewhat more complicated than this example because a given "package" can usually build more or less functionality by enabling option flags (USE flags) and hence testing a package is stable really involves considering not just whether the whole system will build ok with (say) Dovecot installed, but also whether it will all build correctly with Dovecot installed, but with/without SSL support, with/without POP support, etc, etc
So, I think all of the packaging options all have a good deal of
complexity and all deal with it very well all things considered...
Definitely though Gentoo does not just release a new source package and
mark it stable without quite a number of binaries having been built from
that package...
(Just to cover the flip side of this - people also get over hung up about binaries not being provided by upstream. I have a lot of servers to manage due to excessive use of vservers as a virtualisation option - what I do is use a common set of configurations across servers (or at least a minimal set, say one for web servers, another for mail servers) and then build packages only once and hence most servers simply pull down binaries. This means I can test on a single machine and then once that's verified as ok the other machines pull binaries down, much like a Redhat/Debian machine does)
Debian Stable has been averaging about 2 years between releases. Two years is a _LONG_ damn time to wait for a new rev of say, Dovecot.
Do you not think this is really a function of two main reasons:
Finite developers. Manpower is limited
Preference for correctness over "freshness"
Point 2) means that they tend not to call something stable until there is no reported bug at all filed against it with respect to any other stable package on any architecture? This seems to cause a lot of non trivial packages to wait a long time before being bumped simply due to the number of possible dependencies and the effect of point 1) above?
I'm not sure it's "wrong", it's just not always what YOU want..? I know it doesn't suit me, but then again I'm just one data point...
is fine. They just need to be Johnny on the spot WRT getting the new releases into backports in a timely manner. With Dovecot they're actually not that bad.
Seems to my uneducated eye that a lot of users of these "stability over freshness" distros (ie Debian/Redhat) actually seem to want "freshness" for large chunks of their system and end up patching in a bunch of extra repos which then in a way seem kind of counter to the ethos of the distro they chose in the first place?
It seems like a compromise would be for the likes of Debian/Redhat to have a clear split between "Apps" and "System" and offer the option to stay "fresh but tested" on the apps repo, but "stable and mouldy" on the System repo?
Anyway, Linux is all about choice so it's great all these options exist. I think it would be even better if we could try and get more of the distros to pull in the same direction mind... but it seems to be slowly getting there. Those who have strong unix kung-foo, definitely checkout a source based distro such as Gentoo, it's not really useful to those who just want a point and click system (most of the world), but for those who can dig a little deeper it's an excellent and often overlooked option!
Good luck
Ed W
On 2010-06-16 1:18 PM, Ed W wrote:
It seems like a compromise would be for the likes of Debian/Redhat to have a clear split between "Apps" and "System" and offer the option to stay "fresh but tested" on the apps repo, but "stable and mouldy" on the System repo?
Exactly... even gentoo could benefit from this concept, although I'm not sure how hard it would be to implement...
--
Best regards,
Charles
On 16/06/2010 19:14, Charles Marcus wrote:
On 2010-06-16 1:18 PM, Ed W wrote:
It seems like a compromise would be for the likes of Debian/Redhat to have a clear split between "Apps" and "System" and offer the option to stay "fresh but tested" on the apps repo, but "stable and mouldy" on the System repo?
Exactly... even gentoo could benefit from this concept, although I'm not sure how hard it would be to implement...
Hmm, well system packages are those defined in your profile. I guess at the simplest you could simply use a wrapper so that "emerge world" runs with a different ACCEPT_KEYWORDS to "emerge system"?
Note that if you haven't experimented with running your own custom profiles then I would highly recommend it! I start with the generic hardened profiles and then create my own tree in /usr/local/portage/profiles and then have sub profiles for different server types, eg mail / mysql / www_nginx / www_apache / etc
This allows me to centralise my USE flags and required software versions. I then use copious linux-vservers to run apps at a very granular level (pretty much each web site gets it's own vserver) and it's highly memory efficient and very simple to update. The host server runs very few apps and I can easily bump services to a different physical server very easily. Figure out how to sync the storage between nodes and assuming you have that sorted then high availability becomes fairly straightforward case of simply moving the IP addresses between nodes and bringing up the vservers on the node of your choice - moderately straightforward as HA goes...
linux-vserver comes with a bunch of wrappers around emerge that allow you to easily update lots of servers quite quickly. Very neat. I emerge with "-k --new-use" which forces a build of a package if the use flags don't match, but otherwise uses the available binary
Cheers
Ed W
Stan Hoeppner wrote:
I run Debian Stable. If I were to run Debian Testing I'd have much more up to date packages available. Call me conservative I guess. On a positive note, Debian Stable, as far behind as it is, has _much_ newer packages than RHEL and some other "stable" or "enterprise" distros.
I have given up with Debian and now use Ubuntu.
All the lovelyness of Debian but without having to hand-roll umpteen packages from source just to get something that isn't 5 years out of date.
I still have to hand-roll a handful of packages, but it is only a handful rather than umpteen.
Bill
Stan Hoeppner wrote:
I run Debian Stable. If I were to run Debian Testing I'd have much more up to date packages available. Call me conservative I guess. On a positive note, Debian Stable, as far behind as it is, has _much_ newer packages than RHEL and some other "stable" or "enterprise" distros.
I have given up with Debian and now use Ubuntu.
All the lovelyness of Debian but without having to hand-roll umpteen packages from source just to get something that isn't 5 years out of date.
I still have to hand-roll a handful of packages, but it is only a handful rather than umpteen.
Bill
Stan Hoeppner wrote:
I run Debian Stable. If I were to run Debian Testing I'd have much more up to date packages available. Call me conservative I guess. On a positive note, Debian Stable, as far behind as it is, has _much_ newer packages than RHEL and some other "stable" or "enterprise" distros.
I have given up with Debian and now use Ubuntu.
All the lovelyness of Debian but without having to hand-roll umpteen packages from source just to get something that isn't 5 years out of date.
I still have to hand-roll a handful of packages, but it is only a handful rather than umpteen.
Bill
On Mon, Jun 14, 2010 at 07:43, Veiko Kukk veiko.kukk@ekp.ee wrote:
Hello,
I have been using successfully Dovecot 1.1.x for about a year now. It has been very stable. Now I'm uprading that same system to newer and more powerful hardware and I was wondering whether it is good idea or not to switch to Dovecot 1.2.x series. Could anybody direct me to feature comparision document or explain here main differences betweeen thos two branches?
Where the option to upgrade to the latest version (not just a newer version), it is almost always the best choice. Advantages of the latest version include not hearing those words "it is already fixed in the latest version".
If you need to stay back at an older version, you should already know why you need to do so. In my case, I have done so because the first round of servers were being quickly deployed based on Ubuntu 9.10, which is known to not always be friendly to building things from source for which it also has packages. The next round will be more slowly built, based on Slackware 13.1 (or so), and use the latest versions of all major software in use, built from developer released source.
participants (15)
-
Arto Saraniva
-
Charles Marcus
-
Charles Sprickman
-
Ed W
-
Eduardo M KALINOWSKI
-
Eray Aslan
-
Eric Rostetter
-
Eric Shubert
-
Frank Cusack
-
Jerry
-
Noel Butler
-
Phil Howard
-
Stan Hoeppner
-
Veiko Kukk
-
William Blunn