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 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

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

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'

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 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

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

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

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

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.

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 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

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.

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

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

...

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:

1. Finite developers. Manpower is limited

2. 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 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